Re: [9fans] Plan 9/plan9port coding conventions

[Comeau At9Fans <comeauat9fans@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4954 bytes --]

On Wed, Jan 11, 2012 at 1:41 PM, <smiley@icebubble.org> wrote:

> As readers may remember from a previous thread, I have historically
> been, well, less than enamored with some aspects of the coding style
> used in Plan 9/plan9port.  Now that I'm getting into development, I'd
> like to know what coding conventions the Plan 9 community endorses.  I
> have read the Plan 9 compiler paper, and understand the conventions
> described in it.  While conventions such as composing variable names
> using lower case letters and no underscores do irk me a bit, I can live
> with them---because those are the conventions that the community has
> adopted.  However, there are a number of stylistic features in Plan
> 9/p9p code which I've noticed (which AREN'T discussed in the compiler
> paper) and I'm wondering whether they're intentional conventions or not.
>
> (1) For example, P9 code tends to use variable names like "i" and "j",
> where I would typically use self-documenting variable names like "row"
> and "col".  Variable names like "row" and "col" are much easier to
> search for (i.e., with a right-click), too.  Names like "i" and "j"
> (which occur in many identifiers) will generate many false positives.
>

Most stylistic things have both pros and cons.  So for instance, you are
correct that i and j *are* hard to grep for.  And you are also correct that
one should normally strive for so-called self-documenting names.  However,
with that in mind, row and col specifically have their own limitations (for
instance, they don't have much more meaning than i and j and in some ways
can be considered worse).  So, as in many disciplines, we're left with a
bunch of engineering compromises to wiggle through.  Some of the
compromises will be obvious flaws and mistakes, and then so must be dealt
with accordingly (resistance or learned helplessness :).


> (2) In functions, variables are often declared together in one
> paragraph, and then, later, initialized in another paragraph, as in:
>
>  int i;
>  char *s;
>
>  /* stuff */
>
>  i = 0;
>  s = nil;
>
> rather than something like:
>
>  int i = 0;
>  char *s = nil;
>

Neither of these is necessarily superior to the other, or other forms.


> (3) Lots of global variables are used, without any distinguishing
> syntax, i.e. "char *f".  I prefer to designate global variables with
> something like a leading underscore, i.e. "char *_filename".
>

I usually consider this to be putting a set of bad choices into a pot, and
picking from them at will.  It also tends to yield exactly the competing
styles you're bumping into.

(4) In ARGBEGIN/ARGEND blocks, boolean switches are often set using the
> "++" operator rather than "|= 1", i.e.:
>
>  case 'v':
>    verbose++;
>  case 'x':
>    x++;
>
> as opposed to:
>
>  case 'v':
>    verbose++;
>  case 'x':
>    x |= 1;
>

Again, we have language limitations yielding multiple acceptable'ish
compromises of 6 of one and 1/2 dozen of another.


> (5) P9 code tends to repeat constructs such as "argv[i]" over and over
> throughout the code, like:
>
>  for(i = 0; i < argc; i++){
>    somestuff(argv[i]);
>    otherstuff(argv[i]);
>  }
>
> whereas I would typically use something like:
>
>  int argnum;
>  char *argstr;
>
>  for(argnum = 0; argnum < argc; argnum++){
>    argstr = argv[argnum];
>    somestuff(argstr);
>    otherstuff(argstr);
>  }
>

This one's a mixed bag again.  Used to be you may have had to do something
like this in the name of efficiency (of the executable code).  There can be
times to prefer the latter, but that said, argstr has it's own issues, so
does creating another variable when just saying what something is in the
first place can be its best name, but repeating complicated dimensions,
struct membership selections, etc. can get messy too.  So....


> Are these practices official/unofficial Plan 9 coding conventions?  Are
> they used for performance purposes?  Are they just poor style?  Or has
> this kind of style been used for so long that it's BECOME Plan 9's style
> of choice?  Also, is it considered polite or acceptable coding practice
> to alter the style of code written by other contributors?  I don't want
> to step on anybody's toes by "fixing" style which other Plan 9
> developers consider to be "Plan 9" style coding conventions.
>

Be careful when delving into "poor".  Some loose thoughts:  Beauty is in
the eye of the beholder.  There often is not a best, just engineering
compromises.  This does not mean one will not run across something horrid.
 Continue to question all.  Many things are often at odds.

--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[-- Attachment #2: Type: text/html, Size: 6482 bytes --]