Perl - standard kodowania

Każdy programista będzie oczywiście miał własne preferencje dotyczące formatowania, ale istnieją pewne ogólne wskazówki, które ułatwią czytanie, zrozumienie i konserwację programów.

Najważniejsze jest, aby programy były uruchamiane przez cały czas z opcją -w. Możesz ją jawnie wyłączyć dla określonych fragmentów kodu za pomocą pragmy no warnings lub zmiennej $ ^ W, jeśli musisz. Powinieneś także zawsze korzystać z ograniczeń lub znać powód, dla którego nie. Przydatne może się również okazać zastosowanie sigtrap, a nawet pragmatów diagnostyki użycia.

Jeśli chodzi o estetykę układu kodu, jedyną rzeczą, na której bardzo zależy Larry'emu, jest to, że zamykający nawias klamrowy wielowierszowego BLOKU powinien być zgodny ze słowem kluczowym, które rozpoczęło konstrukcję. Poza tym ma inne preferencje, które nie są tak silne -

Wcięcie 4-kolumnowe.
Otwarcie kręcone w tym samym wierszu co słowo kluczowe, jeśli to możliwe, w przeciwnym razie ustaw.
Spacja przed początkiem kręcenia BLOKU wieloliniowego.
Jednowierszowy BLOK może być umieszczony na jednej linii, łącznie z zawijasami.
Brak spacji przed średnikiem.
W „krótkim” jednowierszowym BLOKU pominięto średnik.
Przestrzeń wokół większości operatorów.
Spacja wokół „złożonego” indeksu dolnego (w nawiasach kwadratowych).
Puste linie między fragmentami, które robią różne rzeczy.
Uncuddled elses.
Brak spacji między nazwą funkcji a nawiasem otwierającym.
Spacja po każdym przecinku.
Długie linie przerywane po operatorze (z wyjątkiem i i lub).
Spacja po ostatnim dopasowaniu nawiasu w bieżącej linii.
Ułóż odpowiednie elementy w pionie.
Pomiń zbędne znaki interpunkcyjne, o ile nie ucierpi na tym klarowność.

Oto kilka innych, bardziej merytorycznych kwestii związanych ze stylem do przemyślenia: Tylko dlatego, że MOŻESZ zrobić coś w określony sposób, nie oznacza, że POWINIENEŚ to zrobić w ten sposób. Perl ma na celu dać ci kilka sposobów na zrobienie czegokolwiek, więc rozważ wybranie najbardziej czytelnego. Na przykład -

open(FOO,$foo) || die "Can't open $foo: $!";

Jest lepszy niż -

die "Can't open $foo: $!" unless open(FOO,$foo);

Ponieważ drugi sposób ukrywa główny punkt instrukcji w modyfikatorze. Z drugiej strony,

print "Starting analysis\n" if $verbose;

Jest lepszy niż -

$verbose && print "Starting analysis\n";

Ponieważ głównym punktem nie jest to, czy użytkownik wpisał -v, czy nie.

Nie przechodź przez głupie wygięcia, aby wyjść z pętli na górze lub na dole, kiedy Perl zapewnia ostatni operator, dzięki czemu możesz wyjść w środku. Po prostu „zdezaktualizuj” go trochę, aby był bardziej widoczny -

LINE:
for (;;) {
   statements;
   last LINE if $foo;
   next LINE if /^#/;
   statements;
}

Zobaczmy kilka ważniejszych punktów -

Nie bój się używać etykiet pętli - mają one na celu zwiększenie czytelności, a także umożliwienie wielopoziomowego przerywania pętli. Zobacz poprzedni przykład.
Unikaj używania grep () (lub map ()) lub `backticks` w kontekście void, to znaczy, gdy po prostu odrzucasz ich wartości zwracane. Wszystkie te funkcje mają wartości zwracane, więc używaj ich. W przeciwnym razie użyj zamiast tego pętli foreach () lub funkcji system ().
Aby zapewnić przenośność, podczas korzystania z funkcji, które mogą nie być zaimplementowane na każdym komputerze, przetestuj konstrukcję w ewaluacji, aby sprawdzić, czy się nie powiedzie. Jeśli wiesz, w jakiej wersji lub poziomie poprawek dana funkcja została zaimplementowana, możesz przetestować $] ($ PERL_VERSION w języku angielskim), aby sprawdzić, czy tam będzie. Moduł Config pozwala również na sprawdzanie wartości określonych przez program Configure podczas instalacji Perla.
Wybierz identyfikatory mnemoniczne. Jeśli nie pamiętasz, co oznacza mnemonik, masz problem.
Chociaż krótkie identyfikatory, takie jak $ gotit, prawdopodobnie są w porządku, użyj podkreśleń, aby oddzielić słowa w dłuższych identyfikatorach. Generalnie łatwiej jest czytać $ var_names_like_this niż $ VarNamesLikeThis, zwłaszcza dla osób, dla których angielski nie jest językiem ojczystym. Jest to również prosta reguła, która działa spójnie z VAR_NAMES_LIKE_THIS.
Nazwy pakietów są czasami wyjątkiem od tej reguły. Perl nieformalnie rezerwuje nazwy modułów pisane małymi literami dla modułów „pragma”, takich jak integer i strict. Inne moduły powinny zaczynać się wielką literą i używać mieszanej wielkości liter, ale prawdopodobnie bez podkreślenia ze względu na ograniczenia w reprezentacji nazw modułów przez prymitywne systemy plików jako pliki, które muszą mieścić się w kilku rzadkich bajtach.
Jeśli masz naprawdę włochate wyrażenie regularne, użyj modyfikatora / x i wstaw trochę białych znaków, aby wyglądało trochę mniej jak szum linii. Nie używaj ukośnika jako separatora, gdy wyrażenie regularne zawiera ukośniki lub odwrotne ukośniki.
Zawsze sprawdzaj kody zwrotne wywołań systemowych. Dobre komunikaty o błędach powinny trafiać do STDERR, zawierać informację o tym, który program spowodował problem, jakie były błędne wywołania systemowe i argumenty, oraz (BARDZO WAŻNE) powinny zawierać standardowy komunikat o błędzie systemowym informujący o tym, co poszło nie tak. Oto prosty, ale wystarczający przykład -

opendir(D, $dir) or die "can't opendir $dir: $!";

Pomyśl o możliwości ponownego wykorzystania. Po co marnować siłę mózgu na jednorazową pracę, skoro możesz chcieć zrobić coś podobnego jeszcze raz? Rozważ uogólnienie kodu. Rozważ napisanie modułu lub klasy obiektów. Rozważ sprawienie, aby kod działał czysto, używając ścisłego i używaj ostrzeżeń (lub -w). Rozważ zdradzenie swojego kodu. Rozważ zmianę całego poglądu na świat. Rozważ ... och, nieważne.
Bądź konsekwentny.
Bądź miły.