Stylistic questions on UNIX C coding.
in [Unix Programming]
|
Prev: integer
Next: shared memory question
From: Richard Heathfield on 26 Feb 2010 01:58 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. Really? Why so? > You really use it? I can't speak for Kelsey, obviously, but I wouldn't dream of doubting him. And I've used it in a couple of places. It works very well. -- 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
From: Nick Keighley on 26 Feb 2010 03:29 On 26 Feb, 06:17, "robertwess...(a)yahoo.com" <robertwess...(a)yahoo.com> wrote: > 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 worked on a project where you couldn't check code in unless it had been through indent with a specified set of flags. Well you *could* but it got flagged somewhere. At first I used to indent to my style (the indent style was a mix of tabs and spaces which I hated) edit and indent to project style before check in. But it was such a PITA I just accepted project style in the end. [cue twenty page rant by nilg about the corporate castration of the programmer] > > 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, I do a special layout change only checkin if the layout had gone wildly astray. > > 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. I think your tools are broken > > 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. on the project I was on they simple wouldn't be able to checkin the code. If they did end-run around *that* they'd run into trouble at build time. > 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. apart from some truly hideous layout styles. One guy must have been told that using blank lines would make his code clearer. #include <stdio.h> int main ( void ) { int i = 99; printf ( "%d\n", i ); return 0; } he never used more than one blank line
From: Nick Keighley on 26 Feb 2010 03:53 On 25 Feb, 16:21, John Bode <jfbode1...(a)gmail.com> wrote: > C++ programmers prefer "char* firstName", because the type of the > *object* "firstName" is char*. Fine, but what about "char > lastName[20]"? The type of "lastName" is "20-element array of char", > but we can't write "char[20] lastName". but no True C++ would use a C-style array! > Same thing for function > types. Same thing for pointers to arrays, pointers to functions, > etc.
From: Kelsey Bjarnason on 26 Feb 2010 04:26 [snips] On Fri, 26 Feb 2010 00:29:05 -0800, Nick Keighley wrote: >> > 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. > > I think your tools are broken Why? I happen to feel most comfortable working in a specific manner. Tabs are tabs, three columns wide. Braces belong on the next line, under the "for" or whatever they're tied to. A blank separating various things which should be separated, but only one, and not needlessly. Etc, etc, etc. It's my preferred style, using it keeps me focussed on the problem instead of figuring out where the other guy's (to me) brain-dead style has left the thrice-damned open brace, particularly if he's using the likewise thrice-damned "spaces, not tabs" so popular with some folks but which plays merry hob with any editor capable of actually handling tabs (i.e. anything written in the last 20 years). There are three approaches one can take to this: 1) Adopt the other guy's standard, no matter how brain dead it may be. 2) Force him (or them) to use your own, obviously superior style. 3) Allow each coder to use their own style, but enforce a consistent style for the repository. I go for three, if only because for some strange reason, other coders don't seem to agree that my obviously superior formatting style should be adopted as a universal convention for all C code everywhere. Option 1 ain't even an option. Let *him* use that brain-dead style if he likes, but if I have to use it, I'd sooner quit and go work for Microsoft. </tongue_in_cheek>
From: Tim Streater on 26 Feb 2010 07:08
On 26/02/2010 02:56, Kelsey Bjarnason wrote: > 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. My preferred approach is to do like this: function wiggy () { if (cond) { dostuff; } else { dootherstuff; } } This has been my approach ever since I was writing BCPL in the 70s - it has the braces lining up so that the matching can be seen easily. -- Tim "That the freedom of speech and debates or proceedings in Parliament ought not to be impeached or questioned in any court or place out of Parliament" Bill of Rights 1689 |