这是一个创建于 2119 天前的主题，其中的信息可能已经有所发展或是发生改变。
有些帖子吐槽 python 的缩进梗，特别提到一些大规模代码修改时候的痛苦。
我觉得写这个帖子的人估计是没有研究过祖传代码。
这个维护不是你找女朋友，床的时候只图做的时候爽，拍拍屁股走人，你还得考虑后续的责任问题。
我觉得吧，做的人自己改一下代码可能容易，虽然花点时间，但是这为后面阅读的人节省了大量的时间。
自由格式的代码改起来是快，任意插入代码不用花时间调整缩进，但是后面阅读的人就懵逼了。
你加结束码的时候应该体会一下后面数结束码的人的感受。
我觉得写这个帖子的人估计是没有研究过祖传代码。
这个维护不是你找女朋友，床的时候只图做的时候爽，拍拍屁股走人，你还得考虑后续的责任问题。
我觉得吧，做的人自己改一下代码可能容易，虽然花点时间，但是这为后面阅读的人节省了大量的时间。
自由格式的代码改起来是快，任意插入代码不用花时间调整缩进，但是后面阅读的人就懵逼了。
你加结束码的时候应该体会一下后面数结束码的人的感受。
 |
1
9hills 2019-02-06 03:57:12 +08:00 via iPhone
缩进只有在嵌套层级过多的情况下才会影响代码的修改效率。
如果每个文件最多两三百行，一个方法最多五六十行。缩进层级最多三四层。那么缩进根本不影响什么修改 |
 |
2
largecat OP 其实回到原点了，好的编程习惯，比如规则的缩进，代码分层条理清晰模块化独立化，以及代码的注释，任何语言都没问题。
有文章说 py 的参数不写注释根本不知道什么类型，调整缩进巨麻烦，那我估计写这的都不是好习惯的程序员，写这些文章的人写的代码肯定绵长不绝，想起一出就插个代码都不管格式，积累个几年后正宗的祖传代码了。 |
 |
3
msg7086 2019-02-06 05:50:57 +08:00  7
吐槽强制缩进 = 天天瞎瘠薄写代码不缩进？
你说规则的缩进没问题？我觉得我各种条理清晰的缩进说不定就会被 Python 认为是非法缩进了。 好的编程习惯不是语言强迫你按照他的习惯去缩进的理由。 另外说到后续责任的问题，测试覆盖、注释，这些比缩进重要多了。我拿到一个烂摊子，最最简单的就是处理缩进 —— 拿起编辑器里的格式化功能，一点，几千行代码就格式化完了。测试呢？注释呢？我能哪个按钮点一下就给我变出来吗？哪个重要哪个不重要还分不清吗。都在多人协作做项目了，何必还要在乎这种无关紧要的东西。 |
 |
4
loading 2019-02-06 06:18:51 +08:00 via Android 1
gofmt，真香。
|
 |
5
designer 2019-02-06 06:39:23 +08:00 via iPhone
缩进理念很好。但是强制很差。
但是把代码编辑器上互相复制就出现问题，无法运行。这个体验真的很差。 |
 |
6
trait 2019-02-06 08:19:27 +08:00 via iPhone
楼主 2019 年了，各个语言格式信手胡写，格式化不过是 xxfmt 一个命令的事，python 强制锁进靠人眼 parse 是真的辣鸡
|
 |
7
momocraft 2019-02-06 10:13:12 +08:00
其实为什么要设计成缩进表示 block ... 我暗自怀疑这个语法下只有最简单那些程序变得清楚了
|
 |
