"(I mean, honestly, braces on the SAME line as the if()?)"
Indeed.
I prefer the:
if (el_Reg)
{
NSLog(@"Another top headline");
}
style.
For decades, dour broadsheet the New York Times and its style guide have presided over the world of posh writing: its English usage manual serves as both a bible for upmarket writers and a blunt instrument with which to beat sensationalist tabloid hacks such as your humble correspondent. Now the Grey Lady has turned her hand …
I think I'll wait until the Chicago Manual of Style weighs in.
Jokes aside, style guides can prevent a certain amount of irrational anger in a group coding effort. I have my preferred style, but setting up one's editor for the employer-of-the-month's style can save a lot of aggravation.
(Oh, and of course indentation should be done with tabs. This fad for indenting with spaces is troubling.)
"What goes into the file, however, should be plain old spaces -- however many you've agreed on with your editor."
So what happens when someone edits my code who wants 2 spaces instead of 4? Or 8? Or 5?
If they are left as tabs they can be adjusted by an individual's preference in their editor.
It's been a while since I last wrote any C but, putting the bracket on the same line, or the equivalent in whatever language you are using, just does nothing for clarity, unless it's a one-liner where it is obvious what's going on. I've never understood why people have to cram their code into the smallest space possible, it's not like the extra whitespace is going to make a jot of a difference to the complied code and gone are the days when you have to try and cram your source code onto a 256K floppy or worse! Coding shorthand so often just obscures the flow, especially if it's the first time you've looked at it for months or years or you have the misfortune to inherit someone else's undocumented project!
I agree with you about where the { should be.
However, it is my understanding that the reason for having it on the same line as the if() is that in the days of manual teletypes it saved waiting for the carriage return AND saved paper - remember that once upon a time we didn't edit code on a screen.
It also saved a card if you were submitting your code that way.
Gah, no, putting the open brace on the same line as the controlling block is simply K&R style, and has a long history. There's two reasons, 1) So it's immediately clear what is controlling the block of code, and 2) as defensive coding style against accidentally forgetting to put in the brace.
I personally have no problem with either style, so long as it is entirely consistent in your corpus of code. Mix it in one program and you DIE.
That said - checking your code by visually looking at indents is only going to work when you haven't screwed it up. Check your indents by using an editor which properly shows the scope in a gutter (most good IDE editors), or a least will pop you back and forth from the start to the finish (good old vi). Nice indenting is for ease of reading, NOT debugging!
Why write a text guide for humans to read, why not write a python script that will format the source to their standard?
I had to do this for my A-level computer science project... My tutor complained my code didn't have enough white-space. To my mind it had the perfect amount of white-space, just enough for the BBC Micro interpreter to identify token keywords from variable names.
So I wrote a program which took my code and converted it to code with more spaces.
Tutor was impressed, and asked why I hadn't written it like that before... So I loaded up the new space filled program and typed "RUN"...
"Out of memory" came the reply... :-D
#! /bin/bash -e
sed <"$2" \
's!\([ \t]*__attribute__((.*))[ \t]*\)!/*OTBS<\1> */!;'\
| indent -st -npro \
-pmt -bad -bap -bbo -bc -br -brf -brs -bfda -bfde -c33 -cd33 -ncdb\
-cdw -ce -ci4 -cli0 -cp4 -ncs -nfc1 -nfca -d0 -di0 -hnl -i8 -ip0\
-l78 -lc78 -lp -lps -npcs -ppi2 -nprs -psl -nsaf -sai -nsaw -nsc\
-nsob -ss -ut\
| sed 's![ \t]*/\*OTBS<\([ \t]*__attribute__((.*))[ \t]*\)>.*\*/[ \t]*!\1!' \
| sed '
s/^) {/)\t{/
s/} else {/} else\t{/
/^[ \t]*if .*[^{ \t][ \t]*$/{N;s/[ \t]*\n[ \t]*/ /}
/^[a-zA-Z0-9_]\+($/{s/^\(.\{1,6\}(\)/\1\t/;N;s!\n[ \t]*//!\t\t\t//!}
' >"$1"
This post has been deleted by its author
even if it's only a single line, I'd prefer to seperate my if statements
if ( !error )
{
return success;
}
likewise I like method headers, function headers, comments that explain why we're doing rather than what we're doing. In the above a comment along the lines of "returns a success message if there is not an error" makes me want to bash my head into a wall. If you need a comment for that then you probably need to be warned that the coffee is hot and might burn your tongue, or that not everyone likes spouts.
I set my tabs to 4 spaces in VS, but that's just because it seemed like the nicest fit.
Additionally I prefer putting in spaces around braces and parenthesis quite simply because it makes larger functions easier to read, and easier to track the last closing brace.
Meaningful method names are a must. Likewise for params. I don't want to see a a1 a2 a3, I'd rather see *player player1 player2 player3.
Prefer camelCase to snake_case, it's somewhat grown on me. Anyone who mixes the two ala this_FunctionalMethod should be shot in the foot.
I think that about covers the basics. *begins writing his own style guide*
I suppose by the end of it the only style guide that really applies is what's already in place.
As much as I prefer
{
stuff
}
fed may prefer
{
stuff }
and harry may like
{ stuff }
Each is just as viable as the last (code isn't set in stone like grammar) so really the style you use should be the style of the rest of the code.
If an entire project is done this_is_my() { face }
then I'll write it in that way. If it's my own project, I'll write it the way I prefer. It's really down to the project, it's kind've why coding standards existi in companies (and if they don't then they should.)
2 spaces per level for me. Tabs mean any significantly nested code just disappears off the RHS of my screen or, worse, gets wrapped by the editor. I put the opening curly on the same line as the 'if' and the closing curly in the column below the 'i'. 1-statement blocks don't need curlys. Statements in the block are indented. Works for me, but feel free to flame or downvote.
In VI you can easily remap the number of spaces per tab, I would imagine most new-fangled editors have the same option somwhere.
Which is precisely why you should use tabs instead of spaces, actually. Because then someone else who dislikes reading compacted two-space-indent code can view it the way they want when they open it in their own editor.
Except when you end up having to read code that someone's peppered with tabs on someone else's machine where they haven't bothered to set up a proper editor or they really like 8 characters per tab and anything over a few levels of hierarchy means that the code's disappeared off the edge of the screen, nothing lines up and it's impossible to follow. Fixed spacing using spaces works universally, unless you're a freak who uses variable-pitch fonts....
"Whereas the Reg programming style guide requires that method and variable names contain alliteration and dodgy puns."
Wot, like using a pointerSisters struct for a double linked list? superCalibGoesBallisticCallbacksAreAtrocious() when dealing with a calibration fault? Given our headlines are written to make you think (or blurt out loud) "My god! What?!" and click on the link at once out of raging curiosity, I'd say our programming style would be "rhyming esoteric" that'd make you reach for the comments or VCS for help.
Of course, our backend systems are so very cleanly written (in perl).
C.
Use a decent editor, of course, and when you close the brace it matches it visually with the corresponding open. If the opening brace is off the page Emacs will show the matching line in the message-line. If you put the opening brace on a line of its own THAT COMPLETELY F*CKS IT!
I've always been hoping someone would write a code-styler that we could hook-into revision control so the in-repo copy has no spacing at all (thereby saving all those "extra bytes") but when you take your copy it re-formats the files to your favourite format.
New York Times eh ? I think I'll wait for Hello! to pitch-in...
glad to see the Allman style supporters are out already.
Figured I'd chime in on the one liner if-- this guideline from NYT is clearly from someone who's never written industrial scale code (grabs flame-proof suit). In a good code base, pretty much every function returns error. If you have a function that acts as a switch between hundreds of of different functions all not quite alike, you get a crap-ton of tedious code like
if(function != Success)
{
goto cleanup;
}
well, of course, that is too dang long when you have hundreds of the little buggers all over the place, but the simple, legible
if(function != Success) goto cleanup;
is of course forbidden by your coding standards, so you get the wonderful error handling macro to wrap things up in to bring them down to one line within the remit of the coding convention. Like so:
CHECK_ERROR(function);
Now, this doesn't look too bad, until you actually try to read code that has this stuff in it. I'm not sure about all of you, but when I scan that line, I see CHECK_ERROR, not function. Yes, there are other advantages to this sort of macro, but the one-liner if is miles ahead in terms of legibility.
MACROS??? They are the devil's work.
I know of only a couple of (arguably) legitimate uses of macros - defining constants, and defining log and assert macros that you may wish to redefine and compile-out for production builds. Anything else is an abhorrence.
As for the curly bracket debate, I agree with what most people are saying. having the opening brace on the same line as the 'if' just makes reading the code more difficult than it needs to be. I hate it. Oh, and ALL conditionals should be followed by a block ({...}), even if they are just one-liners.
As for "goto" - You're kidding, yes?
...and while we're at it, all functions have precisely one entry point. They should have only one exit point (at the end).
if (...) return;
....is awful. It breaks the flow of the code, it's ugly, it's just not bloody-well British!!!