Smelly Code - Confessions of a Java Noob

The topic of "code smell" is rather fascinating, as well as rather "geeky". Is it better to learn from one's own mistakes while developing in a new programming language, or, seeing the coding mishaps of someone else?

Here are some interesting points of "code smells" that most OOP (Object-Oriented Programming) "noob" developers could probably use to get better at Java / OOP PHP.

Great examples of code smells are realized when a developer is tasked with having to go back and rework multiple developers' code for a maintenance and upgrade project for an employer. A common example might be a Web Portal that POUNDS on a SQL database by taking field level values of a result set of a SQL query, and creates new queries from that result set, and sends NEW queries on different JOINed tables/views to produce reporting. The database servers capacity and internet pipe might be PATHETIC for what the company is trying to accomplish, so imagine optimization is rather 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 is a disaster to unravel... BUT... it somehow work! Even though, it is still slow during peak usage times, but fully functional for the most part. Does it have a bunch of bugs? No... not really. It likely just lacks design, structure and consistency and n serious need of some "code deodorant".

From: http://www.codinghorror.com/blog/2006/05/code-smells.html We get three great definitions for "Lazy Class", "Feature Envy" and "Indecent Exposure".

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?

OOP "noobs" tend to make a class with the anticipation of needing if for a number of reasons in the future during the planning phase, but then end up only using it as a sort of "stepping stone" and have other classes do the heavy lifting. Perhaps one could get rid of some of the getters/setters they (or a sophisticated IDE like NetBeans or Eclipse) create for example. Since many attributes can be present in a class, getters/setters are usually a benefit to data encapsulation so a developer new to OOP may feel reluctant to hit the delete key because of thoughts such as "Just leave it in there. It may be needed for some reason eventually...", when it often does not.

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 the initial design of the application, procedural developers tend to compartmentalize what tasks need to happen by creating multiple methods to do each "thing" individually. By the time the developer is over halfway finished, the often realize that some of the methods are doing very much the same thing. If they were to just add an if/else statement to one method, I could potentially eliminate another completely.

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.

Object-Oriented Design (OOD) is often a completely new idea to a developer that has experience with procedure style coding, so the idea of "data hiding" seems unnatural. In fact, many time a developer with go out of the way to create function libraries into a single "include file" in PHP, and add the include statement to each of my web page "header" templates so the can access code such as function libraries on the all the pages of the site, "just in case". Solid OOD principles push a developer to start seeing the benefits of the "private" methods/classes as a means of controlling the "flow" of a Java / OOP PHP applications so that they can quickly say "oh, that's a private method, so other methods cannot be changing the value there... where else could it be happening?" It provides an experienced procedural developer with an entirely new way of thinking when develop applications. It is 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, 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.

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

Not enough code (better put the half-baked code back in the oven a while)

Explicitly setting variables to null. Can indicate that either there are references to things that this code has no business referencing, or the structure is so complex that the programmer doesn't really understand it and feels the need to do this to be safe.

An ounce of prevention is worth a pound of cure. Sometimes developers will expect to need some variable or method for some lesser purpose, but later forget what it was created it for after lunch with the VP, or perhaps feel the need to assign it a value so that they do not try to calculate or concatenate with a NULL value with the legendary PHP check:

<?php
                      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.";
                      }
                      ?>

Select all Open in new window

The more a new OOP developer can find a useful implementation to practice Java / OOP PHP, the better they will get at it. Hopefully reading this article and some more practice, much like with these developers' beginnings with Perl or PHP, they can get better at the planning and design process and prevent such smelly code they may have laid thus far as an OOP noob.