8
0xABCD 2019-02-06 10:20:01 +08:00 via Android
缩进本来没问题，问题是为什么一直没有一个类似于 gofmt 一样的工具
|
|
9
largecat OP 其实这个话题可以归结为，
某些语言参数需要预定义的，他们就可以不用写注释吗？ py 参数无法确认是什么类型，所以需要写好注释， 这不就是同一件事吗？ 某些语言不强制缩进，就不用缩进了吗？ py 强制缩进一样的效果， 最后的论点就是，大家都在做一样的事，但是有人拿这个当吐槽点，我也吃饭你也吃饭，一样的行为，你非得说我吃饭不好看。 但是特别是缩进又有一层好的意义，不排除一些程序员在大代码里加点油盐，他加可能要了一分钟，导致后面的人查清楚花了一个月的情况，我觉得强制不是更好吗？ 不要提借助第三方工具，总有人偷懒或者犯错的时候。 |
|
10
largecat OP @designer 你说的是从网页复制代码吧？如果是程序用的编辑器不可能有这个问题，如果真的有，那就是这个编辑器本身不支持 py，既然不支持 py，谁会用这样的编辑器写 py 代码？这不是伪命题么
|
 |
11
Cbdy 2019-02-06 10:31:58 +08:00 via Android
说到底，Python 缩进就是个烂设计
|
 |
13
lihongjie0209 2019-02-06 10:54:20 +08:00
@notreami 人终究是不靠谱的
|
 |
14
Yggdroot 2019-02-06 11:10:46 +08:00 via Android
吐槽强制缩进的应该是刚接触 Python 的，我刚接触时也吐槽过，慢慢习惯了后，就感觉不到跟其他语言有什么差别了。
|
|
15
largecat OP @Yggdroot 并且使用久了后，觉得反而是个好东西，看起来很工整优雅，看别人代码的时候也不担心他的代码乱了，心里有点莫名的踏实感。
|
 |
16
guokeke 2019-02-06 11:17:16 +08:00 via Android
yapf ?
|
|
17
guokeke 2019-02-06 11:18:20 +08:00 via Android
缩进真没啥好吐槽的。。。
|
|
18
lihongjie0209 2019-02-06 11:22:59 +08:00
@largecat 你没用过 ide 的自动格式化吗？
|
 |
19
aijam 2019-02-06 11:24:05 +08:00
反对任何支持用 tab 缩进的语言，我不是说特定的某个语言，我是说在座的各种语言都是垃圾。
|
|
20
designer 2019-02-06 11:25:53 +08:00 via iPhone
@largecat
首先我非常喜欢 python，只能说楼主有自己的完美主义癖好就好了。尊重你的想法。也请你尊重别人的想法。对于新手缩进造成的问题绝对是有的。提倡缩进不能强制缩进这是我的观点，萝卜青菜各有所爱。不再回复 |
|
21
largecat OP @lihongjie0209 用的
|
|
23
lihongjie0209 2019-02-06 11:39:35 +08:00
@largecat 那个任何非 tab 的语言都可以一个快捷键马上就可以工整优雅
|
 |
24
pkookp8 2019-02-06 11:47:59 +08:00 via Android
|
 |
25
luozic 2019-02-06 11:59:00 +08:00 via iPhone
除非是小项目，大项目大部分时间在看代码，写个锤子
|
 |
26
LokiSharp 2019-02-06 13:00:29 +08:00 via iPhone 1
写什么代码不缩进都是烂代码啊
|
 |
27
dacapoday 2019-02-06 13:04:35 +08:00
这就是最佳实践变成规范的情况，然而有些人不认可缩进是最佳实践，甚至以代码不可读为荣。
|
 |
28
FrankHB 2019-02-06 15:26:40 +08:00
@momocraft 可能因为设计这些玩意儿的比较业余吧。
Block 这玩意儿跟缩进本来就没什么关系。虽然一开始发明 block 的（ ALGOL ）大概还清楚是个什么玩意儿，后面就莫名其妙成了祖传视觉艺术了。 ……并且就算 free form 也未必干净。例如，考虑以下 C 艹： xxxxxx; { SomeGuard guard; } xxxxx; 哪天有个菜 13 随便手贱把 block 去了，整坨代码可能就炸了…… 而像样点的设计呢…… https://en.wikipedia.org/wiki/Let_expression 这还不如直接多个关键字清楚呢。（虽然被 BASIC 搞臭了不少。） |
|
29
FrankHB 2019-02-06 15:46:57 +08:00
@9hills 八百行是确数么。
那么请试着改正这段代码使之合格： https://github.com/gcc-mirror/gcc/blob/master/gcc/c/c-decl.c#L5802 @dacapoday 你确定缩进是最佳实践？代码总是给人读的？ 随便定位到不同部分，看看要符合你的断言得有什么条件： https://coding.net/u/dntc/p/videoconverter.js/git/raw/master/build/ffmpeg.js |
 |
