Deze sectie is ook echt een voorwaarde voor coderen, zoals McConnell opmerkt: “Establish programming conventions before you start programming. Het is bijna onmogelijk om de code later aan te passen.”

zoals vermeld aan het einde van coderingsconventies, zijn er verschillende conventies voor verschillende programmeertalen, dus het kan contraproductief zijn om dezelfde conventies in verschillende talen toe te passen. Het is belangrijk op te merken dat er geen enkele specifieke coderingsconventie is voor een programmeertaal. Elke organisatie heeft een aangepaste codering standaard voor elk type software project. Het is daarom noodzakelijk dat de programmeur een bepaalde reeks coderingsrichtlijnen kiest of maakt voordat het softwareproject begint. Sommige codeerconventies zijn generiek die niet van toepassing zijn op elk softwareproject geschreven met een bepaalde programmeertaal.

het gebruik van coderingsconventies is met name belangrijk wanneer een project meer dan één programmeur omvat (er zijn projecten geweest met duizenden programmeurs). Het is veel gemakkelijker voor een programmeur om door iemand anders geschreven code te lezen als alle code dezelfde conventies volgt.

voor enkele voorbeelden van slechte coderingsconventies, geeft Roedy Green een lang (tongue-in-cheek) artikel over het produceren van onverkrijgbare code.

CommentingEdit

vanwege tijdbeperkingen of enthousiaste programmeurs die onmiddellijke resultaten voor hun code willen, neemt het becommentariëren van code vaak een achterbank. Programmeurs die als team werken hebben het beter gevonden om opmerkingen achter te laten omdat codering meestal cycli volgt, of meer dan één persoon kan aan een bepaalde module werken. Sommige opmerkingen kunnen echter de kosten van kennisoverdracht tussen ontwikkelaars die aan dezelfde module werken verlagen.

In de begindagen van de informatica was een becommentariëringspraktijk om een korte beschrijving achter te laten van het volgende::

1. naam van de module
2. doel van de Module
3. beschrijving van de Module
4. oorspronkelijke auteur
5. wijzigingen
6. auteurs die de code hebben gewijzigd met een beschrijving waarom deze is gewijzigd.

de” beschrijving van de module ” dient zo kort mogelijk te zijn, zonder afbreuk te doen aan de duidelijkheid en volledigheid.

De laatste twee punten zijn echter grotendeels achterhaald door de komst van revisiecontrolesystemen. Wijzigingen en hun auteurschap kunnen betrouwbaar worden bijgehouden met behulp van dergelijke tools in plaats van met behulp van opmerkingen.

ook, als ingewikkelde logica wordt gebruikt, is het een goede gewoonte om een commentaar “blok” achter te laten in de buurt van dat deel, zodat een andere programmeur kan begrijpen wat er precies gebeurt.

Unit testing kan een andere manier zijn om aan te tonen hoe code bedoeld is om te worden gebruikt.

Naming conventionsEdit

het gebruik van eigennaamconventies wordt als goede praktijk beschouwd. Soms gebruiken programmeurs X1, Y1, enz. als variabelen en vergeet om ze te vervangen door betekenisvolle degenen, waardoor verwarring.

Het wordt gewoonlijk als een goede praktijk beschouwd om beschrijvende namen te gebruiken.

voorbeeld: een variabele voor het opnemen van het gewicht als parameter voor een vrachtwagen kan TrkWeight of Truckweightkilogrammen worden genoemd, waarbij Truckweightkilogrammen de voorkeur hebben, omdat deze direct herkenbaar is. Zie CamelCase naamgeving van variabelen.

Houd de code simpledit

de code die een programmeur schrijft moet eenvoudig zijn. Ingewikkelde logica voor het bereiken van een eenvoudig ding moet tot een minimum worden beperkt, omdat de code in de toekomst door een andere programmeur kan worden gewijzigd. De logica die een programmeur implementeerde is misschien niet helemaal logisch voor een ander. Houd de code dus altijd zo eenvoudig mogelijk.

neem bijvoorbeeld deze equivalente regels van C-code:

if (hours < 24 && minutes < 60 && seconds < 60){ return true;}else{ return false;}

en

if (hours < 24 && minutes < 60 && seconds < 60) return true;else return false;

en

return hours < 24 && minutes < 60 && seconds < 60;

de eerste benadering, die veel vaker wordt gebruikt, is aanzienlijk groter dan de derde. In het bijzonder, het verbruikt 5 keer meer scherm verticale ruimte (lijnen), en 97 tekens versus 52 (hoewel editing tools kan het verschil in de werkelijke typen te verminderen). Het is betwistbaar, echter, die is “eenvoudiger”. De eerste heeft een expliciete als / dan anders, met een expliciete return waarde duidelijk verbonden met elk; zelfs een beginnende programmeur zou geen moeite moeten hebben om het te begrijpen. De tweede gooit alleen de beugels weg en snijdt de” verticale ” grootte in tweeën met weinig verandering in conceptuele complexiteit. In de meeste talen kunnen de” return ” statements ook worden toegevoegd aan de voorgaande regels, waardoor de “verticale” grootte slechts één regel meer is dan de 3e vorm.

