The other day, I wrote " Why does Python use indentation to divide code blocks? ", which details the 8 reasons why Python uses indentation syntax. I absolutely love the simplicity and elegance of this style, so I compliment it.
However, after the article was published, I was very surprised and received a large number of objections! ! (In the past, there was not much interaction in the article, and this time it set a record)
I won't take any screenshots, but I will excerpt a few of the most dazzling comments:
> The biggest flaw is this indentation mechanism > > Removing the curly braces is the stupidest design > > Definitely over-engineered and flawed > > The biggest flaw is the indentation, which is too anti-human > > …
For these kinds of comments, I think they are "open-eyed nonsense" and confuse right and wrong. Python's indentation syntax is so concise and easy to use, how can it be "overdesigned/stupid/defective/anti-human"?
It is often said that it is difficult to adjust the Tao, some people love sweet zongzi and others love salty zongzi, but everyone has a consensus on the taste of salty and sweet, so that the senses will not be disturbed, and there will be nonsense.
There are also quite a few comments that indentation is confusing:
> Too much code, I look tired, others are more difficult to understand> > Dazzling, or parentheses are better> > Still {} or end is clearer> > I feel insecure without curly braces> > The indentation level is not clear> > No curly brackets are not easy to read. > > The layers look messy. I don't know which layer is which and how much to shrink. In the end there is no exit loop. > > It seems that the indentation is correct, but it always reports an error when running > > Try to write 100,000 lines in python, and then you will know what it means to be confused and unable to read it > > …
Now the mainstream IDE tools are very powerful, and they should be good at using their basic functions, such as: setting the display of space characters, setting tabs to automatically convert to spaces, setting the tab key to 4 spaces... The indentation at the same level will also be shallow Vertical bars to visually aid reading.
As for the case of too many layers and very long code, this is a bad code smell in itself! When a function or class is too long, the first thing a good programmer should consider is refactoring. Recommend a book "Refactoring: Improving the Design of Existing Code", which has right values and a detailed methodology.
It is also said that by clicking the right bracket, you can see the matching left bracket, which will be clear. It's nice to have this, but no, I'm not asking for it. The code itself is compact and concise, and the indented reading will be very fast.
In addition to the above two categories of comments, I also received the following representative comments:
- Some people say "eliminating the curly braces will greatly slow down the operation", "this feature is too robust". ——This is pure speculation, let them give arguments and examples, to no avail. Don't assume that wherever you see someone saying that Python is slow, take the pot for indentation.
- Some people say that "some people use tabs and others use spaces when multiple people are editing collaboratively." - I said that the development team should unify the specification, and then use auxiliary tools such as autopep8. He said that the specification requires constant effort to maintain and costs. please! These days, there are still people who don't pay attention to code specifications and directly expelled from "ape".
- Some people say "indentation can't automatically format code". - This is a requirement when copying and moving code, or changing the code level. I have been using relatively stupid methods to adjust (tab, shift+tab, adding and subtracting spaces). Just did some research in PyCharm and I found out that it supports auto-formatting, just one small issue to be aware of!
Regarding the automatic formatting of indentation, here are two examples to demonstrate to you:
In the above example, delete the line of if conditional statement, and then directly "ctrl+alt+l" for global formatting, the format will be wrong. We want the two print sentences to be indented 4 spaces to the left, but the return sentence is also indented to the left.
After deleting the if line, if we only select two lines of print and format them with local "ctrl+alt+l", then only these two lines will be indented, and there is no problem.
Looking at the second example, we copied a new piece of code, but it was indented incorrectly:
At this time, if you directly "ctrl+alt+l" global format, or select the three lines and then format, the result is wrong! The reason is that the number of indents of the second if is less than 4, so PyCharm thinks it belongs to one-level indentation (that is, there should be no spaces), so it is shifted to the left during automatic formatting.
If they are selected, first press the tab key to move to the right (ie the new code becomes indented more than 4 cells and less than 8 cells):
If they are formatted at this time, their indentation will be consistent with the first level of if (two levels of if are siblings).
Similarly, if you want to indent the new code to the inside of the first level of if (to become a parent-child relationship), just select the three lines of code in the above picture, then press the tab key to move 4 spaces to the right, and then format it!
It is recommended that you practice it in the editor. When I have time, I will record a short video (search for "Python cat" at station B), so stay tuned.
In addition to the comments/opinions above, we also discussed this topic in the WeChat chat group. @yingyulou ( https://github.com/yingyulou ) The views of Miss Sister are quite inspiring to me.
The screenshot of the group chat has been recorded in "Python Knowledge Planet" ( https://t.zsxq.com/jeM33bQ), in which she mentioned two points of "more abstract and philosophical" in programming language design:
- Indentation makes the code lose what is called a "context-free grammar" in formal languages, making the space + number combination less of an option.
- As a "grammatical component", block needs a delimiter, and spaces are generally not used as grammatical components, so I feel that something is missing.
It's impossible to convey in a few words, but her perspective on indented topics is really refreshing!
After the last article was published, many friends said they liked Python's indentation. I expected to hear a lot of these kinds of voices, but it turned out to be more negative comments. (maybe more voices of approval are not shown)
This article responds to several types of typical comments, and once again expresses my concern and understanding (and emotional expression) on this topic, and I hope it can also bring some thoughts and gains to readers.