There’s always a joke about asking programmers what are the four things they hate the most? It must be: comment, document, others don’t comment, others don’t document.

The following is the translation:

What could be more fun than creating your own? Watching your invention slowly come to life? We human beings, are the Lord of all things, is the creator.

But in the digital age, innovation has changed. Now, we all create digital products. We build websites and write software to meet our needs. Although our creation no longer depends on our creativity, we can still be associated with the artist’s name.

The world of programming is very broad and multi-disciplinary, and we have many choices. Can you choose to use functional programming or object-oriented programming? Can you choose to be a server or a client? So, do you have a choice in mind? Below, there are 100 programming languages that you can use to fulfill your needs.

Languages, frameworks, libraries are all growing. You can accomplish the same code functionality in multiple ways. Although these languages may be quite different, most follow the same idea. So, they have the same problem.

Here are seven coding SINS that you can avoid. I’m not a Christian, but I like to define the seven deadly SINS.


1. Do not use version control when collaborating

Thank God we have version control tools. As I said, if we didn’t have a version management tool like Git, the code world would be very difficult. Version control makes it very easy to change or move around when we collaborate.

Imagine sitting in front of a computer, manually checking and merging files, saving different folders for different versions. Doing so is very inefficient and unreliable. Fortunately, we have Git and other version control tools to help us do this.

I’ve worked on projects without version control, and it was a nightmare.


2. Not using proper variable names

I don’t know why, but there are people around who use very short/random names for variables. You can use this when your project is only 10-20 lines of code, or just snippets of code, but don’t do it in large projects. Improper naming can be fatal to readability and efficiency.

A simple rule for naming: the names of your variables are self-explanatory. When you see them, you know what they’re for. But don’t use names that are too long! Keep the names short and readable.

Let’s look for your code that’s named A, B, c.


3. Use too much dependence and upgrade directly without thinking

How many open source projects are on GitHub? There are more than we can count. These open source libraries make developers’ jobs easier and save us time.

But using too many dependent libraries can be risky for the entire project. More dependent libraries mean longer compile and run times. We should add dependency libraries where we need them, not just for the sake of using them.

Therefore, we need to check the dependency library/plug-in support frequently before upgrading. I once upgraded React without checking how it affected other libraries. To this day, I still consider it one of the worst mistakes of my life.


4. Non-self-explanatory code

It is worth mentioning that no one wants to read the whole method/document to understand what it does. Use minimal code to implement features, but don’t let others, or future users, hate what you write.

We should always try to write self-explanatory code. We should make our code know what it does the first time it’s seen. To do this, we need proper code refactoring, uniform syntax, and proper variable names. Add comments to the code when necessary.

Of course, don’t write too many comments. You don’t need comments to explain every line of code. It is best to write a 1-2 line comment that clearly summarizes or explains important parts.


5. Inconsistent format

Similar to # 4, formatting inconsistencies can also have a huge impact on readability and productivity. In a project, pick a specific naming convention and stick with it, don’t change them in mid-stream. I personally prefer to name files in uppercase letters, and camel case naming methods, variables, etc. But these also change according to different languages.

There’s nothing worse than developers formatting code.

In addition, we need to use the same indentation format in our code. Depending on your code style and language of choice, use 2/4/8 Spaces for indentation. But whatever format you use, stick with it throughout the project.


6. Do not handle errors

Fear of it. Escape from it. Bugs will come! — Thanos

Here’s the thing: No matter how good a programmer you are, your code is likely to break unless you write code that looks something like this:

console.log("Yey")
printf("Wow")Copy the code

These errors can be caused by API errors, timeouts, type errors, null values, or god knows what. Often, these can cause problems in your code.

Errors are handled differently in different languages. In general, however, you need to determine whether the data is null before accessing it. In my experience, null Pointers are more common than any other error.

Therefore, when performing data-processing requirements, it is recommended to put your code in a try-catch and handle the corresponding exception, and finally, don’t forget to tell the user where the problem is. If there is no feedback when the user presses buttons and keys, the user will not know what is happening. Give the user an error message and tell it what to do next. Keep thanos’s words in mind.


7. Using improper data types/data structures

Data type requirements vary from language to language. Strongly typed languages are very strict, while weak types can be used freely. Strongly typed languages tell you about errors at compile time, whereas other languages need to know about errors at run time.

For example, when we store values in integer/dot/double dot variables and compare them to variables stored in strings, some languages do automatic type conversion and then compare, while others do not.


conclusion

The seven deadly SINS of programming. It sucks. We need to avoid it.

This is just a common programming error. It’s hard to see a programmer having these kinds of problems in his program. But like the seven deadly SINS of the Bible, it’s not just that. They are original SINS that can be combined into different errors.

If there are any other mistakes you think should be added to this list, let me know in the comments.

Happy Coding!