Manual de Live Systems

Estilo de código

Estilo de código

En este capítulo se documenta el estilo de código utilizado en los sistemas en vivo.

Compatibilidad

●  No utilizar sintaxis o semántica que sea única para el intérprete de comandos Bash. Por ejemplo, el uso de arrays.

●  Utilizar únicamente el subconjunto POSIX - por ejemplo, usar $(foo) en lugar de `foo`.

●  Se puede comprobar las secuencias de comandos con 'sh -n' y 'checkbashisms'.

●  Asegurarse de que el código funcione con 'set -e'.

Sangrado

●  Utilizar siempre los tabuladores en lugar de espacios.

Ajuste de líneas

●  En general, las líneas contienen 80 caracteres como máximo.

●  Utilizar los saltos de línea al «estilo Linux»:

Mal:

Bien:

●  Lo mismo vale para las funciones:

Mal:

Bien:

Variables

●  Las variables deben escribirse siempre en letras mayúsculas.

●  Las variables que se utiliza en live-build siempre comienzan con el prefijo LB_

●  Las variables temporales internas de live-build deben comenzar con el prefijo \_LB_

●  Las variables locales comienzan con el prefijo live-build \_\_LB_

●  Las variables en relación a un parámetro de arranque en live-config comienzan con LIVE_.

●  Todas las demás variables de live-config comienzan con el prefijo _

●  Utilizar llaves para las variables, por ejemplo, escribir ${FOO} en lugar de $FOO.

●  Utilizar comillas dobles en las variables para evitar dejar espacios en blanco: Escribir “${FOO}” en lugar de ${FOO}.

●  Por motivos de coherencia, se debe utilizar siempre comillas en la asignación de valores a las variables:

Mal:

Bien:

●  Si se utilizan múltiples variables, incluir la expresión completa entre comillas dobles:

Mal:

Bien:

Miscelánea

●  Se debe utilizar “|” (sin comillas) como separador cuando se invoque a sed, p.ej. “sed -e 's|foo|bar|'” (Pero sin las comillas "")

●  No se debe utilizar el comando test para hacer comparaciones o pruebas, usar “[” “]” (sin ““); p.ej. ”if [ -x /bin/foo ]; ...” en lugar de “if test -x /bin/foo; ...”.

●  Se debe utilizar case siempre que sea posible en lugar de test, ya que es más fácil de leer y más rápido en la ejecución.

●  Usar mayúsculas en los nombres de las funciones para evitar confusiones con el entorno de los usuarios.