Simple reminder to keep it simple

This morning a tweet caught my attention prompting me to read this post by Gary Hockin also known as @GeeH. (There’s just something about that voice.[inside joke])  In the post he talks of his experiences while attempting to simplify code in a project, and in the process uncovers hidden dependencies that increased the codebase significantly in order to gain the benefit of a mere 100 lines of code.  He also highlights that in today’s mainstream PHP development, where many are using Composer to blindly include packages into applications, we may not fully understand code being pulled in with the consequence of accepting responsibility to maintain those additional packages as well.

I’ll wait a second while that sinks in…

Yes, that’s right.  If you include additional packages and libraries into your application you’re accepting the responsibility to maintain them.  No, I’m not saying you are responsible for contributing to the software package…unless you care to.  What I’m saying is you are now in charge of updating the software within your application, which now includes additional packages created by others.  As security holes get fixed, or new versions come out fixing bugs, it is up to you to ensure you update these packages in your applications which include them.

You’ve been living in a dream world Neo

Ha, didn’t think about that, did you?  If you did, Bravo, you’re behaving like a professional.  For the rest, welcome to reality.  Now go update the applications you’ve neglected.  But first a side note.

I’m not saying Composer is bad.  Actually I think the opposite.  Composer is awesome, and you should be using it if you’re not already.  As in the post by Gary above I’m simply saying it’s our professional duty to know what we’re asking Composer to do on our behalf.  Use it responsibly and do a bit of research so you’re not blindly including potential issues, bugs, security holes, and nightmares to maintain in the future.  Then if you’re satisfied with what you see, go ahead and “require” away.

But wait!  Don’t just look at the packages you’re including into your codebase.  Also take a look at their dependencies as well, because you are also accepting them in the process.  Know what you’re saying “yes” to.

Past knowledge

None of what I’m saying is new stuff.  A while back, in the beginning of 2012 (I thought it was earlier for some reason), Ed Finkler @funkatron wrote the original MicroPHP Manifesto to voice his concern over many frameworks starting to grow in size. (NOTE: Later there was a separate domain dedicated to housing the MicroPHP Manifesto, but I like the original better because the blog post associated with it helps highlight why it’s a concern.)  I encourage you to check it out and consider the meaning, and how it relates to your projects.

Again, nobody is saying large full frameworks are evil or other libraries should not be used.  The idea behind all of this is to caution, so you go in with your eyes open and “know” what you’re including in the codebase.  Know the responsibilities accepted by including other libraries.

Happy coding!

PHPUnit, Composer, PHPStorm, Oh my!

Installing PHPUnit within a project via Composer, then running tests through PHPStorm is not an intuitive process. However, with the right steps it’s actually pretty simple. Here is my story:

To launch the call for papers for the SunshinePHP Developer Conference it was a pleasure to use the OpenCFP project as a starting point rather than creating the entire thing from scratch.  While the project is still a “beta” with a few wrinkles to get ironed out, it’s still a pretty nice effort. (I have a pull requests pending, and another to submit.  Love open source!)

For my CFP I wanted a few more fields of information than the “out of the box” setup, so I quickly added them to the app.  However, doing this meant the included unit tests would fail.  But wait, I hadn’t run the unit tests yet!  I realized immediately how spoiled I had become with today’s modern frameworks with a testing method built in.  This little project did not have that luxury, so I would need to run the tests the old fashioned way, or let an IDE do it for me.  I decided to configure PHPStorm do it. (I’ll do the same for Zend Studio in another post later.)

The way OpenCFP was set up, using Composer, meant that PHPUnit was already placed in the /vendor directory as a requirement in the composer.json.  So rather than taking the lazy way out and using the PHPUnit already installed globally on my system, I wanted to use the latest PHPUnit within the project.  This requires 2 setup steps in PHPStorm.

Step 1

To start I needed to inform the IDE where to find the Composer autoload file and leverage the awesome PSR-0 goodness to autoload PHPUnit in the /vendor directory.  To do this I open the Settings via the icon on the toolbar, or by using the File->Settings menu item, or hitting the Ctrl+Alt+S keyboard shortcut.  Then in the Project Settings (top section) I expanded PHP to get the PHPUnit dialog.

