
Geweldige woordkunstenaar is die kerel

Erg jammer dat hij is gestopt met zijn shows. Gelukkig zijn laatste show live mee mogen maken. Finkers is een van mijn helden

Daos schreef op woensdag 15 mei 2013 @ 21:04:
[...]
Ik heb Clean Code gelezen van diezelfde auteur. Hij houdt er soms wat rare denkwijzen op na. Hij is bijvoorbeeld heel negatief over commentaar en pleit voor het splitsen van algoritmes in kleine functies waardoor je de draad kwijt raakt.
Clean Code is een redelijk briljant boek, je hoeft het in een boek ook niet altijd eens te zijn met iemand

Er staan inderdaad dingen in die te ver gaan, maar het opsplitsen in kleine functies is iets wat in eerste instantie "overbodig" lijkt, maar je op termijn echt wel profijt gaat opleveren.
Zodra je kleine functies gebruikt en je houdt aan het single responsibility principe hoeft je code niet direct complexer te worden. Vaak merk je dat als je een blokje code van comment voorziet (iets als: here happens this or that) je al meerdere acties aan het uitvoeren bent in 1 functie. Als je dit stukje dan isoleert naar een eigen functie (met de naam DoThisOrThat) is direct duidelijk wat er gebeurt zonder dat je met een implementatie geconfronteerd wordt.
Sinds ik dit principe wat strenger aan het toepassen ben (check regelmatig op code complexity in Visual Studio en zorg dat ik onder een bepaald getal blijf) krijg ik korte, duidelijke en herbruikbare functies

Het is dan ineens geen pretje meer om te kijken naar code van andere mensen die vrolijk 100 regels+ in een functie ketsen (en in 1 functie heel veel (verschillende) acties uitvoeren). Probleem is dat als je daar 1 klein dingetje van wil recyclen je dat dan alsnog moet isoleren (en mensen die daar geen ster in zijn, zoals de ontwikkelaar van die betreffende code, zijn eerder geneigd een kopie te trekken van de logica).
Daarnaast vind ik het ontwikkelen met kleine functies soms ook sneller gaan omdat je de function flow al kunt opzetten (dus de onderlinge calls) zonder dat je direct de implementatie hoeft te schrijven. Je kunt dus al een heel stuk framework/bedrading neergooien. Ook testen van losse delen van je implementatie is makkelijker.
Zolang je het niet overdrijft is het maken van korte functies absoluut een verbetering van je code stijl. Uiteraard zijn er uitzonderingen waar het minder nuttig is, maar over het algemeen is het kort houden van je functies iets wat zichzelf terugbetaalt.
En de hoeveelheid functies in een class wen je aan, grotendeels is private/protected. In het begin heb je snel het gevoel van "goh wat een lading functies", maar als je eenmaal hebt ervaren wat de voordelen zijn neem je die hoeveelheid op de koop toe.
Ik hecht zelf veel waarde aan dit principe en krijg tot nu toe de meeste wel overtuigd van de kracht van dit principe. Na toepassing zijn de meeste overtuigd en je ziet direct een gedragsverandering
Heb nu Agile Principles in C# van hem liggen, heb wat hoofdstukken gemarkeerd die ik zeker wil lezen omdat die in een code review besproken werden (gelukkig deden we een groot deel al goed
). Heb het idee dat dat boekje wat taaiere stof is