Warum muss ich "do" in die gleiche Zeile wie "for" setzen?

1. Zusammenfassung

Ich verstehe nicht, warum ich die E010-Bashate-Regel brauche .

2. Einzelheiten

Ich benutze bashate zum Flusen von .shDateien. E010-Regel:

tun nicht auf der gleichen Linie wie für

for bashate:

• Richtig:

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

• Error:

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

Gibt es irgendwelche gültigen Argumente, warum ich forund doin der gleichen Zeile brauche ?

3. Nicht nützlich

Ich kann keine Antwort auf meine Frage finden in:

1. Google
2. Artikel über bewährte Codierungsmethoden ( Beispiel )

3. bashate Dokumentation . Ich finde nur :

   Eine Reihe von Regeln, mit denen die Konsistenz in Kontrollblöcken aufrechterhalten werden kann. Diese werden in langen Zeilen ignoriert, die eine Fortsetzung haben, weil das Abrollen irgendwie "interessant" ist.

Syntaktisch sind die folgenden zwei Codeausschnitte korrekt und äquivalent:

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

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

Letzteres ist möglicherweise schwerer zu lesen, da es doden Befehl im Hauptteil der Schleife leicht verschleiert. Wenn die Schleife mehrere Befehle enthält und sich der nächste Befehl in einer neuen Zeile befindet, wird die Verschleierung weiter hervorgehoben:

for f in *
    do cmd1
    cmd2
done

... aber es als "Fehler" zu kennzeichnen, ist meiner Meinung nach eher die persönliche Meinung eines Menschen als eine objektive Wahrheit.

Im Allgemeinen kann fast jede ;Zeile durch eine neue Zeile ersetzt werden. Sowohl ;als auch newline sind Befehlsabschlusszeichen. doist ein Schlüsselwort, das bedeutet "hier folgt, was zu tun ist (in dieser forSchleife)".

for f in *; do ...; done

ist das gleiche wie

for f in *
do
   ...
done

und wie

for f in *; do
   ...
done

Der Grund für die Überlagerung ist die Lesbarkeit und die lokalen / persönlichen Stilkonventionen.

Persönliche Meinung:

Ich halte es für sinnvoll , in sehr langen Loop - Headern doeine neue Zeile einzufügen , wie in

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

oder

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

Gleiches gilt für die thenin einer ifAussage.

Aber auch hier kommt es auf die persönlichen Stilvorlieben an oder auf den Kodierungsstil, den das Team / Projekt verwendet.

Beachten Sie, was oben auf der Seite steht:

bashate: Ein pep8-Äquivalent für Bash-Skripte

PEP8 ist der Style Guide für Python-Code. Während Python-Leute ihre Stilprobleme oft sehr ernst zu nehmen scheinen ^{[Zitat erforderlich]} , ist es nur das, ein Leitfaden. Wir könnten uns Upsides einfallen lassen, um beide doin die gleiche Zeile wie die zu setzenfor zu setzen und um sie in eine eigene Zeile zu setzen.