PHPUnit setup in PHPStorm

Step 2

Now I had to add a Run/Debug Configuration for the project.  I did this by clicking on the toolbar dropdown and selecting Edit Configurations.

Edit Configuration

Once the dialog opened I clicked the “+” to add a run configuration, and select the PHPUnit type.

Choose configuration type

Now it was just a matter of adding the directory where the tests reside. (Name the configuration to your taste.)

Location of tests

All done!!!  Now I was able to run the tests simply by selecting the new run configuration defined in the dropdown, and clicking the Run button in the toolbar.

Good luck, and happy testing!

Developer advice

As the organizer of the SoFloPHP User Group I am often approached by entry to mid-level developers asking what they can do to advance in their career or become better developers.  Of course I am nowhere near perfect but have been around long enough to get a few bumps and bruises along the way, so below is what I usually share as some pointers:

Note: While some of these items are kind of PHP specific, others may find useful items as well.

  • No self-respecting person should be up at 4:05am sending emails.  Get some sleep. 🙂  It is OK to stay up late once in awhile, but force yourself to get to bed at a decent time (10) each day.  And try to get up early each day also (6 or 7), which will help you get much more out of your days. 😉
    • The myths about developers working all night on caffeine are false.  Yes, it happens sometimes, but it is rare.  Well rested developers learn more, write better code, and get more work done…period!
  • Track your time, and get in the habit of knowing what you did with each hour.  I personally use Hamster religiously, and find that I get much more done each day as a result. (I have it set to nag me every 15 minutes if I have not set an activity.)  If you are not using Linux as your desktop environment I am sure there are time trackers for the other operating systems, find one.
  • Certifications will not actually carry much value on your resume, so I would not make them a main focus.  Sure they do carry some value, but perhaps not in the way you desire.  Achieving a certification is a great personal accomplishment and will make you feel better about yourself, as well as give you bragging rights among developers.  (Most developers tell you they don’t care about certifications, but deep inside they are simply envious.)  While many certifications are not a true gauge of actual knowledge, they do represent a certain amount of skills.  However, I have found that most employers do not even notice certifications.  I am not saying don’t get them. What I am saying is to be aware the actual accomplishment may be different than you perceive.  When I started getting certifications it reinforced, in my own mind, that I knew what I was doing.  That gave me more confidence overall in my jobs, and was still a big “win”.  But do them in your spare time, not as a focus item.
  • Pick an IDE to use and learn it FULLY. I will not recommend one in this post, so explore and find one that fits how you want to work.  Then learn it COMPLETELY, and use it ALWAYS.
    • If an IDE causes you pain, don’t use it any more.  Pick another one.  This tool will be where you spend most of your day, so you should not be forced to spend your time debugging and fixing your IDE.  It should not crash regularly.  You should not dread opening it, instead you should look forward to launching it.
    • Use all parts of your chosen IDE. (FTP, version control, testing, coding, debugging, issue tracking, etc.)
    • Learn the keyboard shortcuts, they will save you time.
    • Just because an IDE is free does not mean it is good.  You should base purchases on value provided, not $$$.
  • Pick a plain text editor, and learn it well.  There are times you just need to do a quick edit, and opening an IDE, creating a project, etc. is just overkill for this.  Again, there are many of these available so I will not recommend a certain one.  Pick what you like best.
    • The best ones come with syntax highlighting.
    • There are some free ones, but don’t be afraid to pay a few bucks for a good one.
  • Pick a pet “full stack” PHP framework to learn, FULLY.  I recommend either Zend Framework 2, Symfony2, or CakePHP 2.* since these 3 are the most common.  But as with an IDE you should learn one COMPLETELY, and use it most of the time.  Each framework has its strengths and weaknesses, so choose one that works best for you.
    • Good frameworks have mechanisms in place where you can add plugins, modules, or helpers in case the framework does not fully support what your trying to do.  But stick to the framework as much as possible.
    • Feel free to write your own framework, but ignore the urge to use it for employers.  As professional developers we owe it to our employers to use more widely available frameworks.  It is just smart business.  It means businesses can find other developers easier, onboard them faster, and train the group more.
  • Always strive to make yourself replaceable.  If you are replaceable you are also promotable, and you can go on vacation pain free.
  • Learn to use GIT for source control, and use it for EVERY project you do no matter how small.  Sure there are other source control products out there, but currently GIT is the way to go.  All it takes is the command ‘git init’ in a directory and you are of and running.  No excuses!
  • Do things publicly so others can see.  Such as github, BitBucket, etc.  I recommend having code in some sort of public place for others to see how you code.  Don’t be shy.  I’ve had other developers provide feedback on code I posted on github, in a constructive way, and it helped me advance my skills.
  • Your LinkedIn profile is your best career tool as a developer.  Tweak it, adjust it, get everyone you can to contribute to it.  Add projects to it, etc. (See “Build your brand” below.)  Don’t connect with everyone who pops up, and be stingy with what recruiters you allow to connect with you.  If someone is not going to help your career in some way, they do not belong in your connections on LinkedIn.
  • Pick up small projects here and there that are NOT urgent, and you can take your time on.  These little projects will afford you a way to learn new things.
  • Get active in the PHP community.  I mean really active.  Sure, it’s OK to be a member of other communities as well, but the PHP community (world-wide as well as local) is what will really “do it” for you. (If you are going to make a career doing PHP.)
  • Give talks at local user groups, blog about your experiences, follow other blogs of good people (phpdeveloper.org is a good place to see activity of PHP community members blogs. Chris Cornutt does a great job at filtering out relevant posts and adds the best of them on this site.)
  • Get somewhat active on Twitter, join IRC channels, travel to a couple of conferences each year and get to know people “doing things”.  Then eventually start submitting talks to the conferences so you can go talk, and have your expenses covered to go to it.
  • Build your “brand”.  By this I mean to say YOU are the product.  Everything you say and do is your offering.  Your name is your “brand”.  Build the reputation carefully, and before you do anything ask yourself, “Will my customers like/buy this?”  If the answer is “yes”, then go for it.  If the answer is “no” re-evaluate.
  • If you are a woman, be careful.  While women are becoming a larger part of the tech community there are still many men who are not used to it yet.  They are jerks, and your feelings will get hurt sometimes in the process.  Learn to ignore them and focus on the good parts as you grow.  KNOW you are going to do great things, and work toward that progress.
  • Learn Linux via command line.  No need to go crazy with this one, but since most web servers are on Linux it is a good idea to have some knowledge in this area.  You should at very least know:
    • Basic vim commands to edit files on the server.
    • Be able to navigate the OS files and directories.
    • Be able to manipulate files on the server. (cut, copy, paste)
  • Spend some time each day on Stackoverflow.  Try to pick a problem someone posted and help them.  “Doing” is the best way to learn, and there are plenty of problems posted to Stackoverflow daily.  This is addictive, so manage your time and limit yourself.  But do it!

