10 Mistakes Every Programmer Makes

[[131972]]

The 10 mistakes listed in this article are not limited to C#, Delphi, JavaScript, etc. - they cover almost all programming languages. Is it an exaggeration? Welcome to taste it...

1. Write code for the compiler, not the user

When people use compilers to create their own apps, they often forget about the verbose syntax that makes programming easier as they translate their ideas into machine code.

Whether you use single-letter identifiers or identifiers that are easier for the human brain to understand, it makes no difference to the compiler. The compiler doesn't care whether you write optimized expressions or whether you wrap subexpressions in parentheses. What the compiler has to do is to parse these human-readable codes into abstract syntax trees and convert these trees into machine code, or some intermediate language.

So why not use more readable or semantically obvious identifiers - instead of just I, J or x. To be honest, the time we spend waiting for the compiler to convert identifiers is almost negligible. However, doing so can greatly reduce the time you and other programmers spend reading and understanding the source code.

A similar point is that you might have memorized the relevant operator precedence and omitted unnecessary parentheses in your expressions, but you didn't consider that later programmers might misread your code and make invalid assumptions about how it works.

My idea is to assume that everyone knows that multiplication (or division) takes precedence over addition and subtraction. Anything else I put in an expression I put in parentheses to make sure I really mean it and that other people understand what I mean.

Studies have shown that the time required to maintain some code is even more than five times the time it takes to write it. Therefore, it is very meaningful to write code that is easy to read and understand.

2. The function method is too large

There is a rule of thumb that the programs we write should not be too large. And we can also find that now methods tend to be smaller and smaller - sometimes just a few lines of code.

Essentially, only a certain amount of code is needed to quickly grasp the purpose and meaning of a program. Long methods are not only unacceptable, but also tend to end up being fragmented.

The reason is very simple: long methods are difficult to understand, maintain, and even test properly.

There is a pretty good measure of how complex your code is, and how likely it is to have bugs - cyclomatic complexity.

The method was developed by Thomas J. McCabe Sr in 1976. Cyclomatic complexity is a convenient and simple method to use, allowing you to make your code run as smoothly as possible in a hurry. Just count the number of 'if' statements and loops in your code, add 1, and that is the CC value of the method.

Of course this is only a rough count of the number of paths your code will take, but if you have a method with a cyclomatic complexity greater than 10, I recommend you rewrite it.

3. Premature Optimization

This is very simple. When we write code, sometimes we are too smart to pay too much attention to details and too meticulously. Although these "smart" codes seem to be faster than the original ones, you ignore the fact that these "smart" codes are often difficult to read and understand - and the actual time saved is often only a few milliseconds. This is called premature optimization.

The famous computer scientist Donald Knuth once said, "Premature optimization is the root of all evil."

In other words: our code needs to be clear and clean, and then we can focus on finding the real bottleneck and optimizing it. Never try to optimize prematurely.

4. Use global variables

In other words, some programming languages ​​have no concept of local variables, so we have to use global variables. Regarding global variables, although we can use it in sub-functions, we cannot declare that this variable can only be used in this function. Despite this, global variables are still very popular because we only need to declare it once and use it everywhere, which saves time and effort.

But its advantages are also its disadvantages, which is also the worst thing about global variables - we have no way to control its changes, nor can we control when to access the variable. Suppose a global variable is assigned a specific value before calling the program, but it is very likely that the value will change after the call, and you will not notice it.

5. No evaluation

Your goal is to write an application, and you are motivated and motivated. But suddenly, you find performance problems and insufficient memory problems.

Further investigation reveals that while your design works well for your current small number of users, records, and entries, it is not suitable for large-scale situations - Twitter is an example. Or it runs smoothly on your 3GHz PC with 8GB RAM and SSD, but once it is moved to a regular PC, it will be slower than a turtle.

Therefore, part of the design process still requires evaluation, and a series of back-of-the-envelope calculations. How many users do we need to handle at the same time? How many records do we need to process? What is the target response time? And so on.

Try to evaluate these types of questions so that you can make further decisions about the technical aspects of your application, such as different algorithms and caching. Don't just throw everything into development - you also need to evaluate your goals and objectives.

6. Size error (array boundary overflow)

Almost every programmer has made this mistake. Usually when writing a loop, the step size of the loop variable is increased too much or too little, resulting in an error in the number of times the loop traverses the elements, causing an array overflow exception.

This error will cause you to access non-existent elements when traversing array elements, or miss elements that should be traversed. The reason for this error is that you forgot whether the array subscript starts from 0 or 1.

7. Flooding anomaly

Most of today's programming languages ​​use exception systems as error reporting techniques, rather than the traditional passing and checking of fault codes. Today's programming languages ​​use new keywords to handle and catch exceptions, with names such as throw, try, finally, and catch.

An important thing to note about exception handlers is that their role is to unwind the stack, automatically returning from nested routines until the exception is caught and handled. You no longer need to check for error conditions, which can lead to code that is mired in incorrect testing.

By using exception handling correctly, we can make the software more powerful. For example, catch allows us to capture exceptions and perform certain actions based on the exception type.

There are two biggest mistakes programmers make when it comes to exception handling. The first is that programmers don't know enough about the exceptions they are catching. Catching too general an exception type can cause you to inadvertently handle specific exceptions that are best left alone. Doing so can cause those exceptions to be buried and lost.

The second mistake is more harmful: the programmer does not want any exceptions to leave their code, so they catch and ignore them. This is called an empty catch block. They may think that as long as certain types of exceptions are thrown, they will be fine: so they just ignore these exceptions.

The reality is that this may cause other fatal runtime exceptions - such as out of memory exceptions, invalid code exceptions, etc., which will prevent the program from running normally. Therefore, when adjusting the exception catch block, it should be as specific as possible.

8. Storing passwords in plain text

Data security is a topic that is always worth discussing, and its importance is self-evident. Here, I want to tell you solemnly that you should never save your password in plain text format.

The standard for passwords is to store the original password after it has been scrambled and then enter the scrambled password after it has been scrambled using the same encryption method to see if they match.

If you don't know the harm of this, here's a tip: If a website promises to email you your original password if you forget it, stay away from it. This could be a huge security problem. If the website gets hacked, all your login information will be exposed, and you won't be able to do anything about it except swallow your anger and live in fear. So, don't touch such websites, and don't store passwords or other "secrets" in plain text in your apps.

9. Not validating user input

In the past, programs were single-user, so we often didn't take user input seriously: after all, if the program crashed, it would only affect one person. Our input validation was limited to numeric validation, date checking, or other types of input validation.

Text input is not usually validated. But then came the web. So your program has users all over the world. And some malicious users will try to take over your app and servers by inputting data into your program.

Most of the new attacks are caused by the lack of checking of user input. The most famous one is SQL injection. Through tag injection, bad user input may trigger XSS attack (cross-site scripting).

Both types rely on the user providing text that contains SQL or HTML snippets as part of normal form input. If the application does not validate user input and uses it directly, it is likely to execute tampered SQL or generate some attacked HTML/JavaScript.

This in turn may cause the app to crash or be taken over by hackers. To avoid these situations, we should always validate or sanitize user input.

10. Not keeping up with the times

The above content I summarized may not be new - you may have read it in other books or web pages. But with the development of the times, more and more new design and programming technologies will be introduced.

If you still cling to some old and gradually obsolete technologies and are unwilling to learn and understand new programming methods and technologies, then you will eventually be beaten to death on the beach. For programmers, learning is an eternal topic. For example, TDD and BDD, SLAP and SOLID methods, and various agile technologies are all technologies we should learn.

We should always stay abreast of the latest advances in programming art and practice.