Re: [dpdk-dev] tools brainstorming

[Bruce Richardson <bruce.richardson@intel.com>]

On Tue, Apr 14, 2015 at 04:47:47PM +0200, Thomas Monjalon wrote:
> 2015-04-14 10:38, Neil Horman:
> > On Tue, Apr 14, 2015 at 03:21:53PM +0100, Bruce Richardson wrote:
> > > On Wed, Apr 08, 2015 at 07:54:40PM +0000, Butler, Siobhan A wrote:
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > > > Sent: Wednesday, April 8, 2015 5:16 PM
> > > > > To: Wiles, Keith; Butler, Siobhan A
> > > > > Cc: dev@dpdk.org
> > > > > Subject: Re: [dpdk-dev] tools brainstorming
> > > > > 
> > > > > 2015-04-08 15:53, Wiles, Keith:
> > > > > > One of the biggest problems with any style is helping the developer
> > > > > > maintain the style. Using some tool does help and I have used astyle
> > > > > > before, not bad code formatter. Here is a few that seem to be reasonable.
> > > > > >
> > > > > > http://astyle.sourceforge.net/
> > > > > >
> > > > > > http://uncrustify.sourceforge.net/
> > > > > >
> > > > > > http://sourceforge.net/projects/gcgreatcode/
> > > > > 
> > > > > I'm not sure it's a good idea to convert the codebase automatically.
> > > > > The coding style must be a reference for new patches and they must be
> > > > > automatically checked with a dedicated checkpatch tool.
> > > > > By forbidding patches which don't comply, the codebase will be naturally
> > > > > converted over time.
> > > > > 
> > > > > I didn't review this proposal yet.
> > > > > My first comment is that it's too long to read :) When a consensus is done, it
> > > > > must be added with a patch with custom checkpatch addition.
> > > > Thanks Thomas, agreed it is a bit of a novel :)- I will refactor with the comments supplied so far and post a fresh version tomorrow.
> > > > Siobhan 
> > > > 
> > > 
> > > Just wondering here, are we looking to codify what the current predominant coding
> > > style in DPDK *is* or what it *should be*? 
> > > 
> > > There has been some good discussion on a variety of areas, but if we focus on
> > > initially codifying what's there now, some issues become easier to resolve  -
> > > e.g. discussion of commenting style, since only C89 comments are allowed right now.
> > > 
> > 
> > This is an excellent question.  I think the answer is we should make the style
> > what we want it to be. That said, when there is a significant discrepancy behind
> > what is wanted and what is, we need to stop and ask ourselves why that exists,
> > and what our reasoning is for wanting the change.
> 
> Yes the question must be asked.
> I think the main goal is to have a consistent style.
> As there is already a lot of code with implicit guidelines,
> it's simpler to make them official.
> 
Sounds good to me. Let's document what we have, then evolve it as necessary. :-)