Shulou(Shulou.com)06/02 Report--

This article mainly explains "what are the bad programming habits of Python programmers". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn what are the bad programming habits of Python programmers.

Programming habits No. 1: using goto

Banning the use of goto can be traced back to the days when many structured programming tools were not available. If programmers want to create a loop or jump to another program, they need to type goto followed by a line number. After a few years, the compiler team asked programmers to use string tags instead of line numbers. This was considered a hot new feature at the time.

Some people think this will lead to "spaghetti code". The code becomes unreadable and it is difficult to understand the execution path of the code. The thread is chaotic and affectionate to the end of the world. Edsger Dijkstra, who has a witty manuscript entitled "Goto sentences do a lot of harm", has repeatedly said that the order should be banned.

But there is no problem with absolute branching. This is confusing. In general, clever break and return statements provide a very clean declaration of what the code does at that time. Sometimes, adding goto to case statements is easier to understand than the more appropriate multi-level nested blocks of if-then-else statements.

There are also counterexamples. The "goto fail" security vulnerability in Apple's SSL stack is one of the best examples. However, if we can carefully avoid some embarrassing problems with case statements and loops, then we can embed a good absolute transfer to make it easier for people who read the code to understand what's going on. We can insert break and return statements to make everyone feel cleaner and happier-except perhaps the hostile ones of goto.

Programming habit No. 2: successfully avoid documentation

A friend of mine has a very shrewd boss who has never written any code, but adheres to the idea that every function must be included in the document. Any programmer who does not provide comments will be punished. So, my friend plugged in something a bit like artificial intelligence in his editor, so he had several lines of "documentation" for each function. My friend dodged a bullet because the shrewd boss was not smart enough to understand that these comments meant nothing. His code is often used as an official document. I think he's going to be promoted soon! Ha!

Many functional methods and even some classes are more or less self-documenting. Functions with names such as insertReservation or cancelReservation or deleteAll do not need to be superfluous to explain what they do. A correct name for a function is often sufficient. In fact, this is better than writing a long comment, because the function name can appear elsewhere in the code. And the document can only stay in a corner in silence. Self-documented function names can improve every file they appear.

In some cases, writing documentation can even make things worse. For example, when the code is rapidly changing and the team is refactoring like crazy, the document will be divided. The code is written in this way, but the document explains what happened before four or five versions. Such "outdated" documents are usually at the top of the code, where some people make a nice summary of what should happen to the code. Therefore, although the refactoring team has carefully modified the relevant comments, it will still miss the "good summary" at the top of the file.

When there is a disagreement between code and text, comments become worthless and even misleading. In this case, good self-documented code clearly wins.

Programming habit No. 3: write too much code in one line

The boss suddenly sent a nasty email to the team: in order to enforce very strict style rules, we all had to rewrite our code. The most magical requirement is that each action or step or clause must go its own way. You can't use point syntax to call functions continuously. In a branch statement, you cannot have two or more clauses that return a Boolean value. If you want to define a variable, start another line. If you are doing a complex calculation, do not use parentheses. Each segment has its own line.

He thinks his decree will make debugging easier. Just as you step through the code, the debugger moves forward one action at a time. So you don't get stuck in a certain line. And easier to implement.

But this makes the enter key on the keyboard annoying because I need to keep inserting rows. And I'm sure the boss can go around bragging about how many lines of code his team can write.

Alas, sometimes it's easier to declare a bunch of variables on the same line; sometimes it's easier to put all the Boolean clauses together-everything can be more compact. That also means that we can see more logic on the screen without scrolling the mouse. Easier to read means faster to understand. This is the essence of simplicity.

Programming habits No. 4: do not declare types

Those who love typed languages think that if you add an explicit data type declaration to each variable, you can write better, error-free code. Spending a little time spelling types can help the compiler mark stupid errors before the code starts running. It can be painful, but it's helpful. This is a precautionary way to stop bug in programming.

But times have changed. Many newer compilers can intelligently infer types by looking at the code. They scan the code backwards and forwards until they are sure whether the variable is string or int, or something else. If the types being viewed are not queued, the error flag is lit. So we no longer need to enter the type of variable.

This means that we can now omit some of the simplest declarations in our code. The code is cleaner, and people who read the code can guess that the variable named I in the for loop represents an integer type.

Programming habits No. 5: wavering code

Some programmers are particularly indecisive and hesitant about the code. First the value is stored as a string and then parsed into an integer. Then it is converted back to the string. This is so inefficient that you can even feel CPU growling at this wasteful load behavior. Smart programmers can code quickly because they design architectures in advance to minimize conversion. Their code runs faster because they have a good plan.

But, believe it or not, this wavering code sometimes makes sense. For example, you have a great library that can do countless smart things in its proprietary black box. If the library needs string data, you give it a string, even if you have just converted the data to an integer.

Of course, you can rewrite all the code to minimize conversion, but it takes time. And sometimes it's okay to make the code spend a little more time running, because it takes us more time to rewrite the code. Sometimes it is cheaper to take on such technical debt than to build it correctly in the first place.

Sometimes, libraries are not proprietary code, but all the code you wrote before is unique to you. Sometimes it is much faster to convert the data again than to write all the code in the library. So, let it be, let the code sway.

Programming habit No. 6: write your own data structures

A standard rule is that programmers should not write code to store data in the second year of the data structure course. Basically all the data structures we need have been written, and the code has been tested and retested for years. It is bundled with language and is often free. Your code can only make bug.

But sometimes you find that the data structure library is a little slow. Sometimes they force us to use standard, but our code is the wrong structure. Sometimes the library pushes us to reconfigure the data before using the structure. Sometimes the library contains some so-called precautionary protection features, such as thread locks, but our code doesn't need it.

If this is the case, we should start writing our own data structures. This may allow you to do faster and more. And the code will be cleaner because we won't include the extra code that is used to format the data to accomplish some functions.

Programming habit No. 7: break the cycle in the middle

A rulemaking team declared that every loop should have a "constant", that is, when the logical statement is true, the loop executes all the time. The loop ends when the constant must not be true. This is a good way to think about complex loops, but it can lead to stupid bans-such as banning us from using return and break statements in the middle of the loop. This is also included in the rule that forbids goto statements.

This theory is good, but it usually leads to more complex code. Take a look at the following simple example, iterate through the array, pass the found element to the test function, and return the element:

While (I)

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.