Småprat om/rundt UiO (informatikk)

[steingrim]

Kommentarer ja... Etter å ha jobbet med mye rar kode i det siste må jeg si at Robert C Martin hadde rett: "Comments are lies"

[sureup]

har bare lagt til masse kommentarer nå og skrevet nederst at jeg ønsker en tilbakemelding på kommentar bruken ^^

men tror nok de vil ha litt kommentarer nå når man er på så basic plan sånn at man viser at man har forstått det og ikke bare copy/paste fra andre

[cyclo]

Kan legge til noe mer til det jeg sa. Veldig mange som lærer seg programering for første gang i en utdanningsinstitusjon gjør feilen å tro at man skal bruke kommentarer for å bevise at man har forstått hva man gjør/oppgaven. Grunnen til at man skal kommentere er for at andre skal kunne forstå koden din fortest mulig.

[sureup]

Kan legge til noe mer til det jeg sa. Veldig mange som lærer seg programering for første gang i en utdanningsinstitusjon gjør feilen å tro at man skal bruke kommentarer for å bevise at man har forstått hva man gjør/oppgaven. Grunnen til at man skal kommentere er for at andre skal kunne forstå koden din fortest mulig.

 

lol ok jeg snur og fjerner de fleste kommentarene da Så får jeg heller spørre på slutten om de synes jeg bør kommentere mer etc

[JohndoeMAKT]

Jeg skiller mellom bruk og refaktorering når det kommer til kommentering. Alle klasser og metoder er kommentert etter Javadoc/PHPdoc-standarden slik at de som skal bruke de får i sitt IDE oppgitt programmerer, mål, input og output, slik at metodene fra utsiden er godt kommentert. Når det kommer til selve koden internt i en metode er mitt pragmatiske syn at dersom du har interesse av å forstå hva som skjer betyr det at du skal refaktorere den, og for det setter jeg krav at du har skills nok til å se hva som skjer uten kommentarer. Så i en ferdig klasse er gjerne 20-30% av linjene PHPdoc, men av normale kommentarer inline er det muligens 2-3 av per 1000 linjer.

 

Jeg fikk jo en kommentar på oblig1 at jeg burde kommentere mer. Jeg kan godt forstå at Javadoc-blokk over både klasse og metode ikke er godt nok for de fire linjene kode.

 

EDIT: Det kan også nevnes at min kommenteringstilnærmelse er et tilfelle av do unto others as you would have them do unto you. Det er ingenting bedre enn når jeg skal bruke en annens klasse/metode at det medfølger en enkel tolinjers 1-2-3-forklaring i toppen som bare fungerer og at jeg aldri trenger å se på noe i den indre mekanikken.

Endret 26. september 2008 av JohndoeMAKT

[Zerblat]

Jeg fikk jo en kommentar på oblig1 at jeg burde kommentere mer. Jeg kan godt forstå at Javadoc-blokk over både klasse og metode ikke er godt nok for de fire linjene kode.

Grunnen til det er at enkelte gruppelærere klarer å si at det skal kommenteres så ~alle kan forstå koden din.

Studenter som lærte det ifjor og er gruppelærere i år klarer dermed å lire av seg det samme and so on.

 

Sitter forøvrig med et par oppgaver her der samtlige 300 linjer er kommentert, må ha tatt lang tid.

 

Typ. "/* lukke løkke */ }".

[JohndoeMAKT]

Det var ( IMO ) en pest på HiO også. En eller annen foreleser kodet som dette:

 

while( true ) {
if ( yesterday == today ) {
	continue;
} //end if
else
{
	syso( "world not broken" );
} //end else
} // end while

 

Og plutselig skulle alle kommentere alle høyre-krøller ( } ) med slike fantastisk overflødige kommentarer. Kompakt K&R-style indentering med lav SNR ( signal to noise ratio ) syntes jeg gir mye mer oversiktlighet enn slik kommentering som bare kaster leseren ut av flyten.

Endret 26. september 2008 av JohndoeMAKT

[x871kx6167ss7]

Er det noen som ikke har bestått oblig fordi de har kommentert for mye?

[cyclo]

Jeg skiller mellom bruk og refaktorering når det kommer til kommentering. Alle klasser og metoder er kommentert etter Javadoc/PHPdoc-standarden slik at de som skal bruke de får i sitt IDE oppgitt programmerer, mål, input og output, slik at metodene fra utsiden er godt kommentert. Når det kommer til selve koden internt i en metode er mitt pragmatiske syn at dersom du har interesse av å forstå hva som skjer betyr det at du skal refaktorere den, og for det setter jeg krav at du har skills nok til å se hva som skjer uten kommentarer. Så i en ferdig klasse er gjerne 20-30% av linjene PHPdoc, men av normale kommentarer inline er det muligens 2-3 av per 1000 linjer.

 

