Stylistic questions on UNIX C coding.
in [Unix Programming]
|
Prev: integer
Next: shared memory question
From: Kelsey Bjarnason on 25 Feb 2010 21:56 On Wed, 24 Feb 2010 22:09:43 +0000, Scott Lurndal wrote: > James Harris <james.harris.1(a)googlemail.com> writes: >>On 24 Feb, 20:53, BruceS <bruce...(a)hotmail.com> wrote: >> >>... >> >>> I would like to add that, as long as you're trying to use good style, >>> for God's sake don't use the wrong indentation style. =A0If you put >>> your opening braces on the same line as your conditional, you'll just >>> look like a fool in front of your friends and colleagues. >> >>Snobbish nonsense! >> >> >> > Indeed. > > if (condition) { > > is preferred over > > if (condition) > { Not by me, it ain't. :) > Makes it much more likely that a properly written function will fit on a > single page/screen. And less likely to catch proper vs improper bracing and indentation, when the braces don't line up with the indents. > In 30 years of C programming, no employer or project has used the latter > form. This is one of those cases where there really are legitimate reasons for each approach, with the deciding factor being preference. My take on this has always been to standardize the format "checked in", then use indent or some equivalent, on check in and check out, to convert between the "checkin format" and the individual coder's preferred format.
From: Ben Pfaff on 25 Feb 2010 22:48 Kelsey Bjarnason <kbjarnason(a)gmail.com> writes: > My take on this has always been to standardize the format "checked in", > then use indent or some equivalent, on check in and check out, to convert > between the "checkin format" and the individual coder's preferred format. I've heard of this approach, but I always assumed that it was a joke. You really use it? -- "Welcome to the wonderful world of undefined behavior, where the demons are nasal and the DeathStation users are nervous." --Daniel Fox
From: Phred Phungus on 26 Feb 2010 00:05 Keith Thompson wrote: > John Bode <jfbode1029(a)gmail.com> writes: > [...] >> The all-caps convention makes it easier to distinguish preprocessor >> macros from other symbols. This can matter, especially when using >> function-like macros (macros that take arguments). Remember that >> macro expansions are simple text substitutions; a macro like >> >> #define square(x) (x*x) >> >> does not compute "x*x" and return a value; it *replaces* the text >> "square(x)" with "(x*x)". If x is "z++", then the replacement text is >> "(z++*z++)", which invokes undefined behavior. If x is "a+b", then >> the replacement text is "(a+b*a+b)". By using all-uppercase for >> macros, it makes it easier to see potential red flags like "SQUARE(x+ >> +)" or "SQUARE(x+y)". > [...] > > The side effect problem can't be solved (or at least can't be easily > solved) if you're using a macro, but the operator precedence problem > can. > > #define SQUARE(x) ((x)*(x)) > > You need to parenthesize the entire definition *and* each reference to > the parameter(s). > > BTW, here's my favorite example of preprocessor abuse: > > #include <stdio.h> > > #define SIX 1+5 > #define NINE 8+1 > > int main(void) > { > printf("%d * %d = %d\n", SIX, NINE, SIX * NINE); > return 0; > } > $ gcc -D_GNU_SOURCE -Wall -Wextra k1.c -o out $ ./out 6 * 9 = 42 $ cat k1.c #include <stdio.h> #define SIX 1+5 #define NINE 8+1 int main(void) { printf("%d * %d = %d\n", SIX, NINE, SIX * NINE); return 0; } // gcc -D_GNU_SOURCE -Wall -Wextra k1.c -o out $ SIX * NINE equals 1 + 5 * 8 + 1 I save these nice little toy programs in my linuxlog. -- fred
From: Kelsey Bjarnason on 26 Feb 2010 00:15 On Thu, 25 Feb 2010 19:48:06 -0800, Ben Pfaff wrote: > Kelsey Bjarnason <kbjarnason(a)gmail.com> writes: > >> My take on this has always been to standardize the format "checked in", >> then use indent or some equivalent, on check in and check out, to >> convert between the "checkin format" and the individual coder's >> preferred format. > > I've heard of this approach, but I always assumed that it was a joke. > You really use it? I have, repeatedly, over the years. The problem with _not_ doing it is that you tend to get a lot of checkins where the "diff" is wildly out of sync with what actually got changed, particularly if the coder's tools do things such as switching tabs to spaces or re-organizing braces, etc, etc, etc, which many tools do. By using indent or an equivalent on checkin, you ensure a standard format going in, such that only "real" changes are recorded, and by using it on checkout, you deliver to the coder whatever flavour he's happiest with. Or, you can skip it on checkout and just let him use whatever tools he likes, but I've found delivering to the developer something which he is maximally comfortable with, right out of the gate, tends to produce maximum productivity and minimum frustration. 'Course, some of that will depend on the repository tools, too. Some can be set to ignore whitespace differences, or to auto-format to a defined standard, etc, etc, etc. Some can't. It's easier just to do it yourself, with indent or equivalent, as part of the check-in/check-out procedure.
From: robertwessel2 on 26 Feb 2010 01:17
On Feb 25, 11:15 pm, Kelsey Bjarnason <kbjarna...(a)gmail.com> wrote: > On Thu, 25 Feb 2010 19:48:06 -0800, Ben Pfaff wrote: > > Kelsey Bjarnason <kbjarna...(a)gmail.com> writes: > > >> My take on this has always been to standardize the format "checked in", > >> then use indent or some equivalent, on check in and check out, to > >> convert between the "checkin format" and the individual coder's > >> preferred format. > > > I've heard of this approach, but I always assumed that it was a joke. > > You really use it? > > I have, repeatedly, over the years. > > The problem with _not_ doing it is that you tend to get a lot of checkins > where the "diff" is wildly out of sync with what actually got changed, > particularly if the coder's tools do things such as switching tabs to > spaces or re-organizing braces, etc, etc, etc, which many tools do. > > By using indent or an equivalent on checkin, you ensure a standard format > going in, such that only "real" changes are recorded, and by using it on > checkout, you deliver to the coder whatever flavour he's happiest with. > > Or, you can skip it on checkout and just let him use whatever tools he > likes, but I've found delivering to the developer something which he is > maximally comfortable with, right out of the gate, tends to produce > maximum productivity and minimum frustration. A problem with that approach is that it will trash any special/careful formatting that you might use to clarify a complex section of code. While indent allows you to disable formatting for sections, that's not an ideal solution in many ways. On the flip side, some people can't be coerced into clean formatting, or making an effort to follow the formatting already established for the module their editing, no matter how much violence you threaten. Or keeping "use tabs" turned off in their editors. At times that gets bad enough that the easiest solution is to go ahead and run indent (or the equivalent) and live with the damage. But there's really no excuse - following a formatting style is not that hard, even if it's not exactly the one you prefer. Frankly there is almost no excuse for not follow the existing style when modifying a program. Or following the shop standards when creating a new module. |