The 7 Deadly Sins Of Programming

Is there anything more fascinating than creating something with your own hands? Watching your creation come to life slowly and slowly? We humans, above everything else, are creators.

But in this digital age, the way we create has changed. Most of us now create digitally. We create software and websites to do our bidding. Though our creations may no longer depend on our creativity, we can still get the same high coding that a potter gets while moulding a vase.

The modern programming world has expanded widely giving us a wide choice of options to chose from. Want to work on functional programming or object-oriented programming? You got a choice. Want to work server side or client side? You got a choice. Oh, so you have decided? Here are a 100 programming languages and libraries you can use to pull it off.

The number of languages, frameworks and libraries available to the programmer are ever increasing. You can create the same block of code in n multiple ways. Though these languages may vary greatly, most of them still follow the same basic concepts. And thus they are also united by the mistakes we make.

Here are the few deadly sins that you should avoid in programming. I ain't-a Christian, but I like the effect.

1. Not using a version control system while collaborating.

God bless version control! Here, I said it. The world would be a tough place without source control management tools like Git. They make it so much easier to collaborate or move around tasks.

Imagine sitting there and manually checking and merging files. Keeping different folders for different versions of the code. These practices would be unproductive and unreliable at best. Luckily we have git and other version control alternatives.

I’ve worked on a project that didn’t have a source control as such, and it was a nightmare. #NeverAgain

2. Not using proper variable names.

I don’t know why, but some people have a habit of using small, random variable names. They may work when you’re writing a 10-20 line program or snippet, but not when working on projects. Improper variables are a menace to readability and productivity.

The basic rule of naming your variables is that they should be self explanatory. When you see them, you should get a basic idea about what they are for. But don’t go overboard with 50 character long variable names! Keep it short, but readable.

Guess what Bill, I’m coming for you for using a,b, c as your variable names.

3. Using excessive dependencies. And updating them without thinking.

How many open source libraries are available on GitHub? More than we could count. These libraries do make the developer’s work so easier. They can save days of effort.

But to use excessive dependencies is a hazard to the overall code. More dependencies can mean slower compile and run time. Use libraries where you need to, but don’t just include them just for the sake of it.

Also, always check the library/plugin’s support before updating it. I once upgraded React without checking its effects on another libraries. I Still count it as one of the worst mistakes of my life.

4. Not documenting the code.

Here’s the thing. Nobody wants to read the whole function or file to understand what it does. Writing the code in the minimum lines and characters required may appear rad to you, but don’t make others or your future self hate you for it.

We should always try to write properly documented code. On the first overview, the reader should get a gist of what’s happening. This may involve proper code refactoring, using uniform syntax and proper variable names among other things. Add comments wherever necessary.

But don’t go overboard with comments. You don’t need to explain each line of code. Writing a 1–2 lines comment which gives a brief overview or note regarding an important part works the best.

5. Inconsistent formatting.

This is very closely related to the sin above. Inconsistent formatting can greatly affect readability and productivity. Select a naming convention for the project and stick to it. Don’t change your style midway through the code. I personally prefer to use capitalized casing for file names and camel casing for naming functions, variables, etc but may vary according to the language being used.

Nothing puts people off more than a poorly formatted code.

Also, use the same style for indentation throughout the code. Pick any among 2/4/8 space indent according to the style and language you’re using. But whatever you chose, stick with it like that popcorn kernel sticks in your teeth.

6. No error handling.

“Dread it. Run from it. Bugs still arrives” — Thanos

Here’s the thing, no matter how good a developer you are unless your function just does console.log(“Yey”) or printf(“Wow”), the chances are that at some point your code will break.

It may be due to an API error, timeout, data type mismatch, null value or god knows what. But more often than not some part of your code will run into trouble.

Error handling can vary greatly depending upon the language you’re working on. But a general rule of thumb is to be consistent with implementing null checks before accessing data. In my experience, they break the code more than anything else.

Therefore whenever doing a data related task, it’s always advisable to enclose your code into try-catch blocks and handle the exceptions as required. Don’t forget to let the user know that something has gone wrong. There’s nothing more frustrating than pressing a button or key and receiving no response. Give an error response, but give something.

Listen to Thanos, he is wise.

7. Poor selection of data types and data structures.

This is something that is more apparent in some languages than others (Read strongly typed vs weakly typed). Some languages won’t even let you compile the code if there is a type mismatch. But some only run into trouble at the runtime.

The most common example of this I believe is when numeric values are stored as integer/float/double/etc, vs when stored as a string. Some languages will do automatic data type conversion while comparing, others will give an error.

Conclusion

The above cardinal sins of programming are frowned upon. Try your best to avoid them.

These are just the common mistakes we all make. You’d rarely found a developer who hasn’t committed one of these programming sins in his life. But just like the Bible’s teachings aren’t limited to the 7 sins, neither are the programming sins. They come in all sizes and shapes.

What mistake do you think should be added to the list? Let me know in the comments

Happy coding :)

Hi, My name is Nitin Sharma and I write about technology, social media and life lessons. Connect with me on Instagram, Twitter or Quora and say Hi!