Zsh 开发指南（第二十篇 代码风格）

导读

由于 shell 脚本语法比较灵活，写 shell 脚本的开发者熟悉的编程语言也有较大差别，你们很容易写出风格迥异的代码出来。若是只有本身一我的用还好，若是是你们合做开发同一个项目，代码风格不一样就会形成不小的麻烦。因此约定一个代码风格是颇有必要的。

本文中的代码风格约定只是个人我的建议，能够根据本身的需求或者喜欢来调整。本文的代码风格约定，在必定程度上也适用于 bash。

注意须要有丰富 shell 编程经验的人制定和维护代码风格约定，否则很容易没法执行或者流于形式而解决不了实际问题。代码风格约定不仅须要约定代码怎么写，并且要说明为何要这么写，否则容易由于难以服众而没法推广。

缩进

• 统一使用 4 个空格来缩进。

缘由：

1. 要用空格而不是 tab。由于在终端上 cat less diff 等命令都将 tab 显示成 8 个空格，有些命令是不可配置的（即便可配置，要让全部机器配置同步也是件麻烦的事情）。若是本身在编辑器上配置 tab 为 4 个或者 2 个空格，那么就会和 cat less 等命令的显示方法不一致，会致使不少麻烦。
2. 8 个空格太长，缩进几回就会致使行太长，而 shell 脚本每行不宜过长。
3. 2 个空格的话，若是缩进比较频繁，看起来比较费劲。另外若是写代码时不当心多了或者少了一个空格，在某些场景，不看逻辑的话，就没法肯定是多个一个仍是少了一个，更容易致使他人错误的修改，或者代码越改越乱。
4. 对于 4 个空格也可能致使缩进层数多时行太长的问题，经过修改逻辑减小缩进层数或者折行的方法，而不是减小缩进的空格数量来解决。

每行代码最多字符数

• 非特殊场景，每行代码不超过 100 个字符。

缘由：

1. 代码过长，阅读起来不方便，用 diff 之类工具对代码进行分析处理也不方便，因此须要约定最长字符数。
2. 经典的 80 个字符的约定，是受当时的输出设备限制而产生的标准，而如今的屏幕基本都是宽屏的，终端模拟器也都是可调大小的（而不是固定的 80x24）不必削足适履迎合陈旧的标准，浪费屏幕空间。并且若是使用 80 个字符的约定，很容易遇到须要折行的状况，反而会致使可读性降低。
3. 若是一行超过了 100 个字符，一般说明逻辑太多，须要分行或者折行。
4. 某些特殊场景，好比显示一个 ASCII 字符组成的图片，会有一行超过 100 个字符的需求，全部不能严格执行每行必须不超过 100 个字符的约定。若是分行或者折行会不可避免地致使代码可读性降低，那么优先考虑可读性。

折行

• 在前一行尾部加一个空格和 \ 折行，折行后缩进一层（4 个空格）。
• 若是缩进的是一个文本块，可使用对齐缩进，也可使用 4 个空格的固定缩进。
• 若是是在 aa && bb || cc、[[ ]] 或者 (( )) 中折行，&& || 放在下一行的行首。

缘由：

1. 折行的缩进和普通的缩进都是为了体现代码的递进关系，不必区分对待（好比折行缩进两层）。
2. 若是为了看起来美观，使用对齐缩进而不是固定缩进。那么由于每一个人的审美不一样，很容易产生不一样的缩进方法，从而产生没必要要的麻烦。但对文本块来讲比较特殊，由于一般对齐缩进不会产生争议。
3. && 和 || 在逻辑上属于后半个语句，在天然语言中也是这样，好比 明天我去公园或者去逛街，若是须要拆成两个子句，那么会是 明天我去公园，或者去逛街，而不是 明天我去公园或者，去逛街。对代码来讲也是同样。并且把 && 或 || 放在行首更容易对齐，看起来更舒服。

空格

