1. #1

    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  

  2. #2
    SDEC's Avatar
    Registered
    13/07/10
    Location
    VL-BR
    Posts
    147
    iTrader
    0
    Mentioned
    0 Post(s)
    Reputation
    0/0
    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.
    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.
    no votes  

  3. #3
    Tyfius's Avatar
    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  

  4. #4
    passero's Avatar
    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  

  5. #5
    Cycloon's Avatar
    Registered
    18/01/04
    Location
    Melle
    Posts
    10,535
    iTrader
    56 (100%)
    Mentioned
    0 Post(s)
    Reputation
    27/102
    Quote Originally Posted by passero View Post
    This quote is hidden because you are ignoring this member. Show
    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....
    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 character
    no votes  

  6. #6
    Albireo's Avatar
    Registered
    21/10/05
    Location
    Herentals
    Posts
    1,515
    iTrader
    5 (100%)
    Mentioned
    0 Post(s)
    Reputation
    2/13
    "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  

  7. #7
    passero's Avatar
    Registered
    28/11/03
    Location
    Drongen
    Posts
    6,665
    iTrader
    5 (100%)
    Mentioned
    0 Post(s)
    Reputation
    6/28
    Quote Originally Posted by Cycloon View Post
    This quote is hidden because you are ignoring this member. Show
    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.
    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  

  8. #8
    Cycloon's Avatar
    Registered
    18/01/04
    Location
    Melle
    Posts
    10,535
    iTrader
    56 (100%)
    Mentioned
    0 Post(s)
    Reputation
    27/102
    Quote Originally Posted by passero View Post
    This quote is hidden because you are ignoring this member. Show
    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.
    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 character
    no votes  

  9. #9

    Registered
    04/11/03
    Location
    Wervik
    Posts
    1,901
    iTrader
    35 (100%)
    Mentioned
    0 Post(s)
    Reputation
    1/14
    Quote Originally Posted by Albireo View Post
    This quote is hidden because you are ignoring this member. Show
    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
    no votes  

  10. #10
    NeverwinterX's Avatar
    Registered
    27/08/04
    Location
    Leuven
    Posts
    930
    iTrader
    0
    Mentioned
    0 Post(s)
    Reputation
    11/38
    I am thee and thou art me and all of one is the other.
    TED talk: Richard Dawkins on militant atheism
    no votes  

  11. #11
    Moto's Avatar
    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 gebruiken
    no votes  

  12. #12
    Tyfius's Avatar
    Registered
    01/09/02
    Location
    Peutie
    Posts
    7,664
    iTrader
    0
    Mentioned
    4 Post(s)
    Reputation
    13/105
    Quote Originally Posted by Destiser View Post
    This quote is hidden because you are ignoring this member. Show
    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
    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  

  13. #13
    passero's Avatar
    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  

  14. #14
    Cycloon's Avatar
    Registered
    18/01/04
    Location
    Melle
    Posts
    10,535
    iTrader
    56 (100%)
    Mentioned
    0 Post(s)
    Reputation
    27/102
    Quote Originally Posted by Tyfius View Post
    This quote is hidden because you are ignoring this member. Show
    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)
    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

    Quote Originally Posted by passero View Post
    This quote is hidden because you are ignoring this member. Show
    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.
    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 character
    no votes  

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Log in

Log in