As a Java noob, I find the “code smell” topic to be rather fascinating

I realize this is rather geeky of me to say… but I guess I’m one of those people who tend to learn from mistakes, both other developers and especially my own. I’ve learned it’s much better to learn from OTHERS’ mistakes though! Here are some interesting points of “code smells” I’ve come across that I could probably use some work on with my Java / OOP PHP.

From: http://www.codinghorror.com/blog/2006/05/code-smells.html

Lazy Class: Classes should pull their weight. Every additional class increases the complexity of a project. If you have a class that isn’t doing enough to pay for itself, can it be collapsed or combined into another class?

I tend to make a class with the anticipation of needing if for a number of reasons in the future during my planning, but then end up only using it as a sort of “stepping stone” and have other classes do my heavy lifting. I could get rid of some of the getters/setters I create for example, but feel reluctant to, because I think to myself, “Well… I’ll just leave it in there. I might need it for some reason eventually…”, when I usually don’t.

Feature Envy: Methods that make extensive use of another class may belong in another class. Consider moving this method to the class it is so envious of.

(During my initial designing of the application, I often compartmentalized which tasks need to happen by creating multiple methods to do each thing individually. By the time I’m over halfway finished, I realize that some of my methods are doing very much the same thing. If I were to just add an if statement to one method, I could eliminate other methods completely and make my code much more elegant and concise.

Indecent Exposure: Beware of classes that unnecessarily expose their internals. Aggressively refactor classes to minimize their public surface. You should have a compelling reason for every item you make public. If you don’t, hide it.

OOP was still kind of new to me before 2011-2012, so the idea of “data hiding” seems unnatural. In fact, I’ve gone out of my way to create function libraries into a single “include file” in PHP, and added the include statement to each of my web page “header” templates so I can access code on the all the pages of the site, “just in case”.

I started to see the benefits of the “private” methods/classes as a means of controlling the “flow” of my Java / OOP applications so that I can quickly say “oh, that’s a private method, so my other method can’t be changing the value there… where else could it be happening?” It’s providing me with a new way of thinking when I develop applications entirely. It’s a bit more cumbersome in the design process, but the end result is quite a bit more “fluid” and elegant.

From: http://en.wikipedia.org/wiki/Code_smell

In computer programming, a “code smell” is any symptom in the source code of a program that possibly indicates a deeper problem. Code smells are usually not bugs—they are not technically incorrect and don’t currently prevent the program from functioning. Instead, they indicate weaknesses in design that may be slowing down development or increasing the risk of bugs or failures in the future.

I have great examples of PHP code smells, as I was often tasked having to go back and rework 3 other developers’ code for a maintenance and upgrade project for an employer:

It was a Web Portal that POUNDED on a SQL database. It was taking field level values of a result set of a SQL query, creating new queries from that result set, and sends NEW queries on different JOIN-ed tables/views to produce the desired reporting. The database servers capacity and internet pipe were PATHETIC for what the company was trying to accomplish. Optimization was absolutely critical in this case. The “too many cooks in one kitchen” code was thrown together to make an impossible deadline, and with little to no business requirements. It was a disaster to unravel… BUT… it DID work! It was slow during peak usage times, but it was fully functional for the most part.

Did it have a bunch of bugs? No… not really. It just lacked design, structure and consistency. It was in serious need of some code deodorant though… I was then able to write new SQL queries that consolidate all the bits and piece that were added “ad-hoc”. This allowed me to stream line single database connections and result sets. This is far more desirable in lieu of pounding away with 3000-5000 database connections opening and closing in foreach loops. These are a few ways I have learned how to cut down on code smells within projects that I touch.

And lastly, From: http://c2.com/xp/CodeSmell.html

Under the heading: Not enough code, better put the half-baked code back in the oven a while:

I found this to be familiar:

Explicitly setting variables to null

This can indicate references to things that this code has no business referencing. Or perhaps the structure is so complex that the programmer doesn’t really understand it. This comes from the need to feel safe when editing pre-existing code that is hard to follow or understand.

I TOTALLY get that.

I’ve always believe that an ounce of prevention is worth a pound of cure. Sometimes I will expect to need something, but either later on I forget what I created it for. Also, sometimes I assign a value to ensure I’m not trying to calculate or concatenate with a NULL value. This is often done with the legendary PHP check:


// PHP syntax
if (is_null($some_junk) == false) {
echo "Do you want to go play pool or ".$some_junk."?";
} else {
echo "I don't have a thing to wear tonight.";
}


The more I find a useful implementation to practice my Java with, the better I will get at it. Hopefully, much like I have with Perl/PHP, I will get better at the planning and design process and prevent such smelly code I’ve laid thus far as a Java noob.