Es ist die gleiche Diskussion wie {beim Starten eines ifoder eines whileBlocks (oder eines solchen), wo der Code in C abgelegt werden soll .

Ein paar Zeilen weiter unten in der Dokumentation gibt es eine andere interessante Regel:

E020: Funktionsdeklaration nicht im Format ^function name {$

Ich gehe davon aus, dass der Autor dieses Styleguides der Meinung ist, dass die Verwendung des functionSchlüsselworts erforderlich ist, damit der Leser eine Funktionsdeklaration erkennt. Dies function fooist jedoch keine Standardmethode zum Definieren einer Funktion: Die Standardmethode istfoo() . Der einzige Unterschied zwischen den beiden (in Bash) ist, dass es schwieriger ist, die andere auf eine Standard-Shell zu portieren/bin/sh in Debian oder Ubuntu.

Daher würde ich vorschlagen, alle diese Styleguides mit ein oder drei Körnern zu nehmen und selbst zu entscheiden, welcher Style der beste ist. Mit einem guten Style-Checker können Sie einige Checks deaktivieren (bashate muss bashate -i E010,E011diese beiden Checks ignorieren). Mit einem ausgezeichneten Style-Checker können Sie die Tests modifizieren, z. B. um hier nach dem Gegenteil von E020 zu suchen.

TL; DR: Das musst du nicht. Es ist nur die Meinung eines Typen.

Wie viele andere schreibe ich seit forJahrzehnten Loops wie diese:

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

Dieses Layout unterstreicht die Tatsache, dass do ... done der Schleifenkörper wie geschweifte Klammern in C-ähnlichen Sprachen umgeben ist, und ermöglicht es Zeilenumbrüchen, die Komponenten des Schleifenkonstrukts zu trennen.

Natürlich gibt es auch religiöse Kriege darüber, wo die geschweiften Klammern platziert werden sollen. Man könnte also sagen, dass die Jury über diese noch nicht entschieden hat. IMHO, dies ist eindeutig, wie dies entworfen wurde, um zu funktionieren; Borowski mochte übereinstimmende Trennzeichen, vgl. if ... fi, case ... esacUnd die Notwendigkeit für ein Semikolon in der kürzeren Version zeigt , dass Sie machen es kürzer ist als ursprünglich entworfen. Daran ist nichts auszusetzen. technologische fortschritte und viele dinge, die früher eine gute idee schienen, werden jetzt missbilligt goto. Aber bis die gesamte Shell-Scripting-Community die Präferenzen der bashateAutoren übernimmt , müssen Sie nichts tun.

Ich bin überrascht, dass noch niemand diese gültige und portable Syntax erwähnt hat:

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

Beachten Sie dies sorgfältig forund dostehen in derselben Zeile ohne Semikolon. Ergebnis:

alfa
bravo
charlie

Hier einige gute Antworten. Nehmen Sie Styleguides immer mit einem Körnchen Salz und seien Sie meiner Meinung nach ein bisschen bis mäßig besorgt über jede Community, die in puncto Stil von übermäßigem Dogma geprägt ist. Es ist fast so, als ob sie glauben, dass die Software funktionieren wird, wenn sie das letzte Mal, dass ich gepunktet habe, und das letzte Mal, dass ich es überschritten habe, ENDLICH bekommen. Manchmal braucht es mehr als perfekten Stil, um Fehler zu entfernen ...

Als ich anfing, Shell zu lernen, verwendeten die meisten Skripte und Tutes das Inline-Semikolon-Format

for i in "$@"; do
    stuff
done

aber weil ich unerfahren war, fiel es mir ein bisschen schwer, die zu entdecken; und do - beides ist wichtig, um die syntaktische Korrektheit zu bestätigen. Also habe ich es vorgezogen, in der nächsten Zeile alles alleine zu machen. Ich mache das nicht mehr (Wortspiel beabsichtigt)

Außerdem ist der Befehl 'while' ein hervorragender Kandidat für einen kleinen Trick:

while prep1; prep2; condition; do
    stuff
done

Wenn die Vorbereitungsbefehle jedoch etwas umfangreich sind und / oder die Bedingung komplex ist, ist es besser, sie so zu formatieren

while
    prep1
    prep2
    condition
do
    stuff
done

und dann das Anhängen des do als "; do" ist positiv flüchtig.

Sie können sogar noch intensiver werden:

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

weil jede aussage ein ausdruck ist. Beachten Sie, wie beide Stile opportunistisch verwendet werden. Halten Sie es sauber und es ist gut lesbar. Kompakt oder verdreht es im Namen des Stils oder "platzsparend" und es wird ein schreckliches Durcheinander.

So! Angesichts des eher barocken Stils von Shell-Skripten im Allgemeinen ist es immer eine gute Sache, die Übersichtlichkeit und den visuellen Zugang zu wichtigen Symbolen zu verbessern.

Die Form, in der 'do' in den Befehl geschrieben ist, ist süß, wenn Sie einen kleinen Befehl haben - ich finde das 'do' weder visuell verborgen, noch ist der innere Befehl wirklich verdeckt:

for i in whatever
  do stuff
done

Ich finde das sehr angenehm anzusehen, und es hat Analogien mit while, if und case:

while condition
  do stuff
end

if condition
  then stuff1
  else stuff2
fi

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

Klarheit und allgemeine Ordnung sind alles, was Codd * von Ihnen verlangt.

* Edgar F. Codd, Vater der relationalen Datenbanktheorie.