Существуют ли соглашения по именованию переменных в сценариях оболочки?


113

Большинство языков имеют соглашения по именованию переменных, наиболее распространенный стиль, который я вижу в скриптах оболочки MY_VARIABLE=foo. Это соглашение или это только для глобальных переменных? Как насчет переменных, локальных для скрипта?


1
Единственное, что я знаю, которому должны следовать все, - все имена в верхнем регистре должны быть зарезервированы для оболочки. Не используйте их , чтобы избежать случайного затирания что - то важное , как PATHили HOMEили что - нибудь еще оболочка может зарезервировать в будущем.
jw013

3
На самом деле, все прописные имена обычно используются для переменных среды. Некоторые переменные (например, PATH) интерпретируются оболочкой, в то время как другие (например, LANGUAGE или PRINTER) могут интерпретироваться другими программами, но в них нет ничего особенного.
JLP

«Переменные среды» - действительно правильное имя, я включу его в свой ответ.
Джиппи

Хотя это руководство не является официальным, у него есть хорошие предложения: google.github.io/styleguide/shell.xml . Он предлагает придерживаться всех заглавных букв только для констант и экспортируемых переменных, случай змеи для всего остального. Лично мне нравится верблюжий чехол для моих глобалов, поскольку никто не рекомендует его, что снижает вероятность именования коллизий. Плюс мне нравится, как они читают.
Бинарный Филе

Ответы:


111

Переменные окружения или переменные оболочки, которые вводятся операционной системой или сценариями запуска оболочки и т. Д., Обычно находятся в CAPITALS.

Чтобы ваши собственные переменные не конфликтовали с этими переменными, это хорошая практика lower case.


32
lower_caseподчеркивание разделено или camelCase?
Гаррет Холл

3
@GarrettHall Это полностью зависит от вас. Как только вы выбираете одну палку с ним. Согласованность важнее, чем фактический выбор.
jw013

2
вопрос вкуса? Мне лично нравится стиль C, camelCaseпотому что он короче и не использует некрасивое подчеркивание. Вкус, стиль, ...
Джиппи

19
вопрос вкуса? Мне лично нравится подчеркивать отдельно, легче читать.
Янош

4
Для полноты картины , переменные окружения не являются единственной категорией имен переменных , обычно все прописные оболочки - это правило распространяется также на встроенные команды (например PWD, PS4или BASH_SOURCE).
Чарльз Даффи

62

Да, для bash существуют соглашения по полному стилю кода, включая имена переменных. Например, вот руководство по стилю оболочки Google .

В качестве резюме для имен переменных конкретно:

Имена переменных : строчные, с подчеркиванием для разделения слов. Пример:my_variable_name

Имена переменных и констант среды : все заглавные буквы, разделенные подчеркиванием, объявлены в верхней части файла. Пример:MY_CONSTANT


1
Приведенная выше ссылка теперь не работает, но я считаю, что это то, с чем она связана: google.github.io/styleguide/shell.xml
Сэм,

1
@ Сэм, спасибо. Да, это так. Самое время, чтобы Google прекратил использовать googlecode.com lol
Anonsage

1
Как вы всегда делать то , что говорит Google? ;-)
tim.rohrer

1
Эти соглашения предназначены только для Google для их собственных проектов с открытым исходным кодом: хотя они могут быть очень хорошими правилами, они не могут применяться ко всем проектам.
smonff

1

Подчеркивание отдельных слов, кажется, лучший путь.
У меня есть несколько причин, чтобы предпочесть snake_case, а не camelCase, когда я могу выбирать:

  1. Гибкость: вы можете использовать верхний и нижний регистр (например, MY_CONSTANTи my_variable);
  2. Согласованно: цифры можно разделять, чтобы сделать число более читабельным (например 1_000_000_000), и эта функция поддерживается во многих языках программирования;
  3. Общее: Общее в том месте, где регулярное выражение \wобрабатывает подчеркивания, такие как символы слов и цифры ( [a-zA-Z0-9_]).
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.