Recently published on JavaWorld, Four harmful Java idioms, and how to fix them struck me as something I could have written if I lived on Bizarro World.
Point by point:
1. Use a naming convention to distinguish three kinds of data, not two: local variables, fields, and method arguments.
The author seems to discount another injury made unto the code's reader, that of a code's noise level. Prefixing variables to indicate scope creates tiny conceptual speed bumps the reader must navigate. IDEs already format variables according to scope, so there's no discernible benefit. If you're using notepad/vi/emacs, then I've no sympathy for you, and I'd be hard-pressed to enact a style guideline to accommodate outdated development environments.
We're fortunate enough to be programmers in a time when programming languages are expressive. Attempts to make the code less English-like, like using prefixes, I regard with suspicion.
3. Don't use JavaBeans for modeling the database.
His thoughts regarding JavaBeans applied to database records rest upon a premise I just am unable to reconcile with my own approach. Namely, my "JavaBeans" aren't modeling database records, they are modeling my domain. The database is also modeling the domain, though naturally through normalized tables and such and not through Java's OO design. It seems to me if a developer attempts to model the database, he/she is ditching Java's rich expressiveness in favor of the bleaker designs of RDMS. I can see how this would lead one to opt for "immutable classes" instead of JavaBeans.
4. Order items in a class in terms of decreasing scope, with private items appearing last.
Again, were we programming in notepad, this might make more sense. With an IDE, I simply hit a key and navigate to a private member's declaration. Further, I'm sure I'm not alone in that I'm accustomed to seeing a class's "vital stats" by looking at the top of it. If I had to switch to the bottom to view its private couplings (probably a class's most important vital stat), insanity might quickly ensue.
You'll notice that I haven't addressed his point #2, favor package-by-feature over package-by-layer. I'd really have to work with such a package design before having an opinion on it, and the article is devoid of any examples. Those interested in hearing more about that I'd recommend perusing a discussion that occurred on TheServerSide here , which, not coincidentally, was started by news of the author's own web4j release (probably the only Java web framework that isn't open source). In fact, that discussion will also provide some context in which to judge other aspects of the author's thesis.