Of course there are many more tips, but I wanted to hit on some key items without writing a book on this blog post.  I hope you find this information helpful, and if you can think of some other hints and tips please feel free to share in the comments.

Good luck!!!

Clean Development Series: Part 4, Rewrite dilemma

Lately I have been talking about clean application development, and how developers can do a better job of it.  Due to the strong focus on this I decided to write some content from my latest talks into a series of blog posts.  Enabling everyone to reap the benefits of the subject matter, and allow attendees of my talks to refresh the content covered at one of the events I spoke at.

In part 1 of this series we discussed reasons for creating dirty code, and the things that dirty code can cause.  We followed with part 2 by giving a possible scenario of how developers get caught in a situation and start writing dirty code.  Then, in part 3 we covered “smells” that hint to dirty code, and some possible situations that can be a bad “smell” highlighting potential problems.  So, what happens when our code carries many of the bad situation covered in the first 3 parts?

Code that made us proud at one time has become an embarrassment we try to hide, and hide from.  In part 2 the developer was very happy with his work in the beginning, and so was his boss.  They were able to complete requests quickly, and everyone was happy to have such fast turn-around on new features.  Then, little by little the problems of the application started to grow.  The bugs began popping out, a change in one place leads to multiple problems in other areas, and time estimates start growing to compensate as the developers are forced to pad them for the unknown. As things become worse the developers tend to care less and less about the code, and this lack of caring shows in newly created code as problems continue to mount.

