4

Variables and procedures in JavaScript are often named via the "camelCase" naming method, as:

  • myVariable

Any letter of the only or not-only-but first letter in an expression which acts as a data structure's name or part of a name is lowercased.
Contrarily, from my experience it is somewhat common to uppercase all starting letters of the only or all expressions of a name as:

  • MyVariable

What is the term to describe the data structure Naming method common in Bash?

muru
  • 72,889
timesharer
  • 51
  • 3
    That's not a bash naming convention. That's a naming convention in javascript for classes/constructors. It is also the naming convention in other, even older programming languages for classes eg. Java, C++ etc. – slebetman Mar 04 '21 at 03:06
  • 4
    I’m voting to close this question because it's off-topic. This convention is not common in bash or in any other Unix-related tool. – Gilles 'SO- stop being evil' Mar 04 '21 at 12:40

2 Answers2

16

This naming convention is called PascalCase, or Upper Camel Case or StudlyCase. Wikipedia has a list of naming conventions.

Though, I haven't heard of such convention for Bash. It seems to be more open-minded. The only convention I know of for Bash is to use capitalized words for constants. This answer talks about that. TL;DR: pick a convention and stick to it.

ilkkachu
  • 138,973
Battleman
  • 276
  • 5
    be careful with all caps : they could collide with existing variables (or internal variables). To my knowledge, using a mix of uppercase and lowercase ensure you don't collide with existing common variables (TERM, LINES, etc) – Olivier Dulac Mar 03 '21 at 12:45
  • 4
    Most of what I've seen in Bash is snake_case. – JoL Mar 03 '21 at 23:00
  • 1
    I've seen a few authors use a convention to have the first letter be upper-case for globals, lower-case for locals, regardless of one's choice of animal. – u1686_grawity Mar 04 '21 at 11:22
12

What you describe is sometimes called PascalCase - but there is AFAIK no "crystal clear" definition of these typographic writing conventions.

As for the naming of Bash variables, I don't know if using PascalCase is really that common. The only "hard" recommendation I know is not to use all uppercase variable names unless you want to export such a variable to an environment variable (there are lots of questions both here and on StackOverflow on that topic). The reason is that (in particular) in Bash, crucial environment variables such as PATH are all-uppercase, and you will want to avoid clashing with/superseding these variables by accidentally same-named variables of your script. Since the shell is case sensitive, using lower- or mixed case names for "normal" variables helps avoiding this problem.

Note however that it is not that easy if you write scripts for other shells; as noted by @StéphaneChazelas e.g., there are all-lowercase variables with special meaning in zsh and csh, so you are in general well-advised to read the documentation for your shell. For sh, bash and ksh, checking your script with shellcheck (also available as standalone program in many Linux distributions) can be a great help as it also looks for (some of) these potential name clashes.

AdminBee
  • 22,803
  • I think the suggestion to not use all-uppercase comes from most "special" or system-defined env vars being all-uppercase, and the risk of clashing with those. Then again, consider Zsh's all-lowercase path, which is special in that it shadows PATH... – ilkkachu Mar 03 '21 at 10:39
  • 1
    @ilkkachu, in zsh scalar special variables are all-uppercase and array special variables are all-lowercase. The tying of the $PATH scalar to the $path array actually comes from csh a decade before zsh. – Stéphane Chazelas Mar 03 '21 at 10:55
  • @StéphaneChazelas, yep, it just means the usual suggestion to use all-lowercase variables to avoid clashes isn't all there is to it. Especially since assigning to path easily breaks your whole script. (Or maybe that's a good thing, at least it gets noticed quickly.) And if there's no namespacing, at all, then it's hard to be sure a new version of the shell won't break a script by introducing a new special variable the script used. Doesn't really matter if it's an array or not. – ilkkachu Mar 03 '21 at 11:04
  • 2
    @ilkkachu, yes very true. I only pointed out that all lower case variables were not limited to zsh, nor to $path there. In zsh, it's a convention for array variables. In csh, there are lower case special scalars like those used for options. bash used to have similar option variables. That's the ones that were converted to shopt options (and explains, though doesn't justify that nonsense with the two sets of options). – Stéphane Chazelas Mar 03 '21 at 11:43