All right. Let’s get the obvious thing out of the way right up front.
One could easily argue that code quality (and poor code quality) is subjective. ?You use camel case while I use Pascal case, and we could argue about the “quality” of the code in those terms. ?But I have no interest in that.
So instead, let’s talk about code quality in terms of observable outcomes. ?You may look at a codebase and, based on your experience, conclude that this unfamiliar code is of poor quality. ?Who wrote this, anyway!? ?But you do that without understanding outcomes. ?Does this code serve its purpose in production with minimal issues? ?Does the application satisfy its constituents? ?And does the team consistently deliver features on time and on budget? ?At best, you can make educated guesses about that information when simply reading the code.
I have a bit of an advantage in my study of codebases. ?You see, I work as a consultant, specializing in codebase assessments, developer training, and team strategy. ?So I receive phone calls from clients when the external qualities are demonstrably poor — in other words, when the code has many issues, the application fails to satisfy its constituents, and the team misses deadlines and causes budget overruns. ?It turns out no prospective clients ever call to say, “Hey, things are GREAT, but will you come take a look at what we’re doing anyway?”
So I wind up looking at codebase after codebase that produces bad outcomes. ?I assess and analyze these things, and I’ve come away with some properties of the code that invariably correlate bad outcomes. ?Here are five things contributing to your poor code quality.