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.
Conclusion
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.
Subscribe to:
Post Comments (Atom)
3 comments:
About the package-by-feature or package-by-layer, you will probably end up mixing the two of them. Once your code gets big enough, you will need to choose between com.acme.web.admin or com.acme.admin.web.
I have worked with both and prefer the first. The second is better implemented by making separate projects and connecting them using web services.
Distinguishing between fields, parameters, and local variables is something I do as well--I *don't* always view (or edit) my code in an AST-aware IDE. I might glance at it using "less" or do a quick edit in TextMate or Notepad++.
Forcing a developer to rely on an IDE to understand your code is just as foolish as doing your work in Notepad.
Dave,
Even those editors you listed have syntax-aware formatting.
Why would forcing use of an IDE be any more foolish than forcing use of any text editor (be it Notepad or vi)? Should I ensure it formats properly in my WebSVN server? Should I also make sure my code reads well using punch cards?
My point being, 95% of the time code is being read, its done so through an IDE. Changing a style guideline as important as variable names to accommodate the remaining 5% seems like folly since, in my opinion, it reduces readability for the other 95%.
Post a Comment