Thread: Goede programmeertechnieken
-
19-12-2011, 12:01 #1Member
- Registered
- 04/11/03
- Location
- Wervik
- Posts
- 1,901
- iTrader
- 35 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 1/14
Goede programmeertechnieken
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" (http://www.9lives.be/forum/programmi...-een-loop.html)
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?no votes
-
-
19-12-2011, 15:11 #2
Als je er een recourse van vind laat dan iets weten, zou best wel handig zijn
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
). 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.
- Definities/statische variabelen moeten altijd in hoofdletters, en elke nieuw woord liefst gescheiden door een '_'Code:int varInCamelCase = 0; (C, 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:#define MAX_IETS 300 (in C) of private static final double GETAL_PI = 3.1415; (Java)
Er zijn er nog zo veel meer, maar dit zijn toch wel de basisregels denk ik.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(); } } }no votes
-
19-12-2011, 15:27 #3Crew Member
- Registered
- 01/09/02
- Location
- Peutie
- Posts
- 7,664
- iTrader
- 0
- Mentioned
- 4 Post(s)
- Reputation
- 13/105
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.
Vanaf nu gaan we verder op BeyondGaming!
In deze thread wordt uitgelegd hoe je jouw account kan migreren.no votes
-
19-12-2011, 16:24 #4Approved 9liver
- Registered
- 28/11/03
- Location
- Drongen
- Posts
- 6,665
- iTrader
- 5 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 6/28
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....no votes
-
19-12-2011, 19:14 #5Approved 9liver
- Registered
- 18/01/04
- Location
- Melle
- Posts
- 10,535
- iTrader
- 56 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 27/102
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.“In terms of how we evaluate schooling, everything is about working by yourself. If you work with someone else, it’s called cheating. Once you get out in the real world, everything you do involves working with other people.”
PSN: Cycloon - Final Fantasy XIV: A realm reborn characterno votes
-
19-12-2011, 19:16 #6Member
- Registered
- 21/10/05
- Location
- Herentals
- Posts
- 1,515
- iTrader
- 5 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 2/13
Code Complete: A Practical Handbook of Software Construction: Amazon.co.uk: Steve McConnell: Books (inclusief hoofdstuk over loops
)
"And we wept, Precious. We wept to be so alone." --- Gollum
"Sometimes there are no words. No clever quotes to neatly sum up what happened that day. Sometimes, the day just . . . ends." --- Hotch (Criminal Minds)no votes
-
19-12-2011, 19:27 #7Approved 9liver
- Registered
- 28/11/03
- Location
- Drongen
- Posts
- 6,665
- iTrader
- 5 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 6/28
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.no votes
-
19-12-2011, 19:30 #8Approved 9liver
- Registered
- 18/01/04
- Location
- Melle
- Posts
- 10,535
- iTrader
- 56 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 27/102
In praktijk is het zelf beter ze aan je laars te lappen. Zo krijg je onderhoudscontracten die weer geld opleveren
. 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.
“In terms of how we evaluate schooling, everything is about working by yourself. If you work with someone else, it’s called cheating. Once you get out in the real world, everything you do involves working with other people.”
PSN: Cycloon - Final Fantasy XIV: A realm reborn characterno votes
-
19-12-2011, 19:51 #9Member
- Registered
- 04/11/03
- Location
- Wervik
- Posts
- 1,901
- iTrader
- 35 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 1/14
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: Booksno votes
-
19-12-2011, 20:13 #10Approved 9-lifer
- Registered
- 27/08/04
- Location
- Leuven
- Posts
- 930
- iTrader
- 0
- Mentioned
- 0 Post(s)
- Reputation
- 11/38
Amazon.com: The Pragmatic Programmer: From Journeyman to Master (9780201616224): Andrew Hunt, David Thomas: Books is naar het schijnt ook goed, zelf nog niet gelezen.
I am thee and thou art me and all of one is the other.
TED talk: Richard Dawkins on militant atheismno votes
-
20-12-2011, 01:01 #11Member
- Registered
- 17/07/02
- Location
- Wilrijk
- Posts
- 1,994
- iTrader
- 2 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 9/16
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 gebruikenno votes
-
20-12-2011, 08:26 #12Crew Member
- Registered
- 01/09/02
- Location
- Peutie
- Posts
- 7,664
- iTrader
- 0
- Mentioned
- 4 Post(s)
- Reputation
- 13/105
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-Im.../dp/0201485672 wel aanraden. (Voor zij die ReSharper ervaring hebben, zij baseren zich op dit boek.)Last edited by Tyfius; 20-12-2011 at 08:58. Reason: Fixed a typo. :o
Vanaf nu gaan we verder op BeyondGaming!
In deze thread wordt uitgelegd hoe je jouw account kan migreren.no votes
-
20-12-2011, 10:54 #13Approved 9liver
- Registered
- 28/11/03
- Location
- Drongen
- Posts
- 6,665
- iTrader
- 5 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 6/28
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.no votes
-
20-12-2011, 19:21 #14Approved 9liver
- Registered
- 18/01/04
- Location
- Melle
- Posts
- 10,535
- iTrader
- 56 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 27/102
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
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.“In terms of how we evaluate schooling, everything is about working by yourself. If you work with someone else, it’s called cheating. Once you get out in the real world, everything you do involves working with other people.”
PSN: Cycloon - Final Fantasy XIV: A realm reborn characterno votes

