Archief - Goede programmeertechnieken

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
D

Destiser

Legacy Member
Er is in de 'Algemeen'-sectie van dit forum een discussie aan de gang ivm 'goed leren programmeren'. Bij deze vraag ik mij dan ook af of er boeken of dergelijke zijn die zoveel taalonafhankelijk mogelijk, goede programmeertechniekentips bevatten.

Zelf ben ik geen IT-er en maar een ingenieur, maar voor het werk doe ik geregeld C# programmatie. En ook al doe ik m'n best om alles zo netjes mogelijk te doen, ik heb te vaak het idee dat ik een basis mis van algemene 'goede programmeertechnieken'. Bestaan hier boeken van en dergelijke?

Je ziet soms boeken ivm 'design patterns', maar ik denk dat dat zich specifiek richt op bepaalde practische problemen. Ik wil eigenlijk gewoon eens een algemeenheid, zoals reeds op het forum verschenen:

"Een for-loop onderbreek je niet met een break maar door er een extra boolean statement in te verwerken" (https://www.beyondgaming.be/archive/web-design-programming.237/break-enof-return-in-een-loop.831780)

Dat soort dingen heb ik nooit gezien. OOP heb ik nu wel gezien maar zo'n dingen zoals daarnet dus niet. Ook regels betreffende naming conventions enzo, allija, echt de dingen die een programmeur moet weten en in (toch bijna) alle talen kan toepassen.

Zijn er mensen die zo'n recources kennen?
S

SDEC

Legacy Member
Als je er een recourse van vind laat dan iets weten, zou best wel handig zijn :D De meeste programmeurs leren de stijlregels d.m.v. ervaring (zijnde in de praktijk of tijdens lessen, of soms op dit forum zoals de bovenstaande link mooi demonstreerd :p). Ook is het zo dat je IDE vaak de stijlregels in jouw plaats toepast zodat je er zelf niet zoveel rekening hoeft mee houden. Dingen die je IDE dan weer niet doet zijn dan weer wel goed om te weten, bv:

- Namen van variabelen horen te beginnen met een kleine letter, en verder in CamelCase (elke nieuw woord in de variabele moet met een hoofdletter beginnen). probeer de naam van de variabele ook altijd relevant te houden, niet iets zoals 'x' of 'var', maar een betekenisvolle naam zoals bv 'loopCounter' of dergelijke.
Code: 
int varInCamelCase = 0; (C, Java, ...)

- Definities/statische variabelen moeten altijd in hoofdletters, en elke nieuw woord liefst gescheiden door een '_'
Code: 
#define MAX_IETS 300 (in C)
of
private static final double  GETAL_PI = 3.1415; (Java)

- Lijn je code altijd mooi uit boven elkaar, dit doet je IDE wel voor jou maar vaak genoeg wordt dit principe nog aan de laars gelapt.

Code: 
DIT: 

function eenFunctie(int eenParameter) {
    if(eenStatement == true) {
        if(eenStatement == true) {
            eenFunctie();
        }
    }
}

NIET DIT (OF DERGELIJKE):

function eenFunctie(int eenParameter) {
if(eenStatement == true) {
    if(eenStatement == true) {
        eenFunctie();
}
}
}

Er zijn er nog zo veel meer, maar dit zijn toch wel de basisregels denk ik.
T

Tyfius

Legacy Member
De namen van variabelen, functies en andere dingen hangen af van de taal, het framework en de project guidelines, indien deze aanwezig zijn. Zeggen dat die altijd met het een of het ander moeten beginnen is dus niet correct.
p

passero

Legacy Member
Ik vind het persoonlijk trouwens dubbelzinnig...
Er is een groot verschil tussen programmeertechnieken en programmeerstijlen

Bovenstaande heeft niets met techniek te maken maar met stijl en gaat enkel de leesbaarheid van uw programma ten goede komen.

Technieken zijn meer dingen die je toepast om problemen op te lossen. Design paterns dus. Daar bestaan veel goeie boeken over.

Wat ik persoonlijk zou toevoegen is dat wanneer je de neiging hebt om een stuk code te copy/pasten, je dat nooit mag doen en er eerder een apparte functie van moet maken.

Aan de andere kant... Richtlijnen zijn soms ook maar richtlijnen. Ik zie het veel "in het veld" dat aan sommige van die regels gezondigd worden om sneller te kunnen werken. Denk bijvoorbeeld aan al die regels in den aard van design patterns, loose coupling,...
Niet elk bedrijf of klant heeft het budget om een grondige analyze te laten maken om tot het bijna perfecte klasse diagram te komen.
Het is allemaal mooi in de theorie....
C

Cycloon

Legacy Member
passero zei:
Aan de andere kant... Richtlijnen zijn soms ook maar richtlijnen. Ik zie het veel "in het veld" dat aan sommige van die regels gezondigd worden om sneller te kunnen werken. Denk bijvoorbeeld aan al die regels in den aard van design patterns, loose coupling,...
Niet elk bedrijf of klant heeft het budget om een grondige analyze te laten maken om tot het bijna perfecte klasse diagram te komen.
Het is allemaal mooi in de theorie....
Klik om te vergroten...

Het gaat niet om "het perfect klassediagram", maar programmeurs die beweren dat ze tijd sparen door bepaalde technieken niet toe te passen bedriegen enkel zichzelf. Initieel lijkt loose coupling en unit testen een zware kost. Op lange termijn betaalt zich dat dubbel en dik terug. De meeste die beweren dat die zaken tijdsverlies zijn hebben gewoon te weinig ervaring met die dingen, want ze leveren net tijd op als je die dingen vanzelfsprekend vindt.

Héél kleine projecten kunnen af en toe een uitzondering zijn, maar zelf daar zie je vaak dat kleine projecten keer op keer groeien. En geloof me vrij, er is geen kat die een dag wil refactoren om iets klein toe te voegen. Door al die kleine wijzigingen die het geheel telkens slechter maken wordt het al snel hopeloos.
p

passero

Legacy Member
Cycloon zei:
Initieel lijkt loose coupling en unit testen een zware kost. Op lange termijn betaalt zich dat dubbel en dik terug. De meeste die beweren dat die zaken tijdsverlies zijn hebben gewoon te weinig ervaring met die dingen, want ze leveren net tijd op als je die dingen vanzelfsprekend vindt.
Klik om te vergroten...

Jij weet dat, ik weet dat en (hopelijk) de meesten onder ons weten dat.
Probeer dit eens aan de mensen uit te leggen die beslissen over het geld.

Unit testing en het uitwerken van een goed design kost tijd en dat kan je gemakkelijk zien in een offerte. Op lange termijn gaat dit beter zijn maar als je een offerte vergelijkt waar ze geen unit testing doen of geen deftig design maken en sneller de requirements implementeren, dan zal die 2de "volgens de offerte" sneller opleveren en minder geld kosten.
In de praktijk zal de voorgestelde deadline van de eerste offerte veel gemakkelijker gehaald worden terwijl de 2de veel zal uitlopen en langer zal duren.

Dit kan je heel moeilijk uitgelegd krijgen aan de business... Die willen zo snel mogelijk en goedkoop mogelijk hun project opgeleverd zien.

Ik ben niet voor het feit dat we de richtlijnen aan ons laars moeten lappen maar in de praktijk moet je een gulden middenweg vinden omdat het commercieel niet altijd haalbaar is.
C

Cycloon

Legacy Member
passero zei:
Ik ben niet voor het feit dat we de richtlijnen aan ons laars moeten lappen maar in de praktijk moet je een gulden middenweg vinden omdat het commercieel niet altijd haalbaar is.
Klik om te vergroten...

In praktijk is het zelf beter ze aan je laars te lappen. Zo krijg je onderhoudscontracten die weer geld opleveren :p. Als softwarebedrijf kan ik ergens wel begrijpen dat sommigen voor het snelle succes gaan. Ik werk dan ook niet voor een softwarebedrijf en dat doet ook al veel. Bij ons primeert (gelukkig) goed design en makkelijk onderhoud boven de snelle invoer van software.
M

Moto

Legacy Member
Belangrijkste is dat ge complexe problemen simpel + elegant probeert op te lossen, hoe minder overbodige klassen/interfaces/patterns/libraries/frameworks/patterns hoe beter

Bv loose coupling enkel wanneer het zin heeft, indien het geen zin heeft => zinloze complexiteit => slecht/overhead.
Bv Design Patterns = complexe problemen simpel oplossen NIET simpele problemen complex maken
Bv Domain Model + Alle DDD Patterns = Overbodig voor de meeste applicaties, enkel voor complexe applicaties met snel wisselende domain rules => anders Anemic Domain Model => Anti-Pattern

Hoe minder code hoe beter
Hoe meer specifieke code en dus minder generische code hoe beter
Bv generic repositories => Anti-Pattern

De waarde van die "best practices" krijgt ge alleen bij het correct gebruik anders is het extra complexiteit die niet nodig is en dus SLECHT is.
Beter af en toe eens geen "best practice" doen en pas later toepassen dan er 1 te snel te gebruiken
T

Tyfius

Legacy Member
Destiser zei:
alvast bedankt voor de headstart! Onder 'other also buy this' ook deze wrs wel interessante gevonden (maar is wel via Java):

Clean Code: A Handbook of Agile Software Craftsmanship Robert C. Martin: Amazon.co.uk: Robert C. Martin: Books
Klik om te vergroten...
Dat is nu een boek dat ik aan niemand zou aanraden. Een van zijn guidelines is de code zoveel mogelijk opsplitsen in functies van maximum 3 regels. Kleine, simpele functies die 1 ding doen is natuurlijk de bedoeling, maar hij gaat daar gewoon te ver in. (Leesmateriaal: Function Hell « Whathecode)

Qua code refactoring kan ik http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672 wel aanraden. (Voor zij die ReSharper ervaring hebben, zij baseren zich op dit boek.)
p

passero

Legacy Member
Agile is nu ook weer niet de methodologie die de beste kwaliteit aan code levert...
Ofwel ligt het aan projecten die ik reeds gezien heb... (ben zelf geen agile expert) maar ik van wat ik gezien heb is dat je maar 1 sprint vooruit denkt zonder veel rekening te houden met de toekomst.
Dan kan je code relatief deftig zijn voor de huidige sprint maar wanneer een volgende sprint andere requirements brengt kan je in de knoop zitten en door de strikte deadlines heb je niet genoeg tijd om het deftig te herwerken...

Ik weet natuurlijk niet of dit de algemene regel is. Ik zag dit enkel gebeuren bij sommige projecten.
C

Cycloon

Legacy Member
Tyfius zei:
Dat is nu een boek dat ik aan niemand zou aanraden. Een van zijn guidelines is de code zoveel mogelijk opsplitsen in functies van maximum 3 regels. Kleine, simpele functies die 1 ding doen is natuurlijk de bedoeling, maar hij gaat daar gewoon te ver in. (Leesmateriaal: Function Hell « Whathecode)
Klik om te vergroten...

Je moet inderdaad niet overdrijven, die 3 regels moet je ook niet bekijken als "regels", maar eerder als maximum 3 niet complexe stukjes logica. Iets in de zin van Open File, Write To file, Close File. Dat zijn 3 oproepen, maar dat moeten geen 3 regels code zijn. Hier en daar wat variabelen opzetten horen naar mijn mening niet bij die 3 regels.

Maar er zijn ook situaties waar zijn stijlregels totaal niet toepasbaar zijn. Daarom moet je bij stijlregels ook wel wat gezond verstand gebruiken :)

