Response to “Java coding decisions I struggle with”

I love this post by Derek Young: Java coding decisions I struggle with.

I chose to write a response here instead of a gargantuan comment.

Interface Names: Shape or IShape?

I hate IShapes, like I hate all hungarian notation. It’s noisy. I want to talk about concepts.

Allow me to hoist some knowledge from a comment to the aforementioned post:

I hate the “I” for the simple reason that when you create a concept central to your system you should name the Java type based on the concept. For example, if “Shape” is a central concept for your application, there should be some type named “Shape” in the code base. When you talk to other developers on the project, you’ll talk about Shapes, creating them, manipulating them, and so on. In many cases, Shape will be an interface (although not always).

Finally, if the “I” is so important, why stop there? Go full-bore for “Hungarian notation” as the old Windows stuff did.

I salute you, Eric Foster-Johnson.

I always enjoy pretending to suggest “C” and “Pojo” prefixes for classes.

“C’mon guys! Let’s suffix all of our classes with ‘Class’. That way, as soon as you see it in your Eclipse Package Navigator, you know it’s a Class!”

Occassionally the hungarians subtlely invade my code, providing noise in the guise of clarity. Last year at this time, if I had a Map of user names to User objects, I would have called it “userMap”. Now, I just call it “users”. I’m liking it.

When to use “final”

I always make local and member variables final, unless I need to modify them.

I like that I have to think about whether things will be modified or not. Mutability is a relevant design decision — maybe not necessary during prototyping, but helpful when figuring out how my system is going to work.

I don’t use final for method parameters, because I don’t see the point — assigning to parameters is kind of weird since it doesn’t have any permanent effect, so I don’t do it.

Organizing Classes into Packages

Once I get around 20 classes in a package, I start thinking about reorganizing into subpackages. This can screw up relationships that rely on default-level access, but I’m using OSGi on my current project anyway, so I rely on a different package access control mechanism.

In OSGi, packages must be explicitly exposed in the bundle configuration, so there is no external harm in making things public. I understand that my situation is the minority on this one.

Assertions

I love the idea of asserts, but I hate that assertion failures throw an Error instead of an Exception. I use asserts as a way of establishing invariants in my system. It’s not the same as a simple “if not X then throw an exception” — it’s a special case of “wow, something really went wrong here.”

Checked or Unchecked Exceptions

I was into checked exceptions, until I started writing a lot of code in Python, where you can catch them if you want to, and if you don’t, at some point, your program will explode.

This sounds hazardous, but works beautifully.

Now I hate checked exceptions, because they force me to write a lot of repetitive code. How many hundreds of thousands of times have I written a “catch and rethrow” block?

Compassionate checked exceptions extend from a common base class, like how FileNotFoundException extends from IOException. I can deal with this.