One of the things about writing code for other people is that you have to be flexible on coding style. Over the years I’ve mellowed a lot on this, but that doesn’t mean I don’t find some coding styles misguided.
For example, the Java coding style suggests the following formatting:
longName1 = longName2 * (longName3 + longName4 - longName5)
+ 4 * longname6;
whereas I prefer:
longName1 = longName2 * (longName3 + longName4 - longName5) +
4 * longname6;
because I tend to read code a line at a time, and having the + at the end of the line lets me know there is more to follow; a bit like seeing a comma when reading English.
Put another way, I don’t need to just be able to look at the second line and realise it is part of the first line, because I don’t start reading at the second line, either in a book or in code. (In fact, if I just looked at the second line, the indenting should tell me it is part of the line before.)
When the operator is at the begining of the line I find my brain has terminated parsing on the first line, and then it has to raise an exception to say, actually we’re not done yet!
That said, when there are multiply ORed (||) clauses in an If() statement, then I like the || to go at the beginning of the line, as in:
if((condition1 && condition2)
|| (condition3 && condition4)
|| ! (condition5 && condition6)) {
doSomethingAboutIt();
}
It marks out the separate sub-clauses to think about more clearly. i.e. unlike the first example which is a cue to say there is more to follow, putting the || at the beginning of the line is a cue to say ‘what follows can be thought about separately from the previous stuff.’
Note that I’ve put some extra space around the NOT operator (!) compared to the example in the Java style guide. I guess my eyesight isn’t so good, but I think it’s important to make sure that little fella isn’t missed, especially when preceded by ||!
Related to this, I wouldn’t do the alternate form suggested in the Java coding style of the above expression:
if ((condition1 && condition2) || (condition3 && condition4)
||!(condition5 && condition6)) {
doSomethingAboutIt();
}
because, presumably, each of the three &&ed sub-clauses has equal merit and should be laid out to reflect that.
Lastly, to finish my morning therapy, I wouldn’t layout the following as:
private static synchronized horkingLongMethodName(int anArg,
Object anotherArg, String yetAnotherArg,
Object andStillAnother) {
...
}
I’d do:
private static synchronized horkingLongMethodName(
int anArg,
Object anotherArg,
String yetAnotherArg,
Object andStillAnother) {
...
}
as it makes it easier to see each of the arguments.
Hum, I guess I still have a lot more mellowing to do!