Many times the first signs of surrender come when the boss asks if hiring more developers will help get things done faster.  It’s an honest question, and makes perfect sense on paper.  If it takes two or three developers six months to create a new feature surely twice as many could do it in half the time.  So the boss instructs us to start a search for more developers to hire, and we spend two or three months (or more) of our “spare” time searching, evaluating, and interviewing candidates until we finally manage to find a couple.  After all, more resources equal more output…right?


Needless to say we go through a few developers, because all of them are not able to grasp the mess we’ve created.  Others just leave for greener pastures rather than try to figure things out.  Then a couple, either due to desperation or being hard workers, manage to stick around and get to work.  But for some strange reason the time-lines never seem to improve, and it still takes a long time to introduce new features.

The boss is very confused, and not happy, because he thought more resources would allow development to get done faster.  He even went to his boss and asked for permission to augment the team, and fought a good fight to get his way.  Meanwhile the developers, seeing the writing on the wall, start scurrying to provide answers for failing to meet expectation.  Technical debt has caught up to them, and it’s time to pay it off.

We talked briefly in part 1 about “technical debt”, and explained it was similar to buying things on credit.  Using credit to buy things means the debt continues to grow and grow, until we’re forced to deal with it.  Either we pay it off, or we go bankrupt and start fresh.  In relation to coding, if we continue to develop poorly taking the “short way”, our technical debt continues to climb with each bad thing we do.  Eventually we find ourselves in a situation where we either repair the code through refactoring, or we rewrite the application entirely and start fresh.

Unfortunately the first reaction to a poorly written application is usually a resounding “rewrite”.  Developers feel like a weight is lifted from their shoulders, as the manager hears a distant “cha-ching” sounds of money slipping away.  The old application took months, maybe even years, to build and cost a HUGE amount of money.  Developers, hosting, tools, sales, customer support, and the hidden costs of insurance/rent/utilities/furniture to keep it all running add up.  In the managers mind a rewrite means it must all be duplicated, and that’s not far from the truth when we consider the salaries of an entire development team for the time it will take to rewrite the whole application.

Challenging sale

In the past there has been times when I inherited an application full of dirty code and recommended a rewrite to the client.  On the surface it seemed like a good idea, and a win/win situation for both me and the client.  It allowed me to make a little more money, because a rewrite take longer than simply doing updates or creating some new functionality.  It also meant I could create the application “my way”.  Because if it was built using my favorite framework, with my coding standards, and unit tests, it would be so much easier for me to work with.

The customer would benefit from a “better” application, pay for less time on future enhancements because it was “better”, and might even get some performance gains with less bugs from the application.  The downside of course is that it costs the customer a much larger sum of money, and much longer time period, to have a rewrite done.

The rewrite

After much debate the developers may eventually win, and the manager will allow the rewrite.  But only if the team is divided so part will be dedicated to building the new vision while the rest will support the old application.  It only makes sense the developers who have been there the longest should develop the new application, since they understand the business better. (Even though they were the ones who created most of the bad code to start with.)  The newly split up developer teams start working.

Rewrite

As the “experienced” team starts the new application the other team continues to fix bugs, and develops new features in the old application.  It happens this way because business must continue to make money and service customers who continually need new functionality, or they will leave.  Which causes endless scope creep for the team developing the new application.  Not only are they attempting to build a new application, but they must also keep pace with new features added to the old application as well as incorporate any bug fixes and/or changes to the business logic.  We start to see how difficult the task of rewriting becomes.

Rewriting started with the best intentions as everything is planned ahead of time, code written in an organized way, and perhaps unit test are even written.  But as time moves on, and the scope continues to creep, the business side of the company starts to become impatient.  The developers start to hear, “Is it done yet?”, and under mounting pressure to speed things up they fall back into the bad practices used in the old application.  Before long the new application starts to suffer the same technical debt issues, and the downward spiral drags on.  Ultimately the developers end up in the same position of apologizing for padded time-lines, unpredictable bugs, and cascading errors.

