The ability to explain something quickly and accurately with a minimum of fuss is usually an advantage. There are exceptions however. My continuing explorations of the JasPer source code are a prime example of that. Too often programmers abbreviate names in source code as if somehow this makes their code better. The thinking is usually that shorter names are quicker to type and therefore shorter names means shorter development times. This is a false economy.

Code is read many more times than it is written and most programmers are relatively fast typists. The time saved not typing a few characters is usually lost when you return to the code a little while later to fix or extend it and have to remember or work out what your abbreviations stood for. Things are even worse when it's a different developer trying to understand the code. Abbreviations which made perfect sense to the original developer may make no sense to the person now reading the code. Not only does this require the new developer to look up the abbreviations, it also increases their cognitive load as they must remember the abbreviations and mentally translate them as they go.

All of this is true in spades of the JasPer source. With the qmfbids (Quadrature Mirror-Image Filter Bank ID), mctranss (Multicomponent Transform), cblkstys (Code Block style) and pis (Packet Iterator, not number of radians in half a circle), understanding JasPer often feels like an exercise in decryption in itself. Fortunately the more I work through the more I find trivially reduces for the specific limited functionality I require.

Brevity can be a virtue in many areas. When it comes to variable, function and class names however I'll take verbosity over terseness any day of the week. Just imagine a world of lex_comp and set_sym_diff.

?nigma