From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <86vcoif5f4.fsf@cmarib.ramside> References: <86vcoif5f4.fsf@cmarib.ramside> Date: Thu, 12 Jan 2012 10:18:38 -0500 Message-ID: From: Comeau At9Fans To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=20cf3010eb69488efb04b65643a7 Subject: Re: [9fans] Plan 9/plan9port coding conventions Topicbox-Message-UUID: 58d845cc-ead7-11e9-9d60-3106f5b1d025 --20cf3010eb69488efb04b65643a7 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 11, 2012 at 1:41 PM, 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? --20cf3010eb69488efb04b65643a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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. =A0Now that I'm getting into development, I&#= 39;d
like to know what coding conventions the Plan 9 community endorses. =A0I have read the Plan 9 compiler paper, and understand the conventions
described in it. =A0While 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. =A0However, there are a number of stylistic features in Plan
9/p9p code which I've noticed (which AREN'T discussed in the compil= er
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&= quot;
and "col". =A0Variable names like "row" and "col&q= uot; are much easier to
search for (i.e., with a right-click), too. =A0Names like "i" and= "j"
(which occur in many identifiers) will generate many false positives.

Most stylistic things have both pros and con= s. =A0So for instance, you are correct that=A0i and j *are* hard to grep fo= r. =A0And you are also correct that one should normally strive for so-calle= d self-documenting names. =A0However, with that in mind, row and col specif= ically have their own limitations (for instance, they don't have much m= ore meaning than i and j and in some ways can be considered worse). =A0So, = as in many disciplines, we're left with a bunch of engineering compromi= ses to wiggle through. =A0Some of the compromises will be obvious flaws and= mistakes, and then so must be dealt with accordingly (resistance or learne= d helplessness :).
=A0
(2) In functions, variables ar= e often declared together in one
paragraph, and then, later, initialized in another paragraph, as in:

=A0int i;
=A0char *s;

=A0/* stuff */

=A0i =3D 0;
=A0s =3D nil;

rather than something like:

=A0int i =3D 0;
=A0char *s =3D nil;

Neither of these i= s necessarily superior to the other, or other forms.
=A0
(3) Lots of global variables are used, without any distinguishing
syntax, i.e. "char *f". =A0I prefer to designate global variables= with
something like a leading underscore, i.e. "char *_filename".
<= /blockquote>

I usually consider this to be putting a set= of bad choices into a pot, and picking from them at will. =A0It 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 "|=3D 1", i.e.:

=A0case 'v':
=A0 =A0verbose++;
=A0case 'x':
=A0 =A0x++;

as opposed to:

=A0case 'v':
=A0 =A0verbose++;
=A0case 'x':
=A0 =A0x |=3D 1;

Again, we have langua= ge limitations yielding multiple acceptable'ish compromises of 6 of one= and 1/2 dozen of another.
=A0
Are these practices official/u= nofficial Plan 9 coding conventions? =A0Are
they used for performance purposes? =A0Are they just poor style? =A0Or has<= br> this kind of style been used for so long that it's BECOME Plan 9's = style
of choice? =A0Also, is it considered polite or acceptable coding practice to alter the style of code written by other contributors? =A0I don't wa= nt
to step on anybody's toes by "fixing" style which other Plan = 9
developers consider to be "Plan 9" style coding conventions.
<= /blockquote>

Be careful when delving into "poor&qu= ot;. =A0Some loose thoughts: =A0Beauty is in the eye of the beholder. =A0Th= ere often is not a best, just engineering compromises. =A0This does not mea= n one will not run across something horrid. =A0Continue to question all. = =A0Many things are often at odds.

--
Greg Comeau / 4.3.10.1 with C++0xisms now in bet= a!
Comeau C/C++ ONLINE =3D=3D> =A0 =A0 http://www.comeaucomputing.c= om/tryitout
World Class Compilers: =A0Breathtaking C++, Amazing C99, Fabulous C90.=
Comeau C/C++ with Dinkumware's Libraries... Have you tried i= t?

--20cf3010eb69488efb04b65643a7--