Stylistic questions on UNIX C coding.
in [Unix Programming]
|
Prev: integer
Next: shared memory question
From: Ben Pfaff on 26 Feb 2010 12:53 Kelsey Bjarnason <kbjarnason(a)gmail.com> writes: > 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. I've never seen widespread problems with that. When I do, I see folks deal with it by telling the coder in question not to screw stuff up. Do any open source or free software projects work this way? I am familiar with many, and I've never seen anything like this. (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".) > 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. Doesn't it screw up any careful formatting, e.g. of comments? And sometimes careful placement of white space can make the code much easier to read. -- "Some programming practices beg for errors; this one is like calling an 800 number and having errors delivered to your door." --Steve McConnell
From: Ben Pfaff on 26 Feb 2010 12:54 Richard Heathfield <rjh(a)see.sig.invalid> writes: > 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? Because I've looked at many, many software projects and worked on several and I've never seen this approach actually used. -- "Structure padding is the use of extraneous materials to enhance the shape of a struct and make it more attractive to members of the opposite struct. (See also "struct silicone.")" --Eric Sosman
From: Tim Streater on 26 Feb 2010 12:53 On 26/02/2010 15:33, Rich Webb wrote: > On Fri, 26 Feb 2010 15:12:02 +0000, Tim Streater > <timstreater(a)waitrose.com> wrote: > >> On 26/02/2010 14:51, Richard Heathfield wrote: >>> Tim Streater wrote: >>> <snip> >>> >>>> Trouble with tabs is, what is a tab? >>> >>> A quick way of inserting exactly two spaces into the source. >> >> Since I don't know what tab setting you had when you handed me the code, >> I think s/exactly two/a random number of/ applies here. > > [George Lucas missed a bet when he chose to make Star Wars instead of > Style Wars.] > > In the context of C source files, the tab character (\t or \x09 or 0x09 > or however expressed) should always advance the cursor position to the > next mod 8 column. > > The tab *key* on the other hand, may be chosen by the user to insert a > tab character, or a fixed number of spaces, or a variable number of > spaces which advance the cursor to a preferred mod n column. > > Hard tabs in code that presume other than "every eight" are just evil. But this is just it. How am I supposed to know *what* you presume. The tab key with my editor inserts spaces to the next mod 5 column. But they are spaces, so any recipient thereof doesn't have to worry about it. Its tabs in code wot are evil. -- 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
From: Nick on 26 Feb 2010 13:51 Keith Thompson <kst-u(a)mib.org> writes: > Stephen Sprunk <stephen(a)sprunk.org> writes: >> On 24 Feb 2010 12:35, Poster Matt wrote: > [...] >>> EG: >>> Variables: int numFiles = 0; >> >> This is camelCase. >> >>> Functions: int CountNumFilesInDir(char* path); >> >> This is PascalCase. >> >> Mixing the two in the same project will drive adherents of _both_ styles >> nuts. Pick one and stick to it; that way you'll only drive half of your >> readers nuts. > > His convention apparently is to use camelCase for variables and > PascalCase for functions. It's not necessarily a style I'd use, but > it's not obviously horrible (and it's more or less the style I use > at work). As with most of these rules, conforming to existing code > is far more important than any benefits of one style over another. > I really dislike the brace placement of the code I work on, but > mixing my own style into it would be far worse (and wouldn't survive > a code review anyway). > >> (There's also this_type_of_identifier; the same logic applies, i.e. >> don't mix that with either of the above. Never, never create some >> God-awful hybrid with both underscores and uppercase letters...) > > Again, This_Type_Of_Identifier isn't obviously horrible. (I use it > myself, though not in C.) I confess to using lower_case_like_this for variables, and Initial_Capitals like that for functions. It does help when you see run_this() and know you don't have to go looking for the prototype. -- Online waterways route planner | http://canalplan.eu Plan trips, see photos, check facilities | http://canalplan.org.uk
From: Nick on 26 Feb 2010 13:56
raltbos(a)xs4all.nl (Richard Bos) writes: > Seebs <usenet-nospam(a)seebs.net> wrote: > >> On 2010-02-24, Poster Matt <postermatt(a)no_spam_for_me.org> wrote: >> > 5. On a slightly different note, I've been handling my error messages by using >> > #define string constants in a header file. I saw some code which did this and it >> > looked good to me. Is that standard practise, if not what is? >> >> > EG. #define ErrorDirNotFound "The directory was not found." >> >> No. Look into gettext() if you need to do this, or just put them in >> literally. > > gettext() is nice if you have it (it's POSIX, isn't it? Not ISO, anyway, > but common), but putting the messages in literally only works if you > don't reuse them. IME, _some_ error messages are used more than once, in > which case a #define is nice. I create an enum for errors, and a table of messages (by using something like this): ERCODE(err_signal,"A Signal was trapped") ERCODE(err_internal,"Something went wrong internal to the interpreter") ERCODE(err_failure,"An operating system function failed") ERCODE(err_memory,"Ran out of memory") // keep this as the last of the prog kil lers ERCODE(err_unimp,"This is not yet implemented") ERCODE(err_syntax,"Syntax error") ERCODE(err_open,"Error with file") ERCODE(err_mismatch,"Mismatched types") ERCODE(err_killed,"Program told to stop") ERCODE(err_locking,"Database locking failed") ERCODE(err_cs,"Error reported by ClearSilver templating system") and a bit of #define magic, you can create the enum and the table indexed by it in one go. Oh, and I've just realised that this is non-conforming code. I probably better start my error code macro with a P or something. -- Online waterways route planner | http://canalplan.eu Plan trips, see photos, check facilities | http://canalplan.org.uk |