[moved from priv...@nuttx.apache.org]
Hi, Xiao Xiang and Haitao Liu
Haitao is preparing a script for style check, the feature include:
1.Auto build nxstyle
2.Improve nxstyle to check the partial file for supporting patch like file
3.Input can be the source files, patch file or commit id
I mentioned that I had two things I planned to do for nxstyle.c too.
Perhaps Haitao would like to take on these changes too?
1. Derive maximum line width from block comments. Ref:
https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#fileorganization
* The Maximum line width should be the same as the width of the file
section block comment, by default the last asterisk '*' lies on
column 78, but wider lines are okay too, as long as things are
scaled corrected. Instead of the line width being a hardcoded 78 or
specified the command line, nxstyle would parse the entire file,
look at the block comments, find the column of the last '*' The
line width is that colument + 1;
* Then also verify that every block comment in the file is the same width
* Perhaps the -m argument could change to a amount that you will
tolerate extending into the right margin. So the block comment with
is 78, then -m 8 would allow lines to extend to 86. That is better
than a hard-coded 86 because the line width will vary with file
content. For some register definition files, the line width may be
120 or so. In that case -m 8 would allow the line to extend to 128.
2. Verify that file section block comments are present.
* Add an enumeration value that indicates every block comment type.
See
https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#cfilestructure
and
https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#hfilestructure
* Currently logic detects only the presence of "* Private Functions"
and "* Private Functions". Add logic to detect all other the block
comment types as well.
* Add a global variable to indicate which code block we are currently
in. Each time a file section block comment is found, set the global
variable.
* The if '# define" is encountered outside of the "* Pre-processor
Definitions" file section, emit an error
* If '# include" is encountered outside of the "* Included Files"
section, emit an error.
* This logic could eventually be extended to assure that all static
functions are defined in the "* Private Functions" section, all
global functions are defined in the "* Public Functions section",
all static data definitions appear in the "* Private Data" section,
and all global data definitions appear in the "* Public data
definitions."
* We could also enable special parsing depending on the section. That
is already done for the Public/Private Functions. But we could, for
example also verify that variables defined at global scope start
with "g-"
Let me know. I was planning to do these things, but if Haitao Liu is
interested, he can take over full responsibility for nxstyle.c.
Greg
