¿Por qué necesito colocar "hacer" en la misma línea que "para"?

1. Resumen

No entiendo, ¿por qué necesito la regla de bashate E010 ?

2. Detalles

Yo uso bashate para .sharchivos linting . Regla E010:

hacer no en la misma línea que para

for bashate:

• Correcto:

  #!/bin/bash
  for f in bash/*.sh; do
      sashacommand "$f"
  done

• Error:

  #!/bin/bash
  for f in bash/*.sh
      do sashacommand "$f"
  done

¿Hay algún argumento válido, por qué lo necesito fory doen la misma línea?

3. No es útil

No puedo encontrar una respuesta a mi pregunta en:

1. Google
2. Artículos sobre las mejores prácticas de codificación ( ejemplo )

3. documentación de bashate . Encuentro única :

   Un conjunto de reglas que ayudan a mantener las cosas consistentes en los bloques de control. Estos se ignoran en las líneas largas que tienen una continuación, porque el desenrollado es algo "interesante"

Sintácticamente, los siguientes dos fragmentos de código son correctos y equivalentes:

for f in bash/*.sh; do
    sashacommand "$f"
done

for f in bash/*.sh
    do sashacommand "$f"
done

Este último podría posiblemente puede decir que sea más difícil de leer como doofusca ligeramente el comando en el cuerpo del bucle. Si el bucle contiene múltiples comandos y el siguiente comando está en una nueva línea, la ofuscación se resaltaría aún más:

for f in *
    do cmd1
    cmd2
done

... pero marcarlo como un "error" es, en mi humilde opinión, la opinión personal de alguien más que una verdad objetiva.

En general, casi cualquiera ;puede ser reemplazado por una nueva línea. Ambos ;y newline son terminadores de comando. does una palabra clave que significa "aquí sigue lo que hay que hacer (en este forciclo)".

for f in *; do ...; done

es lo mismo que

for f in *
do
   ...
done

y como

for f in *; do
   ...
done

La razón para usar uno sobre otro es la legibilidad y las convenciones de estilo local / personal.

Opinión personal:

En los encabezados de bucle que son muy largos , creo que puede tener sentido colocar douna nueva línea, como en

for i in animals people houses thoughts basketballs bees
do
    ...
done

o

for i in        \
    animals     \
    people      \
    houses      \
    thoughts    \
    basketballs \
    bees
do
    ...
done

Lo mismo ocurre con el thenen una ifdeclaración.

Pero, de nuevo, esto se reduce a las preferencias personales de estilo, o al estilo de codificación que el equipo / proyecto esté usando.

Tenga en cuenta lo que dice en la parte superior de la página:

bashate: un equivalente pep8 para scripts de bash

PEP8 es la guía de estilo para el código Python. Si bien la gente de Python a menudo parece tomar muy en serio sus problemas de estilo ^{[cita requerida]} , es solo eso, una guía. Podríamos encontrar ventajas tanto para poner la línea doen la misma línea como forpara ponerla en una línea propia.

Es la misma discusión sobre dónde poner el { en código C al iniciar un ifo whilebloque (o tal).

Algunas líneas a continuación en la documentación, hay otra regla interesante:

E020: Declaración de función no en formato ^function name {$

Supongo que el punto aquí es que el autor de esa guía de estilo piensa que usar la functionpalabra clave es necesario para que el lector reconozca una declaración de función. Sin embargo, function fooes una forma no estándar de definir una función: la forma estándar es foo(). La única diferencia entre los dos (en Bash) es que el otro es más difícil de transferir a un shell estándar, como /bin/shen Debian o Ubuntu.

Por lo tanto, sugeriría tomar cualquiera y todas esas guías de estilo con un grano de sal o tres, y decidir por sí mismo cuál es el mejor estilo. Un buen verificador de estilo permite desactivar algunas verificaciones (bashate tiene bashate -i E010,E011que ignorar esas dos verificaciones). Un excelente verificador de estilo le permitiría modificar las pruebas, por ejemplo, para verificar lo contrario de E020, aquí.

TL; DR: No es necesario. Es solo la opinión de un tipo.

Como muchos otros, he estado escribiendo forbucles como este durante décadas:

for F in arg1 arg2 arg*
do
    somecommand "$F"
done

Este diseño resalta el hecho de que do ... done rodea el cuerpo del bucle, como las llaves en lenguajes tipo C, y permite que las nuevas líneas separen los componentes de la construcción del bucle.

Por supuesto, también hay guerras religiosas sobre dónde colocar las llaves, por lo que podría decirse que el jurado aún no se ha pronunciado sobre esto. En mi humilde opinión, así es claramente cómo fue diseñado para funcionar; Bourne era aficionado a los delimitadores emparejados, cf. if ... fi, case ... esacy la necesidad de un punto y coma en la versión más corta revela que lo estás haciendo más corto de lo originalmente diseñado. Nada de malo con eso; los avances tecnológicos y muchas cosas que antes parecían una buena idea ahora están mal vistas, como goto. Pero hasta que toda la comunidad de scripting de shell adopte las preferencias de los bashateautores, no tiene que hacer nada.

Me sorprende que nadie haya mencionado aún esta sintaxis válida y portátil:

set alfa bravo charlie
for q do
  echo "$q"
done

Observe cuidadosamente que fory doestán en la misma línea, sin punto y coma. Resultado:

alfa
bravo
charlie

Varias buenas respuestas aquí. Siempre tome las guías de estilo con un grano de sal, y en mi humilde opinión y experiencia, preocúpese de una manera moderada a moderada por cualquier comunidad que esté plagada de un dogma excesivo cuando se trata de estilo. Es casi como si creyeran que cuando FINALMENTE obtienen ese último punto, y ese último T cruzado, entonces el software funcionará. A veces se necesita un estilo más que perfecto para eliminar errores ...

Cuando comencé a aprender shell, la mayoría de los scripts y tutes usaban el formato de punto y coma en línea

for i in "$@"; do
    stuff
done

pero como no tenía experiencia, me costó un poco detectar el; y do, ambos esenciales para confirmar la corrección sintáctica. Así que preferí hacer en la siguiente línea por sí solo. Ya no hago eso (juego de palabras)

Además, el comando 'while' es un excelente candidato para un pequeño y agradable truco:

while prep1; prep2; condition; do
    stuff
done

pero cuando los comandos de preparación son un poco voluminosos y / o la condición es compleja, se formatea mejor como

while
    prep1
    prep2
    condition
do
    stuff
done

y luego agregar el do como "; do" es positivamente fugitivo.

Incluso puedes ser más intenso que eso:

while
    if con1; then
      cond2
    elif cond3; then
      cond4
    elif cond5; then
      cond6
    else
      cond7
    fi
do
    stuff
done

porque cada enunciado es una expresión. Observe cómo ambos estilos se usan de manera oportunista. Mantenlo limpio y es bastante legible. Compacta o contorsiona en nombre del estilo o "ahorro de espacio" y se convierte en un horrible desastre.

¡Asi que! Teniendo en cuenta los estilos más bien barrocos de los guiones de shell en general, cualquier cosa destinada a aumentar la claridad y el fácil acceso visual a símbolos significativos siempre es algo bueno.

La forma en que 'do' se escribe en línea con el comando es agradable cuando tienes un pequeño comando: no encuentro el 'do' visualmente oculto, ni el comando interno está realmente oscurecido:

for i in whatever
  do stuff
done

Me parece bastante agradable de ver, y tiene análogos con while, if y case:

while condition
  do stuff
end

if condition
  then stuff1
  else stuff2
fi

case $blah in
  a) stuff1;;
  b) stuff2;;
  c) stuff3;;
  *) stuffInfinity;;
esac

La claridad y el orden general es todo lo que Codd * te pide.

* Edgar F. Codd, padre de la teoría de bases de datos relacionales.