ProgrammeringsBaren! Småprat, om det du elsker!

[Lycantrophe]

Eller så er brainfuck meget enkelt.

[banansplitt™]

Er det jeg som er dum eller er disse oppgavene identiske?

 

 

4. Write a method called doubleList that takes an ArrayList of Strings as a parameter and replaces every String with two of that same String. For example, if the list stores the values (“how”, “are”, “you?”) before the method is called, it should store the values (“how”, “how”, “are”, “are”, “you?”, “you?”) after the method finishes executing.

 

 

11. Write a method called stutter that accepts an ArrayList of strings as a parameter and that replaces every string with two of that string. For example, if the list stores the values [“how”, “are”, “you?”], after the call it should store [“how”, “how”, “are”, “are”, “you?”, “you?”].

Endret 10. september 2013 av banansplitt™

[GeirGrusom]

De er like ja.

[Lycantrophe]

Så utrolig defekte oppgaver. Hvorfor i helvete spesifiserer de "Takes an ArrayList".

 

Ikke rart det skrives mye ræva java-kode.

 

Edit: Enda verre: Hvorfor muterer den input-listen? Og en ArrayList? ARGH

Endret 10. september 2013 av Lycantrophe

[banansplitt™]

Gjerne utdyp.

[Lycantrophe]

#1: Funksjonen bør ta List, ikke ArrayList. Interfacet som gir oppførselen, ikke den konkrete implementasjonen. Siden alt er dispatched og heap-alloc'd uansett taper du ingenting på det, men tjener på et bedre interface. På den måten fungerer den også for LinkedList og AidsList og gudene vet hva Java har implementert. Du kan også implementere din egen!

 

#2: Herreminfred, ArrayList er en kontinuerlig blokk minne. Altså må den re-alloces og herje. Dessuten er det dårlig stemning at en klasse tar inn en liste OG mutererer den. Objekter bør, så langt det er mulig, kun mutere interne ting. Altså burde listen sendes inn som const eller final eller gudene vet hva sølet bruker. Og heller returnere en ny liste som er modifisert.

 

Som en optimalisering kan man tilby en inplace-variant. Denne kan igjen brukes til å implementere return-stuttered-listen.

[banansplitt™]

Eksempel:

 

Tidligere i boken var det en oppgave der man skulle skrive ut en linje 1000 ganger. Løsningen ble å skrive en metode som skrev ut linjen 10 ganger, for deretter å skrive en metode som skrev ut forestående metode 10 ganger. Senere i boken lærer man om løkker og får samme oppgave om å skrive ut en linje 1000 ganger, denne gangen løser man det med løkker naturligvis.

 

Poenget er; boken er step-by-step og fokuset er problemløsning med what you've got. Jeg er sikker på at jeg etterhvert lærer om List og da får en lignende oppgave som jeg løser med List.

 

Det med mutasjonen kan jeg derimot argumentere for eller imot.

[Lycantrophe]

List er bare et interface. Koden hadde sett identisk ut med List (i stedet for ArrayList), men vært bedre.

[g6wkFV6yfl_]

Så utrolig defekte oppgaver. Hvorfor i helvete spesifiserer de "Takes an ArrayList".

 

Ikke rart det skrives mye ræva java-kode.

 

Edit: Enda verre: Hvorfor muterer den input-listen? Og en ArrayList? ARGH

#1: Funksjonen bør ta List, ikke ArrayList. Interfacet som gir oppførselen, ikke den konkrete implementasjonen. Siden alt er dispatched og heap-alloc'd uansett taper du ingenting på det, men tjener på et bedre interface. På den måten fungerer den også for LinkedList og AidsList og gudene vet hva Java har implementert. Du kan også implementere din egen!

 

#2: Herreminfred, ArrayList er en kontinuerlig blokk minne. Altså må den re-alloces og herje. Dessuten er det dårlig stemning at en klasse tar inn en liste OG mutererer den. Objekter bør, så langt det er mulig, kun mutere interne ting. Altså burde listen sendes inn som const eller final eller gudene vet hva sølet bruker. Og heller returnere en ny liste som er modifisert.

 

Som en optimalisering kan man tilby en inplace-variant. Denne kan igjen brukes til å implementere return-stuttered-listen.

 

Nettopp lært deg java eller? Det er en øvingsoppgave fra en bok i grunnleggende programmering, herlighet

 

[Lycantrophe]

Nei. Jeg skriver ikke engang Java. Det at det er en lærebok forsvarer ikke slikt. Det var forøvrig heller ikke opplyst om da postene ble skrevet. Uten at det har så skrekkelig mye med saken å gjøre.

Endret 10. september 2013 av Lycantrophe

[vebbiii]

Noen av dere som har lest boken "Clean Code" av Robert C. Martin(aka Uncle Bob)?

Endret 26. september 2013 av vebbiii

[Matsemann]

Ja. Mye av den, i det minste. Hvorfor det?

[siDDis]

Ja eg har lest Clean Code, boka er ikkje så spesiell som mange skal ha det til. Mykje av det som står der er jo ting som dei fleste utviklarar veit frå før av, det er bare at boka bekreftar deira tankar.

 

Skal du skrive fin kode, så er ein god IDE med godt analyseverktøy mykje mykje betre.

[Lycantrophe]

Skal du skrive fin kode er det best å ikke bruke en IDE.

[siDDis]

Totalt uenige, til og med C konger som John Carmack elsker kodeanalyseverktøy.

[Lycantrophe]

Kodeanalyse som i static analysis? Det kan fint gjøres uten en IDE.

 

edit: also, appeal to authority

Endret 27. september 2013 av Lycantrophe

[Matsemann]

Ja eg har lest Clean Code, boka er ikkje så spesiell som mange skal ha det til. Mykje av det som står der er jo ting som dei fleste utviklarar veit frå før av, det er bare at boka bekreftar deira tankar.

 

Skal du skrive fin kode, så er ein god IDE med godt analyseverktøy mykje mykje betre.

Synes ikke de to tingene har noe med hverandre å gjøre. Et IDE, et analyseverktøy eller egentlig hva som helst vil aldri kunne gjøre dårlig kode til fin kode. Et IDE kan derimot ofte hjelpe til med å refaktorere koden, men da basert på programmererens valg.

 

Boka skriver hva mange "vet", men kanskje ikke har tenkt nok over. Det er også forskjell på å vite hvordan noe *bør* se ut og gjøres, og på å faktisk *gjøre* det riktig.

[Lycantrophe]

Når vi er inne på det: hva er det egentlig IDE-refactor gjør for noe? Search-and-replace på signaturer?

[GeirGrusom]

Skal du skrive fin kode er det best å ikke bruke en IDE.

Tøv. Et IDE tilføyer såpass mye nyttige verktøy at dette vil jeg kalle rent sprøyt.

 

edit: IDE refactor gjør mye mer enn search replace da den forstår semantikken i koden din.

Endret 27. september 2013 av GeirGrusom

[Lycantrophe]

Tøv. Et IDE tilføyer såpass mye nyttige verktøy at dette vil jeg kalle rent sprøyt.

Estetikk. :-------)

 

edit: IDE refactor gjør mye mer enn search replace da den forstår semantikken i koden din.

Utdyp, er du snill, for dette betyr ca. ingenting.

edit: jeg kan ikke være noe dårligere her selv. Ok, la oss anta den forstår semantikken i koden; hvordan kan den bruke dette? Nøyaktig hva er det den får til som gjør at det blir refactor?

Endret 27. september 2013 av Lycantrophe