Python 语言的强制缩进是败笔吗？ 第1页

我觉得至少先讲清楚三件事情：

1. Python是个方便流行好用的优秀语言，但这不代表它的所有设计都是对的，比如强制缩进；
2. Python的简单易用归功于很多Guido的哲学和设计思路，但这完全不等价于它的每个特性是简单易用的，比如强制缩进；
3. 世界上没有银弹语言。很多人认为Python是优秀的并且深爱着Python的强制缩进，但这并不意味着所有人都喜欢这个特性。

至少你在没有用IDE或者自动format code的代码编辑器中编辑Python代码时，强制缩进是个巨大的灾难，会给各个级别的用户们带来灾难性的后果和体验。

其实本质上强制缩进是个非常浅显的、仅限最最表面的前端解析上的、极强个人审美品味上的设计问题，就像大括号换行不换行、用vim还是emacs、甜粽子还是咸粽子一样，形成个人爱好后无足轻重，从个人使用角度来说，压根没有过多讨论的任何必要——但是当Python开发者用户数量指数级增加、整个语言和各个生态空前繁荣强大的今天看来，这个强制缩进给相当一部分用户带来体验上灾难，那就是败笔。

口味问题，我觉得还是有问题的。

C语系其实有一个非常重要的原则，一直被继承从未被推翻，就是空白字符可忽略。

C语系的语言基本做到了：在任何空白字符的位置，空白字符数量和形式的变化不改变代码（字符串和预处理指令除外）。

所以习惯了C语系的程序员，接触Python这种不仅仅是空白字符形式可能对代码构成影响，甚至数量都能构成影响的语言，就很不适应……

C语言这么设计的好处也是显然的，程序员可以自由的使用各种形式的空白字符来给代码进行自由排版。

PS：空白字符的形式发生变化是指，空格、换行和制表符是等价的……

很多层次的缩进？你该检讨的是自己的编程习惯、程序架构，而不是问Python的强制缩进是不是败笔。

当你手工搞过makefile之后，就会觉得python真好……

题主给的正反方理由都很奇怪啊。

正方的好不好看是 code style 的事情，语法可以管也可以不管——然而不管是 python 还是 C，都不是“我要钦定代码要写成什么样的语言”，go 这种才是。

反方的 IDE 无法自动格式化代码，需要按很多次 tab 和代码复制粘贴不能用了好像都是编辑器的问题呢。我用 vim 块粘贴，black 刷格式，怎么就没啥问题的样子……

当然从我个人的角度来说，我的确还是更喜欢括号一点……

我自己的论据：python 里写比较长的表达式，black 一类的工具把它拆成多行的形式的时候，几乎一定是靠挂着几层括号来完成这种拆解的……于是既然长表达式还是要靠括号，那么 scope 用另一种括号总归是更自然一点的。

不过这东西真没啥好纠结的……毕竟就是个语法风格。相比之下，“python 的 lambda 使用上下文中的变量时不能指定 capture by value 所以容易带来隐蔽的错误”一类的事情起码还关乎语义呢……

（对，我知道可以通过默认值来模拟capture by value，但是毕竟 signature 变了不是么……）

你这种说法其实非常愚蠢的，有自动格式化工具可以自动生成缩进，可自动格式化工具是依据什么自动格式化的？依据括号。如果你括号写错了，也就格式化错了。而人不可能快速数清括号数量，即使用IDE辅助也很难很快看清大括号匹配到的位置是不是正确，中间修改的时候也很容易把匹配关系搞乱了，所以人能判断层次结构是否正确的唯一办法就是看缩进是不是正确对齐，所以要在写的时候就清楚看清结构对不对就得一上来就缩进好，那格式化生成缩进的意义在哪？用大括号的语言，很容易缩进是按你想要的在缩进，但大括号位置写错了，实际结构跟缩进对不上，然后你一个自动格式化，哦，缩进跟大括号对上了，那不还是错的吗？难道每次格式化完全文检查一遍？有什么意义？

自动格式化工具的意义从来都是让代码风格统一，而不是生成缩进。

强制缩进解决的是可以省掉回大括号：也就是 } 的使用

然后 { 这个前大括号在 Python 中使用冒号 : 替代。

相当于 python 只有 { 没有 } ，使用缩进来代表。

而，如果缩进具备了真实的含义而不是冗余信息，就无法通过编辑器的格式化代码功能来自动实现。所以确实，它是一个缺点，它使得无法通过编辑器自动格式化代码缩进。这对于那些无法正确处理缩进的程序员来说确实是巨大的缺点。

不过换个角度看，能将无法正确处理缩进的程序员剔除出 python 圈子，也未必就是一件坏事。一个编程语言有一定的门槛并不纯粹是缺点，毕竟编程这件事情本身就是有门槛的。全民编程本来就不现实。