Is there such a thing as bad programming code?

I'm sure this is something that has been discussed somewhere, or maybe you've thought about it.

Can there be such a thing as "bad" programming code?

We have all encountered code that made us say something like

  • "What was he thinking?"
  • "Why did he do that instead of using X method?" (X being a built-in method that already does what the code does manually)

But is it bad programming?

We all know there are usually a dozen ways to do any given task in VBA. Some are more efficient than others. Some ways result in less code. Some ways follow best practice. These usually overlap. What do you consider a "good" piece of code?

  • Short?
  • Most efficient?
  • Outside the box?

Just because a piece of code is long or inefficient or reinvents the wheel, it may still work. Some people might say there are only two kinds of programming code: good code and code that doesn't work. If the code works, can it ever be called bad?

If the code is a little bit slow or does some looping, can it be called bad?

For example, if I write this statement:

Dim workbookName, worksheetName As String

Is this bad code if I use both variables to hold strings? I mean, the code will still work, it may be a few milliseconds slower, it may not be the King's VBA, so what's the problem? I may have copied this from another website without knowing that it really means

Dim workbookName As Variant, worksheetName As String

At what point does code technically become bad? Is it possible, simply by looking at the above line, to determine whether the writer is honestly ignorant about how to properly declare variables? Or is the code just prima facie bad?

I have come to the belief that there is such a thing as bad code. Ex:

  • Multiple hardcoded values (whether it is magic numbers or version-specific hardcoding)
  • Writing ("creating") code that does what built-in methods already do
  • Looping through worksheet ranges instead of arrays
  • Localized code

One of my pet peeves is code that is tightly coupled with a particular workbook. The code is typically localized and will not work in any other environment without extensive modification.

