icy/bash-coding-style

What about global non environment variables

ChillerDragon opened this issue · 3 comments

ChillerDragon commented

You suggest UPPER_SNAKE_CASE for user provided environment variables. And lower_snake_case for local method variables.
That sounds nice. But I would also like to define global non user provided variables to share state between methods. Any recommendations on how to mark them as such? I am tempted to go all UPPER_SNAKE_CASE on those. But then it might look like the user could set environment variables to overwrite them but that is not the case :c

icy commented

You suggest UPPER_SNAKE_CASE for user provided environment variables. And lower_snake_case for local method variables. That sounds nice. But I would also like to define global non user provided variables to share state between methods. Any recommendations on how to mark them as such? I am tempted to go all UPPER_SNAKE_CASE on those. But then it might look like the user could set environment variables to overwrite them but that is not the case :c

hi @ChillerDragon ,

Thanks for your looking at my recommendations.

I used to have _ for internal variables, and __ for very internal variables. The _ prefix is unfortunately deprecated as in https://github.com/icy/bash-coding-style#deprecation after a few (or many) questions about that. However I think that'd be useful for your user case.

I don't think there is any problem if you introduce any consistent style in your scripts, and some (self) documentation so your maintainer can continue your work.

Hope this helps.

ChillerDragon commented

okay cool thanks for the fast response. Yea I might go with the underscore prefix.