简介由于shell脚本语法比较灵活，编写shell脚本的开发者所熟悉的编程语言也大相径庭，所以很容易让大家写出风格各异的代码.如果只是自己用还好，但是大家合作开发同一个项目的话，代码风格不同就会带来很多麻烦。所以有必要约定一种代码风格。本文中的代码风格约定只是我个人的建议，可以根据自己的需要或喜好进行调整。本文中的编码风格约定在一定程度上也适用于bash。注意，需要有丰富shell编程经验的人来制定和维护代码风格约定，否则很容易实施失败或流于形式，无法解决实际问题。代码风格约定不仅要就代码怎么写达成一致，还要解释为什么要这样写，否则很容易推广失败，因为很难说服大众。缩进使用4个空格进行缩进。原因：使用空格而不是制表符。因为catlessdiff等命令在终端显示tabs为8个空格，所以有些命令是不可配置的（即使可以配置，同步所有机器配置也很麻烦）。如果在编辑器上配置tab为4个或2个空格，会和catless等命令的显示方式不一致，会造成很多麻烦。8个空格太长，缩进几次会导致行太长，shell脚本的每一行也不宜太长。如果有2个空格，缩进频繁的话，看起来比较吃力。另外，如果在写代码的时候不小心多了一个或者少了一个空格，在某些场景下，如果不看逻辑，是无法判断是多了一个还是少了一个，而这更容易导致别人改错，或者代码越改越多。混乱。对于4个空格在缩进层数较多的情况下也可能导致行过长的问题，可以通过修改逻辑减少缩进层数或行折叠来解决，而不是减少缩进空格数。每行代码最大字符数没有特殊场景，每行代码不超过100个字符。原因：代码太长，不方便阅读，不方便用diff等工具分析处理代码，所以需要约定最大字符数。经典的80字符约定是当时输出设备限制产生的标准，但现在屏幕基本都是宽屏，终端仿真器也是大小可调的（而不是固定的80x24）。迎合过时的标准并浪费屏幕空间。而且如果使用80个字符的约定，很容易遇到需要换行的情况，导致可读性下降。如果一行超过100个字符，通常表示逻辑过多，需要换行或换行。在一些特殊的场景下，比如显示一张由ASCII字符组成的图片，会有一行超过100个字符的要求，所以不能严格执行每行不得超过100个字符的约定。如果换行或换行不可避免地导致代码可读性降低，请优先考虑可读性。换行符在上一行的末尾添加一个空格和\，并在换行符后缩进一级（4个空格）。如果要缩进一段文本，可以使用对齐缩进，也可以使用4个空格的固定缩进。如果在aa&&bb||中断行cc,[[]]或(()),&&||位于下一行的开头。原因：折行缩进和普通缩进都是为了体现代码的递进关系，没必要区别对待（比如双行缩进）。出于审美原因，使用对齐缩进而不是固定缩进。然后因为每个人的审美不同，很容易有不同的压痕方式，造成不必要的麻烦。但它对文本块来说是特殊的，因为通常对齐缩进是没有争议的。&&和||逻辑上属于语句的后半部分，在自然语言中也是如此。例如，明天我会去公园或去购物。如果需要拆分成两个子句，则为tomorrowIwillgototheparkorgoshopping，和NottomorrowIwillgototheparkor,goshopping。代码也是如此。并放置&&或||在行的开头更容易对齐，看起来更舒服。在空格缩进和缩进之外的场景中，不允许出现逻辑上不必要的连续多个空格。二元运算符，例如+&&|需要在它们周围添加一个空间。一元运算符之间没有空格，例如!~和目标。()和(()){}里面不加空格，[[]]里面因为语法要求加空格。;前后没有空格。在定义函数时（以及在(()中调用函数时），函数名和(之间没有空格。ifwhile等关键字和后面的内容之间加了一个空格。在if[[]等场景中]{，在{和前面的内容之间加一个空格。变量和[]之间没有空格。使用[]获取数组或哈希表值时，[]里面没有空格。><等重定向symbols和files或者filesdescriptor之间不要加空格原因：适量加空格可以让代码更清晰易读这些约定基本上属于很多编程语言代码风格中的习惯，符合大多数人的审美，空行不是特殊场景，连续空行不能超过两个，在#!/bin/zsh后面加一个空行。在ifwhile等语句块后加一个空行。在函数定义后添加一个空行。在逻辑关系较弱的两行（或两块）代码之间，根据逻辑关系的强弱（自行判断）添加一两行空行。原因：加入适量的空格可以使代码逻辑以空行分隔，提高可读性。因为加空行的方法涉及到的因素很多，所以很难具体说明，主要还是要靠开发者自己的判断。括号在判断条件时，不要用[]，用[[]]代替。在数值计算中，使用$(())而不是$[]。原因：在判断条件的场景中，[]的功能没有[[]]丰富，两者的用法也有区别，混用容易出问题。在数值比较或者计算的场景下，$[]的功能没有$(())丰富，混合使用容易出问题。[]各处功能不一致，非必要场景尽量避免使用。如果常量字符串常量中没有特殊符号，可以在两端加上引号。使用数值时，不要在它们两边加上引号。原因：如果任何字符串常量在两端都用引号引起来，很容易使代码充满引号，影响可读性。而如果不小心误删了引号，很容易造成难以定位的错误。Shell脚本不同于许多其他编程语言。处理字符串的逻辑占了很大一部分。如果每个字符串常量两边都用引号引起来，会增加很多额外的工作。变量使用$var获取变量值时，两边不能加双引号，除非非字符串变量需要转成字符串。在非必要场景下，${var}中不需要加花括号。在可以使用局部变量的地方，使用所有局部变量（用local定义）。变量名中的单词可以用下划线或驼峰式分隔，在不影响可读性的情况下可以全部使用小写字母，但在同一个文件中必须保持一致。原因：与bash不同，zsh在使用$var读取变量内容时，不需要因为变量不存在、值为空、或者包含特殊符号而产生各种逻辑错误，所以不需要加双引号在两端。使用$var读取变量是很多编程语言中的用法，而${var}几乎是shell中独有的用法，而且输入起来比较麻烦，所以没有必要提倡这种用法。而且，变量名不带大括号的粘贴导致的错误，在写代码时可以识别，与外部输入无关。不需要输入很多额外的大括号来避免不存在的问题。如果在可以使用局部变量的地方可以使用全局变量，则更容易出现全局变量重名相互影响导致错误的情况。这种错误很难排查（因为不会产生语法错误，很容易怀疑是代码逻辑问题，不检查是否有同名的全局变量），往往会浪费很多开发人员或测试人员的时间。不同编程语言的开发者对变量名的风格偏好不同，不宜规定统一的风格。被引用的字符串常量的两端可以加双引号或单引号，但在同一个文件中样式必须保持一致。原因：双引号和单引号作用不同，混用在所难免。在双引号和单引号都适用的场景下，统一使用一种引号可以让代码更加简洁易读。不同编程语言背景的开发者对单引号和双引号的偏好不同，不宜强行使用默认引号。函数可以使用name()或functionname()来定义函数，但风格必须在同一个文件中保持一致。原因：如果约定使用name()来统一定义函数，那么就没有考虑到JavaScript等编程语言开发者的习惯，function关键字有利于代码查找。如果同意使用functionname()来统一定义函数，需要额外输入9个字符，但意义有限，输入大于输出。脚本行数不是特殊场景，单个脚本文件不超过1000行。原因：由于shell脚本的特性，单个脚本文件过长容易导致各种问题（比如全局变量相互影响）。1000行代码足以应对大多数场景。如果您正在编写需要分发的脚本，例如安装脚本，则分发单个文件比分发多个文件（需要打包和解包等额外工作）容易得多。这种情况可能需要编写很长的脚本。因此，不建议在单个脚本文件中强制执行最大行数。总结本文介绍了我推荐的zsh编码风格，可以适当参考。内容有待完善。本文不再更新，全系列文章更新维护在这里：github.com/goreliu/zshguideWindows、Linux、Shell、C、C++、AHK、Python、JavaScript、Lua等相关问题的付费解决方案，定价灵活，欢迎咨询，微信ly50247。