Usually by the time this entire process plays out there has been a change of developers, and maybe none of the originals are still around.  The current team is now faced with two similar applications that both contain dirty code full of smells, and may not even have tests.  They are now faced with the same choices of the previous team…to rewrite or refactor.  And if they refactor, which application do they refactor?

Meanwhile the company, waiting for the new application, has been dragging its feet on some new features.  Or perhaps have been promising the new application to their customers and building expectation.  This costs the company money in lost revenue from lack of features, lost customers who went elsewhere to get the new features, and higher costs for the extra developers required for a dual-application path.  Eventually, if left unmonitored, companies cannot recover and go out of business from scenarios like this.

Refactor instead

On the other hand, what if we fought the urge to push a rewrite?  If the current application is working and already contains all the business logic needed, but has a very dirty code base, why should the customer endure the loss of time and money for a rewrite?  Plus, if we are new to the application and don’t really know all of the business logic, why should we endure the headaches and heated meetings while we discover every little nuance of a new application.

Now don’t get me wrong.  I realize there are some circumstances where a rewrite is absolutely necessary.  Perhaps the framework the application uses has had a major upgrade, or perhaps the application business logic is undergoing a large overhaul, or maybe the code is just…that…bad!  Yes, there are times a rewrite is inevitable, and simply MUST happen.  What I am introducing here is the idea that many times when we do a rewrite it may have actually been better for the customer, and maybe us as well, if we had simply performed refactoring as we went.

Refactor

What I have come to realize as a much better solution than the rewrite story above is to follow some of the steps, but take a different turn.  What I mean is that I still split the team up, but rather than instructing one team to build a new application I dub them as the “refactor team”.  Their job is to start refactoring the code one module at a time.  First they write unit tests, if there weren’t any.  Then they start performing scheduled refactors.  Meanwhile the other team starts following the new coding standards and styles, and writing unit tests as they continue to do bug fixes and adding enhancements.

Of course these two teams need to be closely monitored, and must communicate very often to ensure they are not stepping on each other.  IT IS VITAL that everything be managed carefully, and that the teams are communicating open and often.  Did I mention that communication is important, and it must happen often?

Sure there will be times when commits clash, and code will need to be altered using pair programming.  However, the cost of time and money will be greatly reduced from a full rewrite.  Not to mention it will help bring the development team closer together in the process.

After the initial modules are refactored in this manner it may be beneficial to rotate some members around on each team.  This will ensure that team members on both sides of the fence do not become bored, or fall into bad habits.

In closing

Remember, I am not saying one way is better than another in every circumstance.  It’s really a judgement call on which method is used to deal with the technical debt of the application we are working on.  However, I hope this post has helped highlight that a rewrite is not always the best solution.  Sometimes the best approach is to plan a series of refactors to recover the application from the junk pile.  We must carefully analyze the entire picture and determine if a rewrite is a “must”, or is it a “nice to have”.  Then we can honestly create a full list of pros and cons to more fully gain the big picture, and use that list to sell what we believe to be the best solution.

It may very well save the company from being a “used to be”, and instead make it a “will be”.

Clean Development Series: Part 3, Dirty Code (how to spot/smell it)

Lately I have been talking about clean application development, and how developers can do a better job of it.  Due to the strong focus on this I decided to write some content from my latest talks into a series of blog posts.  Enabling everyone to reap the benefits of the subject matter, and allow attendees of my talks to refresh the content covered at one of the events I spoke at.

In part 1 of this series we discussed some causes of dirty code, and then talked about the things that dirty code can cause.  In part 2 we followed that by giving a possible scenario of how developers get caught in a situation where they end up with dirty code.  Now in this part we will cover how to spot dirty code, and some possible situations that can be a bad “smell” and highlight potential problems.

Most experienced developers, and development “how to” books, have come to associate “smells” to help find dirty code.  Meaning that most dirty code can be found by looking for certain clues/smells, which like a bad odor can tell us something rotten is nearby.  When something smells we usually are forced to deal with the problem. (If milk smells bad we throw it out.)  The same is true of smells in our code.  Below are some common stenches we may encounter to help point out problems.

