I write from time to time on code quality and structure because it is a topic of interest to me. Clean code and well named logical structures, methods and objects really pay off during the infinitely long Support And Maintenance phase of software development.
Some could accuse me of having too many opinions on the topic, and I’d guess they could be on to something. Heck, I’ll probably disagree with something I’ve said today, tomorrow, just because I’m always refining and learning.
While some of what I think/advocate/do is opinions, and could be subjective, I’d like to share some code I found on a project today and talk about the importance of method names.
A method should describe it’s intent or behavior at the level of where it is inside the program. For example, a method named load() might be sufficiently descriptive to represent the behavior and be flexible enough to withstand a refactor or two. In other places in the program, perhaps the right method name is loadShippedOrders() since there will always be the concept of a shipped order in our proverbial system.
You get the point, right? There is a wide range of OK-ness for method names, with behavioral descriptiveness and refactorability as being two made up words that really judge the method name quality.
I found code today that really flies in the face of any of these principles. The names of these methods do not in any way describe any behavior of any system I’ve ever written, nor will probably be lucky enough to write.
method bodies removed to protect client interests
Be the Judge Yourself:
Before you ask, this code was found in a production eCommerce system that is currently running that has nothing to do with Phasers, Energization nor beaming anything to any location.