I recently ran across the article Why use Vim: Forget easy-to-use design. Choose something hard instead — Quartz. This article suggests that you should learn to use the vim editor because it’s hard. Although I do think most developers would benefit from using an editor like vim, I feel like the because it’s hard advice… Read More »
In previous posts, I’ve talked about the importance of naming to make it easier for whoever maintains the code. One thing I’ve left out is the importance of not misusing standard names. Naming Fail In a previous position, I was manipulating a collection of data, when I hit a bug. After running some new code,… Read More »
You might wonder if code review is necessary if your team practices pair programming. (Assuming that your team does either code review or pairing.) Pair programming was originally one of the practices pushed by Extreme Programming (XP). The reasoning was pretty straight-forward, if we assume code review produces better outcomes, more frequent code review should… Read More »
It’s time for another post in my intermittent series of Best Practices Gone Bad (BPGB). This time we’ll cover the dark side of the Single Responsibility Principle (SRP). According to Robert Martin: A class should have one, and only one, reason to change. The basic concept is easy. Every object or method should be responsible… Read More »
This is another post in my intermittent series of Best Practices Gone Bad (BPGB) Today, we are going to take another side-step into version control. Most development groups use version control of some form. Whether you prefer Subversion, Git, Mercurial, Bazaar, Clear Case, or any of the many others, version control is an important technique… Read More »
It is written We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. —Donald Knuth Most people forget the very next thing he said: Yet we should not pass up our opportunities in that critical 3%. Many developers have lost the original meaning of premature… Read More »
As a first post in the Best Practices Gone Bad series, I figured I would take an simple example from a previous job. An Example In that position, there were two best practices that intersected to generate unreadable code. The first practice was expressive names. All names of variables, classes, and methods were required to… Read More »
Most professional fields develop a set of best practices that help people in the field produce consistent solutions to similar problems. Any given problem has an infinite number of potential solutions, some of those will actually work. Fewer still will work well. Best practices tend to prune some of the bad solutions by pointing out… Read More »
One coding style issues that causes many arguments is the distinction between the Terse/Elegant/Succinct style and the Verbose/Legible/Debuggable style. As usual, each side explains that their style is the only rational choice and that the other approach is obviously wrong. First, let’s look at the two styles to see what they say. In order to… Read More »
My wife is a really good writer and she once gave me a great piece of advice for some documentation I was working on: Know Your Audience. This has helped me to write better documentation. Over the years, I have come to realize that the same advice applies when writing code. Who is the Audience… Read More »