[coreboot] Proposal for new "Commenting" wiki text

Paul Menzel paulepanter at users.sourceforge.net
Sun Jan 29 09:51:30 CET 2017


Dear Nico,


Thank you for taking this up again.


Am Samstag, den 28.01.2017, 15:00 +0100 schrieb Nico Huber:
> 
> sorry to revive this old, stale topic. I got stalled by a request to
> ensure the comment style with a script. Now, that I had a look at
> checkpatch.pl, I don't think this could be done easily without risking
> many false positives.
> 
> So I'm again asking to commit my proposal below. I've incorporated the
> comments from Martin.

Just to be clear, also for the proposal below, the style can’t be
checked, right?

> Even if it's not going to be my preferred style, I would really appre-
> ciate it if we could agree on one style.
> 
> Nico
> 
> > == Commenting ==
> > 
> > Comments are good, but there is also a danger of over-commenting. NEVER
> > try to explain HOW your code works in a comment: it's much better to
> > write the code so that the _working_ is obvious, and it's a waste of
> > time to explain badly written code.
> > 
> > Generally, you want your comments to tell WHAT your code does, not HOW.
> > Also, try to avoid complex comments inside a function body: if the
> > function is so complex that you need to separately comment parts of it,
> > you should probably go back to chapter 6 for a while.  You can make
> > small comments to note or warn about something particularly clever (or
> > ugly), but try to avoid excess.  Instead, put the comments at the head
> > of the function, telling people what it does, and possibly WHY it does
> > it.
> > 
> > coreboot style for comments is the C89 "/* ... */" style. You may also
> > use C99-style "// ..." comments.

Could we change that, C89 style comments are preferred, and add a note about consistency?

> … You may also use C99 style "// …" comments, if it’s beneficial.
> Also, the commenting should be consistent in one file.

Or is that wishful thinking, and both style will always be mixed?

> > The preferred style for concise multi-line comments that explain a
> > single piece of code is:

Please, emphasize *concise*, or elaborate right away with *i. e., one
paragraph*

> > 
> >  	/* This is the preferred style for
> >  	   two or three line comments that
> >  	   avoids excessive blank lines. */
> > 
> > Note that there shouldn't be leading asterisks on new lines in the
> > concise style.
> > 
> > The preferred style for long multi-line comments is:

Please emphasize *long*.

> >  	/*
> >  	 * This is the preferred style for multi-line
> >  	 * comments in the coreboot source code.
> >  	 *
> >  	 * Description: A column of asterisks on the left side,
> >  	 * with beginning and ending almost-blank lines.
> >  	 */
> > 
> > Some rules of thumb to decide which style to use:
> > * If you are commenting a whole function (indentation level 0) or
> >   something high level (indentation level 1), use the long style.
> > * If you want to explain a single piece of code and your comment
> >   doesn't span multiple paragraphs, use the concise style.
> > * Otherwise you might want to ask yourself why what you're going to
> >   explain doesn't deserve an own function.
> > 
> > It's also important to comment data, whether they are basic types or
> > derived types.  To this end, use just one data declaration per line (no
> > commas for multiple data declarations).  This leaves you room for a
> > small comment on each item, explaining its use.
> > 
> > If the author has reasonable arguments for breaking the recommended
> > style guide to improve readability, others should be respectful of those
> > differences.

Nico, thank you again.


Thanks,

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20170129/c9a44dd0/attachment.asc>


More information about the coreboot mailing list