Copyright 2004 by M. Uli Kusterer Fri, 29 Nov -1901 11:06:32 GMT Comments on article blog-lets-talk-about-coding-style at Zathras.de http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm witness_dot_of_dot_teachtext_at_gmx_dot_net (M. Uli Kusterer) witness_dot_of_dot_teachtext_at_gmx_dot_net (M. Uli Kusterer) en-us http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment11 http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment11 Uli Kusterer writes:
Stephen,

I don't really care about other languages here :-) Coding style is inherently language-dependent. Sometimes I make compromises because a project mixes languages and I would otherwise make mistakes switching between them. Sometimes languages are related or so similar that the same style works for all of them.

But I wouldn't code C++ like I would ObjC or HyperTalk, so of course if a keyword has a different meaning in another language, my coding style has to be adjusted accordingly. I'm trying to be sensible here, not force my unavoidable domination over all other programmers' coding styles ;-)
http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment10 http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment10 Uli Kusterer writes:
Well, if( condition ) is really

if( condition != false )

which is technically slightly different than if( condition == true ) if you're using a variable that doesn't only contain true or false (e.g. an int). It's not really a practical consideration in most cases. The main reason for writing the "== true" is readability. Though for me it depends. I often name my bool variables something like "lightIsOn" and then

if( lightIsOn )

is actually very readable. So I think it's OK to use, and good style *if* your variable names form a decent sentence with the "if". Reversing the variable and the constant really only is important when you *need* the constant to compare to, e.g. in cases like

if( 5 == myNumber )

because there it'll catch the typo.
http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment9 http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment9 @rg: "Why not just write if( condition ) that is so much clearer why the unnecessary == true ."

Because when you use if (condition), you do not compare to true but to 0.

It's also [a lot] less readable. Sure with == true, you have extra characters but everybody understand the test. Without == true, some people won't understand it.

if (condition) -> Windows-like User Experience

if (condition==true) -> Mac OS X like User Experience
http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment8 http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment8 leeg writes:
I occasionally use the curly-brace-on-same-line style:
if (foo) {
when writing articles and the like, to waste less vertical space. But for writing code I've always used curly-brace-on-next-line.
http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment7 http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment7 I found this article to be very helpful. I also like aligning my '{' vertically as my eye can quickly scan down to verify I've not forgotten to close a block as well as to immediately and clearly grasp the scope of any particular block. I've found this to be particularly helpful with nested blocks.

Prior to reading this article I still hadn't fully made up my mind with regards to brackets touching their identifier. I really like the reasoning you put forth here and will use your style going forward I think.

As far as color goes, I had read that midnight-style coloring causes less eye-strain long term. Any thoughts on that point? I think it's uglier by far, but I'm willing to make the sacrifice if there are legitimate health benefits for doing so.

Also, I'm a big fan of multiple lines for methods that take multiple arguments. It not only breaks things up visually, but it also helps to clarify the relationships when you're nesting method calls. I realize this sometimes looks a bit like E.E. Cummings--as Wil Shipley would say, but that guy's code has almost no whitespace. Maybe I'm just a noob, but I find using whitespace as an aid for expressing the intention of the code to be completely invaluable for me. I guess that if I were smarter, or more experienced, I probably wouldn't need those extra cues, and therefore would find the extra space to be a wasteful annoyance. That's my theory at least. Any thoughts on multiple lines for multiple argument methods?
http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment6 http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment6 Is there an easier way to make these changes? The command line method is prone to misspellings, bad syntax, etc.

Also, is it necessary to reboot your computer to make them "take"? I made changes, closed and reopened XCode and there is no change.

StartupItems4ever: I like the tFoo and nFoo notations. I also like foo_ for member variables, but I currently use _ for something else so I would need to make the switch at the start of a new project and stick with it.
http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment5 http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment5 Why write if( true == condition) or if(condition == true)
Why not just write if( condition ) that is so much clearer why the unnecessary == true .
I see it a lot and it really bugs me.
http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment4 http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment4 Stephen Celis writes:
You have an unusual style, but with reasonable justifications. A few notes, though:

Aligning opening and closing brackets doesn't always translate well to other languages. You'll have gotchas in ECMAScript-based languages, for example, where bracketing is sometimes interpreted as an object literal.

I also shy away from treating conditions and loops bracketing as functions, since "if", etc., are keywords, not functions, though I suppose this is really a matter of taste.
http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment3 http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment3 o Member variables:

Personally, I use '_' as a suffix or suffix.

member variable -> foo_

private version -> _foo

o Local variables:

Some prefixes I use:

tFoo -> the variable won't exist after the method returns.

nFoo -> the variable is created in the method and will exist after the method returns.

o Method parameters:

Not a big fan of the parenthesis stuck to the parameter name. It makes names more difficult to read.
http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment2 http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment2 Patrick aka Jolly writes:
Somehow a lot of programmers I know use the brackets on a single line convention, even though I rarely see that in the wild. I'm a advocate for single line brackets as well - even though it does use more space.
I also align the values in the variable settings. That stands out even more as settings.

I would like to mention the use of:

lowercase ALL non objects.
camelCase anInstance.
UpperCamel AClassName.

and tests start with the constant not the variable. So it would be

if( true == condition)
...

in my code. This might look weird first, but you recognize the difference between a set and a comparison. Also comes in handy to prevent syntax errors that become semantic errors: e.g.

if( result = NO ) vs. if( NO = result ) // both times I forgot an additional equal sign.


And btw. it always

- init
{
if( !(self=[super init]) )
{
return nil;
}

as don't have to think about the open nil==self state for the whole method.


Oh coding styles are so much fun - Patrick
http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment1 http://www.zathras.de/angelweb/blog-lets-talk-about-coding-style.htm#comment1 Almost the way I do :) Especially where to put the open curly bracket :)

I also do the following: I only declare one variable 'per type and line' - no comma separated lists. And I prefer to not put a space between type and the 'pointer star *' since I prefer to see 'pointer to something' as a type (which I typedef eventually when cleaning up code). In this part, your style seems to be inconsistent (-> variable decl. vs. parameter decl.) to me.

AND I curly bracket EVERY block, even a single line in an 'if/while/...' statement. Waste of space? Sure, but more readable AND secures future changes in my opinion!

And I imagine you did your first 'serious' code in a language named after a man who invented a calculating machine back in the 1600-somethings :)

[after hesitating some seconds, I submitted to the Moderator ...]