乐趣区

关于代码规范:记一次符合Google-Coding-Style的Bash脚本重构

jiezi

最近我在思考这样一个问题，顺便看一下 gpt 对这个问题的解释。搜寻发现：

团队写代码，为什么要遵循 coding guideline？

  1. 一致性：编码准则确保整个团队的代码格调和格局是统一的，这使得团队成员之间更易于交换和合作。这也使得代码更容易保护和更新，因为其他人能够更轻松地了解代码。
  2. 可读性：编码准则有助于进步代码的可读性。通过对代码进行格式化和正文，代码会更易于浏览和了解，从而缩小谬误和缺点，并进步代码的品质。
  3. 可维护性：编码准则有助于进步代码的可维护性。通过应用统一的格局和格调，团队成员能够更轻松地了解代码，并进行更疾速的故障排除和修复。
  4. 代码品质：编码准则有助于进步代码的品质。通过要求团队成员编写可读性高、可维护性强的代码，编码准则能够确保代码更加强壮、牢靠和平安。这也有助于缩小代码缺点和谬误，进步代码的可靠性和可用性。
  5. 代码重用：编码准则有助于进步代码的重用性。通过编写符合标准的代码，团队成员能够更容易地将代码重用在其余我的项目中，从而进步生产力和效率。

持续搜寻：

对于一个应用 bash 为次要语言的我的项目，业界举荐的 coding guideline？

  1. 应用有意义的变量名：变量名应该具备描述性，以便其他人能够轻松地了解代码。
  2. 缩进：应用 4 个空格作为缩进，而不是制表符。
  3. 正文：对代码进行正文，以解释代码的目标和性能。正文应该清晰、简洁，并且易于浏览。
  4. 函数：编写短小精悍的函数，每个函数都应该具备一个特定的目标。函数应该应用有意义的名称，并且应该清晰地形容其目标和性能。
  5. 错误处理：在代码中蕴含错误处理，以确保代码在遇到谬误时不会解体或产生不可预测的后果。
  6. 应用双引号：在援用变量时，应用双引号而不是单引号，以确保变量扩大可能失常工作。
  7. 应用全局变量：尽量避免应用全局变量，因为它们很难调试和保护。
  8. 应用命令替换 ：应用 $() 语法而不是反引号 “ 来执行命令替换。
  9. 应用数组：应用数组来治理相干变量，而不是应用多个独自的变量。
  10. 应用“set -u”：应用“set -u”来查看未定义的变量，以防止在援用未定义的变量时产生谬误。

这些标准有助于进步 Bash 代码的可读性、可维护性和可靠性。
而后我搜寻 “bash script style guideline”，最下面的后果是：

即代码标准：https://google.github.io/styleguide/shellguide.html
我仔细阅读了这份格调指南，对其中的“局部变量”的章节很感兴趣。
文中说：「最好把局部变量的定义与赋值，换行实现，不要写到同一行上」，免得覆盖报错状态码。
原文

Declare function-specific variables with local. Declaration and assignment should be on different lines.
Ensure that local variables are only seen inside a function and its children by using local when declaring them. This avoids polluting the global name space and inadvertently setting variables that may have significance outside the function.
Declaration and assignment must be separate statements when the assignment value is provided by a command substitution; as the local builtin does not propagate the exit code from the command substitution.

我入手验证这个细节，发现果然如此：

而后我开始自查以后的我的项目，寻找相似于如下格调的代码：

local my_var="$(my_func)"

优化后的预期后果：

local my_var
my_var="$(my_func)"

在 https://regex101.com/ 测试代码的运行。给出范例

regex:  
  local fn=$(echo $name_ver| tr ':' '-').tar.xz
test string
  local fn=$(echo $name_ver| tr ':' '-').tar.xz     #一般
    local fn=$(echo $name_ver| tr ':' '-').tar.xz   # 模仿多个空格
    local fn=$(echo $name_ver| tr ':' '-').tar.xz       # 模仿 tab 缩进
    local fn="$(echo $name_ver| tr':''-').tar.xz" # 模仿带引号的变量申明

测仿佛生成的代码

$1local $2\n$1$2=$3

生成的代码

$re = '/^(\s*)local\s+(\w+)=("?\$\(.*)/m';
$str = 'local fn=$(echo $name_ver| tr \':\'\'-\').tar.xzt
    local fn=$(echo $name_ver| tr \':\' \'-\').tar.xzt
    local fn=$(echo $name_ver| tr \':\' \'-\').tar.xz
    local fn="$(echo $name_ver| tr \':\'\'-\').tar.xz"';
$subst = "$1local $2\n$1$2=$3";

$result = preg_replace($re, $subst, $str);

echo "The result of the substitution is".$result;

精简为 perl_oneliner:

perl -pe 's/^(\s*)local\s+(\w+)=("?\$\(.*)/$1local $2\n$1$2=$3/g' -i file.txt

测试的场景：
搜寻代码

pcregrep -lr '^(\s*)local\s+(\w+)=("?\$\(.*)' *

批量修改：

perl -pi -e 's#^(\s*)local\s+(\w+)=("?\$\(.*)#$1local $2\n$1$2=$3#'$(pcregrep -l -r'^(\s*)local\s+(\w+)=("?\$\(.*)' * )

修改之后，仔细阅读 diff，测验成果，发现合乎预期。

后续：减少 git hook 检测代码

为了让当前新增的代码，也都合乎上述标准，我减少了这样一个 pre-commit 脚本。这样，每次提交之前，它都会帮我确保代码合规。

同时，我在编辑器里，设置了 shfmt、shellcheck 之类的标准，并设置为 format on save，即保留时主动格式化，来主动解决格局问题。

# test code 
if ! grep -wq 'Code violates rules' .git/hooks/pre-commit; then
cat >> .git/hooks/pre-commit <<'GIT_PRE_COMMIT_EOF'                                                                                                                                        
#!/usr/bin/env bash
if find . -name '*.sh'| xargs pcregrep '^\s+local\s+\w+="?(`|\$\()'; then
  echo "Error: Code violates rules"
  echo 'use: local var'
  echo 'var="$(...")'
  echo 'instead of local var=``'
  echo 'or local var="$(...)"'echo'as of explained in https://google.github.io/styleguide/shellguide.html'
  exit 1
fi
GIT_PRE_COMMIT_EOF
chmod +x .git/hooks/pre-commit
fi

总结：

  • 寻找业界标准
  • 遵循标准
  • 批改过来不合标准的代码
  • 新增代码确保合规
  • 将代码的标准查看，退出到日常的流程里。（goimport check)
  • 越早做，历史包袱越少。越晚做，历史包袱越惨重。
  • related PR: https://git.yunion.io/projects/CLOUD/repos/yunion-build/pull-…

links

  • Checks · koalaman/shellcheck Wiki
  • ShellCheck – A shell script static analysis tool
  • styleguide | Style guides for Google-originated open-source projects*
  • regex101: build, test, and debug regex

以上是文章的次要内容，作为交融云 / 多云治理 / 公有云 /FinOps 厂商，云联壹云会继续关注这些畛域的动静，分享相干的信息和技术，能够通过的官网（yunion.cn）或关注的公众号（云联壹云）来获取最新的信息，感激大家的工夫。

原文地址：https://www.yunion.cn/article/html/20230524.html

其余举荐浏览

云联壹云交融云治理平台的 10 大利用场景
SkyPilot：构建在多云之上的 ML 和数据迷信，可节约 3 倍以上老本
Flexera 2023 云状态报告解读
新品公布 | Cloudpods 3.10 版本上线！
企业面对 FinOps，到底能做些什么？总结了 4 个方面

退出移动版