10 errors that every programmer could have made

The 10 errors listed in this article are not limited to C #, Java, Delphi, JavaScript, etc.-almost all programming languages. is not fanfare, welcome you to tasting ...

1. Write code for the compiler, not for the user

When people use the compiler to create their own apps, they tend to leave behind the syntax that makes programming easier but lengthy by resorting to machine code. Whether you're using a single-letter identifier or an identifier that's easier for the human brain to understand, there's no difference for the compiler. The compiler doesn't care if you write an optimization expression, or whether you enclose the subexpression in parentheses. What the compiler has to do is to parse the human-readable code into abstract syntax trees and convert the trees into machine code, or some sort of intermediate language.

So why not use more readable or semantically more obvious identifiers--not just i,j or X. To be honest, the time we use to wait for the compiler to complete the conversion identifier is almost trivial. However, doing so can greatly reduce the time that you and other programmers use to read and understand the source code.

Another similar view is that you might have memorized the associated operator precedence and omitted some unnecessary parentheses in the expression, but it did not take into account that the programmer might mistakenly read your code and make some invalid assumptions about how it works.

My idea is that, assuming everyone knows, multiplication (or division) takes precedence over addition and subtraction. Anything else I put in the expression I use brackets to make sure that I can really express what I mean, and that other people can really understand what I think.

Studies have shown that some code maintenance takes more than five times times the time it is written. So it's very meaningful to write code that is easy to read and understand.

2. The function method is too large

One rule of thumb is that the procedures we write should not be too large. And we can also see that the approach now tends to be smaller-sometimes just a few lines of code.

In essence, to quickly grasp the purpose and meaning of the program, only a certain amount of code is enough. Long methods are not only difficult to accept, but tend to be fragmented in the end.

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

There is a pretty good measure to measure the complexity of your code and the probability of a bug--the complexity of the loop.

This method was developed by Thomas J. McCabe Sr in 1976. The ease of use of loop complexity allows you to keep your code running as well as possible in a hurry. You only need to count the number of ' if ' statements and loops in the code, plus 1, which is the CC value of the method.

This is, of course, a rough count of the number of code execution paths. However, if you have a method whose loop complexity value is greater than 10, I recommend that you rewrite it.

3. Premature optimization

This is very simple. When we're writing code, sometimes we're smart about too much detail on some code, though it seems that these "sensible" codes are faster than those originally written, but you're ignoring the fact that these "sensible" codes are often hard to read- And the real time savings are usually just a few milliseconds. This is known as premature optimization.

Well-known computer scientist Donald Knuth once said, "Premature optimization is the root of all evils."

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

4. Using Global variables

In other words, some programming languages have no concept of local variables at all, so they have to use global variables. As for global variables, although we can use it in a child function, there is no way to declare that the variable can only be used in the function. Nonetheless, global variables are still very popular because we only have to declare them once and use them everywhere, which saves time and effort.

But its advantages are also its drawbacks, which is the worst thing about global variables--we have no way to control its changes, and there is no way to control when to access variables. Suppose a global variable is given a specific value before it is called to the program, but it is likely that the value is changed after the call, and you are unaware.

5. No evaluation

Your goal is to write an application that you are motivated to fight. But all of a sudden, you've found problems with performance problems and low memory.

Further research shows that although your design is working well for small numbers of users, records, and entries, it is not suitable for large-scale situations--twitter is an example. Or it's now running smoothly on your 8GB RAM and SSD 3GHz pc, but once on a normal PC, it's a slow crawl than a turtle.

Therefore, part of the design process needs to be evaluated, a series of back-cover calculations are required. How many users do you need to process at a time? How many records do you need to process? What is the target response time? Wait a minute.

Try to evaluate these types of issues so that you can make some further decisions about some of the technical issues in your application, such as different algorithms and caches. Don't mess around with development-you need to evaluate goals and objectives.

6. Size difference one error (array boundary overflow)

This error basically every programmer has committed, usually in the write loop, because the loop variable step increase too much or too little, causing the loop to iterate over the elements of the number of errors, resulting in an array overflow exception.

This error causes the element to be accessed when the array element is traversed, or the element that should be traversed is omitted. The reason for this error is that you have forgotten whether the array subscript starts from 0 or 1.

7. Flooding anomalies

Today's programming languages mostly use exception systems as error reporting techniques, rather than traditional pass-through and check-fault codes. The current programming language uses new keywords to handle and catch exceptions, with names such as throw, try, finally, catch, and so on.

On exception handling it is worth mentioning that their role is to expand the stack and automatically return from the nested program until the exception is caught and processed. You no longer need to check for error conditions, causing your code to fall into the mire of error testing.

By using exception handling correctly, we can make the software more powerful. For example, catch allows us to catch an exception and perform some behavior based on the type of exception.

With regard to exception handling, there are two of the biggest mistakes programmers make. The first is that programmers don't know enough about their catch exceptions to be clear and specific. Capturing an overly generalized exception type may cause you to inadvertently dispose of certain exceptions that are best preserved. And doing so may cause these anomalies to be drowned and lost.

The second error is more harmful: programmers don't want any exceptions to leave their code, so they are ignored after the capture. This is called an empty catch block. They may think so, as long as they throw certain types of exceptions: they are rightfully ignoring the exceptions.

The reality is that this can lead to other fatal runtime exceptions-such as an out-of-memory exception, an invalid code exception, and so on-that the program will not function properly. Therefore, you should adjust the exception catch block as much as possible.

8. Storing passwords in plain text format

Data security is a topic that is always worth discussing, and its importance is self-evident. Here, I would like to solemnly tell you that the password must not be saved in plain text format.

The standard of the password is to store the encrypted and disorganized original password before entering a messy password after the same encryption method to see if they match.

It's not clear that the harm is done, so give you a hint: If a website promises, if you forget the original password, they will send you an email to tell you, then stay away from this site. This can be a huge security issue. If one day, the site will be hacked, then all your login information will be leaked out, and you have to swallow panic and endemic but nothing. Therefore, do not contact such sites, the same, do not in your app in plain text format to store passwords or other "secrets."

9. Do not validate user input

The previous program is single-user, so we often disagree with the user input: After all, if the program crashes, it will only affect the use of one person. Our input validation is limited to numeric validation, date checking, or other types of input validation.

Text input is often not specifically validated. But then there was the webpage. As a result, your program has users all over the world. Some malicious users will try to take over your app and server by entering data into your program.

Most of the new attacks are due to a lack of user input checks. The most notable of these is SQL injection, which is injected by token, and bad user input can cause XSS attacks (cross-site scripting). Both of these types depend on the user providing text containing SQL or HTML fragments as part of normal form input. If the application does not validate user input, it is used directly, and it is likely that the tampered SQL will be executed, or some of the attack html/javascript may be generated. This in turn may cause the app to crash or be taken over by hackers. To avoid these situations, we should always validate or eliminate user input.

10. Not keeping pace with the Times

What I've summarized above may not be new-you may have already covered other books or pages. But with the development of the Times, more and more new design and programming technologies will be available.

And if you're holding on to some old, outdated technology that you're not willing to learn and learn about new programming methods and techniques-then you'll eventually be shot dead on the beach. For programmers, learning is the eternal subject. For example, TDD and Bdd,slap and solid methods, as well as various agile technologies, are the technologies that we should learn.

(Like I'm concerned about me)

10 errors that every programmer could have made