Free Press

Welkom in de wondere wereld van softwareontwikkeling. Bereid u voor op een spannende en opwindende reis vol code, regels en nog meer code. En had ik al gezegd dat er regels zijn? Als u iemand bent die vertrouwd is met coderen, dan is het concept van coderingsstandaarden niets nieuws voor u. Misschien ben je een groot voorstander van deze richtlijnen of een vrijheidsstrijder die gelooft dat code een vorm van expressie is. Hoe dan ook, het kan geen kwaad om te kijken naar een aantal van de beste praktijken als het gaat om het schrijven van een goed stuk code.
Het is de moeite waard om te vermelden dat terwijl coderingsstandaarden bestaan – ze bestaan in vele variaties en zijn vaak slechts richtlijnen die niet hoeven te worden gevolgd. Tenzij je goede code wilt schrijven, dan moet je je waarschijnlijk houden aan een vorm van standaarden.

Schrijf commentaar en documentatie

Misschien een van de eerste dingen die je leert als ontwikkelaar is je code van commentaar te voorzien. In het begin lijkt het misschien tijdverspilling, volgens de mentaliteit van ‘Als zij ook een ontwikkelaar zijn – kunnen ze het begrijpen’. Hoewel het soms waar is, zal het becommentariëren van je code en het voorzien van de juiste documentatie de andere ontwikkelaars door het algoritme en de logica leiden die je geïmplementeerd hebt. Maar laat je niet meeslepen en becommentarieer niet elke regel code! Duidelijke code moet blijven zoals hij is.

Schrijf leesbare en toch efficiënte code

Leesbare codes zijn gemakkelijk te volgen, maar gebruiken toch optimaal ruimte en tijd. Als u code schrijft, wilt u die vaak in zo weinig mogelijk regels schrijven. Misschien kunt u een hele methode of functie in één regel schrijven, maar dat maakt het alleen maar moeilijker te lezen en te begrijpen.

Gebruik helper-methoden

Het is een goede gewoonte om code beknopt en bondig te houden. Een methode moet alleen implementeren wat het moet doen. Als een deel van je implementatie iets anders doet, stop het dan in een aparte methode en roep die aan binnen je methode.

Als het te vermijden is, maak GEEN hard-code!

De enige dingen die hard-gecodeerd moeten worden zijn constanten. Dat is alles.

Schrijf testgevallen. Vergeet de randgevallen niet: 0s, lege strings/lists, nulls, etc.

Op deze manier weet je wat je methode doet, wat het neemt en wat het moet teruggeven. Je weet wanneer het moet werken of wanneer het moet mislukken. Een functie moet altijd gebaseerd zijn op testgevallen; niet op tests op functies.

Schrijf leesbare maar efficiënte code.Voldoe aan de coderingsstandaarden van uw huidige project

“DISCIPLINED PERSONAL PRACTICES CAN REDUCE DEFECT INTRODUCTION RATES BY UP TO 75 PERCENT”

Elk project/bedrijf heeft zijn eigen coderingsstandaarden. Sommigen geven de voorkeur aan de ene stijl boven de andere als het gaat om zaken als naamgevingsconventies, bestandsstructuur en spatiëring.
Er zijn IDE’s waar je de voorkeursstijl kunt instellen, die je automatisch corrigeert als je opslaat. Het is gemakkelijker te lezen en dus te begrijpen, wanneer alle bestanden van de projecten dezelfde stijl, naamgeving conventie, spatiëring, enz. gebruiken.

Gebruik uw IDE drop-down menu

Niet zozeer een standaard, maar een goede praktijk, deze zijn zeer nuttig en zal u helpen minder coderingsfouten te maken.

Bijv.:
Als je een variabele of methode een andere naam wilt geven, gebruik je gewoon de “refactor” optie van je IDE en het zal alle aanroepen naar die methode/variabele naam veranderen. Je hoeft ze niet een voor een te veranderen, wat je code foutgevoelig maakt.
Als je getter/setter methodes wilt maken voor al je prive variabelen, gebruik dan gewoon “create getter/setter” en de IDE zal automatisch de methodes voor je maken.

API’s zijn handig

“CURRENT SOFTWARE PROJECTEN SPENDEN ABOUT 40 TO 50 PERCENT OF THE EFFORT ON AVOIDABLE REWORK”

Voordat je een methode implementeert, zorg er dan voor dat ze niet beschikbaar zijn voor jou om te gebruiken. Je hoeft niet te coderen als je de functionaliteit gewoon kunt importeren. Dat maakt het leven van een ontwikkelaar supergemakkelijk.
Het bekende gezegde luidt: “Vind het wiel niet opnieuw uit” en dat is in veel gevallen waar. Je moet echter altijd de implicaties van het importeren van een bibliotheek overwegen, vooral als het een derde partij is. Afgezien van mogelijke licentieproblemen, kan het zijn dat u uw codebase alleen maar groter maakt. Als alles wat je nodig hebt een methode is die temperaturen converteert, hoef je geen library te importeren die dat doet en nog honderd andere dingen.

Pair programming/code review

“PEER REVIEWS CATCH 60 PERCENT OF THE DEFECTS”

Deze zijn zeer nuttig als het gaat om het refactoren van je code. Anderen zien misschien een betere implementatie om je code te optimaliseren of gewoon je code eleganter te maken. Het zorgt er ook voor dat ontwikkelaars zich aan de standaarden houden en dat het werk dubbel gecontroleerd wordt. Daarnaast is het een geweldige manier voor ontwikkelaars om van elkaar te leren.

BACKUP AND SAVE YOUR WORK OFTEN

Genoeg gezegd. Lege batterij, stroomuitval, softwarefout, brand, kernramp – dit alles kan leiden tot gegevensverlies. Een eenvoudige manier om ervoor te zorgen dat uw code veilig blijft, is ervoor te zorgen dat u vaak opslaat en back-ups van uw code maakt op een versiecontrolesysteem.

Codeerstandaarden en best practices is een enorm onderwerp – een onderwerp dat vele pagina’s kan beslaan. In feite, als je ooit wilt lezen over Java coderingsstandaarden, Oracle heeft precies dat. Toepassing van deze standaarden en praktijken varieert ook per toepassing – of je nu werkt aan een groot bedrijfsproject of je kleine broertje helpt met huiswerk. Op basis van vele factoren is het uiteindelijk aan u om ervoor te zorgen dat de code die u ontwikkelt goede code is.

Disclaimer: Alle standpunten of meningen in deze blogbijdrage zijn uitsluitend die van de auteur en vertegenwoordigen niet noodzakelijkerwijs die van Aversan Inc.