Use curly braces for all variable references

[nikolay]

How about standardizing on braces?

# Yep
echo "${var}"
echo "$1"

# Nope
echo "$var"

[progrium]

This is a somewhat common convention that I've not yet adopted. I understand the argument for consistency and avoiding surrounding text from being interpreted as part of the name. It's just one of those things that's so different from de facto Bash that I'm hesitant to force it upon people, including myself.

I'll leave this open and if I ever use it in a project and it feels like I shouldn't go back, I'll adopt it here. Thanks for bringing this one up.

[stuartpb]

Yeah, I've found that this is generally overkill, since I'm practically never expanding a variable next to a character that's a valid identifier character. I prefer curly-brace expansion as a signifier of "I'm doing something crazy with this variable" like replacement or substringing.

But, then, I use backticks for substituting non-nested commands, so maybe I'm just lazy / character-miserly.

[ernstki]

It adds unnecessary visual noise, and is not required for simple variable interpolation most of the time.

It's only really required when you need to stand off the variable name from a string suffix, e.g., "${base}_suffix.ext", or "${RED}ERROR!$RESET".

But…

…when you list off all the other times when braces are required around a variable name—parameter expansion (${param:+default}) and arrays ("${array[@]}")—I can definitely start to see where you're coming from, from the perspective of consistency.

[nikolay]

Conventions are about picking the best way among multiple options by the spec.

[meleu]

my two cents: I like to not waste time thinking about syntax/styles while coding. In this context, I mean I prefer to always use ${curly_braces} for consistency and just to avoid ":thinking: should I use curly braces here?"

[nikolay]

@meleu Yup! Conventions are not for the lazy but for the consistent.