[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]
 
[an error occurred while processing this directive] [an error occurred while processing this directive]
Skåne Sjælland Linux User Group - http://www.sslug.dk Home   Subscribe   Mail Archive   Forum   Calendar   Search
MhonArc Date: [Date Prev] [Date Index] [Date Next]   Thread: [Date Prev] [Thread Index] [Date Next]   MhonArc
 

RE: [PROGRAMMERING] Quality Assurance



Præcis!!
Jeg var heller ikke altid enig i de metrics TCC tjekkede, men oftest var
jeg.
Flere return statements KAN være ok men ikke altid. Funktioner kan ikke
altid være på skærmen, men hvis den kan splittes op, så gør jeg det. QA
softwaren leder efter MULIGE problemer. Så må man som reviewer tage stilling
til om der skal gøres noget eller ej. Jeg foretrækker altid, at kode, som
ikke er indlysende, bliver kommenteret, og jeg kommenterer altid interfaces
med Doxygen kommentarer, og det er også et krav på arbejdet.

-----Original Message-----
From: sslug@sslug [mailto:sslug@sslug Behalf Of
Peter Makholm
Sent: 14. juni 2004 13:03
To: sslug@sslug
Subject: Re: [PROGRAMMERING] Quality Assurance


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






 
Home   Subscribe   Mail Archive   Index   Calendar   Search

 
 
Questions about the web-pages to <www_admin>. Last modified 2005-08-10, 22:43 CEST [an error occurred while processing this directive]
This page is maintained by [an error occurred while processing this directive]MHonArc [an error occurred while processing this directive] # [an error occurred while processing this directive] *