perlstyle - Online în cloud

PROGRAM:

NUME

perlstyle - Ghid de stil Perl

DESCRIERE

Fiecare programator va avea, desigur, propriile preferințe în ceea ce privește formatarea,
dar există câteva reguli generale care vă vor face programele mai ușor de citit,
intelege si mentine.

Cel mai important lucru este să vă rulați programele sub -w steag în orice moment. Poți
dezactivați-l în mod explicit pentru anumite porțiuni de cod prin pragma „fără avertismente” sau
$^W variabilă dacă trebuie. De asemenea, ar trebui să rulați întotdeauna sub „utilizare strict” sau să cunoașteți
motiv pentru care nu. Se pot dovedi și pragma „utilizați sigtrap” și chiar „utilizați diagnostice”.
util.

În ceea ce privește estetica aspectului codului, singurul lucru la care Larry îi pasă foarte mult este
ca paranteza de închidere a unui BLOC cu mai multe linii să se alinieze cu cuvântul cheie that
a început construcția. Dincolo de asta, are și alte preferințe care nu sunt atât de puternice:

· indentare cu 4 coloane.

· Deschidere ondulată pe aceeași linie cu cuvântul cheie, dacă este posibil, altfel aliniați.

· Spațiu înainte de deschiderea ondulată a unui BLOC cu mai multe linii.

· O singură linie BLOCK poate fi pus pe o singură linie, inclusiv bucle.

· Fără spațiu înainte de punctul și virgulă.

· Punct virgulă omis în BLOC „scurt” cu o singură linie.

· Spațiu în jurul majorității operatorilor.

· Spațiu în jurul unui indice „complex” (în paranteze).

· Linii goale între bucăți care fac lucruri diferite.

· Ceilalți negălăgioși.

· Nu există spațiu între numele funcției și paranteza de deschidere.

· Spațiu după fiecare virgulă.

· Rânduri lungi întrerupte după un operator (cu excepția „și” și „sau”).

· Spațiu după ultima paranteză care se potrivește pe linia curentă.

· Aliniați articolele corespunzătoare pe verticală.

· Omiteți semnele de punctuație redundante atâta timp cât claritatea nu are de suferit.

Larry are motivele lui pentru fiecare dintre aceste lucruri, dar nu pretinde că ale tuturor celorlalți
mintea funcționează la fel ca și a lui.

Iată câteva alte probleme de stil mai importante la care să te gândești:

· Doar pentru că tu CAN a face ceva într-un mod anume nu înseamnă că tu AR TREBUI SĂ Fă-o
asa. Perl este conceput pentru a vă oferi mai multe moduri de a face orice, așa că luați în considerare
alegându-l pe cel mai lizibil. De exemplu

deschis(FOO,$foo) || die "Nu se poate deschide $foo: $!";

e mai bine ca

die "Nu pot deschide $foo: $!" dacă nu este deschis(FOO,$foo);

deoarece a doua modalitate ascunde punctul principal al enunțului într-un modificator. Pe
cealaltă mână

printează „Începe analiza\n” dacă $verbos;

e mai bine ca

$verbose && print „Începe analiza\n”;

deoarece punctul principal nu este dacă utilizatorul a tastat -v sau nu.

În mod similar, doar pentru că un operator vă permite să presupuneți argumente implicite nu înseamnă
că trebuie să utilizați valorile implicite. Valorile implicite sunt acolo pentru sistemele leneșe
programatori care scriu programe one-shot. Dacă doriți ca programul dvs. să fie lizibil,
luați în considerare furnizarea argumentului.

Pe aceeași linie, doar pentru că tu CAN omite parantezele în multe locuri nu
înseamnă că ar trebui să:

returnează tipărire sortare inversă num valori %array;
return print(reverse(sort num (valori(%matrice))));

Când aveți îndoieli, introduceți parantezele. Cel puțin, va lăsa un biet prost să sară
pe tasta % vi.

Chiar dacă nu aveți îndoieli, luați în considerare bunăstarea mentală a persoanei care trebuie
menține codul după tine și cine probabil va pune paranteze în locul greșit.

· Nu trece prin contorsiuni stupide pentru a ieși dintr-o buclă de sus sau de jos, când Perl
oferă „ultimul” operator, astfel încât să puteți ieși în mijloc. Pur și simplu „descărcați” a
puțin pentru a-l face mai vizibil:

LINIA:
pentru (;;) {
declarații;
ultima LINIE dacă $foo;
RÂNDUL următor dacă /^#/;
declarații;
}

· Nu vă fie teamă să utilizați etichete bucle - acestea sunt acolo pentru a îmbunătăți lizibilitatea, precum și pentru a
permite întreruperi de buclă pe mai multe niveluri. Vezi exemplul anterior.

· Evitați să utilizați „grep()” (sau „map()”) sau „backticks” într-un context nul, adică atunci când
aruncați doar valorile lor de returnare. Toate acele funcții au valori returnate, așa că utilizați
lor. În caz contrar, utilizați o buclă „foreach()” sau funcția „system()”.

· Pentru portabilitate, atunci când utilizați funcții care ar putea să nu fie implementate pe fiecare mașină,
testați constructul într-un eval pentru a vedea dacă eșuează. Dacă știi ce versiune sau
la nivel de patch o anumită caracteristică a fost implementată, puteți testa $] ($PERL_VERSION în
„Engleză”) pentru a vedea dacă va fi acolo. Modulul „Config” vă va permite de asemenea
interoga valorile determinate de Configurați program când a fost instalat Perl.

