221

Most languages have naming conventions for variables, the most common style I see in shell scripts is MY_VARIABLE=foo. Is this the convention or is it only for global variables? What about variables local to the script?

codeforester
  • 722
  • 2
  • 8
  • 23
Garrett Hall
  • 5,121
  • 5
  • 19
  • 12
  • 1
    The only one that I know of which everyone should follow is all uppercase names should be reserved for the shell. Don't use them to avoid accidentally clobbering something important like `PATH` or `HOME` or anything else the shell might reserve in the future. – jw013 Jul 11 '12 at 20:53
  • 3
    Actually, all uppercase names are typically used for environment variables. Some variables (like PATH) are interpreted by the shell, while others (like LANGUAGE or PRINTER) may be interpreted by other programs, but there is nothing otherwise special about them. – jlp Jul 11 '12 at 23:01
  • 'environment variables' is indeed the proper name, I'll include it in my answer. – jippie Jul 12 '12 at 06:45
  • 3
    While not authoritative, this Google guide has good suggestions: https://google.github.io/styleguide/shell.xml. It suggests sticking to all caps only for constants and exported variables, snake case for everything else. Personally I like camel case for my globals since no one else recommends it, which lowers the probability of naming collisions. Plus I like the way they read. – Binary Phile May 22 '16 at 14:58
  • 1
    Similar question on SO: [Correct Bash and shell script variable capitalization](https://stackoverflow.com/q/673055/6862601). – codeforester May 11 '18 at 17:05
  • @jlp, because environment variables and regular shell variables share a namespace (setting a shell variable overwrites any like-named environment variable), the conventions defined in the fourth paragraph of https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html apply to both categories. (It's worth noting that while that document is titled "Environment Variables", the list of notable reserved names therein also includes names of some shell variables that are _not_ typically exported to the environment). – Charles Duffy Sep 18 '22 at 16:19

3 Answers3

212

Environment variables or shell variables introduced by the operating system, shell startup scripts, or the shell itself, etc., are usually all in CAPITALS1.

To prevent your variables from conflicting with these variables, it is a good practice to use lower_case variable names.

1A notable exception that may be worth knowing about is the path array, used by the zsh shell. This is the same as the common PATH variable but represented as an array.

Kusalananda
  • 320,670
  • 36
  • 633
  • 936
jippie
  • 13,756
  • 10
  • 44
  • 64
  • 57
    `lower_case` underscore separated or `camelCase`? – Garrett Hall Jul 11 '12 at 20:55
  • 12
    @GarrettHall That's entirely up to you. Once you pick one stick with it. Consistency is more important than the actual choice. – jw013 Jul 11 '12 at 20:57
  • 6
    matter of taste? I personally like the C-style `camelCase` because it is shorter and doesn't use the ugly underscore. Taste, style, ... – jippie Jul 11 '12 at 20:57
  • 39
    matter of taste? I personally like underscore separated, easier to read. – janos Jul 12 '12 at 08:22
  • 9
    For completeness, environment variables aren't the only category of conventionally all-uppercase shell variable names -- this rule also applies to builtins (like `PWD`, `PS4`, or `BASH_SOURCE`). – Charles Duffy Jan 07 '15 at 23:49
  • @GarrettHall What I do is this plus `CamelCase` for `local` variables that I exclusively allow to be referenced inside child functions--when I do allow that. Just a convention, but helps keep scopes clean. – Alois Mahdal May 18 '16 at 19:27
  • @jippie code in python and underscore won't be ugly to you anymore – Nic Szerman Jul 30 '21 at 12:16
147

Yes, there are full code style conventions for bash, including variable names. For example, here's Google's Shell Style Guide.

As a summary for the variable names specifically:

Variable Names: Lower-case, with underscores to separate words. Ex: my_variable_name

Constants and Environment Variable Names: All caps, separated with underscores, declared at the top of the file. Ex: MY_CONSTANT

Roland
  • 163
  • 1
  • 7
Anonsage
  • 1,579
  • 1
  • 9
  • 4
  • 13
    These convention are only Google ones for their own open source projects: though they could be very good rules, it could not apply to *all* projects. – smonff Feb 04 '17 at 14:16
9

Underscores to separate words seem to be the best way to go.
I have a few reasons to prefer snake_case over camelCase when I'm free to choose:

  1. Flexible: You can use upper case and lower case (e.g. MY_CONSTANT and my_variable);
  2. Consistent: The digits can be separated to make the number more readable (e.g. 1_000_000_000) and this feature is supported in many programming languages;
  3. Common: Common at the point the regex \w handles underscores like word characters and numbers ([a-zA-Z0-9_]).
isar
  • 191
  • 1
  • 1
  • 1
    I believe we should steer clear of attempts to rationalize stylistic decisions (or opinions in general) because the rationale is usually tenuous and can swing either way with little effort. (Also, it polarizes people, often inciting religious wars and time wasted on immaterial issues.) Specifically in re: your reasons, `camelCase` does not preclude #2, and #3 is trivially mitigated by considering capitals as additional word boundaries. Re: #1, there is no reason why `LOUD_SNAKE` can't be used with `camelCase`—that is a common combination, the former often being for constants/globals. – Ezekiel Victor Mar 31 '23 at 02:01