perlstyle - Online in de cloud

PROGRAMMA:

NAAM

perlstyle - Perl-stijlgids

PRODUCTBESCHRIJVING

Elke programmeur heeft natuurlijk zijn of haar eigen voorkeuren met betrekking tot opmaak,
maar er zijn enkele algemene richtlijnen die uw programma's gemakkelijker leesbaar maken,
begrijpen en onderhouden.

Het belangrijkste is dat u uw programma's uitvoert onder de -w vlag te allen tijde. Jij mag
schakel het expliciet uit voor bepaalde delen van code via het "geen waarschuwingen" pragma of de
$^W variabele als het moet. Je moet ook altijd uitvoeren onder "gebruik strikt" of de . kennen
reden waarom niet. De "use sigtrap" en zelfs "use diagnostics" pragma's kunnen ook bewijzen:
nuttig.

Wat betreft de esthetiek van de lay-out van de code, is het enige waar Larry veel om geeft:
dat de accolade sluiten van een BLOK met meerdere regels moet overeenkomen met het trefwoord dat
begonnen met de constructie. Verder heeft hij andere voorkeuren die niet zo sterk zijn:

· Inspringing van 4 kolommen.

· Krullend openen op dezelfde regel als trefwoord, indien mogelijk, anders line-up.

· Spatie voor de openingskrul van een meerregelig BLOK.

· Eén lijn BLOCK mag op één lijn worden gezet, inclusief curlies.

· Geen spatie voor de puntkomma.

· Puntkomma weggelaten in "kort" éénregelig BLOK.

· Ruimte rond de meeste operators.

· Ruimte rond een "complex" subscript (tussen haakjes).

· Lege regels tussen chunks die verschillende dingen doen.

· Ontknuffelde anderen.

· Geen spatie tussen functienaam en haakje openen.

· Spatie na elke komma.

· Lange regels onderbroken na een operator (behalve "en" en "of").

· Spatie na laatste haakje dat overeenkomt met de huidige regel.

· Line-up corresponderende items verticaal.

· Laat overbodige interpunctie achterwege zolang de duidelijkheid er niet onder lijdt.

Larry heeft zijn redenen voor elk van deze dingen, maar hij beweert niet dat die van iedereen...
geest werkt hetzelfde als de zijne.

Hier zijn enkele andere, meer inhoudelijke stijlkwesties om over na te denken:

· Gewoon omdat jij CAN iets op een bepaalde manier doen, betekent niet dat jij MOET doe het
op die manier. Perl is ontworpen om u verschillende manieren te geven om iets te doen, dus overweeg:
het kiezen van de meest leesbare. Bijvoorbeeld

open(FOO,$foo) || sterven "Kan $foo niet openen: $!";

is beter dan

sterven "Kan $foo: $ niet openen!" tenzij open(FOO,$foo);

omdat de tweede manier het belangrijkste punt van de verklaring in een modifier verbergt. Op de
andere kant

print "Analyse starten\n" als $uitgebreid;

is beter dan

$uitgebreide && print "Analyse starten\n";

omdat het belangrijkste punt niet is of de gebruiker heeft getypt -v of niet.

Evenzo, alleen omdat een operator u standaardargumenten laat aannemen, betekent niet:
dat u gebruik moet maken van de standaardinstellingen. De standaardinstellingen zijn er voor luie systemen
programmeurs die eenmalige programma's schrijven. Als u wilt dat uw programma leesbaar is,
overweeg het argument aan te voeren.

In dezelfde lijn, gewoon omdat jij CAN haakjes op veel plaatsen weglaten niet
betekenen dat je zou moeten:

retour print omgekeerd sorteren aantal waarden %array;
return print(reverse(sorteer num (waarden(%matrix))));

Bij twijfel haakjes plaatsen. Het zal op zijn minst een arme schmuck laten stuiteren
op de % toets in vi.

Zelfs als u niet twijfelt, overweeg dan het mentale welzijn van de persoon die moet
de code na u onderhouden, en die waarschijnlijk haakjes op de verkeerde plaats zal plaatsen.

· Ga niet door gekke bochten om een ​​lus aan de boven- of onderkant te verlaten, wanneer Perl
biedt de "laatste" operator zodat u in het midden kunt afsluiten. Gewoon "uitspringen" het a
beetje om het meer zichtbaar te maken:

LIJN:
voor (;;) {
statements;
laatste REGEL als $foo;
volgende regel als /^#/;
statements;
}

· Wees niet bang om luslabels te gebruiken - ze zijn er om de leesbaarheid te verbeteren en om
lusonderbrekingen op meerdere niveaus toestaan. Zie het vorige voorbeeld.

· Vermijd het gebruik van "grep()" (of "map()") of `backticks` in een lege context, dat wil zeggen, wanneer u
gooi gewoon hun retourwaarden weg. Die functies hebben allemaal retourwaarden, dus gebruik
hen. Gebruik anders in plaats daarvan een "foreach()"-lus of de "system()"-functie.