de derde vorm minimaliseert uiteraard de grootte, maar kan de complexiteit verhogen: Het laat de “ware” en “valse” waarden impliciet, en vermengt de noties van “voorwaarde ” en”retourwaarde”. Het is waarschijnlijk duidelijk voor de meeste programmeurs, maar een beginner kan niet onmiddellijk begrijpen dat het resultaat van het evalueren van een aandoening is eigenlijk een waarde (van het type Boolean, of zijn equivalent in welke taal dan ook), en dus kan worden gemanipuleerd of geretourneerd. In meer realistische voorbeelden kan het derde formulier problemen hebben als gevolg van de rangorde van de operator, misschien een onverwacht type retourneren, waarbij de eerdere formulieren in sommige talen een fout zouden melden. “Eenvoud” is dus niet alleen een kwestie van lengte, maar van logische en conceptuele structuur; het korter maken van code kan het minder of complexer maken.

voor grote, langlevende programma ‘ s die uitgebreide alternatieven gebruiken, kan dit bijdragen aan bloat.

compactheid kan programmeurs toestaan om meer code per pagina te bekijken, waardoor scrollgebaren en toetsaanslagen worden verminderd. Gezien het aantal keren dat code kan worden bekeken tijdens het schrijven en onderhouden, zou het kunnen neerkomen op een aanzienlijke besparing in programmeur toetsaanslagen in de levensduur van de code. Dit lijkt misschien niet belangrijk voor een student die voor het eerst leert programmeren, maar bij het produceren en onderhouden van grote programma ‘ s zorgt de vermindering van het aantal regels code dat er is voor meer code om op het scherm te passen, kleine code vereenvoudiging kan de productiviteit verbeteren, en ook het verminderen van vinger -, pols-en oogbelasting, die veel voorkomende medische problemen lijden onder productie-programmeurs en informatiewerkers.

terser codering snelheden compilatie zeer licht, omdat minder symbolen moeten worden verwerkt. Bovendien kan de derde benadering het mogelijk maken soortgelijke regels code gemakkelijker te vergelijken, met name wanneer veel van dergelijke constructies tegelijkertijd op één scherm kunnen verschijnen.

ten slotte kunnen zeer korte lay-outs beter gebruik maken van moderne breedbeeldcomputerschermen, afhankelijk van de lay-out en instelling van de monitor. In het verleden waren schermen beperkt tot 40 of 80 karakters (dergelijke grenzen zijn veel eerder ontstaan: manuscripten, gedrukte boeken en zelfs rollen, hebben al millennia vrij korte regels gebruikt (zie bijvoorbeeld Gutenberg Bijbel). Moderne schermen kunnen gemakkelijk 200 of meer tekens weergeven, waardoor extreem lange lijnen mogelijk zijn. De meeste moderne codering stijlen en normen niet nemen die hele breedte. Dus, als het gebruik van een venster zo breed als het scherm, een groot deel van de beschikbare ruimte wordt verspild. Aan de andere kant, met meerdere vensters, of met behulp van een IDE of andere tool met verschillende informatie in zijpanelen, de beschikbare breedte voor code is in het bereik bekend van eerdere systemen.

Het is ook vermeldenswaard dat het menselijke visuele systeem sterk wordt beïnvloed door lijnlengte; zeer lange lijnen verhogen de leessnelheid iets, maar verminderen het begrip en dragen bij aan eye-tracking fouten. Sommige studies suggereren dat langere lijnen tarief beter online dan in print, maar dit gaat nog steeds slechts tot ongeveer 10 inch, en vooral voor de ruwe snelheid van het lezen van proza.

PortabilityEdit

programmacode mag geen “hard-gecodeerde” (letterlijke) waarden bevatten die verwijzen naar omgevingsparameters, zoals absolute bestandspaden, bestandsnamen, Gebruikersnamen, hostnamen, IP-adressen, URL ‘ s, UDP / TCP-poorten. Anders zal de toepassing niet draaien op een host die een ander ontwerp heeft dan verwacht. Een zorgvuldige programmeur kan dergelijke variabelen parametrizen en configureren voor de hostingomgeving buiten de juiste toepassing (bijvoorbeeld in eigenschappenbestanden, op een toepassingsserver, of zelfs in een database). Vergelijk de mantra van een “single point of definition” (SPOD).

als extensie moeten resources zoals XML-bestanden ook variabelen bevatten in plaats van letterlijke waarden, anders zal de toepassing niet naar een andere omgeving kunnen worden overgedragen zonder de XML-bestanden te bewerken. Bijvoorbeeld, met J2EE toepassingen die draaien in een toepassingsserver, kunnen dergelijke omgevingsparameters worden gedefinieerd in de scope van de JVM en de toepassing moet de waarden van daaruit krijgen.

ScalabilityEdit

ontwerpcode met schaalbaarheid als ontwerpdoel omdat in softwareprojecten vaak nieuwe functies worden toegevoegd aan een project dat groter wordt. Daarom wordt de mogelijkheid om nieuwe functies toe te voegen aan een softwarecodebasis een onschatbare methode bij het schrijven van software

herbruikbaarheid Edit

hergebruik is een zeer belangrijk ontwerpdoel in softwareontwikkeling. Hergebruik verlaagt de ontwikkelingskosten en verkort ook de ontwikkeltijd als de hergebruikte componenten of modules al getest zijn. Heel vaak beginnen softwareprojecten met een bestaande baseline die het project in zijn eerdere versie bevat en afhankelijk van het project worden veel bestaande softwaremodules en-componenten hergebruikt, wat de ontwikkelings-en testtijd verkort, waardoor de kans op het leveren van een softwareproject op schema toeneemt.

Bouwrichtsnoeren in het kortdit

een algemeen overzicht van al het bovenstaande: