[an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive]
[an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive]![]() |
![]() |
![]() |
|||||||||||||||||||||||||
|
|||||||||||||||||||||||||||
![]() |
![]() |
![]() |
Jacob Sparre Andersen <sslug@sslug> writes: > > * Der bør være kommentarer rundt omkring i koden som > > forklarer, hvad der sker. QA softwaren kan ikke tjekke > > kvaliteten af kommentarerne, men kan i hvert fald sige > > til, hvis de ikke er der. > > Uenig. Da det ikke er praktisk muligt at tjekke om > kommentarer hænger logisk sammen med koden, bør man have så > få kommentarer som muligt. Jeg er enig i at være uenig, men resten er en non sequitur. Man skal ikke stræbe efter at have få kommentarer. Det handler om at skabe en fornuftig ligevægt, specielt skal forskellige antagelser man gør sig dokumenteres i koden, hvis man af en eller anden grund ikek vil tjekke for dem eksplicit. For mange kommentare kan dog være et tegn på at man enten skriver forkerte komentare eller forkert kode. Følgende er et eksempel på forkerte kommentare: open(LOG, ">>", "$logfile") # Åben logfilen || die "..."; # Ellers dø print LOG $message; # Skrive beskeden til logfilen close LOG; # Luk LOG-filen Her står der ikke noget der ikke er indlysende ud fra koden. Tydelige eksempler på at kommentare viser forkert kode er når man i perl bruger 12 linjer kommentarer og 4 linjer kode på noget der kunne have været gjort pænt og indlysende på 8 linjers kode. Det man eventuelt kunen få et QA-værktøj til attjekke er at alle funktioner enten klart bliver markeret som hjælpefunktioner eller bliver dokumenteret med noget literate programming ala Knuths CWEB, Perls POD eller JavaDoc. Hvis det gøres ordentligt er det dog begrænset hvad der ellers er nødvendigt af dokumentation i selve funktionskroppen. > > * Hvis en funktion har 8 return statements og den > > pludselig skal rydde noget op inden returnering er det 8 > > steder, det skal implementeres. Derfor (og af mange andre > > årsager) bør en funktion kun have ét return statement. > > Tjah. Jeg mener der er for mange gode grunde til at have > mere end en "return"-sætning i en subroutine til at et > sådant tjek giver mening. Det er ofte lidt et spørgsmål om smag om man vil have en return eller flere. Jeg mener ikke at den første af følgende funktioner er objektivt pænere end den anden: sub find_first_one_return { my $found = 0; my $elem = undef; while(!$found and exists(@_[0])) { $elem = pop; if (prop($elem)) { $found = 1; } } return $elem; } sub find_first_two_returns { while(exists(@_[0])) { if(prop(sslug@sslug)) { return $_[0]; } } return undef; } Men et tjek af return-statements ville kunne indgå i en del af et tjek på om man laver spagetti-kode. -- Peter Makholm | One thing you do is prevent good software from sslug@sslug | being written. Who can afford to do professional http://hacking.dk | work for nothing? | -- Bill Gates
![]() |
![]() |
![]() |
||||||||||||
|
||||||||||||||
![]() | ||||||||||||||
|
||||||||||||||
![]() |
![]() |
![]() |