Langr Software Solutions | The Compulsive Coder, Episode 8: You Might Not Like This

Annoyed

“Annoyed,” courtesy Feliciano Guimarães. License.

These are things I like to do in code that others might find off-putting or even stupid. Convince me that I’m wrong. Please. Comments and castigations welcome.

Ignore access modifiers for fields in tests. We’re always taught to make things private when possible. For Java, I simply omit the private keyword–it’s one less piece of clutter, and these are tests, which should have no clients.
Start my test class names with A or An. Examples: AnExpirationCalculator, APantry, AnItem. This means that I have a naming convention for tests that is vetted by sheer readability. For example: APantry.listsItemsExpiringToday(). I’m actually ambivalent and even inconsistent about this; if enough people beat me up, I might change, but I kind of like it the more I do it.
Eschew safety braces. Why type if (x) { doSomething(); }
when if (x) doSomething(); will suffice? “But what if you forget to add the braces when needed (ed: and you don’t remember to format the code)?” Has yet to be a problem, particularly since I’m doing TDD.
Put single-statement if‘s (and for other similar control flow statements) on a single line. In fact, single-line if‘s make the use of safety braces look even stupider, as the previous bullet demonstrates.
import packagename.*; … because I figure one could always hover or automatically get the imports to show explicitly if needed. Lately though I’m feeling a bit repentant and showing explicit imports… for pedantic reasons?
Largely ignore code coverage and other static-code-analysis-tool-generated metrics. My sh*t does stink sometimes, but I know when it does and when it doesn’t.
Use Java. Well, most of the shops I interact with still use it. It is our LCD language.