ProgrammeringsBaren! Småprat, om det du elsker!

[Gloria]

 

Jeg har hvertfall bestilt denne boken: http://www.amazon.com/Introduction-Joes-Pros-Exam-70-536/dp/1451581718/

 

Ser den bra ut?

 

Jeg har aldri hørt om den boken der, men den er helt sikkert en grei introduskjon til alt det mest grunnleggende.

 

I tillegg til å lese om C# bør du kjøpe en bok som forteller deg litt mer generelt om hva som er viktig når man programmerer. Anbefalte bøker som lærer deg gode praksiser er blant andre:

• Clean Code
• Code Complete
• The Pragmatic Programmer

 

 

Tror den boken jeg bestilte var et bomkjøp, da jeg ser jeg allerede kan det meste som står i den. Bøkene du har skrevet skal jeg sjekke ut ved en senere anledning, men vet du om C# 5.0 in a nutshell er en passende bok for meg? Er liksom ikke lysten på enda et bomkjøp, hehe.

[siDDis]

Det er mange som anbefaler Clean Code. Mykje av det som står i boka er common sense, resten er fjas om forfatteren meining om korleis kode skal strukturerast.

 

Har du lyst å skrive bra kode, så gjer koden heller så enkel som mogleg. Mange abstrasjoner gjer ikkje kode lettare for andre.

[Matsemann]

Bra Clean Code var common sense for deg. Det er dessverre ikke det for mange, så nyttig å få folk til og lese den.

 

Dessuten har jeg vært borti flere som sier som deg men så skriver gigantiske funksjoner, dårlig navngivning o.l. Det hjelper lite å ha lest og forstått boka om man ikke faktisk gjør det som er "common sense".

 

Av de 3 bøkene er vel Pragmatic Programmer min "favoritt", fordi jeg er veldig enig i mye av det den sier. Det er så mange purister på nettet og universitetet, men det viktigste er jo å levere et godt produkt og da må man ofte velge middelveier.

 

Ellers er Clean Code veldig bra, til forskjell fra andre slike bøker viser den gode eksempler på det den skriver. Det er lett å si "skriv små, testbare funksjoner", noe helt annet og faktisk gjøre det.

Code Complete synes jeg var litt tung. Mange gode poenger, men pakket inn i litt mye tekst.

 

Usikker på om dette er bøker for nybegynnere, men.

[siDDis]

Gigantiske funksjoner kalles også ofte prosedyrer, dei er ofte lettare å følgje enn ein prosedyre som går igjennom 5000 filer

 

Og boka er jo prakteksempelet på dårlege variabel namn, du trenger ikkje å namngi ein funksjon executeProcedureIfPersonLikeCookies()

 

Ynskje du å skrive god kode, så jobber du i eit team. Dykk vil ha fleire interessante diskusjonar på kva dykk meine er god kode. Gjerne baser koden på ein kodestandard som Google sin.

[Matsemann]

Vanskelig å ha gode diskusjoner om ingen får inn innspill utenifra. Jeg sier ikke boken har rett i alt, men det er bedre å lese igjennom slikt og gjøre seg opp et bevisst, velbegrunnet valg heller enn å gjøre ting på en måte bare fordi man ikke vet bedre.

[Lycantrophe]

Det er selvfølgelig helt umulig å skrive god kode om en ikke er i et team.

[Karl Skapeland]

Og boka er jo prakteksempelet på dårlege variabel namn, du trenger ikkje å namngi ein funksjon executeProcedureIfPersonLikeCookies()

Jeg gjør det hele tiden. Når man refaktorerer kode, så gjør man samtidig koden mye mer lesbar, ved å gi så beskrivende metodenavn som mulig.

[tomsi42]

Jeg gjør det hele tiden. Når man refaktorerer kode, så gjør man samtidig koden mye mer lesbar, ved å gi så beskrivende metodenavn som mulig.

Jeg er enig i at en metode skal ha et beskrivende navn, men executeProcedureIfPersonLikeCookies() er ikke det. Det ser heller ut som dårlig programmering.

 

Istedet for:

 

    executeProcedureIfPersonLikeCookies();

ville jeg skrevet noe slik:

 

    if (personLikeCookies()) {
        BakeCookies();
    }

Her måtte jeg gjette hva slag prosedyre som skal utføres hvis man liker Cookies ... Endret 11. mars 2014 av tomsi42

[torbjørn marø]

Usikker på om dette er bøker for nybegynnere, men.

 

For alle disse tre bøkene så følte jeg når jeg leste dem at jeg burde ha lest dem tidligere i karriæren. Kanskje de ikke er for folk som akkurat har begynt å lukte på programmering (som i for et par uker siden), men den dagen du begynner å gjøre det på orntlig (som at du får deg en programmeringsjobb) så bør disse bøkene eller noe tilsvarende ligge på nattbordet.

 

...etter min mening

[torbjørn marø]

 

Jeg gjør det hele tiden. Når man refaktorerer kode, så gjør man samtidig koden mye mer lesbar, ved å gi så beskrivende metodenavn som mulig.

Jeg er enig i at en metode skal ha et beskrivende navn, men executeProcedureIfPersonLikeCookies() er ikke det. Det ser heller ut som dårlig programmering.

 

Istedet for:

 

    executeProcedureIfPersonLikeCookies();

ville jeg skrevet noe slik:

 

    if (personLikeCookies()) {
        BakeCookies();
    }

Her måtte jeg gjette hva slag prosedyre som skal utføres hvis man liker Cookies ...

 

 

Du kan ha rett. Eller du kan ha feil. Det kommer helt an på. Sånn er det alltid. Det beste vi kan gjøre er å lytte til folk som har programmert lenge (som forfatterne av bøkene jeg nevnte), og så forsøke å erfare selv hva som fungerer i ulike situasjoner. Etter å ha programmert daglig i 30 år - og hele tiden ha forsøkt å reflektere over hva du gjør og hvorfor du gjør det - så velger du forhåpentligvis det beste 9 av 10 ganger

 