Jeg fikk jo en kommentar på oblig1 at jeg burde kommentere mer. Jeg kan godt forstå at Javadoc-blokk over både klasse og metode ikke er godt nok for de fire linjene kode.

Har samme kommenteringsstil, men bruker javadoc i stedet. Første oblig i 2100 (Forøvrig litt mer inline koder, da koden nok er litt mer komplisert.) fikk komentaren "Veldig pen, ren og ryddig kode, bra med javadoc. :-)"

Endret 26. september 2008 av cyclo

[1503]

Lessons om hvordan man failer i basic java pm meg.. cheap as helL!

 

Kom du i mål?

[Thunder1]

not quite, men håper på ikke godkjent og utsatt frist.. trur det burde gå

[Blåbær]

Samme her, noen som har noen hjelpende ord til oblig2 som jeg sannsynligvis ikke fpr godkjent. Hørte om en som ikke fikk oblig1 godkjent fordi han manglet en apostrof og måtte levere på nytt.

[Zerblat]

Samme her, noen som har noen hjelpende ord til oblig2 som jeg sannsynligvis ikke fpr godkjent. Hørte om en som ikke fikk oblig1 godkjent fordi han manglet en apostrof og måtte levere på nytt.

Hva lurer du på?

Kompilerer ikke koden får man det ikke godkjent selv med en liten tullefeil.

[LordjOX]

Samme her, noen som har noen hjelpende ord til oblig2 som jeg sannsynligvis ikke fpr godkjent. Hørte om en som ikke fikk oblig1 godkjent fordi han manglet en apostrof og måtte levere på nytt.

Hva lurer du på?

Kompilerer ikke koden får man det ikke godkjent selv med en liten tullefeil.

 

Eh, ikke nødvendigvis... Det er helheltsinntrykket som teller. Men det er individuellt fra gruppelærer til gruppelærer. Hvis feilen som gir kompileringsfeil ikke har noe å si for resultatet på oppgaven er det ikke noe for at gruppelærer ikke kan rette det opp selv. Men så spørs det da, hvordan kan studenten vite om det er riktig i utgangspunktet hvis det ikke kompilerer..

[Zerblat]

Eh, ikke nødvendigvis... Det er helheltsinntrykket som teller. Men det er individuellt fra gruppelærer til gruppelærer. Hvis feilen som gir kompileringsfeil ikke har noe å si for resultatet på oppgaven er det ikke noe for at gruppelærer ikke kan rette det opp selv. Men så spørs det da, hvordan kan studenten vite om det er riktig i utgangspunktet hvis det ikke kompilerer..

Så du gidder virkelig feilsøke koden om den ikke kompilerer?

Med Java får man gjerne 20-30 errors for en liten tullefeil.

 

Personlig går bare oppgaven i retur med "kompilerer ikke" om jeg mottar noe slikt, men for all del, noen er jo utrolig snille også.

 

(Kompilerer ikke programmet feiler det jo strengt tatt absolutt alle punktene i oppgaven ved at det ikke fungerer også. )

Endret 29. september 2008 av Zerblat

[LordjOX]

Det tar toppen ett minutt. Man må lese igjennom koden uansett. Men som sagt, hvis det ikke kompilerer så er det også et tegn på at noe ikke er riktig overhodet. Dvs underkjent.

 

Ser ikke at det er noe bryderi hvis man må bare bytte ut et tegn eller at tegnsettet skaper problemer.

[Zerblat]

Kommer vel an på hvor lat man er, personlig mener jeg man ikke fortjener å få godkjent om man ikke sjekker at koden man sender inn funker engang.

Tegnsett-krøll vil stort sett bare gi warnings for unmappable character for tekst som skal printes, ikke errors.

 

Men de som tar INF1000 her får håpe de er på gruppe 6!

[LordjOX]

Kommer vel an på hvor lat man er, personlig mener jeg man ikke fortjener å få godkjent om man ikke sjekker at koden man sender inn funker engang.

Tegnsett-krøll vil stort sett bare gi warnings for unmappable character for tekst som skal printes, ikke errors.

 

Men de som tar INF1000 her får håpe de er på gruppe 6!

 

Klart.

 

Ikke nødvendigvis. Feil valg av tegnsett eller norske særtegn f.eks i metodenavn kan gi problemer. Eller UTF-8 filer med BOM.

 

Heldiggriser.

[Zerblat]

Blir det ikke advart mot æ, ø og å i variabel, klasse og metodenavn på forelesningene?

Uansett - ikke godkjent!

[LordjOX]

Blir det ikke advart mot æ, ø og å i variabel, klasse og metodenavn på forelesningene?

Uansett - ikke godkjent!

Mulig. Men når programskjelettet til Obligen har æøå i metodenavn...;p