Does it really matter what the code looks like? The short answer is an emphatic ‘yes’.
matters because ultimately writing code is about discipline and
details. If the code is just slapped together, really messy and there
are issues like extra blank lines or extra variables laying all over, it
reveals an awful lot about the author. Perhaps they were in a huge rush
or even a panic. Maybe they are just lazy or don’t care. Maybe they
really don’t understand what they are doing. Any which way, their
state-of-mind while doing the work was such that they lacked the
self-discipline to clean up their work and thus were probably not
particularly good with playing attention to the all-important details
either. Messy code is almost always fragile and usually a bug fest.
is basically knowledge and intelligence encoded into a sequence of
steps for the computer to execute. It is only as smart as the programmer
that wrote it, and it is only as flexible as they conceived of the
runtime environment. If the programmer’s style if haphazard or their
thinking muddy, then the code will suffer the same faults. If however,
the programmer’s understanding is crystal clear and they grok the
environment, then the code will stand up to a lot and keep on working.
getting something to barely work for a extremely limited set of
circumstances is not good enough to be considered professional quality.
Working code has to work correctly for all circumstances; for all
inputs; for all changes in the environment. It needs to be able to stand
up to the full range of things that happen in the real world. If it
doesn’t, that’s an indication of a lack of quality.
experienced professional programmers always come to understand is that
quality starts in the code. If you want a beautiful system that is a joy
for the users, then the code underneath needs to not only be smart and
well designed, but it also needs to look marvelous as well. The
‘platinum’ standard of coding comes from taking a complex problem and
making the code look simple. Elegance comes from both the readability
and the underlying skill used to make the answer look obvious. A
well-written piece of code hides the messiness of the details carefully.
It misleads a reader into thinking it took just a fraction of the time
to get written. It leverages abstraction to avoid redundancies, but not
at the cost of becoming obfuscated. It basically takes the knowledge of
the programmer and encapsulates that into a small, tight region of the
system that works correctly and makes it easy to extend later. It draws
clean, hard lines through the problem and then ties them up with the
lines in the solution. And because it is easy to see its sole purpose,
it makes it really easy to detect and fix bugs. Quality software comes
from quality code.
it is not just quality that is affected by bad code. Testing, bug fixes
and support are all heavy drains on software development. Work spent in
these areas is work that is no longer available for new development.
Crappy-code bugs are way harder to find and fix, so as a consequence
they chew through more resources. It actually costs more to write bad
code than doing a good job the first time around, line for line.
often projects get caught up in a vicious cycle of coding fast and
recklessly then loosing too much time dealing with the inevitable
problems, causing them to go right back to fast and reckless again. That
type of cycle feeds back into morale, and the whole project does a slow
spiral down the drain.
for programming style, mostly it doesn’t really matter which
conventions are chosen. Some conventions do make improvements in clarity
or readability, and help to make inconsistencies more obvious, but so
long as all of the code is consistent, it can always be refactored to a
better convention at some point.
all of the variable names the same, laying out the lines with the same
whitespace formatting and finding strong conventions for naming core
parts like methods and objects establishes a strong foundation for the
code. Normalization and abstraction help to either hide the details or
put them forth in a way that inconsistencies are noticed easily. A solid
architecture decomposes the system in a way that makes it easy to trace
bugs quickly back to isolated parts of the code base. All of these
things help in reducing the number of bugs, and also reducing the time
it takes to fix them. And because of them, it opens up more time and
resources for new development.
a high quality software system always means playing close attention to
the millions of details floating about the project. It is not enough to
just hack through the work, it is a detail-oriented process, which often
needs great time and patience. All development projects come with
outrageous demands and too little time, but being sloppy doesn’t help
with these issues. Part of the great skill involved in being a
professional programmer is the self-discipline to do the right thing,
even under intense pressure. Sloppiness and short-cuts, while tempting
are just putting off today, what will always cost more in the future. If
the goal is quality, then that has to percolate into every tiny detail.
Fast and cheap is always crap in software.