¿Existen convenciones de nomenclatura para variables en scripts de shell?

113

La mayoría de los idiomas tienen convenciones de nomenclatura para variables, el estilo más común que veo en los scripts de shell es MY_VARIABLE=foo. ¿Es esta la convención o es solo para variables globales? ¿Qué pasa con las variables locales al script?

— Garrett Hall
fuente

El único que sé que todos deben seguir es que todos los nombres en mayúsculas deben reservarse para el shell. No utilizarlos para evitar que accidentalmente clobbering como algo importante PATHo HOMEo cualquier otra cosa la cáscara puede reservar en el futuro.

— jw013

En realidad, todos los nombres en mayúsculas se usan típicamente para variables de entorno. Algunas variables (como PATH) son interpretadas por el shell, mientras que otras (como LANGUAGE o PRINTER) pueden ser interpretadas por otros programas, pero no hay nada especial en ellas.

— jlp

'variables de entorno' es de hecho el nombre propio, lo incluiré en mi respuesta.

— jippie

Aunque no tiene autoridad, esta guía de Google tiene buenas sugerencias: google.github.io/styleguide/shell.xml . Sugiere apegarse a todas las mayúsculas solo para constantes y variables exportadas, caso de serpiente para todo lo demás. Personalmente, me gusta el caso de camello para mis globales, ya que nadie más lo recomienda, lo que reduce la probabilidad de nombrar colisiones. Además, me gusta cómo leen.

— Binary Phile

Pregunta similar sobre SO: Corregir mayúsculas variables Bash y script de shell .

— codeforester

Respuestas:

111

Las variables de entorno o las variables de shell introducidas por el sistema operativo o los scripts de inicio de shell, etc., generalmente están incluidas CAPITALS.

Para evitar que sus propias variables entren en conflicto con estas variables, es una buena práctica usarlas lower case.

— jippie
fuente

lower_casesubrayado separado o camelCase?

— Garrett Hall

@GarrettHall Eso depende totalmente de usted. Una vez que elija un palo con él. La consistencia es más importante que la elección real.

— jw013

¿cuestion de gusto? Personalmente, me gusta el estilo C camelCaseporque es más corto y no utiliza el subrayado feo. Gusto, estilo, ...

— jippie

¿cuestion de gusto? Personalmente, me gusta subrayar separado, más fácil de leer.

— janos

Para completar, las variables de entorno no son la única categoría de los nombres de variables shell convencionalmente todo en mayúsculas - esta regla también se aplica a las órdenes internas (como PWD, PS4, o BASH_SOURCE).

— Charles Duffy

Sí, hay convenciones de estilo de código completo para bash, incluidos los nombres de variables. Por ejemplo, aquí está la Guía de estilo de Shell de Google .

Como resumen de los nombres de variables específicamente:

Nombres de variables : minúsculas, con guiones bajos para separar las palabras. Ex:my_variable_name

Constantes y nombres de variables de entorno : todas las mayúsculas, separadas por guiones bajos, declaradas en la parte superior del archivo. Ex:MY_CONSTANT

— Anonsage
fuente

El enlace de arriba ahora está muerto, pero creo que esto es a lo que se vinculó: google.github.io/styleguide/shell.xml

— Sam

@ Sam, gracias. Sí, eso es todo. Ya es hora de que Google deje de usar googlecode.com lol

— Anonsage

Qué usted hace siempre lo que dice Google? ;-)

— tim.rohrer

Estas convenciones son solo de Google para sus propios proyectos de código abierto: aunque podrían ser reglas muy buenas, no podrían aplicarse a todos los proyectos.

— smonff

Los guiones bajos para separar las palabras parecen ser la mejor manera de hacerlo.
Tengo algunas razones para preferir snake_case sobre camelCase cuando soy libre de elegir:

Flexible: puede usar mayúsculas y minúsculas (por ejemplo, MY_CONSTANTy my_variable);
Consistente: los dígitos se pueden separar para que el número sea más legible (por ejemplo 1_000_000_000) y esta función es compatible con muchos lenguajes de programación;
Común: Común en el punto en que la expresión regular \wmaneja guiones bajos como caracteres de palabras y números ( [a-zA-Z0-9_]).

— isar
fuente