python自动缩进排版_代码缩进排版风格有必要统一吗？

我是来发出一点不同/奇葩的声音的。

我认为：代码的缩进排版风格完全没有必要统一！

不过且慢，前提是你的团队成员都使用了有高级代码格式化功能的IDE，并且项目版本库设置了提交前自动格式化代码的hook！

试想一下，你将自己的IDE配置成自己喜欢的排版风格，然后打开代码文件时，IDE都自动将代码重新格式化成你的prefer风格；你编辑好代码保存之后，提交到版本库，比如Git或Hg，并且在版本库上设置了一个before commit的hook，对所有要进入版本库的源代码都按照一个统一的排版方式重新格式化后再提交到版本库。这样，每个人都可以使用自己喜欢的代码排版方式Coding or Review，也不会影响其他人。(之所以要在代码进库之前再format到标准格式，是为了便于diff，目前基于程序语义的diff/merge工具也没被开始应用——所以会有这种因为diff/merge产生的BUG：http://coolshell.cn/articles/11112.html)

但那只是想象，我从来没听说过哪个团队使用这种方案。因为这个方案有这样几大阻碍：

找不到一个好的格式化代码的工具！你的IDE总是会在格式化代码方面有这样那样的小问题。你自己IDE有问题也就算了，问题是，你也找不到一个好的工具，设置版本库的hook，在代码进库前，调用这个工具，对所有代码进行reformat！

对于Java这种中规中矩的语言，倒容易找到这样的工具，Golang甚至内置了一个go format。但对于Python呢？它将缩进当成语义的一部分啊。对于Java，要是工具处理缩进错了仅仅导致看起来不爽而已，Python自动缩进不正确的话，代码就彻底错了啊！而且有时缩进错误会成为一个潜在的Bug、而不是直接报SyntaxError！或许你会说，我们团队又不用Python这种2B语言，我们就不用这样提心吊胆了。

但你还是找不到那种可以按你的偏好设置对代码进行完美地重新排版格式化的工具啊！TOT！别说「按偏好格式化」了，就算按标准格式化，你在Vim里试试对uglify之后的jQuery源码重新format一下看看。而且你的团队都是用同一种IDE么？只用Java一种语言么？真的只用Java一种语言么？话说你连Java这么死板的语言都能忍受，却不能忍受一下团队规范？TeamLeader看着你意味深长地说：“我觉得你不是一个合格的Java程序员啊！”

好了，假设你真的找到一个完美格式化代码的工具＋一个高级IDE了！ 你们团队不会是用的VSS作版本管理吧？Before commit的hook怎么设置？个个都会设置么？TeamLeader睬你么？格式化工具出Bug了你能去FIX么？你找来的工具有商业支持么？不会是某个Ph.D做了玩玩的毕业作品吧？

最后，你只能去墙角默哀！

如果这样的工具(代码排版格式化、甚至结构化编辑的IDE)在业界受到广泛支持与应用，我想我们就不必在缩进是用空格还是Tab的问题上争论不休了.假如能根据代码语义进行格式化的IDE和工具链成熟了,我们就可以不要脸地在代码中混用Tab和Space了，呵呵。

在IDE还没有对变量名函数名重构功能(将一个函数名重命名后，IDE自动将项目中所有调用到该函数的地方的名字也改成新的名字)的时代，软件项目中就有各种历史遗留的命名问题。你发现项目中一个函数的名称拼写错了有歧义，想要修改正确，但好多地方都调用到了这个函数，没有IDE的refactor功能帮助，谁敢动这大段代码啊，改漏了出错了可承担不起啊。(直到golang才终于有机会将creat拼写错误修正了)。

所以，结论是，囿于现状，团队成员必须都使用相同的代码排版规范！

再补充说说命名规范。

和代码排版问题不一样，这个东西肯定没有办法用IDE自动格式化。但从另一面来看，不但团队需要一个命名规范，而且，不同的语言、不同的开发框架，其规范应该是近似固定的。

比如对于Java，肯定是使用CamelCase！为什么？因为标准库全是这种风格的命名！其实Java甚至应该禁止在标识符中使用下划线的。

上面的观点一点不极端啊。Golang用函数名首字母大小写来区分它是public还是private。Python用双下划线来隐藏方法。 JavaScript也有这个潜规则，用前后双下划线表示内部实现。Ruby将全部大写的变量视为常量，类名模块名必须首字母大写！

而且对于另一些语言，命名规范会影响程序正确性！比如PHP！它的函数名是不区分大小写的。所以对于PHP，更推荐是全局函数名使用下划线，类名变量名使用CamelCase！

可见，对于命名规范问题，其实根本不是什么强迫别人遵守什么代码规范，而是为了将代码语义最佳化，每种平台或语言都形成了自己的一种命名传统(Naming convention)。假如一个Java程序员要是给每个变量名都像int i_count;float f_percent;这样加个下划线和类型提示，要么不会用IDE，要么就是有病，这种将其它平台或语言上的习惯带到Java上肯定不受人待见。当然你会遇到有些语言中变量方法名既流行camelCase又流行under_score，比如Python、PHP之类的，那是，因为，它们本来就是一个不规范的语言，它们的标准库的命名本来就很不一致(又黑了一把)！

如果命名规范的不同 不影响程序的正确性或语义，那最后只有一个标准规范：就是统一。

在同一个项目中始终使用同一个规范。你不能因为下划线在键盘上难输入或是你的Shift、CapsLock键坏了就坚持打这个反传统的圣战。

多关心关心程序的正确性及表现力，给函数起一个易懂且具概括性的名字，是under_score还是CamelCase，并不很能体现一个程序员的执著审美与品味。