Dirty things smell. So does dirty code.

How to spot “common” dirty code

NOTE: All of the items below are not necessarily dirty code, but are merely indications that something may be wrong and require more investigation.

  • Incomplete error handling – While the lack of good error handling doesn’t automatically mean the code is dirty, it is usually a good sign that the developer did not care enough to complete things.  It’s only reasonable to think this carelessness probably washed over to other areas. End-users should never see “raw” error messages, and developers should be alerted to errors.
  • Memory leaks – If PHP faces a memory limitation it is usually a good sign there is bad code lurking under the hood.  We kick off an application and it is churning along, then BAM the browser goes all white.  There is no indication of a problem, except we get no results when something was expected.  Error reporting was turned on (in development), but returned nothing.  This is typical of hitting a memory limit.  In most cases this means memory was being used frivolously and not returned…poor coding. (Do not confuse this with the need to build large files or handle large chunks of data, though these can also be handled in a different manner in many cases.)
  • Race conditions – Though this is rare, it is always a pain when it happens.  There are many ways this can be caused.  A simple explanation is the application execute, and expect an answer to be returned.  However, the script continues along trying to use the return prior to it being ready.  Perhaps the script is creating a file on the file-system, and tries to access the file before the file-system has finished creating it.  The script failed, and when we check the file appeared to be there.  So what happened?  Or maybe we do a few AJAX calls back-to-back and our script is not sure which answer came first since AJAX doesn’t always return the results in the same order they were called.
  • Inconsistent naming conventions – Whether it’s a class, a function, or a variable, we should ensure our application is consistent in naming convention.  If we use StudlyCaps for the class name, do it everywhere.  If we are using camelCase for functions, do it consistently.  The same can be said for variableNames, that should use the same convention throughout the entire application to ensure those who follow behind us will be able to read our code.  This will also help in certain situations where we may have named a function and a variable by a similar name.  The convention will help us figure out what it actually is.  Also we should ensure that our names are descriptive and meaningful, so we can pretty much tell what is happening simply by looking at the name.  Doesn’t the function name ‘getFinanceCharge()’ make more sense than ‘charge()’?
  • Inconsistent coding standard – Coding standards can encompass many areas, and there are a few different standards available (PEAR, Zend, PSR-2, etc.) for those who are not currently following one. (I will talk more about this in later parts.)  The important thing is that we have a coding standard in place, and that our team is also using it on the same projects.  There is nothing worse than starting to work on a new project and discovering that 3 different developers were working on it and they all used their own flavor of coding standard.  We spend most of our time reading code versus writing code.  A coding standard makes reading that much easier when it is consistent.  For instance, putting the opening curly braces for a function on a new line throughout an entire class does make it easier to scroll through and pick out the functions starting point, if done consistently.
  • Un-initialized variables – By allowing our application to run without initialized variables we are opening ourselves up to problems.  In a loop an unset variable will retain the previous value it had from a previous iteration, causing our application to act in an inaccurate manner. This could also cause security issues where the application freely uses a variable that may have been set wrong early on, then did not initialize it again for later use.
  • Code lacks clear purpose – If we look at our code and say, “Huh?”, it is usually a good sign that this “smell” is strong.  Code within an application should be clear on what it is doing, rather than like a large puzzle to be solved.  Often this is caused by poor planning, and “flying by the seat of our pants”, as we build the application.
  • Large classes – Often if a class is very large it is usually because we have stuffed too many things into it.  Perhaps we have combined two or more different types of things into it and we should have actually created other objects out of them.  If a class is very long, and we find ourselves sifting through method names to figure out the one we need, we should start planning to break it up into more objects.
  • Functions do too much – (more than one thing) A function should be “single minded” and do only one thing.  For me this is a difficult one I often find myself fighting internally with, and often need to return to a function and refactor to break out new functions.  But that’s OK.  We should often refactor to simplify our code.  This one goes hand in hand with unit testing (covered later), which should only test one thing.  In order to make functions testable, and single minded, they should inherently be short.  How short?  We should be able to look at a function and immediately see that it does pretty much what we expected.  Nothing fancy, or hard to follow.  Functions should be short, to the point, and easy to understand at a glance.  If a function is 100, 50 or even 30 lines long, how can we possibly tell what it is doing at a glance?
  • Long parameter list – Referring back to the previous item, if a function/method is truly doing only one thing how many parameters do we really need?  Long parameter lists are usually caused by trying to keep our application DRY (Don’t Repeat Yourself).  We are working on a new part of our application and realize that we can reuse a function we created earlier, but it will require another bit of info to perform this new task.  So we add another parameter to the list and alter the function to multi-task.  Before we know it our list of parameters has grown to be 4, 5, maybe even 6. (I won’t go larger than that, because nobody should.)  I would challenge that if a function’s parameter list is longer than 2 it is doing more than one thing and should be broken down into smaller functions.  Agreed?
  • Globals used – I will only say this once…Globals are dangerous, and should not be used.  In a situation where we feel a Global must be used, we need to find another way…period!  There are huge security risks, inconsistencies to be accounted for, not to mention it takes longer to code by using them.  Remember, where do we spend most of our coding time?  Yes, we spend most of our time reading code.  If we need to track down a Global, it is hard to truly comprehend the amount of time we will spend tracking down where the Global may have been set.  Imagine someone taking over an application from another developer who used Globals!  Ouch!
  • Too many comments – Yeah, yeah, everyone says that commenting code is good.  So why do I feel it is a “smell”?  I feel it can be a bad smell if our code is so complex that we need to explain it.  If our functions/methods are only doing one thing, they tend to be small.  And if we add well named variables and functions to a small amount of code doesn’t that mean the code can be “self documenting”?  Instead of adding a comment, doesn’t it make more sense to simplify the code to be drop-dead simple and self documenting?
  • Notices, Warnings, Fatal Errors – When I take over a project the first thing I do is turn on full error reporting and try to use the application.  This is the best way to see how “responsible” the previous developer was, and will usually give a fast indication on what size of mess I got myself into.  Developers should ALWAYS code with error reporting turn ON for their development environments.  If I see a bunch of notices and errors I know there is no way the previous developer was doing this, and that means there are probably errors that were never fixed.
  • Switch statements – A switch statement is not really a bad coding practice, but it could be a missed opportunity to use polymorphism.  I have seen many applications in the past where the developer used switch statements in far too many places, and this made the application far less dynamic.  If polymorphism had been used instead and broken down into functions it would have made the application far more flexible.  A switch statement is also a sure sign we will need to return to the application at some point and edit the code when the customer requests that another criteria be added to the application.  Properly done that can be alleviated.
  • Temporary variables – We have all done it, and will continue to do it.  Developers will use a temporary variable to carry a value for later use by the application.  It is unavoidable in some places, but it can also be over-used and can lead to memory leaks if not handled properly.  Temporary variable usage should be limited, and only used when absolutely necessary.
  • No unit tests – Lack of unit tests are a sure sign that a developer was in a hurry.  It is also a sure sign that every line of code was not necessarily analyzed to ensure it functioned as expected.  It is also a good “smell” to highlight other potential issues, such as long functions, or functions that do too much, or large classes.  Unit testing, done properly, tests only one thing and ensures that we pay closer attention to our classes and functions in order to make unit testing work best.  If there are no tests it means we can get away with more, and be lazy.

While these are not the only “smells” that may be encountered, they are the most common indicators that ugly and spoiled things lurk inside.  Like a spoiled package of meat, you don’t need to open the package to know something is very wrong.  We should always analyze our code to look for these and other smells, then fix them quickly.  Remember, one bad apple will ruin a bunch if left unattended.  Don’t let these bad apples infect the rest of the code.  Fix them, take them out before they multiply, leave the code better than when you arrived.

As I have said many times, we read code more than we write code.  By eliminating smells we ensure that our reading, or other developers reading, of the code goes faster and enables creation of new code to be faster.  Not to mention how this affects our reputation.  If you write dirty code please believe that other developers WILL talk about you, and it can determine what jobs you get hired for in the future.  So please, write clean code and clean up old code.