Common design errors for the "Go" programming language (1)-one-sided pursuit of short

I often take pride in writing my own "very short" code. Some people appreciate it after listening, and then say that he also likes to write short code, and then began to say that C has a lot of clever design, can make the code very short. Then I found out that what these people call "short" is not exactly the same as what I mean by "short".

The "short" of my program is built on the basis of clear semantics and clear concepts. On this basis, I strive to remove redundant, mealy, confusing code, so that the program more direct, more efficient expression of my mind conceived "model." This is an optimization at the conceptual level, and the short program is just one of its "appearances". It's like tidying up a wire, not just rubbing it in a group and stuffing it in a box. This will only give you more trouble in future work, and there are also security risks.

So I tend to be short on a semantic and logical level, rather than a few lines of code that are syntactically dead. I will never make it difficult to understand or error-prone for the sake of the program to appear short. On the contrary, many others seek short, but they are blind and have no principle. In many cases, these tricks are just grammatical, such as trying to "rub" two lines of code into one line. It can be said that this "one-sided pursuit of short" error tendencies, creating a number of language design errors, and a group of "good at" the use of these errors of programmers.

Now I give a few simple "one-sided pursuit of short" language design.

Self-increment operation

In many languages there are i++ both ++i "self-increment" operations and these i-- --i two "self-subtraction" operations (hereinafter collectively referred to as "self-increment operations"). Many people like to use the self-increment or decrement operation in the code, because it can "save one line of code". As everyone knows, save a few lines of code than the resulting confusion and errors, in fact, is one of the nine cattle hair.

Theoretically, the self-increment or decrement operation itself is the wrong design. Because they combine the "read" and "write" of the variables in a fundamentally different way, without principle. This confusion about read and write operations has resulted in very difficult errors to be found. On the contrary, an equivalent, "dumb" point of writing, i = i + 1 not only easier to understand, but also more logically clear.

Some people are very concerned i++ with ++i the difference, to pursue the (i++) + (++i) meaning of such expressions, i++ and ++i who is more efficient. These are in vain. For example i++ , ++i the efficiency difference, in fact, comes from the stupidity of the early C compiler. Since i++ the original value needs to be returned after the increment i , it is actually compiled as:

(tmp = i, i = i + 1, tmp)

But in

for (int i = 0; i < max; i++)

In such a statement, you do not actually need to i++ get the value before it is added. So some people say that it should be used here ++i instead of i++ , otherwise you would waste one assignment of the middle variable tmp . In fact, a well-designed compiler should generate the same code in both cases. This is because in i++ the case, the code is actually first converted to:

for (int i = 0; i < max; (tmp = i, i = i + 1, tmp))

Since tmp this temporary variable has never been used, it will be eliminated by the compiler's "Dead Code elimination". So the compiler finally actually gets:

for (int i = 0; i < max; i = i + 1)

So, "mastering" these subtle questions doesn't make you a good programmer. What many people think of as clever skills is often due to flaws in early system design. Once these systems have been improved, these techniques will be of little use.

The real right thing to do is to not use self-increment or decrement operations at all, as they are inherently wrong designs.

Well, a small example may have made you aware of the perceived, temporal cost of one-sided pursuit of short programs. Unfortunately, programming language designers are still continuing to make similar mistakes. Some of the new languages include many similar tricks designed to "shorten the code" and "reduce the amount of typing". Perhaps one day you will find that these tricks, in addition to the short-term excitement, are actually wasting your time.

Assignment statement return value

In almost all languages like C,c++,java, an assignment statement can be used as a value. It is designed so that you can write code like this:

if (y = 0) { ... }

Instead of

y = 0;if (y) { ... }

The program seems to shorten the line, however, this kind of writing often causes a common mistake, that is, in order to write if (y == 0) { ... } and == compare the operation of a few dozen = , became if (y = 0) { ... } . A lot of people do this because math is about = comparing two values for equality.

Accidentally hit a wrong word, let the program appear a bug. Regardless of the y original value, after this "condition", y the value will become 0. So this judgment statement will always be "false", and a silent change y in the value. This bug is pretty hard to spot. This is another example of a one-sided pursuit of short-running problems.

What is the right thing to do? In a full-fledged language, an y=0 assignment statement like this one should not be able to return a value, so it does not allow you to write:

x = y = 0

Or

if (y = 0) { ... }

Such a code.

x = y = 0Works like this: After parser it actually becomes x = (y = 0) (because the = operator is "right-associative"). x = (y = 0)This expression x is (y = 0) the value assigned to the value. Notice that I'm talking about the value of (y = 0) this whole expression, not y the value. So here's the (y = 0) side effect is the value, it returns y the "new value".

The right thing to do is: You shouldn't y = 0 have a value. It should be the "assignment" of this "action", and should not have any "value". Even if it is forced to insist that it has a value, its value should also be void . This and will be rejected by the x = y = 0 if (y = 0) compiler because of "type mismatch", thus avoiding possible errors.

Think about it, x = y = 0 and if (y = 0) bring very little benefits, but the problems they bring are costing people a lot of time. That's why I call them "smart".

Study Questions

1. Google's code specification stipulates that, in any case, curly braces must be written after the for statement and if statements, even if C and Java allow you to omit them when they contain only one line of code. For example, you can't write like this.

   for (int i=0; i < n; i++)   some_function(i);

   and must be written

    for (int i=0; i < n; i++) {   some_function(i); }

   Please analyze: So write more than two curly braces, is good or bad?

   (hint that Google's code specification is correct at this point.) Why? ）

2. When I went to Google for a second internship, I found the code I wrote to them a year ago, and a lot of the structure was tweaked. Code for almost all of the following structures:

    if (condition) {   return x; } else {   return y; }

   have been changed to:

    if (condition) {   return x; } return y;

   elsewhat are the advantages or disadvantages of omitting one and two curly braces here?

   (hint, the code after the changed is not as good as the original.) Why? ）

3. Based on the view of the self-increment operation in this paper, and referring to the traditional Turing design, do you find that there are similar problems in the design of Turing? How do you change the Turing to make it no longer a problem?

   (Hint, note the "read-write head" of Turing.) ）

4. Refer to the Go language Getting Started Guide to see if you can find design errors that are not found in other languages because of the "one-sided pursuit of short".

Common design errors for the "Go" programming language (1)-one-sided pursuit of short