12 programming mistakes to avoid

1 2 3 4 5 Page 2
Page 2 of 5

"Having worked on one code base for three-plus years, my biggest regret is not making the code more modular," Subelsky says. "I've learned the hard way why the Single Responsibility Principle is so important. I adhere to it strongly in new code, and it's the first thing I attack when refactoring the old code."

Subelsky, as you may surmise, is a Ruby on Rails programmer. The framework encourages lean code by assuming most of the structure of the software will fall into well-known patterns, a philosophy that Rails programmers often summarize as "convention not configuration." The software assumes that if someone creates an object of type Name with two fields first and last, then it should immediately create a database table called Name with two columns, first and last. The names are specified in only one place, avoiding any problems that might come if someone fails to keep all of the layers of configuration in sync.

Mistake No. 4: Delegating too much to frameworks

Sometimes the magic tools lead only to confusion. By abstracting functionality and assuming what we want, frameworks can all too often leave developers at a loss for what's gone wrong in their code.

G. Blake Meike, a programmer based near Seattle, is one of many developers who finds over-reliance on automated tools such as Ruby on Rails a hindrance when it comes to producing clean code.

"Convention, by definition, is something outside the code," Meike says. "Unless you know Ruby on Rails' rules for turning a URL into a method call, for instance, there is no way, at all, that you will ever figure out what actually happens in response to a query."

He finds that reading the code often means keeping a manual close by to decipher what the code is doing behind his back.

"The rules are, while quite reasonable, not entirely trivial. In order to work on a Ruby on Rails app, you just have to know them. As the app grows, it depends on more and more of these almost-trivial bits of external knowledge. Eventually, the sum of all the almost-trivial bits is decidedly not trivial. It's a whole ecosphere of things you have to learn to work on the app and remember while you are debugging it," he says.

To make matters worse, the frameworks can often leave you, and any who come after you, stranded with pretty code that's difficult to understand, revise, or extend.

As Mike Morton, another programmer, explains, "They carry you 90 percent of the way up the mountain in a sedan chair, but that's all. If you want to do the last 10 percent, you'll need to have thought ahead and brought oxygen and pitons."

Mistake No. 5: Trusting the client

Many of the worst security bugs appear when developers assume the client device will do the right thing. For example, code written to run in a browser can be rewritten by the browser to execute any arbitrary action. If the developer doesn't double-check all of the data coming back, anything can go wrong.

1 2 3 4 5 Page 2
Page 2 of 5
7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon