Now I remember, David was proposing a C beautifier to be used in the
work flow. I cannot find that one right now.
Related:
Gregory Nutt <spudan...@gmail.com>
Subject Re: [DISCUSS - NuttX Workflow]
Date Wed, 18 Dec 2019 13:36:24 GMT
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
