Over the years, I’ve become fluent in several programming languages: C#, JavaScript, Visual Basic .NET, Ruby, FoxPro, and a few others. Last month, I started the process of adding Python to my repertoire because my development team is currently in the process of building a data processing platform. This platform pulls data from multiple sources of data and uses Python (with its rich ecosystem of statistical libraries), to run various models over the data. I was tasked with integrating these Python modules into our ETL pipeline, so I asked the data analyst for a copy of the code to determine first, how it works and second, how I was going to integrate this code into our pipeline.

I spent some time with the developer. The smell of the code became apparent rather quickly. When developing the code, the analyst implemented a metadata-driven approach to loading and running modules for each client. The application looked up the client code and used the parameters attached to that client to make it simple to maintain.

At first blush, this was a good sign. This code "smells" rather nice. Upon further digging, I found some code that has a distinctly unpleasant odor. The main program accepted a number of dynamic command arguments. These parameters read and assigned to different memory variables. Okay, so far so good. Where was the smell? The smell came from a called module that reread the command line arguments:

start_date = "'%s'" % sys.argv[5]end_date = "'%s'" % sys.argv[6]

It didn’t look correct to me. It shouldn’t be the job of the called program to reread the command-line parameters from the calling modules argument list. This was a definite smell to me.

I know that THIS is not an interesting story. The interesting part is that I was able to identify a code smell in an unfamiliar programming language. You see: Code Smells are Universal. Let’s take a look at some JavaScript code used to validate the format of a date string in Figure 1. For reference, the correct format of the string is as follows: 1977-05-25 01:30 pm

Figure 1: Validating the format of a date string.

This code has several different smells. First, it has a bit of stinker code in that it uses brute force to validate a date time string. Can you think of better ways to write this validation? The first idea that comes to mind is that this code could probably be handled by a regular expression. So, does this code have a bad or a good smell?

When it comes to code, whether it has a good or bad smell is a subjective thing. This code is probably a mix of both. The bad smell comes from its brutish nature. It basically validates each character one at a time. The good part is the intention of the code; when an error does occur, the code tells the user EXACTLY what’s wrong with the time string.

Finally, other smells can be determined by answering the following questions:

  • Does the code work as designed?
  • Is the code maintainable?
  • Is the code understandable?

In my judgement, the answers to these questions for this bit of code is yes. Even if you don’t write a lot of JavaScript code, can you decide for yourself whether the code is any good or not? What comments would you make about this code? Tell you what. Ping me at @rodpaddock on Twitter. I’d love to hear your comments about this code, good or bad. Please be kind though.

After spending some time thinking about the Python code, I came to the realization that most programming falls back on the old premise: It’s the concept that matters. By spending time mastering concepts, I’ve been able to master multiple languages. And now I’ve also found a new superpower: the ability to look at code in unfamiliar languages and determine whether or not it has code smell, both good and bad.