Stylistic questions on UNIX C coding.
in [Unix Programming]
|
Prev: integer
Next: shared memory question
From: pete on 26 Feb 2010 23:17 Ike Naar wrote: > > In article <2i3m57-tcp.ln1(a)news.eternal-september.org>, > Richard <rgrdev_(a)gmail.com> wrote: > >It is ludocrous to recommend the second form. ALL it does is waste a > >line. Indentation is there for a reason. We dont need to see the opening > >bracket on its own wasted line. > > Are you not also "wasting a line" for the closing brace? > Is that ludicrous too? > Why do you need to see the closing brace on its own line, but not the > opening brace? Doesn't that destroy the symmetry? > > Then, it's not always black and white. > Consider the case where a condition does not fit on a single line: > > if (sscanf(input_buffer, "%d %d %d", &length, &width, &height) == 3 && > sscanf(other_buffer, "%d %d %d", &color, &price, &weight) == 3 && > needs_processing(color)) { > compute_volume(length, width, height); > compute_something_else(price, weight); > } > > vs. > > if (sscanf(input_buffer, "%d %d %d", &length, &width, &height) == 3 && > sscanf(other_buffer, "%d %d %d", &color, &price, &weight) == 3 && > needs_processing(color)) > { > compute_volume(length, width, height); > compute_something_else(price, weight); > } > > In the first case, it is hard to see where the condition ends > and where the body starts. In the second case it's obvious. > Don't you think that the opening brace on its own line here improves > the readability? Yes, but only in that case. That's a special case under Indian Hill C Style and Coding Standards . http://www.psgd.org/paul/docs/cstyle/cstyle06.htm -- pete
From: William Ahern on 27 Feb 2010 00:19 In comp.lang.c Ike Naar <ike(a)localhost.claranet.nl> wrote: <snip> > Consider the case where a condition does not fit on a single line: > > if (sscanf(input_buffer, "%d %d %d", &length, &width, &height) == 3 && > sscanf(other_buffer, "%d %d %d", &color, &price, &weight) == 3 && > needs_processing(color)) { > compute_volume(length, width, height); > compute_something_else(price, weight); > } I agree that that's a sore spot. But in complex conditions I often like to align the logical operators w/ the if statement. if (sscanf(input_buffer, "%d %d %d", &length, &width, &height) == 3 && sscanf(other_buffer, "%d %d %d", &color, &price, &weight) == 3 && needs_processing(color)) { compute_volume(length, width, height); compute_something_else(price, weight); } Along with 8 space aligned indentation, it's not that bad.
From: Kelsey Bjarnason on 27 Feb 2010 00:32 [snips] On Fri, 26 Feb 2010 12:29:13 +0000, Tim Streater wrote: > Trouble with tabs is, what is a tab? It's a character, often ASCII 9, which tells your editor to indent (or, on removal, unindent) by whatever number of columns is required to bring things in line with the next (previous) tab stop. Contrast that to hitting delete on a line which uses spaces instead of tabs. All this does is mess up the formatting, as the editor is almost certain to treat a space as a _space_, as it should, not as a tab, which it _shouldn't_, because the character involved is not a tab, but a space. Then, of course, there's inserting. Hit space. See how many columns the line indents. One, isn't it? Why is that? Oh, yes, because spaces aren't tabs, and editors won't treat them as tabs. Tabs are tabs, and editors treat them that way. AFAIK, even Emacs and vi can cope with tabs. I've yet to meet _any_ editor which, when you delete a space, correctly determines that you really meant to delete four spaces, and removes that many, or, when you hit the spacebar, correctly figures out that you actually meant a tab, not a space, and thus inserts 4 (or is it 3? 8? 5?) spaces. > I use the tab key but my editor > (TextWrangler) just converts them to spaces. Why should spaces bother an > editor, anyway? Because spaces, for purposes of indentation, are defective by design, and editors are generally built in such a manner as to use the right thing for the right job. Spaces between words, etc, tabs for indentation.
From: Kelsey Bjarnason on 27 Feb 2010 00:36 On Fri, 26 Feb 2010 11:28:19 -0800, Keith Thompson wrote: > Richard Heathfield <rjh(a)see.sig.invalid> writes: >> Tim Streater wrote: >> <snip> >> >>> Trouble with tabs is, what is a tab? >> >> A quick way of inserting exactly two spaces into the source. > > The One True Tabstop Width is 8. Three, actually. Okay, 8, if you're stuck using output devices from the 1960's which didn't allow user-defined tab spaces, but for how many people is this true anymore? > I have to deal with code that was modified by multiple different people. > Most of them use a tabstop width of 4, but some apparently use 2, 8, or > something else, resulting in code that's not properly formatted > regardless of my own tabstop setting. Now imagine if they were using spaces. This guy uses two, the next guy uses three, the third guy uses 4, the fourth guy uses 5, some other guy uses 8. With tabs, at least just by setting your tab stops, you can get a degree of consistency. Have fun sorting out the nightmare of inconsistency spaces lead to.
From: Richard on 27 Feb 2010 01:00
Kelsey Bjarnason <kbjarnason(a)gmail.com> writes: > [snips] > > On Fri, 26 Feb 2010 12:29:13 +0000, Tim Streater wrote: > >> Trouble with tabs is, what is a tab? > > It's a character, often ASCII 9, which tells your editor to indent (or, > on removal, unindent) by whatever number of columns is required to bring > things in line with the next (previous) tab stop. Something tells me Tim might have know that. > > Contrast that to hitting delete on a line which uses spaces instead of > tabs. All this does is mess up the formatting, as the editor is almost > certain to treat a space as a _space_, as it should, not as a tab, which > it _shouldn't_, because the character involved is not a tab, but a > space. Not with any half competent editor. > > Then, of course, there's inserting. Hit space. See how many columns the > line indents. One, isn't it? Why is that? Oh, yes, because spaces > aren't tabs, and editors won't treat them as tabs. Tabs are tabs, and > editors treat them that way. And often treat spaces as tabs too. press left or right or delete on y white space area and it deletes to a tap stop. > > AFAIK, even Emacs and vi can cope with tabs. I've yet to meet _any_ Even? Emacs is probably the most advanced editor out there. And vi one of the most popular programmers editor. > editor which, when you delete a space, correctly determines that you > really meant to delete four spaces, and removes that many, or, when you > hit the spacebar, correctly figures out that you actually meant a tab, > not a space, and thus inserts 4 (or is it 3? 8? 5?) spaces. > >> I use the tab key but my editor >> (TextWrangler) just converts them to spaces. Why should spaces bother an >> editor, anyway? They don't if you're half competent and configure it properly. > > Because spaces, for purposes of indentation, are defective by design, > and What total bullshit. Most people use spaces for indentation. > editors are generally built in such a manner as to use the right thing > for the right job. Spaces between words, etc, tabs for indentation. > Totally and utterly wrong. Its rare to find tabs used anymore. Most editors are LSEs (language sensitive editors) and indent automatically based on a configured language layout. -- "Avoid hyperbole at all costs, its the most destructive argument on the planet" - Mark McIntyre in comp.lang.c |