Dlaczego muszę umieszczać „zrobić” w tym samym wierszu, co „za”?

1. Podsumowanie

Nie rozumiem, dlaczego potrzebuję reguły bashate E010 .

2. Szczegóły

Korzystam z bashate do segregowania.sh plików. Reguła E010:

zrobić nie na tej samej linii co do

for bashate:

• Poprawny:

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

• Błąd:

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

Czy jakieś ważne argumenty, dlaczego muszę fori dow tej samej linii?

3. Nieużyteczne

Nie mogę znaleźć odpowiedzi na moje pytanie w:

1. Google
2. Artykuły o najlepszych praktykach kodowania ( przykład )

3. dokumentacja bashate . Znajduję tylko :

   Zestaw reguł, które pomagają zachować spójność w blokach kontrolnych. Są one ignorowane w długich liniach, które mają kontynuację, ponieważ rozwijanie jest swego rodzaju „interesujące”

Składniowo następujące dwa fragmenty kodu są poprawne i równoważne:

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

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

Ta ostatnia może ewentualnie być uznane trudniej rozumieć jako donieco zaciemnia polecenia w organizmie pętli. Jeśli pętla zawiera wiele poleceń, a następne polecenie znajduje się w nowym wierszu, zaciemnianie będzie dodatkowo podświetlone:

for f in *
    do cmd1
    cmd2
done

... ale oznaczenie go jako „błąd” jest osobistą opinią IMHO, a nie obiektywną prawdą.

Zasadniczo prawie każdy ;może zostać zastąpiony nowym wierszem. Zarówno ;i nowa linia są terminatorami poleceń. doto słowo kluczowe, które oznacza „tutaj następuje to, co należy zrobić (w tej forpętli)”.

for f in *; do ...; done

jest taki sam jak

for f in *
do
   ...
done

i jako

for f in *; do
   ...
done

Powodem do używania jednego nad drugim jest czytelność i konwencje w stylu lokalnym / osobistym.

Osobista opinia:

W nagłówkach pętli, które są bardzo długie , myślę, że warto umieścić donową linię, tak jak w

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

lub

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

To samo tyczy się thenw ifoświadczeniu.

Ale znowu sprowadza się to do osobistych preferencji stylowych lub dowolnego stylu kodowania stosowanego przez zespół / projekt.

Zwróć uwagę na to, co jest napisane na górze strony:

bashate: odpowiednik pep8 dla skryptów bash

PEP8 to przewodnik po stylu dla kodu w języku Python. Podczas gdy ludzie Pythona często traktują swoje problemy ze stylem bardzo poważnie ^{[potrzebne źródło]} , to po prostu przewodnik. Możemy wymyślić zalety zarówno dla umieszczenia linii dow tej samej linii, jak fori dla umieszczenia jej w linii własnej.

