Tips for Writing Better Code

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 14-day 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.

Photograph of a car engine.

Like building an engine, fine-tuning every last detail of your code will only make you feel like a genius temporarily, and usually the increased performance is marginal. (Photo from Flickr user Andrew Taylor.)

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!

Free Workshops

Watch one of our expert, full-length teaching videos. Choose from HTML, CSS or WordPress.

Start Learning

Nick Pettit

Nick is a designer, public speaker, and teacher at Treehouse. He is also a co-host of The Treehouse Show. Twitter: @nickrp

Comments

9 comments on “Tips for Writing Better Code

  1. I always have a good experience when asking for code reviews. It can be from someone in your company or just a friend who codes as well to take a peek and see what they think. You’ll be surprised by what you’ll learn.

  2. A tip I remember from another blog was to write as little code as possible.

    Of course that doesn’t mean to do that even if readability is reduced or you have less robust code.
    For example there are python one liners that are perfectly readable and achieve the same thing
    with 3 or 5 lines of code in other languages.
    That also means don’t leave commented out code or functions that you don’t use anymore.
    If you ever need them again, which is unlikely, you can easily retrieve them from the code management system mentioned in this article.

    Advantages of that:
    Easier debugging, easier maintenance, easier changes.
    Also most of the times faster

    And one of my favorite quotes:
    Programs should be written for people to read, and only incidentally for machines to execute
    Abelson & Sussman, SICP, preface to the first edition