Free Press

Velkommen til den vidunderlige verden af softwareudvikling. Gør dig klar til en spændende og spændende rejse fyldt med kode, regler og mere kode. Og nævnte jeg, at der er regler? Hvis du er en person, der er fortrolig med kodning, så er begrebet kodningsstandarder ikke noget nyt for dig. Du er måske en stærk tilhænger af disse retningslinjer eller en frihedskæmper, der mener, at kode er en udtryksform. Uanset hvad der er tilfældet, skader det ikke at se på nogle af de bedste metoder, når det gælder om at skrive et godt stykke kode.
Det er værd at nævne, at selv om der findes kodningsstandarder – så findes de i mange variationer og er ofte blot retningslinjer, som ikke behøver at blive fulgt. Medmindre du ønsker at skrive god kode, så bør du nok holde dig til en eller anden form for standarder.

Skriv kommentarer og dokumentation

Måske er en af de første ting, du lærer som udvikler, at kommentere din kode. I første omgang kan det måske virke som spild af tid, idet man følger mentaliteten “Hvis de også er udviklere – kan de forstå det”. Selv om det er sandt nogle gange, vil det at kommentere din kode og give ordentlig dokumentation guide de andre udviklere gennem den algoritme og logik, som du har implementeret. Men lad dig ikke rive med og kommentér hver eneste kodelinje! Indlysende kode bør efterlades som den er.

Skriv læsbar, men effektiv kode

Læsbar kode er let at følge, men bruger alligevel optimal plads og tid. Når du skriver kode, kan du ofte ønske at skrive den på så få linjer som muligt. Måske kan du skrive en hel metode eller funktion i én linje, men det gør det kun sværere at læse og forstå.

Brug hjælpemetoder

Det er god praksis at holde koden kortfattet og kortfattet. En metode bør kun implementere det, den har brug for at gøre. Hvis en del af din implementering gør noget andet, skal du placere den i en separat metode og kalde den i din metode.

Hvis det kan undgås, må du IKKE hardcode!

De eneste ting, der bør hardcodes, er konstanter. Det er det hele.

Skriv testcases. Glem ikke edge cases: 0’er, tomme strenge/lister, null’er osv.

Sådan ved du, hvad din metode gør, hvad den tager, og hvad den skal returnere. Du vil vide, hvornår den skal virke, eller hvornår den skal fejle. En funktion bør altid være baseret på testcases; ikke test på funktioner.

Skriv læsbar, men effektiv kode.Overhold kodningsstandarderne for dit aktuelle projekt

“DISCIPLINEREDE PERSONLIGE PRAKSISER KAN REDUCERE FJECT INTRODUKTIONS RATERNE MED OP TIL 75 %”

Alle projekter/virksomheder har deres egne kodningsstandarder. Nogle foretrækker måske en stil frem for en anden, når det gælder ting som navngivningskonventioner, filstruktur og mellemrum.
Der findes IDE’er, hvor du kan indstille den foretrukne stil, som automatisk vil korrigere dig, når du gemmer. Det er nemmere at læse og dermed forstå, når alle filer i projekterne bruger samme stil, navngivningskonvention, afstand osv.

Brug din IDE’s drop-down menu

Det er ikke så meget en standard, men en god praksis, disse er meget nyttige og vil hjælpe dig med at lave færre kodningsfejl.

For eksempel:
Hvis du ønsker at omdøbe en variabel eller en metode, skal du blot bruge “refactor”-muligheden i dit IDE, og den vil ændre alle kald til det pågældende metode-/variabelnavn. Du behøver ikke at ændre dem en efter en, hvilket vil gøre din kode udsat for fejl/fejl.
Hvis du ønsker at oprette getter/setter-metoder for alle dine private variabler, skal du blot bruge “create getter/setter”, og IDE’en vil automatisk oprette metoderne for dig.

API’er er praktiske

“CURRENT SOFTWARE PROJECTS SPEND ABOUT 40 TO 50 PERCENT OF THEIR EFFORT ON AVOIDABLE REWORK”

Hvor du implementerer en metode, skal du sørge for, at de ikke er tilgængelige for dig at bruge. Du behøver ikke at kode, hvis du bare kan importere funktionaliteten. Det gør en udviklers liv super nemt.
Det berømte ordsprog er “Don’t reinvent the wheel”, og det står sandt i mange tilfælde. Du bør dog altid overveje konsekvenserne af at importere et bibliotek, især hvis det er et tredjepartsbibliotek. Bortset fra eventuelle licensproblemer kan du måske bare oppustet din kodebase. Hvis det eneste, du har brug for, er en metode, der konverterer temperaturer, behøver du ikke importere et bibliotek, der gør det og hundrede andre ting.

Pair programming/code review

“PEER REVIEWS CATCH 60 PERCENT OF THE DEFECTS”

Disse er meget nyttige, når det gælder refactoring af din kode. Andre kan måske se bedre implementering for at optimere din kode eller bare gøre din kode mere elegant. Det sikrer også, at udviklerne overholder standarderne, og at arbejdet bliver dobbeltkontrolleret. Ud over alt det er det en vidunderlig måde for udviklere at lære af hinanden.

BACKUP OG GEM DIT ARBEJDE OFTE

Gen nok sagt. Dødt batteri, strømsvigt, softwarefejl, brand, atomkatastrofe – alt dette kan resultere i tab af data. At sørge for at gemme ofte og sikkerhedskopiere din kode på en eller anden form for versionskontrolsystem er en simpel måde at sikre, at din kode forbliver sikker.

Kodningsstandarder og bedste praksis er et stort emne – et emne, der kan fylde mange sider. Hvis du nogensinde ønsker at læse op på Java-kodningsstandarder, så har Oracle faktisk netop det. Anvendelsen af disse standarder og praksisser varierer også fra applikation til applikation – uanset om du arbejder på et stort virksomhedsprojekt eller hjælper din lillebror med lektier. På baggrund af mange faktorer er det i sidste ende op til dig at sikre, at den kode, du udvikler, er god kode.

Disclaimer: Alle synspunkter eller holdninger, der præsenteres i dette blogindlæg, tilhører udelukkende forfatteren og repræsenterer ikke nødvendigvis Aversan Inc.