1. Uavhengig av språk: Tester!

Hvis noen ber meg vurdere kode der det ikke er skrevet en eneste unit-test, så får utvikleren beskjed om å komme tilbake når det er gjort.

2. Størrelse på klasser / metoder / funksjoner

Jeg hater koder med metoder / funksjoner på hundrevis av linjer. Da er det bedre å bryte opp problemene i mindre biter, noe som blir både mer leselig, men også mer testbart.

3. Kommentarer i kildekoden

Hvis en utvikler skriver masse kommentarer i koden, vitner det om at vedkommende ikke er dyktig nok til å skrive lesbar kode. Man kommer langt med korte metoder / funksjoner med forklarende navn.

Kunne sikkert ha skrevet mer.

Litt uenig med deg om kommentarer. Jeg mener det bør være bra kommentert så en kan lese hva programmet skal gjøre uten å være ekspert-programmerer selv. Men er det alt for mye kommentarer kjøper jeg argumentet ditt. Mest mulig subsutiner med forklarende navn vil jo også hjelpe.

Jeg skjønner ikke rasjonale ditt bak færre kommentarer. Det er helt essensielt for å forstå hva noen tror at koden deres skal gjøre. Det er tilnærmet umulig å drive med code review uten.

Jeg ser at størrelsen på klasser blir nevnt, hva med kombinasjoner av disipliner? Som proseduralt, OOP, og / eller funksjonelt i samme klasse?

Folk som mener man ikke skal kommentere kode er litt som folk som mener de ikke trenger å bruke blinklys fordi de er en "god sjåfør".

Alt med måte.

Du har de nybegynnerne som kommenterer omtrent hver 3. linje med kode også har man de som ikke kommenterer i det hele tatt. Hver sin ende av skalaen.

Det er lett å se forskjell på en god og en dårlig programmerer. Jeg tror Barte Sam er leder for et utvikler team så jeg er ganske sikker på at han vet hva han snakker om.

Du tenker på de som kjører Tesla og BMW? Men husk at de som kjører elbil tror at det er den som kjører raskest gjennom rundkjøringa som har forkjørsrett, ikke den som passerte vikepliktmerkene først som har den.

En ting jeg ikke nevnte i mitt svar på trådstarters innlegg, er at unit-tester er den beste måten å dokumentere kildekode på.

Om du hadde vært i et jobb-intervju-møte med meg, og sagt at unit-tester bare er teknisk gjeld, så hadde jeg strøket deg av lista med én gang.

Interessant tråd. Vi må ha flere slike her på Freak.

Dette kommer helt an på hva slags kode og hvor det skal brukes, synes jeg. På mange plattformer så er det en kost/nytte-avveining om hvor ille det er at feil slipper gjennom. Hvis man kan deploye en fiks på noen minutter så er det mindre stress enn hvis man må trekke tilbake ferdige produkter. Andre ganger skriver man veldig midlertidig kode, f.eks. for å analysere data. Dette er kode man kanskje kjører et par ganger med et datasett og så blir den ikke brukt igjen.

Skriver du veldig optimalisert kode for f.eks. en mikrokontroller, er det utrolig viktig med designdokumentasjon og unit-tester for hver modul og et lass med integrasjon- og systemtester lengre ut i løypa. Slik kode programmeres kanskje på brikker og sendes ut i verden med svært begrenset støtte for å kunne oppgraderes. Man må levere noe som fungerer på første forsøk. Som oftest ender man opp med en lang errata over kjente feil, og så fikser man ting i neste versjon, men det kan ta år mellom hver revisjon. For programvare til medisin eller luftfart må man ofte bruke en godkjent standard for programmering, f.eks. MISRA C. Her er det altså sjeldent nødvendig med kommentarer inni koden, annet enn TODOs, for å linke til tickets eller kapitler i dokumentasjonen, eller for å påpeke quirks man må huske på mens man endrer på funksjonen (f.eks. hvor mange mikrosekunder du har i budsjettet). Her ender man ofte opp med svært lange funksjoner inne i critical path, rett og slett fordi man ikke har tid til å kalle nye funksjoner hele tiden, og inlining øker størrelsen for mye.

Kode for en nettside eller lignende kan og vil endre seg ganske drastisk flere ganger i året, og automatisk testing av det visuelle blir vanskeligere. Dokumentasjon av back-end og tester på de mest kritiske funksjonene er nødvendig, men å lage tester av typen "bakgrunnen er blå" blir meningsløst hvis dette endrer seg. Masse kommentarer og "pen" HTML kan også gi deg dårligere ranking pga. innlastingstid, så å forsøke å generere noe som er "pent" der kan være å skyte seg selv i foten. For back-end forventer jeg dokumentasjon over hver eneste funksjon som forklarer inputs og outputs, og merker spesielt om en input fra bruker er sanitert enda, og på hvilken måte. Det er forskjell på å sanitere for XSS, SQL injection, paths og ugyldige eposter for eksempel. Funksjonene bør også være forholdsvis korte, og ikke prøve å gjøre alt for mye magisk.

Hvis man lager kode for Web3, f.eks. Solidity-kontrakter eller mer spesialiserte chains som Solana, Move, Cairo e.l. så programmerer man med pengene til ekte mennesker. Koden her bør være så enkel som mulig, ikke koste for mye gas å kjøre, og det bør være åpenbart hva som skjer. Det er også et minstekrav om natspec på alle funksjoner og både 100% statement og branch coverage, men mange velger å ikke gjøre dette. Koden her blir ofte lest av andre selskaper som leser koden og ser etter feil i den, og jo mer krøkkete og komplisert koden din er, jo mer tidkrevende og derav dyrere blir det for en audit. Her er det altså viktig å unngå å ta snarveier, og alltid sjekke returverdien på absolutt alt. Man bør også programmere inn en mulighet til å redde pengene hvis en krise skulle skje, uten at dette går på bekostning av brukernes sikkerhet (f.eks. sette alt på pause og holde en avstemming om hvor pengene skal sendes).