30
ywgx 2019-02-06 16:01:29 +08:00 via Android 1
[JUNK REMOVED]
|
|
32
FrankHB 2019-02-06 16:10:01 +08:00 1
顺便，要是某几个最佳实践真的有对外宣传得那么清楚的话，就压根不用这货里面的其中一大坨复读了：
https://www.python.org/dev/peps/pep-0008 题外话，想要打起来的话，缩进本身相比其中的具体问题其实是排不上号了。这里面就不止一坨： https://stackoverflow.com/questions/120926/why-does-python-pep-8-strongly-recommend-spaces-over-tabs-for-indentation PEP-8 钦定的规则实际上还不就是所谓多数票暴政拣软柿子捏嘛，还搞出来光标随便一定位就可能有“半个缩进”的不合逻辑的问题……真搞什么最佳事件，敢强行统一么。 另外，洗 Go 的也别高兴太早。老实说 Go 强制 OTBS 逻辑上也挺蠢的：凭什么}那么脸大占一行{就不行？要省地方为什么不}}}}}？ |
|
33
momocraft 2019-02-06 16:24:47 +08:00
这个设计中语法结构信息 *仅* 存在于缩进那几个空格里，因此一个 "正确" 的 pyfmt 也许不可能实现（一个程序要像人一样理解代码才能知道“应该”加几个空格）
也许作者想的是... 强迫人类手打空格能防止粘贴代码导致火箭发射失败 |
 |
34
AX5N 2019-02-06 20:01:15 +08:00
我很喜欢强制缩进这个设计思路。
|
 |
35
xabc 2019-02-06 20:33:10 +08:00
@ywgx 账号刚才发了一个 curl xabc.io/tips | bash 的回复； 而实际上我的本意是 curl xabc.io/tips ，习惯日常工具使用了，多加了一个 | bash , 而我个人经常需要改缩进问题，而经常忘记这个 tips 所以做成这个简便方案, curl xabc.io/tips 可以看看输出前面几行， 而下面的几行多余代码， 可以看看 也是我个人的日常快捷记录
``` TAB 替换为空格: :se ts=4 :se et :%retab! 空格替换为 TAB: :se ts=4 :se noet :%retab! ``` @aijam 请问恶意代码在哪里？ 能不能别动不动恶意的揣测别人的友好回复提醒？ @livid 站长，你是否动过自己的脑筋？确认我这是恶意代码吗？ 可以让大家看看恶意在哪里？ |
|
36
xabc 2019-02-06 20:37:04 +08:00
curl xabc.io/ tips 的全部输出内容如下， 前面一段是 对 tab 和 空格记录的说明， 下面的是一个 nginx 配置的快捷记录， 下面两个 iptables 是我日常 封闭恶意挖矿代码的时候，自己的记录， 下面几个 sql 域名，也是我自己快捷记录，这是恶意代码吗？ 大过年的能不能别这么敏感嘛 😄
TAB 替换为空格: :se ts=4 :se et :%retab! 空格替换为 TAB: :se ts=4 :se noet :%retab! return 301 https://$host$request_uri; */5 * * * * ps aux|grep nginx|grep -v grep||/opt/openresty/nginx/sbin/nginx iptables -A INPUT -s xmr.crypto-pool.fr -j DROP iptables -A OUTPUT -d xmr.crypto-pool.fr -j DROP use mysql; update user set host = '%' where user = 'root'; FLUSH PRIVILEGES; se et ts=4 sts=8 sw=4 |
 |
37
Taojun0714 2019-02-06 21:25:45 +08:00 via iPhone 1
@aijam 9102 年了，还有人没把 tab 自动设置成四个空格，也是好玩
|
 |
