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ę for
i do
w tej samej linii?
3. Nieużyteczne
Nie mogę znaleźć odpowiedzi na moje pytanie w:
- Artykuły o najlepszych praktykach kodowania ( przykład )
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”
bash
shell-script
Саша Черных
źródło
źródło
do
jest zdecydowanie nieco nietypowe, alefor ... \ndo\n<indent>body...
jest bardzo powszechne, a nawet bardziej to oceniłbymfor ... ; do
. Czy też na to narzeka?bashate
to sprawdzanie stylu . Style są z natury subiektywne. Nie używaj go, jeśli nie podoba ci się styl biblioteki. Zamiast tego powinieneś rozważyć moduł sprawdzania składni / błędów, taki jak shellcheck .E010
- tylko styl reguła lub w niektórych przypadkach muszę za i zrobienia w tej samej linii, nie tylko ze względów stylistycznych.do
. To jak wcięcia klamry Otwarcieif
i dodanie kodu na tej samej linii, jak w języku C. Kolejny przykład, jeśli pyton zezwolił, będzie kładzenie:
odif
wcięty w następnej linii i dodanie kodu na tej samej linii. Sprawi, że będzie się to różnić dodatkowymi liniami w ciele.Odpowiedzi:
Składniowo następujące dwa fragmenty kodu są poprawne i równoważne:
Ta ostatnia może ewentualnie być uznane trudniej rozumieć jako
do
nieco 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:... 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ń.do
to słowo kluczowe, które oznacza „tutaj następuje to, co należy zrobić (w tejfor
pętli)”.jest taki sam jak
i jako
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ć
do
nową linię, tak jak wlub
To samo tyczy się
then
wif
oświadczeniu.Ale znowu sprowadza się to do osobistych preferencji stylowych lub dowolnego stylu kodowania stosowanego przez zespół / projekt.
źródło
do
, nie widzę powodu, dla którego umieszczenie go w następnym wierszu poprawiłoby jego czytelność.do
(lubthen
) linię jako własną (jak w drugim do ostatniego przykładu). Wszystko to musi zależeć od osobistych preferencji. Nie lubię zbyt długich linii, częściowo dlatego, że mój terminal ma „tylko” 80 znaków szerokości, a częściowo dlatego, że uważam, że wygląda nieporządnie. Trudno mi też analizować bardzo długie linie pod kątem błędów.do
w oddzielnym wierszu „błąd”. Są to raczej surowe zwroty, więc nie wydaje się warto podkreślić, że wręcz przeciwnie, tak zwana „zasada” jest właściwie tylko subiektywna opinia.Zwróć uwagę na to, co jest napisane na górze strony:
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
do
w tej samej linii, jakfor
i dla umieszczenia jej w linii własnej.To ta sama dyskusja, co do umieszczenia
{
kodu C podczas uruchamiania blokuif
lubwhile
bloku (lub takiego).Kilka wierszy poniżej w dokumentacji jest jeszcze jedna interesująca zasada:
Zakładam tutaj, że autor tego przewodnika po stylu uważa, że użycie
function
słowa kluczowego jest konieczne, aby czytelnik mógł rozpoznać deklarację funkcji. Jednakfunction foo
jest niestandardowy sposób definiowania funkcji: standardowy sposób jestfoo()
. Jedyną różnicą między nimi (w Bash) jest to, że druga jest trudniejsza do przeniesienia do standardowej powłoki, jak/bin/sh
w 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,E011
zignorować te dwa testy). Doskonały moduł sprawdzania stylu pozwoliłby zmodyfikować testy, np. Aby sprawdzić przeciwieństwo E020 tutaj.źródło
TL; DR: Nie musisz. To tylko opinia jakiegoś kolesia.
Jak wiele innych, pisałem
for
takie pętle od dziesięcioleci:Ten układ podkreśla fakt, że
do ... done
otaczają 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 ... esac
a 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ą odrzuconegoto
. Ale dopóki cała społeczność skryptów nie przyjmie preferencjibashate
autora (autorów), nie musisz nic robić.źródło
fi
Który odpowiadaif
, iesac
itd. Pochodzi z Algol 68. Jedynym powodem, dla któregofor
pętla „sdo
nie jest zakończony przezod
to, żeod
jest nazwą istniejącego standardowego narzędzia. Zobacz en.wikipedia.org/wiki/ALGOL_68C#Algol_68C_and_Unixbegin ... end
itp.).od
, to zabawne ... (Chociaż dlaczego więc nie skończyć z for-loopamirof
?)BEGIN
iEND
tam też są zdefiniowane.FOR
iDO
będzie również na oddzielnych liniach, zwyczajowo, z wyjątkiem, kiedy cała pętla będzie łatwo zmieścić się na jednej linii.Dziwi mnie, że nikt jeszcze nie wspomniał o tej poprawnej i przenośnej składni:
Zauważ, że uważnie
for
ido
są na tej samej linii, bez średnikiem. Wynik:źródło
for q
ido
są na oddzielnych liniach (forma, w tym przykładzie był nieobsługiwane parę lat temu na oryginalnym Almquish shell (ash
): in-ulm.de/~mascheck/various/ bourne_args / # endnote )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
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ę:
ale gdy polecenia prep są nieco nieporęczne i / lub warunek jest złożony, lepiej go sformatować jako
a następnie dołączenie do jako „; do” jest dodatnio niezrównane.
Możesz nawet stać się bardziej intensywny:
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:
Uważam, że jest to całkiem przyjemne i ma analogie z while, if i case:
Codd * wymaga od ciebie jasności i ogólnego porządku.
* Edgar F. Codd, ojciec teorii relacyjnych baz danych.
źródło
while
zeif
stanu poprzedniego. Fajne!