> Any ideas? What's the customary way to do this?
move your changes to a fresh clone of the repository and submit from
there without running ./INSTALL.
smi...@icebubble.org writes:
> used in Plan 9/plan9port. Now that I'm getting into development, I'd
Well, I've been hacking on P9P for a bit, rolled up a patch, and noticed
that the patch contains edits to the shebang (#!) lines for the shell
scripts in the development tree. I presume they're t
> Also, notations like Hungarian are usually problematic (http://programmers.=
> stackexchange.com/questions/102689/what-is-the-benefit-of-not-using-hungari=
> an-notation) instead of beneficial.
I don't ever use Hungarian notation myself, but in its defense I would
say that there is some merit to
I haven't developed anything for Plan 9 yet but these are my thoughts.
IMHO there's nothing wrong with using i and j as names for local variables with
a short life. If a function is as short as it normally should be, you will
generally search for functions instead of variable names. And function
2012/1/11 :
>
> (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"
i was providing the example to what John was pointing out about the
futility of including type information in identifiers when there isn't
an enforcement mechanism. in this case, presumably the variable named
pszBesmirchesAllHungariansEverywhereNotation is a 'pointer to zero
terminated string ...'
> style(6) deals with some of your questions.
Since nobody mentioned it yet,
Besides style(6) you may want to read "Notes on Programming in C", Rob
Pike, 1989.
quans...@quanstro.net (erik quanstrom) writes:
> On Wed Jan 11 20:34:39 EST 2012, skip.tavakkol...@gmail.com wrote:
>> by way of an example:
>>
>> int pszBesmirchHungeriansNotation;
>
> who let the camel's nose in the tent?
The Go people.
--
Christian Neukirchenhttp://chneukirchen.org
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 P
On Wed Jan 11 20:34:39 EST 2012, skip.tavakkol...@gmail.com wrote:
> by way of an example:
>
> int pszBesmirchHungeriansNotation;
who let the camel's nose in the tent?
- erik
by way of an example:
int pszBesmirchHungeriansNotation;
-Skip
On Wed, Jan 11, 2012 at 3:57 PM, John Stalker wrote:
> One thing to remember about descriptive identifiers is that the
> compiler doesn't check whether the descriptions are accurate or
> not. Often they were when the code was first
One thing to remember about descriptive identifiers is that the
compiler doesn't check whether the descriptions are accurate or
not. Often they were when the code was first written, but become
less so over time. Sometimes they were never accurate. One nice
thing about i, j, etc. is that you aren
On Wed, Jan 11, 2012 at 7:20 PM, John Floren wrote:
>
>> (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
Style is style; it is not defensible on its own.
If I were contributing to smiley's projects, I would
make the code look the way the rest of his code
does. It's not that one way is necessarily better,
but one way is definitely least distracting in a given
context.
Russ
> (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 occu
> (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;
this (the former me
In any project, the polite thing to do is to make your code
look like the surrounding code. You have identified many
ways in which your code does not look like the surrounding
code. That's always the first step.
Russ
> 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
> t
style(6) deals with some of your questions.
19 matches
Mail list logo
