PHP- & MySQL-innføring: Kapittel 3

[fiskfisk]

For mange parenteser kan også skape bugs og ødelegge lesbarheten, som vist i eksempelet jeg gjenga nedenfor.

 

Nei, eksempelet ditt nedenfor er feil uansett hvor mange paranteser du bruker, fordi vedkommende har misforstått hva "print" er. Det er koden som er problemet, ikke parantesbruken.

 

Men, altså:

 

Ville du stolt på resten av logikken i et program som inneholder dette?

if (($a && $b) || $c)

Det ville ikke jeg!

 

Nå har jeg lest dette om igjen og om igjen og prøvd å finne ut hva du mener er problemet. Det eneste jeg har klart å finne fram til, er at du teknisk sett kan ta bort parantesen rundt ($a && $b), og fortsatt få samme resultat.

 

Hvis du mener at

 

$a && $b || $c

 

er mer lesbart enn:

 

($a && $b) || $c

 

Så håper jeg at jeg aldri skal vedlikeholde kode du har skrevet.

 

Det å stole på evalueringsrekkefølge og presedens er en forferdelig ting, spesielt når man veksler mellom mange språk over kort tid.

Her er jeg uenig.

 

Man skal ikke bruke samme kodestil på tvers av programmeringsspråk; det er dårlig programmeringsskikk, og fører til mer forvirring enn det er verdt.

 

Det kan også skape tvil om hvorvidt programmereren faktisk vet hva han driver på med (for de som bryr seg om slikt).

 

Du må gjerne få være uenig, men om du tror dette handler om å bruke samme kodekonvensjon og syntax over alle språk har du misforstått. Vi snakker om evalueringsrekkefølge og presedens, og det er ting man ikke bør ta for gitt i et språk. Ikke fordi det endrer seg over tid, men fordi du alltid bør skrive kode som er lett å lese. Derfor bør du skrive kode på samme måte som du tenker, og gruppere det som hører logisk sammen.

 

Jeg ville aldri ha vurdert hvorvidt "programmereren faktisk vet hva han/hun driver på med" ut fra om de hadde minst mulig paranteser i forhold til presedensrekkefølgen til språket. Hvis du mener at _DET_ er vesentlig for en god programmerer, så gjentar jeg poenget mitt fra tidligere: jeg vil ikke vedlikeholde kode du har skrevet.

 

Nei, ikke legg på ekstra syntaks i forhold til det som kreves i henhold til kodestandardene der du jobber, eller i forhold til det som er normen i programmeringsspråket. Bruk gjerne de alternative syntaksene som er tilgjengelig, men ikke lat som om ekstra parenteser, ekstra krøllklammer eller liknende faktisk gjør noe.

 

Selvfølgelig skal du bruke kodestandarden etter der du jobber; det er jo det du får betalt for. Du kan også regne med at det er en GRUNN til at kodestandarden er sånn. Nå dreier kodestandarder seg om at koden skal være lett å lese og å unngå unødvendige feil, og jeg tror definitivt at de Fleste Fornuftige kodestandarder jeg har sett og brukt har gjort sitt for å unngå å stole på implisitt presedens. Det er mulig dine erfaringer skiller seg fra mine.

 

 

Unntak: hvis du skriver kode for MySQL, så må du være forberedt på at presedensreglene for SQL endrer seg i en ny patchlevel og ikke bare i en ny versjon

 

Dette var en ren syntax-endring, ikke presendensendring (og ja, jeg måtte patche en del kode på grunn av den).

 

I samme åndedrag vil jeg også si at det er langt mer lesbart å skrive

 

[if-snip]

 

enn samme statement uten { }. (og plassér de for all del på egen linje! Det øker navigasjonshastigheten din på kodelesing!)

Her er det rom for personlig smak eller lokale kodestandarder.

 

Folk som kommer fra et tradisjonelt Unix-miljø vil trives mer med den varianten som Findus nevner.

 