38
CloudnuY 2019-02-07 00:09:46 +08:00
“自由格式的代码改起来是快，任意插入代码不用花时间调整缩进，但是后面阅读的人就懵逼了。
你加结束码的时候应该体会一下后面数结束码的人的感受。” -------------------------- 9102 年了还在吐槽这？ |
 |
39
lynskylate 2019-02-07 00:15:30 +08:00 via Android
9102 年了吐槽 python 缩进真是太搞笑了。还有过多缩进是坏代码的重要味道提现
|
|
40
aijam 2019-02-07 05:38:57 +08:00 via iPhone
@Taojun0714 少见多怪了不是，golang 的 indent 了解下
|
 |
41
Livid MOD @xabc 在接到举报之后，我去看了那个文件的内容。因为你的回复原文只是这样的一条代码：
curl xabc.io/tips | bash 而其中的内容并不是和正在讨论的主题 100% 相关，因此标记为 [JUNK REMOVED] |
|
43
FrankHB 2019-02-07 13:48:48 +08:00
@xabc 虽然我本来不想评价具体内容，不过老实说，认为把 tab 替换成空格就**算**解决了问题的，和解决问题应该先解决提出问题的人的做法某种意义上差不多——闻起来是味道类似的反智主义。
虽然严格来讲还和屁股有关，把这样的操作理解成一种恶意并不是什么奇怪的事。 |
|
44
FrankHB 2019-02-07 14:12:24 +08:00
本着“请尽量让自己的回复能够对别人有帮助”，还有另外几点没预热过的先给过一遍，预防以后跑题：
1.在实现语言时，indentation 的 error condition 不管算成 syntax error 还是 semantic error 都很别扭。这种逼迫实现无法区分 syntactic grammar 的语言设计姿势当然远不止是引入 semantic-sensitive indentation 一种，更著名拉仇恨的比如 C++的 vexing parse。据我所知，职业搞 PL 的基本不会在这上面跟自己和用户一起过不去，非要搞就是一个 preprocessing phase （ C processor、Lisp reader、……），和余下的语言规则的耦合通常是较为松散的；而这里 indentation 甚至能影响控制结构的特典就显得非常突兀了。某些语言的设计者如何忍受这些问题并坚持在一个实用且不拒绝未来扩展的语言中保留这类奇怪的 feature，就是一个耐人寻味的话题了。 2.有人提到，缩进多或少也跟代码质量普遍地有关。然而从操作上来看，这原则上只能在已知整个翻译单元的自顶向下的视点下才看起来有那么点意义。讨论重构之类的“工程级别”的变换（区分于语言实现的 code transformation ），通常默认更强调代码的局域性和松耦合：如果不影响外部的代码，能局部定位修改满足目的才是好的。这里和缩进层次多少并没有直接关系，差别只是编辑嵌套比较深的代码时需要对付的前缀缩进的数量确实比较多而已，然而调整这种缩进在大部分（ py 以外的）用户的严重，本来就该是编辑器的机械劳动。缩进多影响代码质量的观点这个看法看起来也不是 py 用户的发明，那么它到底是哪来的？我能记得的好像就是某些 C 用户对嵌套控制语句的“滥用”非常不满而鼓吹嵌套超过若干层是不好的代码，逐渐演化成了缩进过多是不对的。但是这很大程度本来就是 C 的无能，不知道为何推广到不少其它语言上好像也被莫名其妙地接受了。 技术细节：C 没有函数嵌套（倒是省了 funarg problems ），因此除了控制语句外很多重复构造的变换其实经常没有能耐嵌套（严格来说，struct+模仿 C++的 lambda operator()的 free function 可以做到，但实在太麻烦了，没见到有人日常这样写），所以很多东西干脆直接重复用代码（或者宏）实现了。Python 哲学里所谓 flat 优于 nested 这样的说法似乎也是这样来的？ 反观 Lisp-like 的，大部分有意无意随便嵌套（倒也间接增加了)))))))))))的概率），用户就完全没这样的意识。 |
Select Language