Hi Xiang,
-----Original Message-----
From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
Sent: Tuesday, January 07, 2020 6:30 PM
To: dev@nuttx.apache.org
Subject: Re: Working Effectively (was Point of Order)
David, why you think this tool promote the violation?
[DBS]
May be I do not understand what the -p and -c options do?
"no new code" All lines in the file or the lines that were changed in the
file?
If it is the latter, then refer the this:
o Strict conformance to the NuttX coding style. No "revolutionary"
changes to the coding standard (but perhaps some "evolutionary"
changes).
o Personal or organizational preference is not a justification for a
coding style change.
o Nothing can come into NuttX that does not follow the coding standard.
o Expediency is not a justification for violating the coding standard.
With -p or -c option, we can ensure no new code violate the coding style.
With -f option, we can review and correct the current code base.
The jenkins job can select one option base on the workflow definition,
the tool self hasn't any preference.
Base on your measurement:
https://github.com/apache/incubator-nuttx/pull/12
4043 files doesn't confirm the coding standard, how about each
committer(candidate) take several folders to fix the style issue?
[DBS] Yes when there is a documented set of work instructions (The commands
and steps and repos to be used)
David
On Wed, Jan 8, 2020 at 12:40 AM David Sidrane <david.sidr...@nscdg.com>
wrote:
>
> +1
>
> Adding a tool that promotes violating the INVIOLABLES.txt on several
> aspect
> (expedience and non conformant code into the repo) feels like a very bad
> choice.
>
> How is this being justified?
>
> David
>
>
> -----Original Message-----
> From: Alin Jerpelea [mailto:jerpe...@gmail.com]
> Sent: Tuesday, January 07, 2020 4:18 AM
> To: dev@nuttx.apache.org
> Subject: Re: Working Effectively (was Point of Order)
>
> I think that we should update all code with nxstyle then we start with a
> clean code on which patches will be checked
>
> Alin
>
> On Tue, Dec 31, 2019 at 3:42 PM Haitao Liu <liugu...@gmail.com> wrote:
>
> > Greg, I'll finish the nxstyle & check script these days firstly and
> > then
> > take time to handle the two issues you mentioned if allowed. I wish I
> > could
> > be competent to take over full responsibility for nxstyle.c.
> >
> > Gregory Nutt <spudan...@gmail.com> 于2019年12月30日周一 下午11:31写道：
> >
> > > [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
> > >
> > >
> > >
> > >
> > >
> >
