Czy istnieją konwencje nazewnictwa dla zmiennych w skryptach powłoki?

113

Większość języków ma konwencje nazewnictwa dla zmiennych, najczęstszym stylem jaki widzę w skryptach powłoki jest MY_VARIABLE=foo. Czy to konwencja, czy tylko zmienne globalne? Co ze zmiennymi lokalnymi dla skryptu?

— Garrett Hall
źródło

Jedyne, o którym wiem, że wszyscy powinni podążać, to wszystkie wielkie litery powinny być zarezerwowane dla powłoki. Nie należy używać ich w celu uniknięcia przypadkowego przebijania coś ważnego podobnego PATHlub HOMEczy cokolwiek innego powłoka może zastrzec w przyszłości.

— jw013,

W rzeczywistości wszystkie nazwy pisane wielkimi literami są zwykle używane dla zmiennych środowiskowych. Niektóre zmienne (jak ŚCIEŻKA) są interpretowane przez powłokę, podczas gdy inne (jak JĘZYK lub DRUKARKA) mogą być interpretowane przez inne programy, ale nie ma w nich nic specjalnego.

— jlp

„zmienne środowiskowe” to rzeczywiście właściwa nazwa, uwzględnię ją w mojej odpowiedzi.

— jippie

Chociaż nie jest autorytatywny, ten przewodnik Google ma dobre sugestie: google.github.io/styleguide/shell.xml . Sugeruje to, aby trzymać się wszystkich wielkich liter tylko dla stałych i eksportowanych zmiennych, w przypadku wszystkich innych - wielkość węża. Osobiście lubię futerał wielbłąda dla moich globali, ponieważ nikt inny go nie zaleca, co zmniejsza prawdopodobieństwo kolizji nazw. Dodatkowo podoba mi się sposób, w jaki czytają.

— Binarny Phile

Podobne pytanie dotyczące SO: Correct Bash i wielkich liter zmiennych w skryptach powłoki .

— codeforester

Odpowiedzi:

111

Zazwyczaj wszystkie zmienne środowiskowe lub zmienne powłoki, które są wprowadzane przez system operacyjny lub skrypty startowe powłoki itp CAPITALS.

Dobrym zwyczajem jest zapobieganie konfliktom własnych zmiennych z tymi zmiennymi lower case.

— jippie
źródło

lower_casepodkreślenie oddzielone lub camelCase?

— Garrett Hall,

@GarrettHall To zależy wyłącznie od Ciebie. Po wybraniu jednego kija z nim. Spójność jest ważniejsza niż faktyczny wybór.

— jw013,

kwestia gustu? Osobiście lubię styl C, camelCaseponieważ jest krótszy i nie używa brzydkiego podkreślenia. Smak, styl, ...

— jippie

kwestia gustu? Osobiście lubię podkreślenia oddzielone, łatwiejsze do odczytania.

— janos

Dla kompletności, zmienne środowiskowe nie są jedyną kategorią konwencjonalnie wszystkie wielkie litery nazw zmiennych powłoki - zasada ta odnosi się także do poleceń wbudowanych (jak PWD, PS4lub BASH_SOURCE).

— Charles Duffy,

Tak, istnieją pełne konwencje stylu kodu dla bash, w tym nazwy zmiennych. Na przykład oto Przewodnik po stylach powłoki Google .

Jako podsumowanie nazw zmiennych w szczególności:

Zmienne nazwy : małe litery, z podkreślnikami do oddzielania słów. Dawny:my_variable_name

Stałe i zmienne środowiskowe Nazwy : Wszystkie wielkie litery, oddzielone podkreślnikami, zadeklarowane na górze pliku. Dawny:MY_CONSTANT

— Anonsage
źródło

Powyższy link jest już martwy, ale uważam, że jest to link do: google.github.io/styleguide/shell.xml

— Sam

@Sam, dziękuję. Tak, to wszystko. Najwyższy czas, żeby Google przestało używać googlecode.com lol

— Anonsage

Czy ty zawsze robić to, co mówi Google? ;-)

— tim.rohrer

Te konwencje są tylko Google dla ich własnych projektów open source: chociaż mogą to być bardzo dobre zasady, nie może mieć zastosowania do wszystkich projektów.

— smonff

Najlepszym sposobem wydaje się podkreślenie oddzielnych słów.
Mam kilka powodów, dla których wolę snake_case niż camelCase, kiedy mogę wybrać:

Elastyczność: możesz używać wielkich i małych liter (np. MY_CONSTANTI my_variable);
Spójny: cyfry można rozdzielić, aby numer był bardziej czytelny (np. 1_000_000_000), A ta funkcja jest obsługiwana w wielu językach programowania;
Często: Często w punkcie, w którym wyrażenie regularne \wobsługuje znaki podkreślenia, takie jak znaki słowne i cyfry ( [a-zA-Z0-9_]).

— isar
źródło