Anders Borum

Rss
Personligt feed med nye kommentarer i tråde, du overvåger:
https://www.version2.dk/mit/0/kommentarer?token=HPnHcLYhJ8jCXC_UoTnfzqY2R9xpwMBmKONAZAek0jk

Kommentarer

Kommentar til Seniorudvikler: Sådan skriver vi selvforklarende kode

Re: Al denne debat

Nu har jeg så svært ved at se en bog som et stykke software produkt opbygget af kode, men jeg må indrømme i en stor del af det litteratur jeg læser er der indsat fodnoter med henvisning til forklarende/uddybende/bevis tekst. Så jo - der er sådan set 'kode kommentar' i bøger. Det sagde jeg ...
Kommentar til Seniorudvikler: Sådan skriver vi selvforklarende kode

Re: Al denne debat

Det mener du vel forhåbentligt ikke alvorligt? Afprøvning er af stor betydning, men de fungerer ikke til alle formål. Jeg mener det ret bogstaveligt. Og nej, afprøvning ér af stor betydning men tjener ikke alle formål. De fungerer som et sikkerhedsnet. Hvordan tester du ellers, at din softw...
Kommentar til Seniorudvikler: Sådan skriver vi selvforklarende kode

Re: Hvor er uenigheden?

Virkeligheden er blot for rigtig mange, at den største forhindring IKKE er hvorvidt IT folk forstår den problematik. Det gør langt de fleste og altså også ledelsen hos e-conomic Bare til din information, har jeg på intet tidspunkt kommenteret på e-conomics metoder; det er mit indtryk at de h...
Kommentar til Seniorudvikler: Sådan skriver vi selvforklarende kode

Re: Til forsvar for en kommentar

Den dårlige kodekvalitet er oftere resultatet af manglende ledelsesmæssig prioritering, end udtryk for en lav professionel standard. En programmør bør/skal ikke bede sin chef om at fortælle ham, hvordan han skal gøre sit arbejde - tests underbygger fx. korrektheden af implementeringen, og de...
Kommentar til Seniorudvikler: Sådan skriver vi selvforklarende kode

Re: Al denne debat

Hvad med ting som at beskrive invarianter (løkkeinvarianter er et meget udbredt eksempel), beviser for en algoritmes korrekthed, noter omkring køretiden og potentielle forbedringer der ikke var nødvendige da koden først blev skrevet? Beviset for en algoritmes korrekthed finder jeg i de tests...
Kommentar til Seniorudvikler: Sådan skriver vi selvforklarende kode

Re: Al denne debat

Du har så ret, jeg undgår også fuldstændigt parametre til funktioner, i stedet laver jeg klasser, hvor jeg putter parametrene ind som felter og kalder klassen én metode, som har erstattet den grimme funktion. Jeg håber vi begge er enige om, at der må være tale om ironisk pseudokode i dit ind...
Kommentar til Seniorudvikler: Sådan skriver vi selvforklarende kode

Re: If versus ?:

Det kan være det er mine return-udtryk der er for lange, men jeg synes netop at if/else er lettere læseligt, især hvis udtrykket indeholder et funktionskald med mange parametre. Det ér typisk en "code smell", hvis din funktion tager for mange parametre. Løsningen kan bl.a. være at...
Kommentar til Seniorudvikler: Sådan skriver vi selvforklarende kode

Re: Al denne debat

Når man ser alt denne debat og holdning til noget så simpelt som lidt kode stumper, så giver det netop mere vægt til argumentet at man lige så godt kan smide en eller to liniers komentar ind hvor det giver mening frem for at forsøge at få ens kode til at være 'selvforklarende'. Jeg er lodret...
Kommentar til Seniorudvikler: Sådan skriver vi selvforklarende kode

Ternære operatorer (ternary operators)

Der er forhåbentligt ingen professionelle programmører, der har svært ved at forstå (endsige læse) kode, der gør brug af ternære operatorer ("?:"). Ofte er argumentet for if/else-alternativet, at det gemmer på to eller flere operationer - som man så pakker ind i curlies ({}). Men ofte...
Kommentar til Seniorudvikler: Sådan skriver vi selvforklarende kode

Re: pæn kode?

Angående navngivning på klasser og funktioner, så bør man gøre sig selv (og andre programmører) en tjeneste ved at lægge sig op af standarder i det framework/den platform man arbejder på - og altså ikke opfinde den dybe tallerken, når alternativet allerede foreligger. Når jeg læser "...
Kommentar til Seniorudvikler: Sådan skriver vi selvforklarende kode

Re: Vi har også lige taget Clean-Code tyren ved hornene :)

I vores team (MailTalk), er alle (nærmest religiøst) enige om at arbejde efter SOLID principperne (bl.a. etableret af Robert C. Martin, forfatter til en række bøger - herunder den anerkendte "Clean Code" som nævnt tidligere). Det er en stor fordel, at alle tænker og arbejder efter de...