· Alegeți identificatori mnemonici. Dacă nu vă amintiți ce înseamnă mnemonic, aveți un
problemă.

· În timp ce identificatorii scurti precum $gotit sunt probabil ok, utilizați liniuțe pentru a separa cuvintele
în identificatori mai lungi. În general, este mai ușor să citiți $var_names_like_this decât
$VarNamesLikeThis, în special pentru cei care nu sunt vorbitori nativi de engleză. Este, de asemenea, un simplu
regulă care funcționează în mod consecvent cu „VAR_NAMES_LIKE_THIS”.

Numele pachetelor sunt uneori o excepție de la această regulă. Perl își rezervă informal
nume de module cu minuscule pentru modulele „pragma” precum „integer” și „strict”. Alte
modulele ar trebui să înceapă cu o literă majusculă și să folosească litere mari și minuscule mixte, dar probabil fără
subliniază din cauza limitărilor în reprezentările modulului ale sistemelor de fișiere primitive
nume ca fișiere care trebuie să se încadreze în câțiva octeți rari.

· S-ar putea să vă fie util să folosiți majuscule pentru a indica domeniul sau natura unui
variabil. De exemplu:

$ALL_CAPS_HERE numai constante (atenție la ciocniri cu perl vars!)
$Some_Caps_Here global/static la nivelul întregului pachet
$no_caps_here sfera funcției variabilele my() sau local().

Numele de funcții și metode par să funcționeze cel mai bine ca toate litere mici. De exemplu,
„$obj->as_string()”.

Puteți utiliza un caracter de subliniere pentru a indica faptul că o variabilă sau o funcție nu ar trebui să fie
folosit în afara pachetului care l-a definit.

· Dacă aveți o expresie obișnuită cu adevărat păroasă, utilizați modificatorul „/x” și introduceți câteva
spațiu alb pentru a face să arate puțin mai puțin ca zgomotul de linie. Nu folosiți slash ca a
delimitator atunci când expresia regulă are bare oblice sau bare oblice inverse.

· Utilizați noii operatori „și” și „sau” pentru a evita să fiți nevoit să introduceți operatorii de listă în paranteze
mult și pentru a reduce incidența operatorilor de punctuație precum „&&” și „||”. Apel
subrutinele dvs. ca și cum ar fi funcții sau lista de operatori pentru a evita excesul
ampersand și paranteze.

· Folosiți aici documente în loc de instrucțiuni repetate „print()”.

· Aliniați lucrurile corespunzătoare pe verticală, mai ales dacă ar fi prea lung pentru a se potrivi pe unul
linie oricum.

$IDX = $ST_MTIME;
$IDX = $ST_ATIME dacă $opt_u;
$IDX = $ST_CTIME dacă $opt_c;
$IDX = $ST_SIZE dacă $opt_s;

mkdir $tmpdir, 0700 sau die "nu se poate mkdir $tmpdir: $!";
chdir($tmpdir) sau die „nu se poate chdir $tmpdir: $!”;
mkdir 'tmp', 0777 sau die "nu se poate mkdir $tmpdir/tmp: $!";

· Verificați întotdeauna codurile de returnare ale apelurilor de sistem. Mesajele de eroare bune ar trebui să ajungă la
„STDERR”, includeți ce program a cauzat problema, ce apelează sistemul eșuat și
argumentele au fost și (FOARTE IMPORTANT) ar trebui să conțină mesajul standard de eroare de sistem
pentru ceea ce a mers prost. Iată un exemplu simplu, dar suficient:

opendir(D, $dir) sau die „nu se poate deschide directorul $dir: $!”;

· Aliniați-vă transliterațiile atunci când are sens:

tr [abc]
[xyz];

· Gândiți-vă la reutilizare. De ce să irosești puterea mentală într-o singură lovitură când ai vrea să faci
ceva asemanator din nou? Luați în considerare generalizarea codului dvs. Luați în considerare scrierea unui modul
sau clasa de obiecte. Luați în considerare ca codul să ruleze curat cu „use strict” și „use”.
avertismente” (sau -w) in efect. Luați în considerare să oferiți codul dvs. Luați în considerare schimbarea dvs
viziune asupra lumii întregi. Luați în considerare... oh, nu contează.

· Încercați să vă documentați codul și să utilizați formatarea Pod într-un mod consecvent. Aici sunt
convenții așteptate în mod obișnuit:

· utilizați „C<>” pentru numele de funcții, variabile și module (și mai general orice
care pot fi considerate parte a codului, cum ar fi handlere de fișiere sau valori specifice). Notă
că numele funcțiilor sunt considerate mai lizibile cu paranteze după lor
nume, adică „funcție()”.

· utilizați „B<>” pentru nume de comenzi precum pisică or grep.

· utilizați „F<>” sau „C<>” pentru numele fișierelor. „F<>” ar trebui să fie singurul cod Pod pentru fișier
nume, dar după cum majoritatea formatatoarelor Pod îl redau ca italic, căile Unix și Windows cu
barele oblice și inverse ale acestora pot fi mai puțin lizibile și mai bine redate cu
„C<>”.

· Fii consistent.

· Fii dragut.

Utilizați perlstyle online folosind serviciile onworks.net