This annoys me because the code is almost useless. It is only being shown to show off or demonstrate some marginal coding technique that almost nobody will ever need to use. The code relies on a very specific workbook setup, and the slightest deviation will cause the code to fail. The chances of anyone (other than the author) being able to actually use it as-is are low. We've all been to training classes where the trainer only shows you what he wants you to see and can't answer the simplest question that falls outside of the predetermined agenda. (psst: you're not supposed to ask those kinds of questions)

If your code only works for you, keep it to yourself. I consider localized code "bad" not because it doesn't work, but because it's been posted in public yet has a severely limited scope. When I see this kind of code, I have trouble keeping my fingers off the keyboard.

Although my instinct is to immediately attribute this type of coding to ignorance, after reading Why You’re a Bad PHP Programmer I've realized that I probably have a self-serving bias. I understand that there are a lot of circumstances other than bad intent that could lead someone to write bad code. I know I've written plenty of code that is pretty scary looking to others, without having bad intentions. It may be an innocent series of concessions that leads to the abominations I've given birth to.

Do you do any of the things that could land you in the programming doghouse? Things like

  • writing poor comments — you literally explain what the code is doing (which should be obvious from the code itself) instead of sectional commenting that explains the purpose of the code?
  • writing "Dim workbookName, worksheetName As String" instead of "Dim workbookName As String, worksheetName As String" or similar things which, while technically correct, are inefficient?
  • publishing code that only works under very limited conditions and can't be cut and pasted elsewhere?

Do you think there is such a thing as bad code? If so, what do you consider bad?

About JP

I'm just an average guy who writes VBA code for a living. This is my personal blog. Excel and Outlook are my thing, with a sprinkle of Access and Word here and there. Follow this space to learn more about VBA. Keep Reading »


Related Articles:


Share This Article:

Share and bookmark this articledelicious buttonfacebook buttonlinkedin buttonstumbleupon buttontwitter button

comment bubble 5 Comment(s) on Is there such a thing as bad programming code?:

  1. If I construct a building and it doesn't collapse in the next 20 years, it is a good building? This can't be that simple…
    Well, in soccer, there is no such thing as an ugly score. If it scores, it is OK.
    But if I was delivered a code with a lot of bad programmning manners, I would question the ability of the programmer before asking for another project.
    Opening workbook instead using SQL queries to extract data from workbooks, excessive use of .Activate or .Select methods, messing user's Application properties after running code, no error handling are, no Option Explicit use, long subs or functions, lots of declared public variables are, for me, bad coding examples.

  2. Well, I tend to try and write pretty clear comments in my code, so I guess I have to question what is too much? My standard commenting mantra is pretty much about inline with anything that I post in an article on my site, and I do it pretty deliberately. My reasoning is simply that, in my organization, it is VERY unlikely that I'm going to be followed up by someone who has my knowledge. (With the exception of one of my staff who has been exposed to it once or twice, no one even knows what the IDE looks like!) So to help him out and learn his way through it I try to leave a pretty clear audit trail.

    With regards to bad code… I guess you'd have to ask the purpose really. If the routine is needed for a one-off situation, and it's ugly, but it works, is it really bad? Should you spend hours perfecting it if you're just cleaning up a data set? If you don't have the skill, is it bad code? When I teach into VBA courses, my focus it to get the students the ability to do something effectively, not necessarily efficientlyy. That can come later as they learn more.

    I think we need to recognize that we're experts, and hold ourselves to a much higher standard than many others. We'd never be happy without elegant and efficient code that we can use in all kinds of situation. But the reality is that it took us a long time to get there. And many users can't be expected to know that out of the gate.

    Now, as I'm supposedly an expert, I'd have to say that there are things that I consider best practices that I follow to avoid writing bad code: declaring all variables with types, declaring routines as public/private, using whitespace, indenting code, develop early release late bound, encapsulate procedures in re-usable chunks, etc.. If the code I'm reading doesn't have those qualities and the author was supposedly an expert, I would certainly question that status.

    In all honesty, so long as the code does the intended job and returns the right result though, I wouldn't call it bad code. I might call is sloppy though, and that's something I do frown on. I take great pride in trying to make my code as elegant, robust and self auditable (plus comments) as possible. But I also have to temper thatn by balancing that goal against how much time I have. I'm also under no illusions that I always (or even mostly) get it right. ;)

  3. Bad code. Depends on who you are comparing it to. If I'm comparing it to myself, bad code is what I was writing a few months ago (and I'm sure the longer I code and the more I learn the time from will go up) and now I'm writing better code. If I'm comparing to others then bad code is whatever I write, because there's at least one person better than me (of course, I haven't been writing for that long, so there's a ton of people that write better than me).

    Yes, if you are talking about professionals, then yes, if you aren't doing those simple things that make your code fast and efficient and easy to change, then yes, your code is bad. I'm just finishing up my first consulting job that has taken about a year and a half to complete, the code that I started out with is pretty sloppy, the code I'm writing now is leagues ahead (now I use a ImportExcel function (among other standard functions that I use now) that makes it so I don't have to worry if I'm returning a single value or not, it always returns a 2D array, makes it much easier to code).

    For my personal products, I've turned to VB.NET with Excel DNA. It's taken awhile to get up to speed with .NET but now that I'm there, it is much easier to write good code because of LINQ and declarative programming among other things.

  4. "Looping through worksheet ranges instead of arrays"…

    The dichotomy you're using puts a lot of people firmly in the 'bad code' camp, including myself. However, I'd hope you can at least say there are degrees of bad. For self-taught people less accomplished and experienced than you, who haven't progressed past whatever the Macro recorder gives in some areas, using worksheet ranges is a must. In some ways, I have improved to write code that's not bad, or to write code that's more efficient– in others, I have not because I don't know how or I don't have time to learn when it's time to use it or because I don't code enough or whatever other reason/excuse.

    As someone who is less sophisticated, bad code to me would be hardcoded values, lack of comments, and just plain poor logic– which is more of a process issue. Spreadsheets and/or the code sitting behind them need to have a logical flow.

  5. I think Chris has a point. For some people there is a limited amount of time that can be devoted to programming. I personally got started just hacking code together that would “get the job done.” Of course, I’ve improved over time but still have a ton to learn before my code could be called good. Nevertheless, it has saved me many hours of manual refreshes.

    I do think it should be everyone’s goal to write good code, but there is going to be various levels of bad as Chris pointed out.

    With that being said, I hope that people like you, JP, will continue blogging and sharing your knowledge with the rest of us…especially VBA best practices.

This article is closed to any future comments.
Peltier Tech Charting Utilities for Excel