#20 Don’t Document Deprecated Code

This should be obvious, but I worked with a team where several members thought it was important to document functions which were no longer considered part of the future of the product.

#19 Reduce Cognitive Load

Deeply nested IF statements can be hard for the brain to unwind and process correctly.  In many cases, the branch statements are selecting for a single, or a small set of conditions for which processing will be done, and outside of those conditions nothing will be done.  Given this, the code can be structured to avoid complexity, make it easier to understand, and less costly to maintain.

#18 Don’t use TAB Characters

An age-old debate that should not exist.  Tabs are evil.  It is an attractive idea, but poorly implemented, non standardized, unpredictable handling, and so this post enumerates the ways that their cost far outweighs their benefits.

#17 Program Logic Error

Not all exceptions are the same, and when writing a program, it is important to be mindful of whether the root cause of an exception is the programmer, or possibly environment or user data.  The latter type of exception can reasonably occur in a production environment, and so needs a translatable message.  But errors of the programmer can not happen in production, and thus should be handled differently.

#16 Avoid Overloading Methods

One of the things that programmers learn with object oriented programming is that you can overload methods. That is, have the same method with differing parameters.  This can be convenient sometimes, but most of the time, it is an exceedingly bad idea.

#15 Branch Handling with Fixes

This is really a management issue, not a coding issue. In short: when a bug is fixed on a branch, it should be at the same time (or immediately after) fixed in the trunk. The logic should be obvious, but I found out recently that some development teams are NOT following this guideline.This post is an attempt to lay out the logic of why a software development team must follow this.

#14 Never Catch and Continue

I ran across a body of code that is using a spectacularly evil coding pattern. This is not evil that presents itself as a devil with horns and pitchfork, but rather this is a wolf in sheep’s clothing. It is an evil pattern that looks so reasonable, and I bet most readers will look at it and initially ask “What is wrong with that?”

#13 Always Replicate Fix to the Trunk

We try to avoid having multiple versions of a product under maintenance at a time, but every product shipped to real customers has to offer support of the version that the customer has.  This post offer guidance around handling of bug fixes in a multi-branch development environment.

Working Around Java’s SSL Limitations

The Java run-time environment (JVM) is able to support connections to other servers using SSL, but it has this very inconvenient behavior of refusing to connect to self-signed servers.  A self signed server has the public key necessary to ensure private communications, but does not have a certificate that proves who it is.  In the default mode of operation, when connecting to such a server, Java SSL subsystem with throw an exception and prevent all communications.  But there are good reasons why a service that you want to communicate with privately may not have a certificate, and this post tells you how to accomplish this.

#12 context path and browser redirecting

What is the URL to the application? There is one, and that is the one that the user places into the browser in order to access the application. Unfortunately, along the way, the request will pass through many intermediate services which will distort the request headers. Many of the TomCat services designed to provide information about the context of the running application will return incorrect values. Thus we must be very clear on how to get those values correctly and consistently across the application, so that when the browser is forwarded it is always successful.