• 在缩进和对其以外的场景，不容许出现逻辑上没必要要的连续多个空格。
• + && | 等双元运算符左右要加一个空格。
• ! ~等一元运算符和做用对象之间不加空格。
• ( ) 和 (( )) { } 内侧不加空格，[[ ]] 由于语法须要，内侧加一个空格。
• ; 以前不加空格，以后加一个空格。
• 定义函数时（以及在 (( )) 中调用函数时），函数名和 ( 之间不加空格。
• if while 等关键字和后边的内容之间加一个空格。
• if [[ ]] { 等场景中，{ 和前边的内容之间加一个空格。
• 变量和 [ ] 之间不加空格，用 [ ] 取数组或者哈希表值时，[ ] 内侧不加空格。
• > < 等重定向符号和文件或者文件描述符之间不加空格。

缘由：

1. 适量地添加空格可让代码更清晰易读。
2. 这些约定基本属于不少编程语言代码风格中约定成俗的习惯，符合多数人的审美。

空行

• 非特殊场景，不容许出现超过两个连续空行。
• #!/bin/zsh 后加一个空行。
• if while 等语句块以后加一个空行。
• 定义函数后加一个空行。
• 逻辑关系不强的两行（或者两块）代码之间，根据逻辑关系强弱（自行判断），加一个或两个空行。

缘由：

1. 适量添加空格，可让代码逻辑按照空行分隔，提升可读性。
2. 由于添加空行的方法涉及诸多因素，很难详细约定，主要靠开发者自行判断。

括号

• 在判断条件的场景，不使用 [ ]，用 [[ ]] 代替。
• 在数值计算的场景，使用 $(( )) 而不是 $[ ]。

缘由：

1. 在判断条件的场景，[ ] 的功能没有 [[ ]] 丰富，并且两者的用法存在差别，混合使用容易出问题。
2. 在数值比较或者计算的场景，$[ ] 的功能没有 $(( )) 丰富，混合使用容易出问题。
3. [ ] 在各类地方功能不一致，非必要场景尽可能避免使用。

常量

• 字符串常量中若是没有特殊符号，两端能够不加引号，也能够加引号。
• 使用数值时，两端不加引号。

缘由：

1. 若是任何字符串常量两端都加引号，容易让代码中充斥着引号，影响可读性。而且若是不当心误删引号，容易致使难以定位错误。
2. shell 脚本和不少其余编程语言不一样，处理字符串的逻辑占很大部分，每一个字符串常量两边都加引号的话，会增长不少额外工做量。

变量

• 用 $var 取变量值时，两边不加双引号，除非须要将非字符串变量转换成字符串。
• 在非必须场景，不须要加 ${var} 中的大括号。
• 能用局部变量的地方所有使用局部变量（用 local 定义）。
• 变量名中的单词可使用下划线分隔或者驼峰风格，在不影响可读性的状况也可使用全小写字母，但在同一个文件中要一致。

缘由：

1. 和 bash 不一样，zsh 在使用 $var 读取变量内容时，不用由于变量不存在、值为空、包含特殊符号而产生各类逻辑错误，因此无需在两端加双引号。
2. 用 $var 读变量是不少编程语言都有的用法，而 ${var} 几乎是 shell 中特有的用法，而且输入更麻烦，不必推广这种用法。并且由于不加大括号致使变量名粘连而出错的状况，编写代码时便可识别出来，和外部输入无关，不须要为了不不存在的问题而输入不少额外的大括号。
3. 若是能使用局部变量的地方使用全局变量，更容易出现全局变量重名而互相影响致使错误的状况。这种错误是很难排查的（由于不会产生语法错误，容易让人怀疑是代码逻辑的问题，而不去检查是否有全局变量重名的状况），每每会浪费开发或者测试人员大量的时间。
4. 不一样编程语言的开发者对变量名的风格偏好不一样，不宜规定统一风格。

引号

• 字符串常量两端能够添加双引号或者单引号，但同一个文件中风格要一致。

缘由：

1. 双引号和单引号的功能不一样，混合使用是不可避免的。
2. 在双引号和单引号都适用的场景，统一使用一种引号，可让代码更整洁易读。
3. 编程语言背景不一样的开发者，对单双引号的偏好不一样，不宜强行规定默认使用的引号。

函数

• 可使用 name() 或者 function name() 定义函数，但同一个文件中风格要一致。

缘由：

1. 若是约定统一使用 name() 定义函数，那么没有照顾 JavaScript 等编程语言开发者的习惯，并且 function 关键字有助于代码的搜索。
2. 若是约定统一使用 function name() 定义函数，须要额外输入 9 个字符，而意义有限，投入比产出要大。

脚本行数

• 非特殊场景，单个脚本文件不超过 1000 行。

缘由：

1. 由于 shell 脚本的特性，单个脚本文件过长容易致使各类问题（好比全局变量互相影响）。1000 行代码对于多数场景都够用了。
2. 若是写的是安装脚本之类须要分发的脚本，那么分发单个文件要比分发多个文件（须要打包解包等额外工做）容易不少，这种场景可能须要写长脚本。因此不宜强行规定单个脚本文件最大行数。

总结

本文介绍了我建议的 zsh 代码风格，能够适当参考。内容待完善。

本文再也不更新，全系列文章在此更新维护：github.com/goreliu/zshguide

付费解决 Windows、Linux、Shell、C、C++、AHK、Python、JavaScript、Lua 等领域相关问题，灵活订价，欢迎咨询，微信 ly50247。