Option d)  Make minimal coding standard changes that can be 100% supported by 
option a.*

*) Greg suggested this in the bar at NuttX2019 - caveat it was in the BAR!

No one should be held accountable for what the say in a bar 8-)

A lot depends on the nature of the coding standard change.  If you make small coding standard changes, the existing indent.sh is nearly perfect (nearly).  As a general principle, I think that the coding standard should not change to match to a tool.  Changing code to match a tool is a little bothersome as a concept because it is the "tag wagging the dog."

The Inviolables.txt addresses this:

   o Strict conformance to the NuttX coding style.  No "revolutionary" 
   changes to the coding standard (but perhaps some "evolutionary" 
   changes).

That is open to some interpretation.  I'm not sure if fixing the behavior of a tool by changing the coding standard is correctly "evolutionary" or not.  it is more or a kludge.  The Inviolables also say:

   o Expediency is not a justification for violating the coding standard.

Together, I would take that to mean that we should consider changing the coding standard only if we have exhausted all other possibilities.  If is is difficult to make a pretty printer behave properly, then that is not enough.  It must be impossible.  "Short cuts" is the enemy in the Inviolables.txt

I would add that one person cannot change the Inviolables or any NuttX standards.  That really must be a vote of the PPMC.  And, I think like a constitutional change or an impeachment, it probably should require more than a simple majority to change any standard.  If a super-majority is in favor of any change, that the other just need to accept it.

Greg




Reply via email to