mboost-dp1
Iterator + Datamatiker + Lærer
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Implementering af en iterator i java. Af vores lærer på 3 semester af datamatiker i Århus.
Kig kode, og grin med.
Først og fremmest kan det interne index 'i' aldrig blive 0.
Derudover bliver der lavet noget kode der kan forsimples til:
Det er til grin at en lærer ikke ved bedre.
Kig kode, og grin med.
public boolean hasNext() {
if(i < 0 || i >= list.size())
return false
else
return true
}
Først og fremmest kan det interne index 'i' aldrig blive 0.
Derudover bliver der lavet noget kode der kan forsimples til:
if(true) { return true; } else { return false; }
Det er til grin at en lærer ikke ved bedre.
Windcape (1) skrev:Implementering af en iterator i java. Af vores lærer på 3 semester af datamatiker i Århus.
Kig kode, og grin med.
public boolean hasNext() {
if(i < 0 || i >= list.size())
return false
else
return true
}
Først og fremmest kan det interne index 'i' aldrig blive 0.
Sludder... første element (såfremt i er en cursor) vil være 0.
Derudover bliver der lavet noget kode der kan forsimples til:
if(true) { return true; } else { return false; }
Ja... vis det! Forresten kan din ovenstående kode forsimples tilreturn true;!
Det er til grin at en lærer ikke ved bedre.
NioBe (2) skrev:Jeg havde en SQL lære der ikke kunne en skid SQL... Det endte med at vi alle fik en karakter på 7, fordi han viste ikke noget om SQL undtagen at finde de små kommandoer i en bog, for at vide hvad de betød/gjorte, uden selv at kunne forstå det...
Jeg så engang et indlæg på newz.dk hvor NioBe lavede alt for mange stavefejl, hun kunne så ikke engang (i modsætning til en berygtet SQL lærer) finde ud af at bruge stavekontrol (eller se i en ordbog), uden selv at kunne forstå det.
lære = lærer
viste = vidste
gjorte = gjorde
Det ville aldrig have sket i Vejle (mvh. den glade datamatiker)
#1
Jeg kan slet ikke hidse mig op over den kode.
Først er der:
i < 0 || i >= list.size()
versus kun:
i >= list.size()
Jeg vil ikke kalde den første variant for dårlig kode. Skepsis overfor "i vil aldrig være mindre end 0" kan være godt.
Man kunne også have smidt en:
ind øverst.
Alle 3 varianter bør kunne accepteres.
Derefter er der:
versus:
Jeg vil give dig ret i at den første er lidt ufix.
Men jeg synes ikke at det er et stort problem.
Koden virker og den er letlæselig.
Og man betaler ikke per linie.
Der er set langt langt værre kode ude i virkeligheden !
Jeg kan slet ikke hidse mig op over den kode.
Først er der:
i < 0 || i >= list.size()
versus kun:
i >= list.size()
Jeg vil ikke kalde den første variant for dårlig kode. Skepsis overfor "i vil aldrig være mindre end 0" kan være godt.
Man kunne også have smidt en:
if(i < 0) {
throw new IllegalStateException("Object can not be iterated in this state");
}
ind øverst.
Alle 3 varianter bør kunne accepteres.
Derefter er der:
if(...) {
return true;
} else {
return false;
}
versus:
return ...;
Jeg vil give dig ret i at den første er lidt ufix.
Men jeg synes ikke at det er et stort problem.
Koden virker og den er letlæselig.
Og man betaler ikke per linie.
Der er set langt langt værre kode ude i virkeligheden !
Det er der skam.arne_v (5) skrev:Der er set langt langt værre kode ude i virkeligheden !
Men de 20 andre studerende i min klasse kan ikke gennemskue at de bare kunne lave
return (i > list.size())
Og læren blev sur da det blev kommenteret det var en mulighed.
Jeg synes at lave statements i stil med dette her viser at man ikke har særlig god styr på hvad der rent faktisk er logiske statements i ens kode.
if(true) {
return true;
}
Det bør virkelig ikke forekomme på en uddanelse.
Windcape (7) skrev:
Jeg synes at lave statements i stil med dette her viser at man ikke har særlig god styr på hvad der rent faktisk er logiske statements i ens kode.
if(true) {
return true;
}
Det bør virkelig ikke forekomme på en uddanelse.
Du er helt forkert på den. Det bør *netop* forekomme på en uddannelse! Det er simpelt og let at læse og overskue.
Hvis det er korrekt, at underviseren blev sur for at høre om alternativer, så har du ret og krav på din tudekiks; men ellers så mener jeg bestemt, du brokker på et yderst spinkelt grundlag.
Vores underviserer er generelt meget negative omkring alternativer til deres måder at gøre tingene på.Pally (8) skrev:at underviseren blev sur for at høre om alternativer
Hvilket de få af os som har erfaring før vi startede på uddanelsen, har det med at benytte os af.
Der har mange gange været direkte dum kode præsenteret af vores lærere, både uoverskuelig og dårlig kodet.
Jeg synes ikke at bruge 4 linjer til at skrive en linje på 10 tegn med er smart overhovedet. Folk skal lære at forstå hvordan en if sætning rent faktisk fungerere.
Windcape (9) skrev:Vores underviserer er generelt meget negative omkring alternativer til deres måder at gøre tingene på.
Hvilket de få af os som har erfaring før vi startede på uddanelsen, har det med at benytte os af.
Der har mange gange været direkte dum kode præsenteret af vores lærere, både uoverskuelig og dårlig kodet.
Jeg synes ikke at bruge 4 linjer til at skrive en linje på 10 tegn med er smart overhovedet. Folk skal lære at forstå hvordan en if sætning rent faktisk fungerere.
Fair nok. Dårlige undervisere er en pest og det er en ond spiral som gør, at du irriteres over mindre ting end ved en god underviser. Helt forståeligt.
Men det konkrete eksempel mener jeg stadig er åben for diskussion. Jeg vil til enhver tid foretrække at review'e kode a la:
if (somethingSimple1)
return false;
if (somethingSimple2)
return false;
...
return true;
fremfor:
return (somethingVeryLongAndComplexWithLotsOfAndsAndOrs)
Pally (10) skrev:...Men det konkrete eksempel mener jeg stadig er åben for diskussion. Jeg vil til enhver tid foretrække at review'e kode a la:
if (somethingSimple1)
return false;
if (somethingSimple2)
return false;
...
return true;
fremfor:
return (somethingVeryLongAndComplexWithLotsOfAndsAndOrs)
Det ville jeg så ikke... jeg ville hellere strukturere min kode:
...
return cursorWithinBounds() && somethingElse());
...
private boolean cursorWithinBounds() {
....
}
private boolean somethingElse() {
....
}
Det øger efter min mening letlæseligheden. Jeg mener desuden også det er MEGET dårlig stil at have return statements i enkelt-line if-statements - det bliver næsten til spaghetti-kode.
Helt klart, men der skal jo være en grænse.Pally (10) skrev:
return (somethingVeryLongAndComplexWithLotsOfAndsAndOrs)
Et mini statement med et enkelt logisk statement (dette tilfælde: x > y), er en simple return at foretrække.
Jeg skulle nok havde uddybet det, men pointen var mere at folk slet ikke forstod at de kunne lave en "return (statement)" fremfor at retunere true/false.
Hvis du refferer til #1, var det fordi jeg var for doven til at trykke på enter da jeg skrev denne post.Corholio (11) skrev:Jeg mener desuden også det er MEGET dårlig stil at have return statements i enkelt-line if-statements - det bliver næsten til spaghetti-kode.
Var mest for at illusterer det dumme i lærens kode.
#14
Men unødvendig kode som dette her, vil jeg mene skaber mere forvirring end godt.
Det er jo ikke en C implementering af en advanceret algoritme.
Og desværre så er uddanelser aldrig gode til at skrive kode der nemt kan ses igennem, da lærerne sjældent tager tid til dette, men bare skriver noget som virker for dem (og ikke nødvendigvis andre).
Men unødvendig kode som dette her, vil jeg mene skaber mere forvirring end godt.
Det er jo ikke en C implementering af en advanceret algoritme.
Og desværre så er uddanelser aldrig gode til at skrive kode der nemt kan ses igennem, da lærerne sjældent tager tid til dette, men bare skriver noget som virker for dem (og ikke nødvendigvis andre).
Om man returnerer true eller false i en situation som aldrig burde kunne forekomme er ret ligemeget. Så jeg er enig i at i<0 delen ikke hører hjemme der. Hvis man endeligt vil checke for det, så skal man bruge assertions (eller hvad java ækvivalenten til det er).
Men simplificeringen er jeg ikke helt enig i. Hvilken af de to man bør vælge skal helt og holdent afhænge af hvad der er nemmest at forstå når man læser det.
Hvis man kigger på koden og tænker det kunne være gjort simplere, så er det sådanset ikke noget dårligt tegn. Så længe man bare kan kigge på den og se at den gør det den skal gøre.
Hvis man derimod havde kigget på den kortere version og tænkt, hvad er det lige den gør, så ville det have været en skidt ting.
Hvilken af de to der er nemmest at forstå når man læser det er ikke helt oplagt i det her tilfælde, så jeg vil sige at begge varianter kan forsvares. Men der er helt klart andre situationer, hvor længere kode er mere læseligt end en kortere men ellers ævkivalent kode.
Hvis det er oplagt for læseren at to stykker kode gør nøjagtigt det samme, så vil det som regel også være oplagt for compileren, som vil producere den samme bytecode i begge tilfælde. (Men betydningen af oplagt er ikke helt oplagt, for nogen gange kan en programmør eller en compiler tro, at to stykker kode er ækvivalente hvor det faktisk ikke er tilfældet. Og så er det man ender med bugs i sine programmer).
Men simplificeringen er jeg ikke helt enig i. Hvilken af de to man bør vælge skal helt og holdent afhænge af hvad der er nemmest at forstå når man læser det.
Hvis man kigger på koden og tænker det kunne være gjort simplere, så er det sådanset ikke noget dårligt tegn. Så længe man bare kan kigge på den og se at den gør det den skal gøre.
Hvis man derimod havde kigget på den kortere version og tænkt, hvad er det lige den gør, så ville det have været en skidt ting.
Hvilken af de to der er nemmest at forstå når man læser det er ikke helt oplagt i det her tilfælde, så jeg vil sige at begge varianter kan forsvares. Men der er helt klart andre situationer, hvor længere kode er mere læseligt end en kortere men ellers ævkivalent kode.
Hvis det er oplagt for læseren at to stykker kode gør nøjagtigt det samme, så vil det som regel også være oplagt for compileren, som vil producere den samme bytecode i begge tilfælde. (Men betydningen af oplagt er ikke helt oplagt, for nogen gange kan en programmør eller en compiler tro, at to stykker kode er ækvivalente hvor det faktisk ikke er tilfældet. Og så er det man ender med bugs i sine programmer).
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.