· Voor draagbaarheid, bij gebruik van functies die mogelijk niet op elke machine zijn geïmplementeerd,
test het construct in een evaluatie om te zien of het faalt. Als u weet welke versie of
patchniveau een bepaalde functie is geïmplementeerd, kunt u $] ($PERL_VERSION in . testen)
"English") om te zien of het er zal zijn. Met de module "Config" kunt u ook:
ondervragen waarden bepaald door de Configure programma toen Perl werd geïnstalleerd.

· Kies geheugensteuntjes. Als je niet meer weet wat geheugensteuntje betekent, heb je een
probleem.

· Hoewel korte identifiers zoals $gotit waarschijnlijk ok zijn, gebruik underscores om woorden te scheiden
in langere identifiers. Het is over het algemeen gemakkelijker om $var_names_like_this te lezen dan
$VarNamesLikeThis, speciaal voor niet-moedertaalsprekers van het Engels. Het is ook een simpele
regel die consistent werkt met "VAR_NAMES_LIKE_THIS".

Pakketnamen vormen soms een uitzondering op deze regel. Perl reserveert informeel
modulenamen in kleine letters voor "pragma" -modules zoals "integer" en "strikt". Ander
modules moeten beginnen met een hoofdletter en hoofdletters gebruiken, maar waarschijnlijk zonder
onderstreept vanwege beperkingen in de representaties van module door primitieve bestandssystemen
namen als bestanden die in een paar schaarse bytes moeten passen.

· Misschien vindt u het handig om letters te gebruiken om de omvang of aard van een a . aan te geven
variabel. Bijvoorbeeld:

$ALL_CAPS_HERE alleen constanten (pas op voor botsingen met perl vars!)
$Some_Caps_Here pakket-breed globaal/statisch
$no_caps_here functiebereik my() of local() variabelen

Functie- en methodenamen lijken het beste te werken in kleine letters. bijv.
"$obj->as_string()".

U kunt een leidend onderstrepingsteken gebruiken om aan te geven dat een variabele of functie niet mag worden
gebruikt buiten het pakket dat het definieerde.

· Als je een erg harige reguliere expressie hebt, gebruik dan de "/x" modifier en voeg wat . toe
witruimte om het iets minder op lijnruis te laten lijken. Gebruik geen schuine streep als a
scheidingsteken wanneer uw regexp slashes of backslashes heeft.

· Gebruik de nieuwe operatoren "en" en "of" om te voorkomen dat u lijstoperatoren tussen haakjes moet plaatsen, dus
veel, en om de incidentie van interpunctie-operatoren zoals "&&" en "||" te verminderen. Telefoongesprek
uw subroutines alsof het functies of lijstoperators zijn om overmatig te voorkomen
ampersands en haakjes.

· Gebruik hier documenten in plaats van herhaalde "print()"-instructies.

· Zet corresponderende dingen verticaal op een rij, vooral als het te lang zou zijn om op één te passen
lijn toch.

$IDX = $ST_MTIME;
$IDX = $ST_ATIME als $opt_u;
$IDX = $ST_CTIME als $opt_c;
$IDX = $ST_SIZE als $opt_s;

mkdir $tmpdir, 0700 of die "kan niet mkdir $tmpdir: $!";
chdir($tmpdir) of die "kan $tmpdir niet chdir: $!";
mkdir 'tmp', 0777 of sterven "kan niet mkdir $tmpdir/tmp: $!";

· Controleer altijd de retourcodes van systeemoproepen. Goede foutmeldingen moeten gaan naar
"STDERR", inclusief welk programma het probleem heeft veroorzaakt, wat de mislukte systeemaanroep is en
argumenten waren, en (HEEL BELANGRIJK) zouden de standaard systeemfoutmelding moeten bevatten
voor wat er mis is gegaan. Hier is een eenvoudig maar voldoende voorbeeld:

opendir(D, $dir) of sterven "kan $dir niet openen: $!";

· Zet uw transliteraties op een rij als het zinvol is:

tr [abc]
[xyz];

· Denk aan herbruikbaarheid. Waarom zou je denkkracht verspillen aan een eenmalige actie als je dat misschien ook zou willen doen?
weer zoiets? Overweeg om je code te generaliseren. Overweeg een module te schrijven
of objectklasse. Overweeg om uw code netjes te laten werken met "use strict" en "use
waarschuwingen" (of -w) in werkelijkheid. Overweeg om je code weg te geven. Overweeg om uw
hele wereldbeeld. Overweeg... oh, laat maar.

· Probeer uw code te documenteren en pod-opmaak op een consistente manier te gebruiken. Hier zijn
algemeen verwachte conventies:

· gebruik "C<>" voor functie-, variabele- en modulenamen (en meer in het algemeen alles
die als onderdeel van code kunnen worden beschouwd, zoals filehandles of specifieke waarden). Opmerking
dat functienamen als leesbaarder worden beschouwd met haakjes na hun
naam, dat is "functie()".

· gebruik "B<>" voor commandonamen zoals hoe or grep.

· gebruik "F<>" of "C<>" voor bestandsnamen. "F<>" zou de enige Pod-code voor bestand moeten zijn
namen, maar aangezien de meeste Pod-formatters het cursief weergeven, Unix- en Windows-paden met
hun slashes en backslashes zijn mogelijk minder leesbaar en beter weergegeven met
"C<>".

· Wees consistent.

· Wees aardig.

Gebruik perlstyle online met onworks.net-services