[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150725125146.4R6EA.19944.imail@fed1rmwml301>
Date: Sat, 25 Jul 2015 12:51:46 -0400
From: <jfoug@....net>
To: john-dev@...ts.openwall.com
Cc: magnum <john.magnum@...hmail.com>
Subject: Re: Coding Style
---- magnum <john.magnum@...hmail.com> wrote:
> On 2015-07-25 15:05, Kai Zhao wrote:
> > Chapter 6: Functions
>
> Our code style should not be a programming tutorial. IMHO drop all of
> chapter 6.
I disagree with removing 6.4 That is a style that can add a lot of information (but can be misleading if the source changes but the header does not get maintained....). 6.4 is actually a style, not must a programming tut.
> > Chapter 7: Centralized exiting of functions
>
> Same here.
This one can probably be dropped. We have enough auto bug finding tools now (mem leaks, etc), that after someone gets their hand slapped once or twice, then will learn the power of the goto for cleanup. Most of the valid()/salt() are already written this way if they allocate temp buffers.
But again, this is a style. The other 'style' is to cleanup and return at every check. It does not leak, but looks like crap. I am sort of for leaving this in, as an expectation of what is expected.
> > Chapter 8: Commenting
> >
> > 8.1 C89 style and C99 style
> >
> > John core and Linux style for comments is the C89 /* ... */
>
> I'm not overly happy about mandating this in Jumbo.
Nor am I.
> > 8.2 Comment content
>
> Our code style should not be a programming tutorial. IMHO drop this.
There are many times where a comment telling what are actually doing, if some code has used some optimization tricks which by themselves are not instantly apparent. Yes, over-commenting 'can' be a problem, but it has also saved my butt many times, when dealing with complex code written years ago. I do understand why this was listed. There is some code that is so verbose with comments that it is almost impossible to follow.
But like magnum has mentioned, this is not a programming tut, so this may not fit into a style guide.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
