做过长期开发的程序员都知道保持编程风格统一的重要性, 统一的风格能够降低各种成本.
有一句名言是咋说的来着? 代码主要是给人看的, 其次才是给电脑去运行.
但另一方面, 大家又普遍是偷懒的, 对于这些长期会受益, 但短期收益不明显甚至带来麻烦的事, 许多团队中的成员不能说抵制吧, 但至少是积极性不高的.
此时, 假如你是一个团队的领导者, 怎么才能有效地保持项目中编程风格的统一呢? 下面介绍的这个 .editorconfig 文件的方式将能有效地帮助我们.
.editorconfig 文件及作用
其实它就是一个类似于 ini 之类的配置文件, 而它的名字 editor config 显然也暗示了它是用于配置(config)编辑器(editor)的.
至于前面开头的那个点".", 这个在 windows 系统下将不会有什么作用;
在 linux 之类的系统上, 这个表示隐藏文件, 因为这些配置文件通常而言不需要普通成员了解及改动, 所以设置为一般情况下不显示.
具体而言它的作用是: 帮助工作在同一个项目的使用不同的编辑器和 IDE 的众多开发者维持统一的编程风格.
EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs.
下面是一个在 IDEA IDE 中项目里该文件的截图:
通常, 你至少需要在项目的根文件下放置一个.
具体配置项及含义
虽然这个文件没有后缀名(或者说只有后缀名), 但它其实就是一个普通的文本文件, 任何的文本文件编辑器都可以直接打开它.
我们直接看下它的内容:
root = true
[*]
charset = utf-8
indent_style = space
indent_size = 4
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true
就是一行一行的配置项, 关于编码, 缩进, 换行等等的规定.
比如上述的
charset = utf-8的就配置了工程的文本编码缺省都用 utf-8;又如
indent_style = space则规定了整个工程使用空格来缩进, 而indent_size = 4则规定具体缩进 4 个空格;而
end_of_line = lf则规定了使用 unix(linux) 风格的换行符(lf), 而不是 windows 回车+换行风格的crlf;等等...
更多的配置项及高级用法, 请参考其官网 https://editorconfig.org/.
比如, 除了在项目的根目录下放置此文件外, 你还可以在子文件夹内放置它, 以进行更细微的控制, 规则将综合起作用;
又如, 除了将缩进风格统一为 4 空格的粗暴方式外, 你还可以控制根据文件后缀名进行细微控制, 比如 js 才用 2 空格, 而 java 用 4 空格;
还支持各种通配符的设置等等, 这里不一一介绍
作用机制
当然, 你可能会好奇, 为什么在这个文件设置了这些, 它就能起作用呢?
自然, 这离不开 IDE(编辑器)本身对这些文件的支持(可能是直接集成或是通过插件的方式).
比如 Intellij IDEA 就直接集成了对它的支持, Visual Studio 也是如此;
而 Eclipse 和 Visual Studio Code 则可能需要安装插件, 在其插件库中搜 editorconfig 关键字即能找到相关插件.
后续的版本也许可能直接支持, 但目前据我所知是没有直接支持.
另: 除了重量级的 IDE, 很多轻量级的编辑器也是有插件支持的, 具体见官网介绍, 如 Atom, Sublime 之类的.
对于 IDE 而言, 一个很好的观察角度是看这个文件上的图标, 如果该文件上有特殊的图标(以及打开时有代码高亮之类的), 则说明是有相关支持的.
而如果是普通文本图标, 而打开也只是一个普通文本显示, 则说明没有得到支持, 则可能需要安装相关插件.
另一方面, 许多 IDE 本身会有这些代码风格的设置, 对于支持 .editorconfig 文件的(或是安装了插件后支持的) IDE, .editorconfig 文件配置的规则就会作用到这些设置上.
这就带来了一个好处, 无需让团队成员一一去设置, 也避免了一些成员由于犯懒或规范意识不高而不去做这些设置的问题.
引入时机及版本管理要求
显然, 通过了解 .editorconfig 文件的作用, 我们不能猜测到, 引入这个配置文件的最佳时机显然就是在项目的创建之初, 有了它, 各类规则就有了落地的具体载体, 团队成员有机会明确知道项目有哪些具体代码风格上的规范.
另一方面, 成员后续创建并提交的各类源代码文件也会受到它所配置规则的约束, 从而形成统一的风格.
如果没有一开始引入, 后期也是可以引入的, 自然, 越早越好.
而这个配置文件自然也是需要纳入版本管理(git 或 svn), 直接提交到代码仓库中的. 这样一来, 项目成员只要拉取了代码, 就能获取到这些配置了.
同时, 后续的新规则补充或旧规则调整都能很方便同步到各个成员中.
延伸思考: 如何做好项目管理
最后, 想借此机会谈谈如何去做好项目的管理. 比如你现在是一个项目的负责人, 自然, 你自己首先要有规范化的意识, 然后才能去推动整个项目朝着规范化方向前进.
可是, 任何一个有经验的管理者都知道, 事情没有那么简单, 你可能开了好几次会议, 形成了很多决议, 大家也似乎意识到了统一规范的重要, 但在后续的实际运行中, 你也还是可能发现大家慢慢又不遵循规范了.
甚至在一开始就没有遵循!
好的管理者一定是深谙人性的, 而人就是无时不刻想犯懒想省事的, 这或许是最大的人性.
很多时候, 甚至不需要去说别人, 我们想想我们自己是不是这样的?
因此, 很多事情如果你只是靠嘴去说说, 到最后你已经说到厌烦不想再说的时候, 事情最终就又还是回到老样子.
当你不想再说时, 你也犯懒了!
真要把事情做好, 你是需要一些技巧的, 这通常就表现为借助一些工具而非依赖于人的觉悟, 而这里介绍的 .editorconfig 正是这样一个工具, 有助于你达到自己的目的.
相比于各种工具与机制, 人的觉悟实在是太不可靠了, 是不值得依赖的.
另一方面, 好的管理者一定要有成本意识. 当你要做一件事情的时候, 你需要找到一个成本最低的方式, 如果你的方式需要大家做很多配合, 往往大家是不愿意的, 因为这给大家带来了成本, 而你反复去鼓动大家, 又给你带来了成本, 而最终事情却还是可能不能如你所愿.
因此, 很多时候你需要找到一个方便, 不那么麻烦的方式, 而这才能为大家所接受.
这通常也是阻力最小的方式, 而这往往又是最终成功的保障.
如果你只是在会议上对大家说, 不要怕麻烦, 长期来看这事受益很大, 但短视也是人性呀, 大家听到你的话可能不过是眨眨眼睛, 后面该干嘛还是干嘛.
把问题消灭在萌芽阶段, 这是你需要的, 也是成本最低的, 同时, 尽量少给大家带来麻烦, 甚至是大家不知不觉地就被规范起来了, 这才是最容易被接受的方案.
随风潜入夜, 润物细无声. -- 杜甫<<春夜喜雨>>
规范的透明化, 这是最高的境界, 这也是我所认为的 .editorconfig 这类工具机制背后的思想.
在技术层面, 你还能听过什么缓存透明化, 又或者什么透明地持久化, 这都表明这些东西起了作用而你甚至都没有意识到它们的存在, 无需你去关注.
任何东西, 你不主动去控制, 都可能走向失控, 这就是"水往低处流"的熵增原理, 因此管理好一个项目, 需要你的控制力.
但控制是需要成本的, 被你控制的人也需要付出成本, 因此你会遇到阻力, 怎么去平衡这些则是对你的考验:
拔最多的鹅毛, 听最少的鹅叫!
关于 .editorconfig 文件的介绍就到这里.