Re: [PROGRAMMERING] Quality Assurance

[Peter Makholm <sslug@sslug>]

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