passero zei:
Agile is nu ook weer niet de methodologie die de beste kwaliteit aan code levert...
Ofwel ligt het aan projecten die ik reeds gezien heb... (ben zelf geen agile expert) maar ik van wat ik gezien heb is dat je maar 1 sprint vooruit denkt zonder veel rekening te houden met de toekomst.
Dan kan je code relatief deftig zijn voor de huidige sprint maar wanneer een volgende sprint andere requirements brengt kan je in de knoop zitten en door de strikte deadlines heb je niet genoeg tijd om het deftig te herwerken...

Ik weet natuurlijk niet of dit de algemene regel is. Ik zag dit enkel gebeuren bij sommige projecten.
Klik om te vergroten...

Agile betekent niet dat je binnen een sprint werkt en niet meer werkt naar een geheel. Agile betekent dat je niet je project gaat afwerken en dan pas naar de eindgebruiker gaat om dan te zien dat je project eigenlijk niet is wat de klant wenst. Agile programming gaat er van uit dat je een systeem geleidelijk aan opbouwt en dat je na elke x aantal sprints zeker iets hebt wat werkt. Met incrementele verbeteringen toe te passen gaat het project dan naar zijn eindfase waar het volledig moet werken. Gedurende dat proces veranderen eisen toch quasi constant waardoor je nog heel makkelijk kan gaan sleutelen. Sleutelen betekent dan niet constant quick fixes toepassen, want dan kan je evengoed voor een non-agile methodologie gaan.

In totaal nieuwe projecten kan agile programming in het begin onnuttig zijn vermits je toch heel wat structurele zaken moet opzetten. Maar ook dat deel moet je tot een minimum beperken. Hoe sneller je een klant iets kan laten zien hoe meer die betrokken is en hoe beter de software zal voldoen aan zijn eisen.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan