What is good code?
We know when we spot bad code. But because good programming is harder to define, it’s difficult to know you’ve actually created quality.
In my experience, there are two great questions that can indicate code quality:
- When you’re working on a team, do others easily understand your code’s logic?
- When changes are required, is it a quick and straightforward process?
If it’s difficult to explain code to others or if lots of things break when making changes, then chances are the code is bad. Fixing these problems often involves finding sensitive solutions in the context of a particular environment. For example, perhaps it’s a matter of using an established design pattern, or writing unit tests.
Free trial on Treehouse: Do you want to write better code? Click here to try a free trial on Treehouse.
While it’s important to fix code directly, it’s equally important to address the conditions that lead to bad code in the first place. Every time I’ve encountered poor programming on a project I’m working on, it has typically stemmed from the same chronic issues.
Don’t optimize code too soon
When I first started programming, I remember marveling at my own “brilliance” when I was able to condense several lines of code into a single line. I would remove all the spaces and comments I made, nest multiple function calls instead of using clearly marked variables, and so on. I would also look for any type of optimization I could find, no matter how small.
Writing clear code is more important that writing clever code. I once learned this when I had to go back and modify one of my own projects after letting it sit for six months. By that point, I had to spend a lot of time just figuring out what I wrote before I could make the necessary change. Suddenly, I didn’t feel so clever.
Never hack a framework
All developers encounter high-pressure deadlines from time to time. Maybe you’re preparing the latest version of a project for client review or for a public demo. The clock is ticking and there’s code to deliver, so you start taking shortcuts. Sometimes these are necessary and can indeed be refactored later, as long it’s done “the right way” soon after.
However, hacking a framework like Bootstrap or jQuery is never a shortcut. Sure, it might help get something delivered quickly, but ultimately these end up being expensive to fix. In the worst-case scenarios, the client might be promised functionality that’s only possible by making changes to framework files rather than properly building proper code. Those unusual hacks must to be maintained going forward.
Refactor every so often
Speaking of shortcuts, it’s a good idea to collect all those quick-and-dirty hacks into one place using a shame.css file. (The same idea can be applied to non-web projects.) Then when the high-pressure delivery date has lapsed, it’s easy to erase all the “shame” and rewrite the code properly. Even when I’m not making quick hacks, I still try to allow myself time to review, reflect, and refactor. For example, when you revisit some of the first code you wrote, is it still easy to understand? As a project grows, this becomes increasingly important.
I also recommend doing this in the morning or after the weekend. The passage of time always provides a fresh perspective, and it’s a good way to get back into a workflow.
Use revision control for your code
If you’re not using revision control, you should start today. Github is free and reasonably priced if your needs grow. Coding without revision control is like driving without a seatbelt. Everything will be fine for a while, but as soon as something goes wrong, the consequences can be dire.
I’ve worked on several projects that involved “cowboy coding” with total disregard for simple precautions, and in every case, a revision control system could have made work move a lot faster. If you need to learn how to use a revision control system like git, check out the Git Basics course on Treehouse. Here’s the trailer:
Allow time for learning
When you’re crunching between one deadline and the next, learning can feel like a luxury. A programmer who isn’t learning, however, is just treading water. Almost every time I learn something new, it helps me work faster and more efficiently. This can immediately elevate quality of life if it means career advancement or more leisure time. What always amazes me is the ratio between the time it takes to learn something new versus the time that it ultimately saves. Try to learn something every day and, over time, you’ll reach a new level of understanding.
If you have more tips you’d like to share, I’d love to hear them in the comments!