I spent an hour or so the other night refreshing my knowledge of Sun’s official coding convention for Java.  Obviously these are just suggestions and you don’t have to follow them at all, though I’ve made it clear that I would be in full support of a language that did enforce such a standard in my post standard style post.  Nevertheless, there are a few suggestions in the documentation that make me wonder why support wasn’t just built into the language for them even if they didn’t want to completely support a coding convention through the compiler.

The fact that these are part of the convention says to me that someone at least considered these items possible problem areas.  Were they banished to the convention in order to avoid building any barriers that might deter C/C++ programmers from adopting Java in the early years?  Maybe the convention just came later.  Or maybe it has been edited several times since the language was originally developed and these items were just oversights that can’t be fixed at this point.  This is certainly a possibility considering how easily a convention can be changed compared to the language itself.

/* falls through */

I think switch case statement fall-through is a bad thing in its only supported form, as I mentioned in my simple rules post from a while back.  It shouldn’t be allowed without the compiler being able to have some kind of control over it, and I think Sun knows this.  The switch statement below is directly from the coding convention.

    switch (condition) {
    case ABC:
        statements;
        /* falls through */

    case DEF:
        statements;
        break;

    case XYZ:
        statements;
        break;

    default:
        statements;
        break;
    }

In my opinion the /* falls through */ comment is just hack.  Imagine you have a wall in your house where a 2x4 is missing.  So, at one position on the wall there is a span of 32 inches without a beam and the wall is a little less stable in that vertical strip, a little less likely to support weight.  So, to avoid a drunken idiot, or just a normal idiot, from breaking through the wall, you write in big red letters, “Weak Spot” in the problem area.  Problem solved, unless the drunken idiot didn’t notice it, as he was too busy crashing through your new lamp that you just picked up at IKEA over the weekend.

An open manhole cover is another, possibly more realistic analogy.  It’s likely that an open manhole cover will have some kind of visual warning similar to the /* falls through */ comment.  Possibly orange cones.  The only difference is the manhole is only open temporarily, it’s not a permanent situation.  Also, they use bright orange cones, an object out of the ordinary.  Comments are usually all over the place in code and quickly are filtered by your SEP field.

There might be nothing they can do about it now considering that there are way too many applications out there developed with Java that might just stop working if they made such changes to the language, but it is still a pretty hack solution to the issue.  They would serve new developers better by just telling them not to use case fall-through.

In the most hindsite, snooty, Monday morning quarterback way, they should have done something like this.

    switch (condition) {
    case ABC:
        statements;
        continue;
    case DEF:
        statements;
        break;

    case XYZ:
        statements;
        break;

    default:
        statements;
        break;
    }

Use the continue keyword to allow case fall-through.  Or they could’ve created a fall keyword; maybe even, gasp, a goto <case> type of implementation.  Anything that gives the compiler control over case fall-through is better than nothing…er, having a /* falls through */ comment.

Statements Always Use Braces

I always use braces…always.  I can’t stand the look of of the following in my code:

    if(condition)
        doSomething();

It just comes off as messy to me, not uniform with the rest of the code. I think it’s perfectly acceptable in a language like Python as code blocks are defined by indentation, not opening and closing curly brackets.  But, in languages that rely on braces, you shouldn’t be allowed to define a code block any other way.  And again, it seems the developers of Java agree with this.  Section 7.2 of the coding convention states:

Braces are used around all statements, even single statements, when they are part of a control structure, such as a if-else or for statement. This makes it easier to add statements without accidentally introducing bugs due to forgetting to add braces.

I’m going to chalk the decision to not put this in the language up to staying inline with the supported syntax of C/C++.  Programmers are fussy prima donnas.  You don’t mess with their preferences, even if there preferences are completely wrong.

The fact that this isn’t a part of the language isn’t a big deal, but if I see an if statement missing curly brackets in code I’m working on,  I’m compelled to add them.  And you should be too.

Public, Private, Protected…why not Package?

Recently I’ve been seeing this a lot in code I’ve been working on.

    /*package*/ class SomeClass {
        public String someVariable;
        /*package*/ Object someVariable2;
    }

It irritates the shit out of me.  If you spend ten freaking minutes working in Java it’s likely that you will learn, or figure out that the absence of an access modifier makes the member/class public to the package, but private to the world.  But, it does make me wonder why they didn’t just go the extra step and make a package access modifier.  It neatly falls in line with the length and first letters of the other access modifiers; it seems like it would have been a natural part of the language.  Also, it would keep my code looking slightly more uniformed.  The variable name for private, protected and public variables all start in nearly the same location.  Then you have the package variables that start way before anything else…or at least a couple of characters.

I know, this one’s a bit nitpicky.  Unlike the other two, having a package modifier doesn’t help fend against introducing defects.  It’s completely a visual preference of mine.  It doesn’t matter.  However, putting the /*package*/ is way worst than just having nothing at all, so just don’t do it.  All that says to me is that the programmer was too stupid to remember that the member would only be able to be accessed by other members of the package.  You don’t want me thinking you’re stupid, do you?

Anyways…

I understand that creating a flawless language is hard, if not impossible.  I also understand that this stuff is subjective and you may not agree with it.  And I also realize that even if Sun now believes this stuff should be enforced by Java’s compiler that it will never happen due to the fact that many companies and developers rely on their shit being consistent with what is already available.  But, that doesn’t mean I can’t point out their flaws from atop my safe little mountain of hindsight.