programmeren H8 Programmeerprincipes.pdf

PROGRAMMEREN THEORIE H8: PROGRAMMEERPRINCIPES ENKELE BELANGRIJKE PRINCIPES 2 ONTWERPCYCLUS 1. 2. 3. 4. 5. 6. beschrijf en analyseer het probleem § wat moet het programma doen? § wat is de invoer, en wat de gewenste uitvoer? ontwerp een algoritme (pseudocode) § hoe bereik je het vooropgestelde d...

PROGRAMMEREN THEORIE H8: PROGRAMMEERPRINCIPES ENKELE BELANGRIJKE PRINCIPES 2 ONTWERPCYCLUS 1. 2. 3. 4. 5. 6. beschrijf en analyseer het probleem § wat moet het programma doen? § wat is de invoer, en wat de gewenste uitvoer? ontwerp een algoritme (pseudocode) § hoe bereik je het vooropgestelde doel? zet algoritme om in broncode (source code) § volgens syntaxisregels van gekozen programmeertaal § volgens stijlregels vertaal de broncode naar machinetaal (compile) voer het programma uit (run) spoor eventuele fouten op (debuggen) 3 TEST DRIVE DIVELOPMENT (TDD) Is een ontwikkelingsmethode waar eerst tests worden voorzien en dan pas code wordt geschreven. Dit principe werd voor het eerst beschreven door Kent Beck in 2003 en vormt een onderdeel van Agile-software ontwikkeling. De TDD ontwikkelingscyclus: § Test maken: De programmeur schrijft eerst een test, gebaseerd op een requirement, en schrijft pas dan de code. § Alle tests draaien en kijken of de nieuwe test faalt: Een test moet initieel in principe falen, aangezien het stuk code waarop deze test van toepassing is, nog niet bestaat. Het laten falen van de nieuwe test is belangrijk om na te gaan of de test effectief is (geen fouten bevat en daardoor bijvoorbeeld altijd slaagt). § Code schrijven: In deze stap wordt de daadwerkelijke code geschreven om de zojuist gemaakte test te laten slagen. Deze code mag alleen functionaliteit bevatten die nodig is om de test te laten slagen. De code hoeft niet perfect geschreven te zijn, zolang deze maar werkt. In een latere stap zal de code nog herschreven worden volgens de standaard. § Tests draaien en kijken of deze slagen: In deze stap draaien alle tests nogmaals en wordt gekeken of alle tests slagen. Is dit het geval dan is dit een goed uitgangspunt om aan de volgende stap te beginnen. § Code herschrijven (refactoring): In deze stap wordt de code opgeschoond en volgens de standaard herschreven. Ook zal eventuele dubbele code, nodig om de onderlinge afhankelijkheid van de componenten te minimaliseren, verwijderd worden. Bron : wikipedia (https://nl.wikipedia.org/wiki/Test-driven_development) 4 DON’T REPEAT YOURSELF (DRY) The DRY principe luidt als volgt : “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” zoals beschreven in “The Pragmatic Programmer” (door Andy Hunt). 5 DRY VS WET VS COPY/PASTE Het DRY principe is bedoeld om herhaling tegen te gaan in code of data. In plaats van code te herhalen, wordt code zo gemaakt dat ze op een abstracte en generieke manier alles oplost. In plaats van data te herhalen wordt data genormaliseerd. WET : We Enjoy Typing (work-around voor WET, Copy/paste programming) WET oplossingen zijn “1_stap_verwijderd” om fouten te veroorzaken door niet alle kopieën van een stuk code aan te passen als er iets moet wijzigen. Bij DRY veranderen “alle kopieën” automatisch, omdat er niets herhaald wordt. 6 COMMENTAAR IN CODE § Commentaar is bedoeld om code beter te begrijpen in een later stadium. § Commentaar in code is een belangrijk hulpmiddel § Commentaar in code is nooit een verspilling van tijd! 7 RUBBER DUCK DEBUGGING Een probleem uitleggen aan iemand kan soms resulteren in het vinden van de oplossing, ook al weet deze persoon niets van het probleem. Programmeurs gebruiken dit principe door hun probleem uit te leggen aan een rubberen eentje, om zo de oplossing te vinden. PS: Er wordt veel gezegd “programmeurs zijn nerds die geen vrienden hebben”, vandaar de behoefte aan een eendje om tegen te praten. 8 CODING CONVENTION (STIJLREGELS) § Het is belangrijk dat code goed leesbaar is. § De beste manier om code te (her)begrijpen, is door te lezen wat er gecodeerd staat. Door afspraken te maken kan leesbaarheid verbeteren. § Er zijn verschillende conventies om met code om te gaan. Deze zijn veelal afgesproken, en taal afhankelijk. § De PEP-8 styleguide is een veel gebruikte voor python. 9 DE PEP-8 STYLEGUIDE 10 TAAL VAN DE CODE § De internationale standaard van het programmeren is het Engels. § In professionele context wordt alle code steeds in het Engels geschreven. Dit omvat: commentaar, variabelenamen, namen van modules, functies, klassen, …. 11 PEP-8 STYLEGUIDE IN PYTHON Enkele belangrijke onderdelen van de PEP-8 styleguide: § Code lay-out § String quotes § Het gebruik van spaties § Commentaren § Naamgeving conventies §… https://www.python.org/dev/peps/pep-0008/ 12 CODE LAY-OUT Enkele belangrijke principes rond de lay-out van python code in PEP-8: § Het gebruik van een insprong § Maximale lengte van een lijn code § Het gebruik van lege lijnen § Imports 13 HET GEBRUIK VAN EEN INSPRONG Insprongen worden gebruikt om stukken bij elkaar horende code te groeperen. § PEP-8 maakt gebruik van 4 spaties om een insprong aan te geven. (liefst spaties en geen tabs) § Wanneer een code-lijn gesplitst dient te worden, dan probeert men de 2de regel ta alliëren met het openen van de statement. Test = lange_naam_fucntie (variabel_1, variabel_2, variabel_3, variabel_4) 14 MAXIMALE LENGTE VAN EEN LIJN CODE Alle lijnen code mogen maximum 79 tekens hebben. Dit laat het toe om meerdere vensters tegelijk open te hebben. Maak gebruik van de insprongregels om lijnen code op te splitsen. 15 LIJNEN MET OPERATOREN SPLITSEN Splits voor een binaire operator. Op die manier staan de verschillende operatoren onder elkaar en is de code makkelijker leesbaar. # No: operators sit far away from their operands income = (gross_wages + taxable_interest + (dividends – qualified_dividends) – ira_deduction – student_loan_interest) # Yes: easy to match operators with operands income = (gross_wages + taxable_interest + (dividends - qualified_dividends) - ira_deduction - student_loan_interest) 16 HET GEBRUIK VAN LEGE LIJNEN § Toplevel functie definities en klassen worden omringd door 2 lege lijnen. § De definitie van methoden binnen een klasse worden omringd door 1 lege lijn. § Lege lijnen mogen (schaars) gebruikt worden om logische secties aan te duiden. 17 IMPORTS § Elke import staat op een aparte lijn § Imports staan altijd in het begin van de file, na de commentaar van de module en voor de globale parameters en constanten van de module. § Imports moeten op de volgende manier gegroepeerd worden : 1. Standard library imports. 2. Related third party imports. 3. Local application/library specific imports. Tussen elke groep van imports moet een lege lijn staan § Andere conventies rond imports zie PEP-8 website. 18 STRING QUOTES § Zowel de enkele qoute(‘) of dubbele qoute (“) hebben dezelfde betekening is python, bij het gebruik in strings. § Kies enkel of dubbel, maar gebruik deze keuze in de ganse code. § Indien er een enkele quote of dubbele quote gebruikt wordt als karakter binnen een string, gebruik dan de andere notaties als string quote, en dit voor de ganse code. 19 HET GEBRUIK VAN SPATIES Spaties worden niet gebruikt in volgende gevallen: § Bij de start van haakjes Yes: spam(ham[1], {eggs: 2}) No: spam( ham[ 1 ], { eggs: 2 } ) § Na een eindkomma binnen haakjes Yes: foo = (0,) No: bar = (0, ) § Direct voor een komma, puntkomma of dubbelpunt Yes: if x == 4: print x, y; x, y = y, x No: if x == 4 : print x , y ; x , y = y , x 20 HET GEBRUIK VAN SPATIES Spaties worden niet gebruikt in volgende gevallen: § Direct voor de open haakjes bij een functie-oproep Yes: spam(1) No: spam (1) § Direct voor het openen van haakjes bij indexing of slicing Yes: dct['key'] = lst[index] No: dct ['key'] = lst [index] § Meer dan 1 spatie gebruiken om argumenten te alinieren Yes: x=1 y=2 long_variable = 3 No: x =1 y =2 long_variable = 3 21 COMMENTAREN (IN PEP-8) § Commentaren die een contradictie vormen op de code zijn erger dan geen commentaren. Zorg er voor dat de commentaren up-to-date zijn met de code. Indien de code veranderd, dient ook de commentaar te veranderen. § Commentaren moeten volle zinnen zijn. § Een blok commentaar bestaat uit 1 of meer paragrafen commentaar, bestaande uit volle zinnen, die elk beginnen met een hoofdletter en eindigen op een punt. § Maak gebruik van 2 spaties na de punt, op het einde van een zin, in een blok commentaar (behalve aan het einde van het blok) § Maak gebruik van klare taal! § Probeer altijd Engels te gebruiken om commentaar te schrijven. 22 NAAMGEVING CONVENTIES § Gebruik nooit “l” (kleine letter L), “O” (hoofdletter o) of ‘I” (hoofdletter I) als singelton. § Gebruik altijd code die alleen gebruik maakt van ASCII compatibele letters § Voor modules maak gebruik van kleine namen bestaande uit kleine letters § Voor klassen maak gebruik van CapWods § De namen van functies en variabelen moeten in kleine letters zijn. § … Andere conventies rond naamgeving zie PEP-8 website. 23 DESIGN PATERNS 24 WAT IS EEN DESIGN PATROON Een design patroon is een beschrijving van de oplossing die gebruikt dient te worden om software te ontwikkelen. Bij OOP bijvoorbeeld zal dit een beschrijving zijn van de klassen en de relaties tussen de klassen, objecten en methoden. Dergelijke beschrijvingen kunnen hergebruikt worden. Veel voorkomende problemen kunnen herkend worden. Door gebruik te maken van de ontwerpen die al in het verleden hun werking bewezen hebben, zal software beter presteren en minder onderhevig zijn aan fouten. 25 ONDERDELEN VAN DESIGN PATERNS De meest voorkomende onderdelen van een design pattern: § § § § § § § § § § § § § Patroonnaam en indeling Doel Ook bekend als Motivering Toepasbaarheid Structuur Rollen Collaboraties Gevolgen Implementatie Voorbeeldcode Bekende toepassingen Gerelateerde patronen 26 N-TIER N-tier is eigenlijk een verhaal over (software) architectuur. N-tier is ontstaan uit het idee dat software op te delen is in meerdere componenten of lagen (tiers) die met elkaar samenwerken om tot een oplossing te komen. § Elke tier heeft een duidelijk omschreven functionaliteit. § Elke tier kan individueel getest worden en eventueel hergebruikt worden in andere software. § Tiers kunnen een rol spelen bij het beveiligen van onderdelen van een applicatie. § Elke tier kan vervangen worden door een nieuwe tier met dezelfde functionaliteit (bijvoorbeeld een nieuwe/ andere gebruikersinterface) 27 3-TIER Een veel gebruikte vorm van n-tier architectuur is een 3tier architectuur. § De presentatie-laag: gebruikersinterface § De applicatie-laag: de ontwikkelde software § De data(base)-laag: de toegang tot de databank. 28 N-TIER EN BEVEILIGING Tiers of lagen kunnen op aparte toestellen (servers) draaien. Wanneer die toestellen zo worden geconfigureerd dat ze gescheiden zijn binnen het netwerk (door bijvoorbeeld een firewall) kan dus een grotere graad aan beveiliging gegarandeerd worden. 29 MODEL-VIEW-CONTROLER MODEL (MVC) MVC is een design model dat vertrekt van 3 modellen met elk hun eigen verantwoordelijkheid. § Model Definieert de representatie van de informatie waarmee de applicatie werkt. Aan ruwe gegevens wordt betekenis gegeven door relaties tussen data en logica toe te voegen. § View Informatie wordt weergegeven via de View. Userinterface-elementen zullen gedefinieerd zijn in dit onderdeel. § Controller De controller verwerkt en reageert op events, die meestal het gevolg zijn van handelingen van de gebruiker Bron : wikipedia 30 MVC WERKING De gebruiker heeft contact met de view. De view geeft de gegevens door naar de controller. De controller verwerkt de gegevens. De verwerkte gegevens worden doorgegeven aan het model. Het wordt afgeraden om de view rechtstreeks te koppelen aan het model. Bron : wikipedia 31 LIBRARIES 32 LIBRARIES “Don't Reinvent The Wheel, Unless You Plan on Learning More About Wheels” § Vele software-toepassingen zijn algemeen en werden al door anderen geprogrammeerd. § Gebruik deze zo veel mogelijk. § Je hoeft niet te weten hoe deze gecodeerd zijn, maar enkel gebruikt worden (encapsulation principe). 33 INTERESSANTE PYTHON LIBRARIES: § § § § § § § § § Numpy (geavanceerde wiskundige functionaliteiten) Pandas (data analyse) scikit learn (machine learning) Matplotlib (grafieken) Tensorflow (neurale netwerken) Flask (html) Django (webapplicaties) Beautiful Soup (web scraping) … 34 REGELS VAN HET PROGRAMMEREN 35 RULES OF PROGRAMMING 1. Think before you program! 2. A program is a human-readable essay that happens to execute on a computer. 3. The best way to improve your programming skills is to practice! 4. A foolish consistency is the hobgoblin of little minds. 5. Test your code, often and thoroughly! 6. If it was hard to write, it is probably hard to read. Add a comment. 7. All input is evil until proven otherwise. 8. A function should do one thing. 9. Make sure your new class does the right thing. 36 THEORIE: Len Lemeire Hoofdlector EB24 Henleykaai 84, 4G08 [email protected] PRAKTIJK : Els Clarysse : [email protected] Ghent University @ugent Ghent University