Poenget er: Det er sjelden en fasit på hva som er god kode, og jeg synes ikke man fremstår så veldig bra om man påstår at man vet hva som er best.

 

Min erfaring med kodebaser hvor man har fulgt det Uncle Bob sier om veldig små metoder er derimot at det etterhvert blir veldig vanskelig å følge logikken. Min tommelfingerregel - som er enklere å si enn å forklare og å forstå - er at all kode som man må forstå samtidig bør befinne seg på samme sted. En annen måte å si det på er at en metode (eller prosedyre eller funksjon) bør inneholde all koden som har samme abstraksjonsnivå, men skjule all kode som er på et lavere abstraksjonsnivå.

 

Gir det mening for noen?

[Matsemann]

 

Usikker på om dette er bøker for nybegynnere, men.

 

For alle disse tre bøkene så følte jeg når jeg leste dem at jeg burde ha lest dem tidligere i karriæren. Kanskje de ikke er for folk som akkurat har begynt å lukte på programmering (som i for et par uker siden), men den dagen du begynner å gjøre det på orntlig (som at du får deg en programmeringsjobb) så bør disse bøkene eller noe tilsvarende ligge på nattbordet.

Ja, det kan jeg være enig i. Har selv hatt stor nytte av dem nå som jeg har begynt på mer "ekte" prosjekter som er store og langvarende. Med nybegynner tenkte jeg mer i baner noen som har programmert en liten stund (1-2 år kanskje) ikke vil kjenne seg igjen i de beskrevede situasjonene og egentlig ha viktigere ting å lære først.

 

Min erfaring med kodebaser hvor man har fulgt det Uncle Bob sier om veldig små metoder er derimot at det etterhvert blir veldig vanskelig å følge logikken.

(...)

En annen måte å si det på er at en metode (eller prosedyre eller funksjon) bør inneholde all koden som har samme abstraksjonsnivå, men skjule all kode som er på et lavere abstraksjonsnivå.

 

Gir det mening for noen?

Gir mening her. Det er jo også et av poengene til Bob, i samme kapittel til og med tror jeg, at abstraksjonsnivået bør være likt i en metode. Og nettopp derfor splitte ut detaljene i mindre metoder.

[torbjørn marø]

Gir mening her. Det er jo også et av poengene til Bob, i samme kapittel til og med tror jeg, at abstraksjonsnivået bør være likt i en metode. Og nettopp derfor splitte ut detaljene i mindre metoder.

 

Det var det jeg mente å huske - at Bob sier akkurat det. Men det folk husker er "extract 'til you drop", og resultatet blir kode som blir som Da Vinci-koden; man må grave og grave for å finne ut hva som skjer.

 

Forsøker å skrive en blogpost som snakker om dette og illustrerer hvordan man bør gjøre det....

[Lycantrophe]

Eller så er du for dårlig til å abstrahere. Gi helperne dine bedre navn, så løser problemet seg.

[torbjørn marø]

Eller så er du for dårlig til å abstrahere. Gi helperne dine bedre navn, så løser problemet seg.

 

Å lage gode abstraksjonsnivåer er vel kanskje det vanskeligste problemet man har som utvikler (av lesbar kode), og det kan ta mange år å bli god på dette. Mange blir det aldri. Navngivning er kanskje den nest største utfordringen. Hvis du har en mirakelformel for hvordan man lager gode navn så er jeg veldig interessert i å høre den

[siDDis]

Det er ingen formell for å namngiving, akkurat som det ikkje er ein formell for moteklede.

 

Og når det gjelder abstraksjoner, så er ofte duplisering av kode betre enn disse dårlege abstraksjonene ein ofte kjem over.

[torbjørn marø]

Og når det gjelder abstraksjoner, så er ofte duplisering av kode betre enn disse dårlege abstraksjonene ein ofte kjem over.

 

Flere som mener det: https://twitter.com/BonzoESC/status/442003113910603776/photo/1

Endret 16. mars 2014 av torbjørn marø

[Matsemann]

Istedet for:

    executeProcedureIfPersonLikeCookies();

ville jeg skrevet noe slik:

    if (personLikeCookies()) {
        BakeCookies();
    }

 

Eksempelet ditt er litt urettferdig, hva om den første heller var:

bakeCookiesIfPersonLikeCookies();

? Da skjønner du jo fint hva som gjøres. Ikke at jeg nødvendigvis ville ha laget en slik metode, da. Evt. måtte kodesnutt nr. 2 vært slik for at det skulle bli en bra sammenligning:

    if (personLikeCookies()) {
        executeProcedure();
    }

I et spill jeg skriver nå skal jeg spille av lyder når ting skjer. Da kan jeg enten gjøre slik overalt

if(settings.isSoundEnebaled() {
    clickSound.play();
}

eller bedre:

playIfSoundEnabled(sound);

og så får metoden ta seg av hva som skal skje. Endret 16. mars 2014 av Matsemann

[Lycantrophe]

playIfSoundEnabled, om man ser bort fra cancerCase, trenger egentlig ikke engang hete det. Det er opp til objektet selv å avgjøre hva som skal skje, så noe á play( sound ) bør duge.

[Matsemann]

Ja, den heter bare play() her, var mer for å gi et eksempel på en liten if som var verdt å dra ut i en egen metode.

 

Ang. case har jeg lite formeninger, jeg bruker det som er standard i hva enn språk/prosjekt jeg er borti.

[Lycantrophe]

Vel, OO-wise bør det være god nok motivasjon alene. ->sound_enabled() lekker state.