Programming is all about working smart and finding efficient ways to build useful software. Whether you’re creating software programs, web apps or mobile apps the sources of programming remain the same.
The contemptible dozen of application development traps and how to avoid these all-too-common programming oversights. If you need any better proof that code is art, look no further than how the programmers view their mistakes. Just as the world is filled with wildly conflicting opinions about painters, architects, writers, and poets, the range of programmers can’t agree upon much beyond the requirement that the code doesn’t crash. Even this is an extent. Some are fine with failing code as long as it produces beautifully before the user notices.
The disputes are usually born out of experience. When a developer says not to do X, it’s probably because some evening, weekend, or even spring vacation was ruined because someone around the office did X and it failed badly. X seemed like a good idea at the time but it was an intelligent spring and now the descendants want to warn the world about it.
When first learning to code it’s important to understand good habits and bad habits. Knowing mistakes coders make, and how to avoid them, can help you build a better foundation in your programming.
Here are 10 very common blunders to avoid.
- Playing it fast and loose: Failing to shore up the basics is the easiest way to undercut your code. Often this means disregarding how subjective user behavior will affect your program. Will the input of a zero find its way into a division operation? Did will submit text be the right length? Have date formats been vetted? Is the username verified against the database? Mistakes in the most modest places cause the software to fail.
- Repetitive Code: Don’t Repeat Yourself is one of the basic postulates of programming that you will come across as you learn. This is often shortened to DRY, and code that is written using this principle is called DRY code. Repeating code is an easy trick to fall into, and oftentimes takes some review to understand just how much code is repeated. As a good rule of pollex, if you’re copying and pasting code it’s probably repetitive and should be changed.
- Bad Variable Names: Variables are essential in programming no matter which language you’re working in. Because they are so broadly used, it’s important to have good habits naming variables. Variables should be named correctly and deftly. Avoid using general terms that don’t mean anything. It’s quick and easy to throw something collectively, but when you need to come back to your code later it makes it much more difficult to figure out what is going on.
- Over-committing to details: On the flip side, overly buttoned-up software can slow to a crawl. Barring a few null pointers may not make much difference, but some software is written to be like an obsessive-compulsive who must check that the doors are locked again and again so that sleep never comes.
- Delegating too much to frameworks: Sometimes the magic tools lead only to confusion. By extracting functionality and considering what we want, frameworks can all too often leave developers at a loss for what’s gone wrong in their code.
- Not Using Comments: Use comments! Comments are the documentation of your code. They’re the best way to describe what exactly is happening in your code as it grows. Positively, it seems a little bit more work to explain your code but you will be praising yourself later.
- Not Backing up Code: Not building the right habits to protect your code is frustrating to new developers, and ruinous to mature ones. As a programmer, it is so important to save and backup your work constantly. It’s no different than working on an important document or spreadsheet, which is saved regularly.
- Not planning in Advance: Writing effective software commences with good planning and design. If you wanted to build a house you would draw up a blueprint before building. Programming is no different. Before you even write one line of code, identify what you want to achieve. Know what the problem is, how you want to solve it. If you try and figure queries out while you’re writing code, you may find yourself missing the right solutions. Separate the problem solving from the coding and life is good.
- Relying too heavily on magic boxes: Worried about security? Just add some cryptography. Want your databases to be backed up? Just push the automated replication button. Don’t worry. The salesman said, “It just works.” Computer programmers are a lucky lot. After all, computer scientists keep creating wonderful libraries filled with endless options to fix what ails our code. The only problem is that the ease with which we can leverage someone else’s work can also hide complex issues that gloss over or, worse, introduce new pitfalls into our code.
- Following too many trendy ideas: Trends often begin with a good plan to fix some gnarly problems. If we can just rewrite our code with a new language, framework, or collection of libraries, we can eliminate the difficulty. The plan usually ends up bearing some fruit. The trouble isn’t the cost of rewriting the code although that is often substantial it’s the shift to the new paradigm, which often leaves a mirror image of the failure mode. A dong instead of a ding.
It’s painful for most software developers to accept this because they love code so much, but the best code is no code at all. Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, and code that has to be supported. Every time you write new code, you should do so grudgingly, under constraint, because you completely drained all your other options. Code is only our enemy because there are so many of us programmers writing so damn much of it.
It’s easy to get into a circle, either trying to get your head around something that should be simple or trying to remember what some code does. Whatever the problem, avoid making all of these mistakes and you should find your code improving.