Hvis det er noe som kan anses for "allmenn kodestandard" innenfor et så bredt begrep som "Unix-miljø", så er det vel K&R-syntax for C som ligger nærmest opp til PHP-syntaxen som vi diskuterer her originalt.

 

K&R Code Standards

 

Det endrer ikke nevneverdig på lesbarheten.

 

Det var det jeg trodde også, i de fem-seks-syv årene jeg skrev kode med if() { og else {. Så var jeg involvert i et prosjekt som hadde en eksplisitt kodestandard som sa at { og } skulle være på egne linjer, og brått så innså jeg at dette passet langt bedre i forhold til rask kodenavigasjon for min del.

 

 

1) Ikke bruk så lange testbetingelser; det gjør koden vanskelig å lese.

 

Iallfall om du ikke skal bruke paranteser

 

Seriøst: Ja. Da bør man heller vurdere om det kanskje er bedre måter å bygge opp flyten i et program på. Det er irrelevant i forhold til plasseringen av krøllparantesen, tho.

 

Motargumentet er at do-while gjør det helt klart at det som står mellom krøllklammene vil bli utført minst en gang.

 

Nei, ettersom du fortsatt kan gå ut fra løkka. Det gjør at du ikke har den garantien i det hele tatt, og uansett må lese deg gjennom koden for å sette deg inn i hva den faktisk gjør.

 

 

Hvis du bruker en vanlig while istedenfor, så må den som leser koden både lese og tolke betingelsen i while() for å vite hvorvidt dette skjer eller ikke. Dersom ikke verdien av innholdet i while() er opplagt ut fra de nærliggende linjene i koden, så vil dette medføre mye merarbeid. I tillegg kan det være mer jobb å vedlikeholde koden.

 

Men dette har igjen med faktisk fornuftig kodestil å gjøre, og ikke nødvendigvis med do{}-while-constructen.

 

men jeg ser altså at det kan være like nyttig som f.eks.:

print "Yeeha!";

while ($somevar && ($othervar || $anothervar)) {
   print "Yeeha!";
}

6541106[/snapback]

 

Dette forsto jeg ingenting av uten noen større sammenheng. Jeg skjønner at du mener å skrive ut 'yeeha' uansett, men hvorledes dette relaterer seg til bruken av do{} while i dette tilfellet ser jeg ikke. I et slikt tilfelle vil det uansett være nærliggende å tro at argumentet til while() vil være sant ved første gjennomkjøring.

 

Du sier tross alt "kjør dette mens .." og da er det logisk feil (for meg) å gjøre et spesialtilfelle ut av første gjennomkjøring.

 

Jeg tror imidlertid jeg avslutter denne diskusjonen her for min del, ettersom dette kommer så langt på sidene av det denne tråden bør brukes til.

[dios]

Hvis du mener at

 

$a && $b || $c

 

er mer lesbart enn:

 

($a && $b) || $c

 

Så håper jeg at jeg aldri skal vedlikeholde kode du har skrevet.

Ad hominem er jo et fint lite triks, det synes jeg godt du kunne latt være.

 

Nei, jeg hevder ikke at det er mer lesbart, men jeg hevder at det førstnevnte utviser en større forståelse for presedensreglene enn det sistnevnte.

 

Du må gjerne få være uenig, men om du tror dette handler om å bruke samme kodekonvensjon og syntax over alle språk har du misforstått. Vi snakker om evalueringsrekkefølge og presedens, og det er ting man ikke bør ta for gitt i et språk. Ikke fordi det endrer seg over tid, men fordi du alltid bør skrive kode som er lett å lese. Derfor bør du skrive kode på samme måte som du tenker, og gruppere det som hører logisk sammen.

Evalueringsrekkefølge og presedens er kanskje ikke noe man skal ta for gitt ut fra hva man vet om andre programmeringsspråk, men det er noe man skal kjenne til i det språket man programmerer i.

 

Jeg ville aldri ha vurdert hvorvidt "programmereren faktisk vet hva han/hun driver på med" ut fra om de hadde minst mulig paranteser i forhold til presedensrekkefølgen til språket.

Jeg vurderer om propgrammereren vet hva han driver med ut fra hvordan koden ser ut. Forståelse av evaluering og presedens er en viktig del av dette.

 

Hvis du mener at _DET_ er vesentlig for en god programmerer, så gjentar jeg poenget mitt fra tidligere: jeg vil ikke vedlikeholde kode du har skrevet.

Stråmann og ad hominem i en enkel pakke, flotte saker.

 

Selvfølgelig skal du bruke kodestandarden etter der du jobber; det er jo det du får betalt for. Du kan også regne med at det er en GRUNN til at kodestandarden er sånn. Nå dreier kodestandarder seg om at koden skal være lett å lese og å unngå unødvendige feil, og jeg tror definitivt at de Fleste Fornuftige kodestandarder jeg har sett og brukt har gjort sitt for å unngå å stole på implisitt presedens. Det er mulig dine erfaringer skiller seg fra mine.

Ja, mine erfaringer skiller seg fra dine.

 

Kodestandarder dreier seg ikke alltid om det du skriver her; av og til er de også laget slik av politiske grunner eller på grunn av dogma. Det betyr at de ikke alltid fremmer lesbarhet og vedlikeholdbarhet (jeg setter sistnevnte høyt!), og at de i en del tilfeller har glemt av mulige unntakstilfeller.

 

Ideelt sett vil en kodestandard fungere bra, og jeg har vært med på et par prosjekter hvor det både har vært en kodestandard og hvor den har fungert bra.

 

Men som regel er kodestandardene ganske uformelle, og noen ganger er de kav idiotiske, f.eks. en som i C benyttet seg av forhåndsdefinerte konstanter TRUE og FALSE, sånn i tilfelle man ønsket å endre TRUE til 8 og FALSE til -7.

 

Når det gjelder din bruk av "Fleste Fornuftige kodestandarder", så ser det jo nesten ut som om du har vurdert Fornuften ut fra reglene for håndtering av presedens og ditt personlige syn på det. Mente du det, eller mente du at kodestandarder som ellers var fornuftige i tillegg hadde samme holdning til presedens og ekstra parenteser som du har?

 

Unntak: hvis du skriver kode for MySQL, så må du være forberedt på at presedensreglene for SQL endrer seg i en ny patchlevel og ikke bare i en ny versjon

 

Dette var en ren syntax-endring, ikke presendensendring (og ja, jeg måtte patche en del kode på grunn av den).

Beklager, her husker du nok feil. Les nøyaktig hva MySQL-håndboken sier om endringen, og du vil se at det faktisk er endring i presedensen som gjør at man må bruke parenteser for å gruppere der hvor dette ikke var nødvendig tidligere:

 

Previously, the comma operator (,) and JOIN both had the same precedence, so the join expression t1, t2 JOIN t3 was interpreted as ((t1, t2) JOIN t3). Now JOIN has higher precedence, so the expression is interpreted as (t1, (t2 JOIN t3)). This change affects statements that use an ON clause, because that clause can refer only to columns in the operands of the join, and the change in precedence changes interpretation of what those operands are.

 

Hvis det er noe som kan anses for "allmenn kodestandard" innenfor et så bredt begrep som "Unix-miljø", så er det vel K&R-syntax for C som ligger nærmest opp til PHP-syntaxen som vi diskuterer her originalt.

 

K&R Code Standards

Denne er mindre utbredt enn man skulle tro. I tillegg bruker boka til K&R (The C Programming Language) den varianten jeg skriver om.

 

Jeg anbefaler The Practice of Programming av Brian W. Kernighan og Rob Pike, Addison-Wesley 1999, ISBN 0-201-61586-X.

 

Disse bøkene bruker krøllklammer på samme linje som if, while og andre kontrollstrukturer, mens de er nøye på at de ligger på egen linje i f.eks. funksjons- og klassedeklarasjoner. Dette skillet har man for å gjøre det lettere å se forskjell på kontrollstrukturer og slike deklarasjoner.

 

For øvrig er det ikke vanlig å bruke krøllklammer der hvor de ikke er nødvendige, men her er jeg litt uenig.

 

Svært lik kodestil vil du også finne i f.eks. Linux-kjernen, Apache HTTP-server 2.0 og i ganske mye annen programvare.

 

I tillegg vil jeg anbefale Verifiable Programming av Ole-Johan Dahl, Prentice Hall International Series in Computer Science 1992, ISBN 0-13-951062-1; ikke fordi den egentlig sier noe om kodestandarder, men fordi den omhandler programspesifikasjon- og verifikasjon, noe som igjen påvirker stil.

 

Det endrer ikke nevneverdig på lesbarheten.

 

Det var det jeg trodde også, i de fem-seks-syv årene jeg skrev kode med if() { og else {. Så var jeg involvert i et prosjekt som hadde en eksplisitt kodestandard som sa at { og } skulle være på egne linjer, og brått så innså jeg at dette passet langt bedre i forhold til rask kodenavigasjon for min del.

Jeg trodde det samme som deg de første par-tre årene, blant annet fordi jeg hadde bakgrunn i Simula (Pascal-liknende syntaks), og fordi jeg trodde det gjorde koden mer lesbar. I løpet av de neste årene åpnet jeg øynene litt mer for andre stiler, og har fått den oppfatningen av at dette i stor grad handler om personlig smak og tradisjoner.

 

1) Ikke bruk så lange testbetingelser; det gjør koden vanskelig å lese.

 

Iallfall om du ikke skal bruke paranteser

 

Seriøst: Ja. Da bør man heller vurdere om det kanskje er bedre måter å bygge opp flyten i et program på. Det er irrelevant i forhold til plasseringen av krøllparantesen, tho.

Dette var for å foregripe standardargumentet mot å ha krøllparentes på slutten av linjen med betingelsen: at det med lange testbetingelser vil bli mindre leselig.

 

Motargumentet er at do-while gjør det helt klart at det som står mellom krøllklammene vil bli utført minst en gang.

 

Nei, ettersom du fortsatt kan gå ut fra løkka. Det gjør at du ikke har den garantien i det hele tatt, og uansett må lese deg gjennom koden for å sette deg inn i hva den faktisk gjør.

Det må du da i en vanlig test også, bortsett fra at du må legge på ekstra logikk for å håndtere det samme tilfellet som i en do-while (forutsatt at do-while vil gi et enkelt uttrykk, altså).

 

Hvis du bruker en vanlig while istedenfor, så må den som leser koden både lese og tolke betingelsen i while() for å vite hvorvidt dette skjer eller ikke. Dersom ikke verdien av innholdet i while() er opplagt ut fra de nærliggende linjene i koden, så vil dette medføre mye merarbeid. I tillegg kan det være mer jobb å vedlikeholde koden.

 

Men dette har igjen med faktisk fornuftig kodestil å gjøre, og ikke nødvendigvis med do{}-while-constructen.

Hold deg til saken; dette er i konteksten av nettopp do-while.

 

Dette forsto jeg ingenting av uten noen større sammenheng. Jeg skjønner at du mener å skrive ut 'yeeha' uansett, men hvorledes dette relaterer seg til bruken av do{} while i dette tilfellet ser jeg ikke. I et slikt tilfelle vil det uansett være nærliggende å tro at argumentet til while() vil være sant ved første gjennomkjøring.

Saken er at $somevar, $othervar og $anothervar ikke nødvendigvis har fått satt verdien sin i nærheten av denne kodeblokken i det hele tatt. Kodeeksempelet var ikke ment å være fungerende kode som gjorde noe fornuftig, og jeg ser det lider under det.

 

print "Yeeha!";
// do something useful

while ($somevar && ($othervar || $anothervar)) {
   print "Yeeha!";
   // do something useful
}

 

Det er ikke sikkert at du har noen lett måte å vite at det er første gang while-løkka kjører uten at du introduserer en ekstra variabel:

 

$firsttime=true;
while ($firsttime || ($somevar && ($othervar || $anothervar)))  {
   print "Yeeha!";
   // do something useful
   if ($firsttime) {
       $firsttime=false;
       continue;
   }
}

 

do {
   print "Yeeha!";
   // do something useful
} while ($somevar && ($othervar || $anothervar));

 

Disse tre kodesnuttene gjør altså det samme. Hvilken synes du er lettest å vedlikeholde, forutsatt at "do something useful" er noe mer enn en kommentar?

 

Du sier tross alt "kjør dette mens .." og da er det logisk feil (for meg) å gjøre et spesialtilfelle ut av første gjennomkjøring.

Synes du det er bedre å bedrive kodeduplisering eller legge til en bunke med ekstra logikk? Det er alternativene her.

 

Ja, det er ganske få tilfeller hvor do-while faktisk er nyttige i praksis. Men jeg synes ikke dette er grunn god nok til å legge hele konstruksjonen død.

 

Unødvendig kodeduplisering er en vederstyggelighet, og jeg er heller ikke glad i å måtte lage og vedlikeholde unntaksregler når det finnes en ferdiglaget kontrollstruktur som gjør det for meg.

 

Jeg tror imidlertid jeg avslutter denne diskusjonen her for min del, ettersom dette kommer så langt på sidene av det denne tråden bør brukes til.

Hvis du sikter til dine ad hominem, så er jeg hjertelig enig.

 

Hvis du sikter til saken, så er det fornuftig at det diskuteres rundt kodestandarder og slikt; kanskje det gjør at eventuelle lesere blir litt mer bevisst på de valgene de tidligere foretok helt ubevisst. Bare dét kan jo føre til bedre kodekvalitet der ute (og du verden så mye PHP-programvare det er som har behov for det).

[Kadmium]

Hva med kapittel fire? Kommer det noen gang?

[TSP]

Det kommer visst ikke noen del 4. Etter hva jeg har fått høre skal Dahl etter heftige diskusjoner med moderatorer og kritikk av forumstyret ha forlatt hw-nettverket for godt.

Ingen andre i hw-nettverket kan uten tillattelse fra Dahl (så vidt jeg vet) fortsette på artikkelserien, uantsett ville nok ingen kunne erstattet hans plass i skrivingen av denne guiden.

 

Jeg syns det er leit at det er slik du mener det må ende Dahl

[Gjest Slettet+6132]

Å? Hva slags diskusjoner er det snakk om da?

 

EDIT: Og hvorfor skulle de ikke kunne fortsette på den? Selv om noen skriver en guide har ikke personen patent på å skrive guider om saken, med mindre det er noen interne regler.

Endret 3. august 2006 av Slettet+6132

[dios]

Det kommer visst ikke noen del 4. Etter hva jeg har fått høre skal Dahl etter heftige diskusjoner med moderatorer og kritikk av forumstyret ha forlatt hw-nettverket for godt.

Ingen andre i hw-nettverket kan uten tillattelse fra Dahl (så vidt jeg vet) fortsette på artikkelserien, uantsett ville nok ingen kunne erstattet hans plass i skrivingen av denne guiden.

 

Jeg syns det er leit at det er slik du mener det må ende Dahl

Ja, dette er trist.

 

Jeg tror ikke det hadde vært så mye diskusjon om disse artiklene om de ikke hadde hatt noe for seg i utgangspunktet; da hadde folk heller postet "artikkelen er dritt" og vært totalt usaklige. Istedenfor har det for det meste vært saklige tilbakemeldinger, slik man kan forvente når det er noen som har gjort en brukbar, bra eller veldig bra jobb.

[Ernie]

Det kommer visst ikke noen del 4. Etter hva jeg har fått høre skal Dahl etter heftige diskusjoner med moderatorer og kritikk av forumstyret ha forlatt hw-nettverket for godt.

Ingen andre i hw-nettverket kan uten tillattelse fra Dahl (så vidt jeg vet) fortsette på artikkelserien, uantsett ville nok ingen kunne erstattet hans plass i skrivingen av denne guiden.

 

Jeg syns det er leit at det er slik du mener det må ende Dahl

6610130[/snapback]

Der tror jeg du bommer grovt. "Slaveavtalen" (som noen har kalt den) innebærer at alt journalistisk arbeide (dvs. artikler) eies av Hardware Online AS, iallfall den versjonen jeg i sin tid skulle ha skrevet under for en annen side i nettverket.

 

Uannsett, det er uheldig siden godeste Dahl er eneste som har skrevet noen artikler relatert til programmering på alt for lang tid (forige før Dahls artikler er vel mars en eller annen gang, og før det skal man svært langt bakover). På den andre siden har jeg overhode ingen problemer med å skjønne at noen klarer å havne oppi heftige diskusjoner med moderatorer og spesielt med forumstyret. Det styret har vært gjenstand for svært mye kritikk (både offentlig og internt) og tilsynelatende er det visst sjeldent den kritikken medfører noe konkret positivt.

Endret 3. august 2006 av Ernie

[Kadmium]

Var nettopp på grunnlag av at Dahl har forlatt nettverket jeg spurte om et nytt kapittel. Da blir det ikke noe mer av den artikkelserien da? Helvete! Unnskyld uttrykket.

Endret 4. august 2006 av Kadmium

[sdhild99]

Det er synd hvis det ikke kommer flere artikler i denne serien

[Øystein T.]

Synd at da ikkje kjem fleire artiklar! Få tilbake Dahl!

[Dahl]

Hei!

 

Takk for støtte. Et nytt kapittel av denne guiden er lite trolig, iallefall ikke med den nåverende situasjonen vi har her i nettverket. Uten å gå for mye off topic - jeg ønsker ikke å støtte opp under slik moderatorsystemet fungerer i dag, og har som flere har fått med seg forlatt nettverket.

 

Hvis jeg før eller siden skulle komme tilbake til HW-nettverket kan det imidlertid bli aktuelt å fortsette på denne artikkelserien. Men slik det ser ut nå er det lite trolig.

[Gjest Slettet+6132]

Godt å høre fra deg hvertfall, forstår godt at du ikke vil fortsette dersom folk i nettverket bare byr på trøbbel.

[TSP]

Dette er synd Dahl, er det ingen mulighet for at du vil lage de ferdig privat? Poste de på forumet eller noe slikt. Det var nå jeg følte at jeg kunne lære PHP og etter de to første kapitlene som forklarte meg ganske mye var jeg overbevist, jeg har prøvd å lære meg PHP før, men det er liksom bare din artikkelserie som har hjulpet meg. Og det mener jeg helt oppriktig.

 

Er det virkerlig ingen mulighet for at du fortsetter på artikkelserien når du ikke er ansatt i hw.no?

[-Teddy-]

Jeg ble litt *cries* når jeg fikk denne nyheten jeg og. Jeg ble skikkelig tent på PHP og storkoste meg med guiden. Har jo t.o.m. begynt å bruke php-include i menyene mine.

 

Siden vi trolig ikke får flere deler av denne guiden må iallefall jeg begynne å se meg om etter andre guider for PHP. Sikkert flere her som kan trenge det, noen som har noen de kan anbefale?

[TSP]

Jeg har prøvd mange andre, men ingen har de lært meg like mye på så kort tid som Dahl sin og jeg har tdligere bare gitt det opp. Det er virkerlig synd at han ikke planlegger å fortsette uten hw-nettverket. Hvis du Dahl helst vil ha penger for å skrive det fordi du mener det bruker opp mye dyrebar tid, kan vi vel alltids opprette et spleiselag...

[-Teddy-]

Jeg er gjerne med på et spleiselag.

Men siden noen moderatore, ironisk nok, sikkert snart kommer til å stenge denne tråden pga OT, kanskje vi skulle opprette en egen tråd der vi kan diskutere mulige løsninger for å tvinge Dahl ned foran tastaturet igjen og true han med smekk på balla om han ikke skriver videre på guiden?