正确的Bash和shell脚本变量大写化

Question

正确的Bash和shell脚本变量大写化

我遇到了许多带有所有大写变量的shell脚本，而且我一直认为对此存在严重的误解。我的理解是，根据惯例(也许在很久以前就有必要)，环境变量全副武装。

但是在像bash这样的现代脚本环境中，我总是更喜欢用小写名称来表示临时变量和大写变量。仅用于导出(即环境)变量..例如：

#!/usr/bin/env bashyear=`date +%Y`echo "It is $year."export JAVA_HOME="$HOME/java"

这一直是我对事情的看法。是否有权威人士同意或不同意这种做法，还是纯粹是一种风格的问题？

Answer 1

任何一贯遵循的命名约定都会有所帮助。以下是shell变量命名的一些有用提示：使用所有上限和下划线用于导出变量和常量，特别是当它们在多个脚本或进程之间共享时。在适用的情况下使用通用前缀，以便相关变量突出，不会与Bash内部变量都是大写字母。例子：具有公共前缀的导出变量：JOB_HOME JOB_LOG JOB_TEMP JOB_RUN_CONTROL常数：LOG_DEBUG LOG_INFO LOG_ERROR STATUS_OK STATUS_ERROR STATUS_WARNING使用“蛇壳”(所有小写和下划线)对于范围为单个脚本或块的所有变量。例子：input_file first_value max_amount num_errors局部变量与环境变量有某种关系时的混合情况，如：old_IFS old_HOME用前导下划线用于“私有”变量和函数。如果您曾经编写一个shell库，其中库文件中或跨文件中的函数需要共享变量，而不与主代码中可能类似命名的任何内容发生冲突，则这一点尤为重要。例子：_debug _debug_level _current_log_file避骆驼箱..这将最大限度地减少案例键入所导致的错误。记住，shell变量是大小写敏感.例子：inputArray thisLooksBAD, numRecordsProcessed, veryInconsistent_style另见：开放组基础规范问题7-环境变量

Answer 2

我做你该做的。我怀疑是否有权威来源，但这似乎是一个相当广泛的事实上的标准。