Stylistic questions on UNIX C coding.
in [Unix Programming]
|
Prev: integer
Next: shared memory question
From: Anand Hariharan on 26 Feb 2010 19:31 On Feb 26, 5:11 pm, Stephen Sprunk <step...(a)sprunk.org> wrote: > On 26 Feb 2010 11:53, Ben Pfaff wrote: > > > (Doesn't it take *forever* to reformat a large source tree, by > > the way? It took a few minutes here just to run "wc" on the .c > > files in a Linux kernel tree, and I imagine that "indent" is > > slower than "wc".) > > Last time I checked, the vast majority of wc's runtime was opening, > reading, and closing files, i.e. the parts that make the disk's head > skip all over the place, not actually counting lines. indent does a > little bit more with the data than wc does, but on a tolerably fast > machine I suspect that the extra work would just fill in (a few of) the > CPU cycles wc wastes while waiting for the disk... > > S > indent would have to /write/ the files to the disk, but wc does not.
From: Ersek, Laszlo on 26 Feb 2010 20:00 In article <hm9j5p$u88$2(a)news.eternal-september.org>, Eric Sosman <esosman(a)ieee-dot-org.invalid> writes: > On 2/26/2010 5:45 PM, Eric Sosman wrote: >> [...] pi spaces. This is easily approximated by making the tab >> key operate probabilistically, advancing to a three- or four- >> space position with probabilities 0.142 and 0.858, respectively. >> [...] > > You've heard of "fencepost errors?" This is a "newspost error." (I'm going out on a limb here.) Do you mean you reversed the order of probabilities (relative frequencies)? E(spc_per_tab) = E(3 + X) = 3 + E(X) = 3 + (0 * 0.858 + 1 * 0.142) You also wrote: > (If you need a more accurate approximation to the fractional > part of pi, your lines are too long.) Having a large number of tabs is also possible by having many lines in a file, or many files in a project :) Cheers, lacos
From: William Hughes on 26 Feb 2010 20:10 On Feb 26, 8:31 pm, Anand Hariharan <mailto.anand.hariha...(a)gmail.com> wrote: > On Feb 26, 5:11 pm, Stephen Sprunk <step...(a)sprunk.org> wrote: > > > > > On 26 Feb 2010 11:53, Ben Pfaff wrote: > > > > (Doesn't it take *forever* to reformat a large source tree, by > > > the way? It took a few minutes here just to run "wc" on the .c > > > files in a Linux kernel tree, and I imagine that "indent" is > > > slower than "wc".) > > > Last time I checked, the vast majority of wc's runtime was opening, > > reading, and closing files, i.e. the parts that make the disk's head > > skip all over the place, not actually counting lines. indent does a > > little bit more with the data than wc does, but on a tolerably fast > > machine I suspect that the extra work would just fill in (a few of) the > > CPU cycles wc wastes while waiting for the disk... > > > S > > indent would have to /write/ the files to the disk, but wc does not. Which might not take any appreciable extra time, depending on (among other things) seek vs read vs write time, disk fragementation and buffering strategies. - William Hughes
From: Ike Naar on 26 Feb 2010 21:10 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?
From: Richard Heathfield on 26 Feb 2010 23:10
Ian Collins wrote: > Richard wrote: <snip> >> 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. > > What's the going rate for a line these days? People should avoid trying to answer that question until they have checked their answer in the debugger. -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within |