Python的缩进是反人类的设计？前几天写了《Python为什么使用缩进来划分代码块？》，详细梳理了Python使用缩进语法的8个原因。很喜欢这种简洁大方的风格，所以非常赞。然而，文章发出后，竟然收到了很多反对意见，真是太意外了！！（前几篇互动不多，但这次创下了记录。）我就不截图了，先摘录一些最刺眼的评论：最大的缺陷是缩进机制去掉了花括号，这是最愚蠢的设计。这绝对是过度设计的，最大的瑕疵是压痕，太反人类了。。。对于这种评论，我觉得是“睁眼瞎说瞎话”，颠倒黑白。Python的缩进语法如此简洁好用，为什么会“过度设计/愚蠢/有缺陷/反人类”？俗话说口味难调，有人喜欢甜的粽子，有人喜欢咸的粽子，但咸甜的口味谁都认同，才不会扰乱感官，胡说八道。也有不少评论，认为缩进容易造成混淆：代码太多，看腻了，别人更难看懂。最好使用方括号或{}或结尾更清楚。没有花括号，我总是没有安全感。缩进层次不清晰。没有大括号，就不容易阅读了。如果层数过多，则显得凌乱。不知道哪一层是哪一层，缩小多少。最后退出循环。明明缩进是正确的，但是运行时总是报错。尝试用Python编写100,000行。到时候你就知道什么是乱了，受不了了。。。现在主流的IDE工具都很强大，应该善于使用它的基本功能，比如：设置显示空格字符，设置tabs自动转换到空格，把tab键设置成4个空格...同级缩进也会有浅竖线，视觉上辅助阅读。至于层数太多，代码很长的情况，这本身就是一种不好的代码味道！当函数或类太长时，好的程序员首先应该考虑的是重构。推荐一本书《重构：改善既有代码的设计》，里面有正宗??的价值观和详细的方法论。还有说点击右括号，可以看到匹配的左括号，就一目了然了。拥有这东西真的很好，但不，我不要求它。代码本身紧凑简洁，缩进阅读会很快。除了以上两类评论之外，我还收到了以下具有代表性的评论：有人说“取消花括号会大大降低运行速度”、“这个特性的健壮性太低”。——这纯属猜测，要他们给出论据和例子是没有用的。不要以为看到有人说Python慢，就想当然地认为锅压在了缩进的头上。有人说“多人一起编辑时，有的用tabs，有的用空格”。——我说开发组要统一规范，然后用autopep8等辅助工具。他说，规范需要不断地花费在维护和成本上。请！这年头，还有人不注意代码规范，直接开除“猿猴”。有人说“缩进不能自动格式化代码”。——这个在复制手机码或者更改码级时需要。我一直在用比较笨的方式调整（tab、shift+tab、加减空格）。确实比较笨，但是会比较有把握。刚刚在PyCharm里研究了一下，发现它支持自动格式化，但是有一个小问题需要注意！关于缩进的自动格式化，这里举两个例子给大家演示一下：上面的例子，把if条件语句删掉，然后直接"ctrl+alt+l"进行全局格式化，格式会出错。我们希望两个print语句向左缩进4个空格，但return语句也将向左缩进。删除if行后，如果我们只选中两行print，做部分“ctrl+alt+l”格式化，那么就只缩进这两行，没问题。再看第二个例子，我们复制了一段新的代码，但是它的缩进是错误的：这时候如果直接"ctrl+alt+l"全局格式化，或者选中那三行再格式化，结果会错的！原因是第二个if中的缩进数小于4，所以PyCharm认为它属于第一级缩进（即不应该有空格），所以自动向左移动格式化。如果选中它们，先按tab键右移（即新代码变成大于4格小于8格缩进）：此时再格式化，它们的缩进会和第一层if（第二层if是兄弟关系）。同理，如果要将新代码缩进到if的第一层（成为父子关系），只需要选中上图中的三行代码，然后按tab键即可向右移动4个空格，然后格式化！建议大家在编辑器中练习。有空我会录个小视频（B站搜索“蟒猫”），敬请期待。除了上面的评论/意见，我们还在微信交流群里讨论过这个话题。@红雨楼（https://github.com/yingyulou）小姐姐的观点对我还是蛮有启发的。群聊截图已被记录在“Python知识星球”（https://t.zsxq.com/jeM33bQ），其中她提到了编程语言设计中“更抽象、更哲学”的两点：缩进让代码失去了形式语言中所谓的“上下文无关文法”，让空格+数字的组合不再可有可无。block作为“语法成分”，需要分隔符，而空格一般不作为语法成分，感觉少了点什么。很难用三言两语来解释，但她对缩进这个话题的看法确实令人耳目一新！上一篇文章发表后，很多小伙伴都表示喜欢Python的缩进。本以为会听到很多这样的声音，没想到负面评价更多。（可能更多的赞同的声音还没有表达出来。）本文回应了几种典型的评论，再次表达了我对这个话题的关注和理解（以及情绪的表达），希望也能带来读者有所思考，有所收获。