To ta sama dyskusja, co do umieszczenia {kodu C podczas uruchamiania bloku iflub whilebloku (lub takiego).

Kilka wierszy poniżej w dokumentacji jest jeszcze jedna interesująca zasada:

E020: Deklaracja funkcji nie jest w formacie ^function name {$

Zakładam tutaj, że autor tego przewodnika po stylu uważa, że ​​użycie functionsłowa kluczowego jest konieczne, aby czytelnik mógł rozpoznać deklarację funkcji. Jednak function foojest niestandardowy sposób definiowania funkcji: standardowy sposób jest foo(). Jedyną różnicą między nimi (w Bash) jest to, że druga jest trudniejsza do przeniesienia do standardowej powłoki, jak /bin/shw Debianie lub Ubuntu.

Sugerowałbym więc wzięcie dowolnego przewodnika po stylu z odrobiną soli lub trzema i samodzielne wybranie najlepszego stylu. Dobry moduł sprawdzania stylu pozwala na wyłączenie niektórych testów (bashate musi bashate -i E010,E011zignorować te dwa testy). Doskonały moduł sprawdzania stylu pozwoliłby zmodyfikować testy, np. Aby sprawdzić przeciwieństwo E020 tutaj.

TL; DR: Nie musisz. To tylko opinia jakiegoś kolesia.

Jak wiele innych, pisałem fortakie pętle od dziesięcioleci:

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

Ten układ podkreśla fakt, że do ... doneotaczają ciało pętli, takie jak nawiasy klamrowe w językach podobnych do C, i pozwalają nowym wierszom oddzielić elementy konstrukcji pętli.

Oczywiście toczą się wojny religijne na temat tego, gdzie należy założyć również nawiasy klamrowe, więc można powiedzieć, że jury wciąż nie bierze udziału w tej. IMHO, właśnie tak to miało działać; Bourne lubił dopasowane ograniczniki, por. if ... fi, case ... esaca potrzeba średnika w krótszej wersji ujawnia, że ​​jest on krótszy niż pierwotnie zaprojektowany. Nic w tym złego; postęp technologiczny i wiele rzeczy, które kiedyś wydawały się dobrym pomysłem, teraz są odrzucone goto. Ale dopóki cała społeczność skryptów nie przyjmie preferencji bashateautora (autorów), nie musisz nic robić.

Dziwi mnie, że nikt jeszcze nie wspomniał o tej poprawnej i przenośnej składni:

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

Zauważ, że uważnie fori dosą na tej samej linii, bez średnikiem. Wynik:

alfa
bravo
charlie

Kilka dobrych odpowiedzi tutaj. Zawsze bierz przewodniki po stylu z odrobiną soli, a IMHO i doświadczeniem, bądź tak bardzo lekko lub umiarkowanie zaniepokojony każdą społecznością, która jest pełna nadmiernego dogmatu, jeśli chodzi o styl. To prawie tak, jakby wierzyli, że kiedy W KOŃCU dostaną ostatnią kropkę, i ostatnią literę T, to oprogramowanie będzie działać. Czasami usunięcie błędów wymaga więcej niż idealnego stylu ...

Kiedy zacząłem uczyć się powłoki, większość skryptów i tut używała wbudowanego formatu średnika

for i in "$@"; do
    stuff
done

ale ponieważ byłem niedoświadczony, miałem trochę trudności z zauważeniem; i do - oba niezbędne do potwierdzenia poprawności składniowej. Więc sam wolałem zrobić w następnym wierszu. Już tego nie robię (gra słów zamierzona)

Ponadto polecenie „while” jest doskonałym kandydatem na niezłą sztuczkę:

while prep1; prep2; condition; do
    stuff
done

ale gdy polecenia prep są nieco nieporęczne i / lub warunek jest złożony, lepiej go sformatować jako

while
    prep1
    prep2
    condition
do
    stuff
done

a następnie dołączenie do jako „; do” jest dodatnio niezrównane.

Możesz nawet stać się bardziej intensywny:

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

ponieważ każde zdanie jest wyrażeniem. Zwróć uwagę, jak oba style są używane oportunistycznie. Utrzymuj go w czystości i jest dość czytelny. Kompaktuj lub wykrzykuj w imię stylu lub „oszczędzania miejsca” i stanie się okropnym bałaganem.

Więc! Biorąc pod uwagę raczej barokowe style skryptów powłoki, wszystko, co ma na celu zwiększenie przejrzystości i łatwy wizualny dostęp do znaczących symboli, jest zawsze dobrą rzeczą.

Forma, w której „do” jest napisane w linii z poleceniem, jest słodka, gdy masz małe polecenie - nie uważam, że „do” jest ukryte wizualnie, ani też wewnętrzne polecenie nie jest naprawdę zasłonięte:

for i in whatever
  do stuff
done

Uważam, że jest to całkiem przyjemne i ma analogie z while, if i case:

while condition
  do stuff
end

if condition
  then stuff1
  else stuff2
fi

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

Codd * wymaga od ciebie jasności i ogólnego porządku.

* Edgar F. Codd, ojciec teorii relacyjnych baz danych.