[alg] Herschrijven brakke code collega's?

[Verwijderd]

Een aantal van mijn collega's zijn van het type "als het werkt, dan werkt het", en anderen (meestal diegene met minder ervaring of minder gevoel voor techniek), produceren gewoon altijd code wat kwa structuur gewoon niet klopt, ook al proberen ze expliciet om het netjes te doen.

Altijd als ik commits van gare code in onze cvs zie binnenkomen dan jeukt het bij me om gewoon het hele stuk direct zelf overnieuw te gaan schrijven en meteen te comitten.

Zijn er hier mensen die dat ook kennen en hoe gaan jullie hier mee om?

ps, dit topic is niet bedoeld als bad code example topic, daar loopt namelijk al een draadje over. Het gaat hier primair hoe je in een team werkt als je zelf gefocussed bent op de goede structuur maar de anderen dit telkens nalaten. Of mischien zijn ervaringen andersom wel interesant: ben -jij- zo'n type die altijd brakke structuren produceert en erger je je groen en geel aan die betweterige collega die telkens jou code zit te vervangen?

[The Eagle]

Wij werken hier in een team van 10 beheerders / developpers, met elk hun eigen specialiteit op het gebied van PeopleSoft. Wij hebben onderling de afspraak gemaakt (al wordt die niet altijd nageleefd) dat de een standaard het werk van de andere nakijkt voordat het in productie gaat. Daar hoort code-controle in principe gewoon bij. Gooi iets dergelijks eens in de groep daar zou ik zeggen, veel van je collega's zullen het wel met je eens zijn dat een extra check nooit kwaad kan

[momania]

Ik heb het wel met code die door een andere collega is gemaakt en ik moet er later defects in op gaan lossen. Zolang het werkt en er hoeft niets meer aan te worden gedaan, laat ik het wel voor wat het is (behalve als het heel weinig code is, dan kan ik het toch niet weerstaan om het 'netjes' te maken )

In geval van de defects oplossen:
Als het echt brakke code is en iemand heeft zich ook niet echt aan de van te voren afgesproken standaard gehouden qua stuctuur/architectuur/etc dan ben ik idd ook zo'n persoon die de hele boel gewoon opnieuw schrijft.

[defusion]

Ik ben zelf van het type "jong, weinig ervaring, maar wel een technische knobbel"
ik werk bij een reisbureau, en doe hier wat perl en php coding (website + parse-scripts voornamelijk)
en doe wat algemeen systeembeheer op de bedrijfs-servers, en de desktops

degene die hier voor mij zat heeft de site gemaakt, en heeft dat redelijk netjes gedaan, en daar doe ik ook gewoon netjes aan mee. Maar laatst had de baas om eens wat te testen een extern bedrijf ingeschakeld dat totaal niet wist hoe wij werkten, en heeft die een script laten maken. Dit script werkt totaal niet samen met de andere scripts, en veranderingen inbrengen zijn ontzettend lastig. Het is iets van 1200 regels code, en ik ben uit ergernis maar begonnen met het herschrijven van de code, en heb de baas aangeraden dat niet meer te doen

[naruto]

refactoring is het antwoord.

maar ja ben nog maar sinds kort met dit "techniek".

[Verwijderd]

Er moet een balans zijn tussen mooie structuren en effectief werken, en hoe die balans ligt is zeer afhankelijk van de omgeving, het soort project e.d. Je hebt bijna overal mensen aan beide kanten zitten, dus de perfectionistische techneuten en de slordige pragmatisten. Om goed en effectief te werken moeten die samen werken, dus polariseren helpt niet. Helaas zie je vaak dat de cultuur 1 bepaalde kant aanhangt en de andere kant verkettert.

De leidinggevende (lead developer) heeft een grote hand in deze balans, en moet leiden door een goed voorbeeld te geven. Daarbij moet er natuurlijk wel een minimale kwaliteitstandaard zijn, die af en toe met harde hand moet worden afgedwongen. Denk dan aan naamconventies uit een standaard document, goed gebruik van source control systemen (alleen code die goed compileert inchecken e.d.), en ga zo maar door. Ook kunnen tools erg helpen om de standaarden hoog te houden, zoals code formatting tools, goede IDE's, etc. Bovendien kun je je technische ontwerpen wat gedetailleerder maken om mensen die niet goed in structuren (kunnen) denken te helpen met het goed opzetten van code.

Daarnaast moet je ook bedenken dat je een gezamelijk nivo moet bereiken en dat ook de slordige mensen een belonend gevoel moeten hebben bij het verbeteren van de kwaliteit van hun werk. Als je direkt verwacht dat ze op een hoog technisch nivo zullen komen, zal er alleen teleurstelling zijn. Verder schieten techneuten soms ook veel te ver door in het maken van kunstwerken van een stukje code. Uiteindelijk is code een middel tot een doel (nl. een werkend programma) en niet een doel op zich (estetisch mooie architectuur, patterns mooi uitgewerkt, schaalbaarheid van een enterprise applicatie voor een simpel intranetje, etc). Dus het feit dat code gewoon werkt is soms helemaal niet zo slecht, zolang het nut van verbeteringen niet op relatief korte termijn in geld is uit te drukken.

Over het algemeen is mijn code redelijk netjes, maar ik ben wat pragmatischer geworden dan ik vroeger was. Ik was altijd veel te veel tijd bezig om te dromen over alle mooie dingen die ik ervan zou kunnen maken, waardoor ik soms te weinig tijd nam om het gewoon simpel, goed en effectief te maken.

[Serpie]

Hier wordt de code altijd gereviewed samen met een andere collega, per project is er minimaal 1 beheerder. Deze weet hoe het project in elkaar zit en hoe de structuur in elkaar zit. Als er iets niet klopt kan deze netjes een advies geven, bijvoorbeeld hoe hij het beter zou kunnen doen.

Dit heeft als voordeel dat degene die de brakke code schrijft daar ook van leert (als het goed is) en de volgende keer minder brakke code zal produceren.

Nieuwe projecten worden alleen opgepakt door de capabele programmeurs, die kunnen dan de eerste structuren opzetten. Later kunnen wijzigingen door iedereen gedaan worden, deze wijzigingen worden dus weer met de beheerders doorgenomen.

[pjonk]

Uit ervaring kan ik zeggen dat krappe deadline's nogal uitnodigen tot een Quick & Dirty programmeerstijl. Daarbij is het noodzakelijk om als bedrijf over een goed programming Framework te beschikken waardoor de code consistenter en volgens bedrijfs/programmeer standaarden kan worden opgebouwd.

[RedRose]

Verwijderd schreef op donderdag 21 juli 2005 @ 16:43:

Mooi antwoord. Daar wil ik nog graag aan toevoegen dat communicatie erg belangrijk is. Ga met zn allen om de tafel zitten en kaart dingen rustig aan. Werk samen aan een goede coding-standaard. Dan ben je heel eind, alhoewel dat waarschijnlijk wel redelijk wat tijd in beslag neemt. Neem die tijd, scheelt je later een hoop frustraties.

[ Voor 72% gewijzigd door ACM op 22-07-2005 13:23 ]

[Michali]

Je kunt idd iets snel opzetten of iets goed uitdenken. Maar een tekort aan tijd vind ik geen reden om hele lappe code te dupliceren of systematisch variable namen als 'tmp', 'inputVar', 'v' en 'p' te gebruiken. Dat is imo gewoon slecht prog werk. Een beetje denken aan de leesbaarheid en en begrijpelijkheid van je code neemt niet zo veel tijd in beslag en je wint er vrijwel altijd op een ander tijdstip wel tijd mee.

[pjonk]

Michali schreef op vrijdag 22 juli 2005 @ 12:20:
Je kunt idd iets snel opzetten of iets goed uitdenken. Maar een tekort aan tijd vind ik geen reden om hele lappe code te dupliceren of systematisch variable namen als 'tmp', 'inputVar', 'v' en 'p' te gebruiken. Dat is imo gewoon slecht prog werk.

Als ervaren programmeur zou ik dit ook nooit doen, maar voornamelijk de minder ervaren programmeur zal hiermee sneller de fout in gaan als hij te weinig tijd krijgt voor zijn klus.

Een beetje denken aan de leesbaarheid en en begrijpelijkheid van je code neemt niet zo veel tijd in beslag en je wint er vrijwel altijd op een ander tijdstip wel tijd mee.

Zaken als validatie en error logging programmeren is belangrijk en kost veel tijd. Dit soort zaken worden maar al te vaak achterwege gelaten wegens gebrek aan tijd. Dan zit je klant op dat moment dus met een unstabiele applicatie en moet je 'm weer updates gaan sturen omdat ineens blijkt dat allerlei errors niet afgevangen zijn.

[Soultaker]

Ik ben het wel grotendeels eens met Mr. X: je moet niet willen dat alles precies zo eruit ziet als jij zou willen, ook al zijn daar wel goede argumenten voor. Het is voor je collega's waarschijnlijk ontzettend frustrerend als de code die ze schrijven direct door jouw herschreven wordt.

Ik heb zelf ook wel gewerkt aan code die door een ander geschreven is en ik beperk me dan altijd tot het oplossen van bugs; als een functie niet werkt zoals zou moeten dan pas ik 'm aan (en dan reviseer ik vaak de hele body, dus ook andere rariteiten), maar als de functie doet wat 'ie moet doen zonder heel inefficent te zijn, dan blijf ik er gewoon vanaf.

Dat is een beetje een 'als het werkt, dan werkt het' mentaliteit, maar om werk gedaan te krijgen is het niet zo'n heel gek uitgangspunt: je hebt functies en klassen die een bepaald gedrag moeten vertonen; als ze dat doen is de implementatie niet zo belangrijk. Die code gaan herschrijven is dan niet direct productief.

Overigens is het natuurlijk wel een goed plan om te proberen de geschreven code naar een hogere kwaliteit te krijgen, maar zorg dan dat je het samen aanpakt, door bijvoorbeeld elkaar's code te reviewen. Zorg in ieder geval dat je iedereen er bij betrekt en dat jij niet gaat bepalen hoe anderen moet werken, want daarmee jaag je ze alleen maar tegen je in het harnas.

[jelmervos]

Wij werken vaak in tweetallen die veel veranderen van samenstelling. Dit zorgt ervoor dat code niet compleet hoeft worden herschreven, maar dat mensen direct wat leren van mensen die het beter weten. Hiermee voorkom je ook dat je bezig blijft met het herschrijven van code. Ook is het de regel dat een oplossing zo simpel mogelijk moet worden gemaakt, als het in de toekomst nodig is om het uit te breiden, dan zien we dat dan wel weer. Natuurlijk moet er gerefactored worden.

[ Voor 9% gewijzigd door jelmervos op 23-07-2005 11:59 ]

[flowerp]

Soultaker schreef op vrijdag 22 juli 2005 @ 14:26:
Ik ben het wel grotendeels eens met Mr. X: je moet niet willen dat alles precies zo eruit ziet als jij zou willen, ook al zijn daar wel goede argumenten voor. Het is voor je collega's waarschijnlijk ontzettend frustrerend als de code die ze schrijven direct door jouw herschreven wordt.

Inderdaad. Die frustratie is er zeker. Veel mensen die aan een programmeurs baan voor de eerste keer beginnen hebben al vaak veel voor hun zelf geprogrammeerd. Je denkt dat je het goed weet, maar als je dan telkens commentaar krijgt op je code werkt dat niet echt bemoedigend.

Maar als een collega met meer ervaring of hogere opleiding mijn code herschrijft en me dan uitlegt op welke punten ik het beter had kunnen doen, dan is dat een goede leerervaring. Zeker als dit een beetje vriendelijk gebeurd. Als ik iets incheck en 20 minuten doe ik een update en er komt meteen zo zonder commentaar een geheel herschreven versie van mijn code binnen dan denk ik ook WTF! Maar als ik nu een mailtje krijg met als attachment de herschreven versie en wat uitleg waarom dat beter is of zoiets, dan komt dat veel beter over.

Moeilijker wordt het als 2 of meer mensen in een team het fundamenteel oneens zijn met elkaar. In het bedrijf waar ik nu werkzaam ben zitten 2 van dergelijke personen. De ene is van de lijn netjes en volgens standaards/regels, terwijl de andere een soort hippie is die juist de schurft heeft aan alles wat maar aan regels en structuur doet denken. En dan moet ik als zogenaamd neutraal persoon af en toe een mening geven

[EfBe]

Verwijderd schreef op donderdag 21 juli 2005 @ 15:29:
Een aantal van mijn collega's zijn van het type "als het werkt, dan werkt het", en anderen (meestal diegene met minder ervaring of minder gevoel voor techniek), produceren gewoon altijd code wat kwa structuur gewoon niet klopt, ook al proberen ze expliciet om het netjes te doen.

En wie bepaalt wat juiste structuur is? Jij? Of een boekje, of een gezamelijke afspraak?

Altijd als ik commits van gare code in onze cvs zie binnenkomen dan jeukt het bij me om gewoon het hele stuk direct zelf overnieuw te gaan schrijven en meteen te comitten.

Dan dicht je jezelf een bepaald inzicht toe die wellicht niet aanwezig is of in mindere mate dan jij denkt. Ik ken geen developer, mijzelf incluis, die andermans code echt mooi vindt, gemiddeld gezien. Iedere developer waar ik mee gewerkt heb of die ik ken vind veelal andermans code maar niks of er mankeert altijd wel wat aan.

Zijn er hier mensen die dat ook kennen en hoe gaan jullie hier mee om?

Het willen corrigeren van andermans code is IMHO een slechte zaak. Je moet met de personen die die slechte code in JOUW ogen produceren gaan discussieren wat hun ontwerp was, wat de ontwerpbeslissingen waren en dus inzicht leren krijgen in waarom ze de code zo hebben geconstrueerd. Het is nl. zo dat een willekeurig stukje code-text maar EEN implementatie is van de functionaliteit die het representeerd en niet DE.

Wellicht dat jouw collega's een bepaalde stap niet zetten of een bepaalde connectie niet maken waardoor hun implementatie dan wel werkt maar niet van topkwaliteit is. Door over de ACHTERLIGGENDE beslissingen te discussieren (en dat is dus niet over code statements en andere narigheid) krijg jij inzicht in hun denkpatroon en krijgen zij wellicht kennis mee die zij niet bezitten maar die jij jezelf wel toedicht.

ps, dit topic is niet bedoeld als bad code example topic, daar loopt namelijk al een draadje over. Het gaat hier primair hoe je in een team werkt als je zelf gefocussed bent op de goede structuur maar de anderen dit telkens nalaten. Of mischien zijn ervaringen andersom wel interesant: ben -jij- zo'n type die altijd brakke structuren produceert en erger je je groen en geel aan die betweterige collega die telkens jou code zit te vervangen?

Nou, er is niets erger dan een betweterige programmeur, dat kan ik je wel vertellen. Het is nl. totaal irrelevant hoe code eruit ziet.

Ooit code van Carmack bekeken? Indien nee, moet je eens doen, bv de Q1 source. Je schrikt je een hoedje hoe goor die code is en je vraagt je werkelijk af waarom het niet mooier is opgezet. En dat terwijl meneer Carmack op handen wordt gedragen en een 'top programmeur' genoemd wordt. De reden is simpel: de code is niet bedoeld om mooi te zijn, maar om snel te zijn en hoeft niet 10 jaar mee maar 1 jaar. Een randvoorwaarde die dus bepaalde restricties minder belangrijk maakt en dat soort randvoorwaarden heb je wellicht in jouw project ook. Als je bv aan een web applicatie werkt, weet je dat die code echt geen 10 jaar mee hoeft. Als jij wel zo je code opzet, ben je wellicht teveel werk aan het doen (voorbeeld), terwijl jouw collega's dat niet doen. Je krijgt dan wrijving terwijl dat nergens voor nodig is.

En doe iets aan dat ego, Henk, 1 Juval Lowy is meer dan genoeg

[EfBe]

flowerp schreef op zaterdag 23 juli 2005 @ 13:07:
Inderdaad. Die frustratie is er zeker. Veel mensen die aan een programmeurs baan voor de eerste keer beginnen hebben al vaak veel voor hun zelf geprogrammeerd. Je denkt dat je het goed weet, maar als je dan telkens commentaar krijgt op je code werkt dat niet echt bemoedigend.

Commentaar op code is zo onzinnig. Commentaar op achterliggende gedachtes omtrent de code, zoals class design bv, dat is belangrijk, maar dat is eigenlijk code onafhankelijk. Je kunt flaws in iemand's inzicht herkennen door naar code te kijken, maar de code is niet meer dan een voorbeeld voor de discussie die dan kan volgen, niet de reden noch waar de discussie over moet gaan.

Maar als een collega met meer ervaring of hogere opleiding mijn code herschrijft en me dan uitlegt op welke punten ik het beter had kunnen doen, dan is dat een goede leerervaring.

Ik zie niet in waarom dat een goede leerervaring is, het is hooguit een domper voor je eigen zelfvertrouwen. Daarom vind ik ook dat men niet in andermans code mag zitten, maar hooguit bij anderen zou moeten aankaarten (bv in een wekelijks overleg) mbv kennisoverdracht waarom iets beter is, maar niet op basis van een stukje code, maar op basis van een algemeen voorbeeld. Iemand's while loops vervangen door for loops omdat while loops minder compact zijn en Wirth-esk is bv onnozel, of het opdelen van een method in 2 methods. Blijf er met je tengels vanaf! Who died and made you god! denk ik dan.

Zeker als dit een beetje vriendelijk gebeurd. Als ik iets incheck en 20 minuten doe ik een update en er komt meteen zo zonder commentaar een geheel herschreven versie van mijn code binnen dan denk ik ook WTF! Maar als ik nu een mailtje krijg met als attachment de herschreven versie en wat uitleg waarom dat beter is of zoiets, dan komt dat veel beter over.

Nou ik zou zoiets dus nooit pikken. Als jij je best doet en iemand anders denkt dat beter te kunnen, dan doet die persoon de rest ook maar, waarom zou jij je uitsloven, die ander verbetert je toch. En wie is die persoon nu helemaal, zometeen introduceert DIE persoon een bug in JOUW code.

Jij doet werk, JIJ bent verantwoordelijk voor jouw werk. Heb je een bug in JOUW code, dan verbeter JIJ de code die JIJ geschreven hebt, tenzij je speciaal daarvoor aangestelde helpdesk mensen hebt, die dat mogen en dan ook automatisch verantwoordelijk worden voor de code die zij hebben aangepast.

Overleg waarom iemand wat doet en waarom hij/zij denkt dat dat niet goed is. Ik kom zo vaak mensen tegen die tegen mij zeggen "dit is niet goed blablabla" en dan denk ik.. "nee, JIJ vindt dat niet goed want ..., maar ik vind het wel goed want ....". En dan ontstaat er een discussie, waarbij ik soms denk "zit wat in, ga ik de volgende keer meenemen", of de ander denkt "ok, ik zag het verkeerd, of mistte de context (!) waarin het wordt gebruikt". DAAR heb je wat aan. Je hebt geen fluit aan betweterige knoeiers die met hun tengels aan andermans code zitten omdat zij holier than the rest zijn.

Moeilijker wordt het als 2 of meer mensen in een team het fundamenteel oneens zijn met elkaar. In het bedrijf waar ik nu werkzaam ben zitten 2 van dergelijke personen. De ene is van de lijn netjes en volgens standaards/regels, terwijl de andere een soort hippie is die juist de schurft heeft aan alles wat maar aan regels en structuur doet denken. En dan moet ik als zogenaamd neutraal persoon af en toe een mening geven

Dan loop je naar je manager en geeft dit aan. Als de manager dat dan niet oplost is het niet meer jouw probleem. Je werkt in een organisatie met mensen die meer dan jou verdienen omdat ze meer verantwoordelijkheid hebben. Gebruik die organisatie en die mensen om jouw problemen op te lossen, daarvoor krijgen ze meer geld en hebben ze meer verantwoordelijkheid.

En stop met het pikken van hufterige acties als dat ze jouw code verbeteren!

[Alarmnummer]

EfBe schreef op zaterdag 23 juli 2005 @ 13:27:
Dan dicht je jezelf een bepaald inzicht toe die wellicht niet aanwezig is of in mindere mate dan jij denkt. Ik ken geen developer, mijzelf incluis, die andermans code echt mooi vindt, gemiddeld gezien. Iedere developer waar ik mee gewerkt heb of die ik ken vind veelal andermans code maar niks of er mankeert altijd wel wat aan.

Van de code die ik bekijk van andere 'bekendere' programmeurs mankeerd ook wel eens iets. Maar er zijn een paar bekende java developers waarbij ik meestal erg blij ben als ik hun code zie. Ipv dat ik veel kritiek op hun code lever, probeer ik te kijken wat ik er nog van kan leren. Wat ik wil zeggen is dat er wel bepaalde vormen van code zijn die ik prettig vind werken. Code van Doug Lea of Joshua Bloch (uit de JDK`s) en bv code van het Spring-framework (alhoewel daar ook wel eens vieze uitwassen in zitten)

Het willen corrigeren van andermans code is IMHO een slechte zaak. Je moet met de personen die die slechte code in JOUW ogen produceren gaan discussieren wat hun ontwerp was, wat de ontwerpbeslissingen waren en dus inzicht leren krijgen in waarom ze de code zo hebben geconstrueerd.

Nu ga jij ervanuit dat iedereen goed nadenkt over zijn code. Dat is niet altijd zo. Soms is code gewoon slecht opgezet omdat het in elkaar geplakt is zonder goed na te denken. En verder wil code wel eens 'groeien' zonder dat mensen de centrale gedachte erachter zien (als die er uberhaubt al geweest is).

Nou, er is niets erger dan een betweterige programmeur, dat kan ik je wel vertellen. Het is nl. totaal irrelevant hoe code eruit ziet.

Ben ik niet met je eens. Hoe code geschreven is, is behoorlijk belangrijk omdat het ook onderhouden en eventueel uitgebreid moet worden. Ik heb vaak genoeg slechte code volledig wegeknikkerd en (sub)systemen opnieuw opgezet omdat het te rampzalig was om uberhaubt nog iets van te maken. Tel dan je totale kosten eens bij elkaar op
1) schrijven van slechte code
2) komt extreem veel tijd te zitten in het onderhoud
3) het uiteindelijk gaan vervangen door iets beters.
In 1e instantie zijn je kosten misschien lager, maar zo gauw je langer met een systeem bezig moet dan kan je het denk ik beter in 1 keer goed opzetten.
Ik zie slechte code als een indicatie van een slecht systeem.

Als je bv aan een web applicatie werkt, weet je dat die code echt geen 10 jaar mee hoeft. Als jij wel zo je code opzet, ben je wellicht teveel werk aan het doen (voorbeeld), terwijl jouw collega's dat niet doen. Je krijgt dan wrijving terwijl dat nergens voor nodig is.

Ik probeer ook wel eens te 'knoeien' maar het gaat me slecht af. Ik zie het dan niet meer en na verloop van tijd kom ik volledig vast te zitten omdat ik niet meer begrijp wat er gebeurt. Verder begin ik de plezier in het ontwikkelen dan ook te verliezen omdat ik niet blij ben met hetgeen wat ik doe.

Soms kwak ik ook wel eens iets simpels in elkaar onder het motto: gaan met die banaan. Maar dit zal alleen in de buitenste randen van een systeem plaatsvinden. Ik wil uitspraken kunnen doen over een systeem en daarvoor heb je heldere structuren nodig (vooral als je met complexe problematiek bezig bent). Herbruikbaarheid zijn in de buitenste randen van een systeem ook veel minder een belangrijk issue.

[ Voor 18% gewijzigd door Alarmnummer op 23-07-2005 14:39 ]

[EfBe]

Alarmnummer schreef op zaterdag 23 juli 2005 @ 14:26:
[...]
Van de code die ik bekijk van andere 'bekendere' programmeurs mankeerd ook wel eens iets. Maar er zijn een paar bekende java developers waarbij ik meestal erg blij ben als ik hun code zie. Ipv dat ik veel kritiek op hun code lever, probeer ik te kijken wat ik er nog van kan leren. Wat ik wil zeggen is dat er wel bepaalde vormen van code zijn die ik prettig vind werken. Code van Doug Lea of Joshua Bloch (uit de JDK`s) en bv code van het Spring-framework (alhoewel daar ook wel eens vieze uitwassen in zitten)

Ik ken die personen niet, maar de enige sourcecode die ik ooit gezien heb waar ik echt van onder de indruk was was de semaphore-less concurrent thread scheduler van Dijkstra.

Let wel: het was een puik stukje code. Maar verder vind ik dat als code niet saai is om te lezen er wellicht wat te versimpelen valt.

Komt wellicht verkeerd over, maar ik ben dan ook geen schrijver

[...]
Nu ga jij ervanuit dat iedereen goed nadenkt over zijn code. Dat is niet altijd zo. Soms is code gewoon slecht opgezet omdat het in elkaar geplakt is zonder goed na te denken. En verder wil code wel eens 'groeien' zonder dat mensen de centrale gedachte erachter zien (als die er uberhaubt al geweest is).

Maar wat is 'slecht opgezet' dan? Jij gaat er dan vanuit dat je met het kijken naar code het ontwerp en de denkpatronen erachter kunt achterhalen, maar dat is IMHO een grote vergissing. Als jij denkt dat jij dat kunt, kijk dan maar eens in de Hibernate sourcecode en probeer te ontwaren waar de functionaliteit zit die bepaalt welke instance te creeeren bij een hierarchical fetch.

Omdat dat gewoon te lastig is voor een mens, kijk je naar onderdelen van een groter iets, en kun je wellicht conclusies trekken als "wat een gore troep", terwijl het helemaal niet een gore troep is.

[...]
Ben ik niet met je eens. Hoe code geschreven is, is behoorlijk belangrijk omdat het ook onderhouden en eventueel uitgebreid moet worden. Ik heb vaak genoeg slechte code volledig wegeknikkerd en (sub)systemen opnieuw opgezet omdat het te rampzalig was om uberhaubt nog iets van te maken.

Maar wat was dan rampzalig: het ontwerp of de code die als resultaat dient van dat ontwerp? Want code moet wel onderhouden worden, maar met een goed ontwerp en ditto projectie van ontwerp op code is er geen probleem.

Ik zie slechte code als een indicatie van een slecht systeem.

Nee, slechte code is ten eerste subjectief en kan worden gebruikt als aanduiding van een slechte implementatie van een ontwerp, maar alleen na grondige analyse.

[...]
Soms kwak ik ook wel eens iets simpels in elkaar onder het motto: gaan met die banaan. Maar dit zal alleen in de buitenste randen van een systeem plaatsvinden. Ik wil uitspraken kunnen doen over een systeem en daarvoor heb je heldere structuren nodig (vooral als je met complexe problematiek bezig bent). Herbruikbaarheid zijn in de buitenste randen van een systeem ook veel minder een belangrijk issue.

Je hebt heldere structuren in je ontwerp nodig, of beter: je hebt een helder ontwerp nodig, waarin dingen zijn afgewogen en beslissingen zijn verwoord met de redenen voor die beslissingen. Als je heldere code hebt, prima, maar 'heldere code' of 'begrijpelijke code' is afhankelijk van in hoeverre de lezer van de code begrijpt wat de context is van die code. Carmack's BSP traversal routine is onbegrijpelijke rotzooi voor mensen die niets snappen van bsp trees. Voor mensen die het wel snappen kan het mooie code zijn.

(edit)
Verder worden hier 'buggy troep' en 'werkende troep' doorelkaar gehaald. Slechte code die buggy is of bug-gevoelig is slecht, en dat weten we allemaal wel (zie thedailywtf.com voor voorbeelden). Werkende code die 'beter kan' is iets heel anders en daar gaat het hier om IMHO. waar dat 'beter' op gebaseerd is is IMHO subjectief, vandaar dat ik zei: "slechte code is subjectief".

[ Voor 7% gewijzigd door EfBe op 23-07-2005 14:56 ]

[pjonk]

Alarmnummer schreef op zaterdag 23 juli 2005 @ 14:26:
Ben ik niet met je eens. Hoe code geschreven is, is behoorlijk belangrijk omdat het ook onderhouden en eventueel uitgebreid moet worden. Ik heb vaak genoeg slechte code volledig wegeknikkerd en (sub)systemen opnieuw opgezet omdat het te rampzalig was om uberhaubt nog iets van te maken. Tel dan je totale kosten eens bij elkaar op
1) schrijven van slechte code
2) komt extreem veel tijd te zitten in het onderhoud
3) het uiteindelijk gaan vervangen door iets beters.
In 1e instantie zijn je kosten misschien lager, maar zo gauw je langer met een systeem bezig moet dan kan je het denk ik beter in 1 keer goed opzetten.
Ik zie slechte code als een indicatie van een slecht systeem.

Helemaal mee eens. Ik heb complete programma's en procedures (voornamelijk VB6 code) van ex-collega's herschreven omdat de code niet te onderhouden was of voor geen meter performd.
Sommige mensen presteren het om procedures van 1000 regels code te schrijven. Dan hoeft er IMHO niet eens discussie gevoerd te worden of dit goed of fout is. Het gaat trouwens vaak niet om de code zelf, maar meer de programmastructuur.
Als je in een team werkt is het IMHO vanzelfsprekend dat er eerst overleg gevoerd wordt voor je iets gaat herschrijven.

[Verwijderd]

De code is vaak het probleem niet. Die kan chaotisch, ongestructureerd en onefficient zijn, zonder dat dit problemen hoeft op te leveren. Het geheim heet 'documentatie' en op dat vlak ontbreekt er vaak veel.

Zo heb ik wel eens een stuk code herschreven wat an-sich wel werkte, maar men wilde er een uitbreiding op hebben (change request). De code in kwestie besloeg uitgeprint 15 pagina's A4, en er stond geen enkel regeltje commentaar in, noch was er documentatie van aanwezig. Daarnaast was het niet tot nauwelijks gestructureerd, er zaten zelfs her en der enkele 'goto' commando's in verwerkt.

Op zo'n moment heb je nog maar 1 optie; herschrijven. En dan zie je het nut van 'goede' code (er zal ongetwijfeld nog wel wat mis geweest zijn met wat ik gemaakt had). Ik kwam uit op code van uitgeprint 3 pagina's A4. Het geheel was leesbaar, voorzien van commentaar en documentatie. Die code wordt nu nog steeds (5 jaar later) gebruikt, en er zijn al diverse uitbreidingen op gemaakt zonder problemen.

Dat is een schoolvoorbeeld van 'beide broncodes werkten prima, maar toch was de ene evil'.

Als je een grafiek tekent van projecttijd verstreken en reparatiekosten, dan loopt die bijna exponentieel op. Naarmate een project verder gevorderd is, worden de reparatiekosten hoger.

Een heel simpel voorbeeldje is identatie. Stel jij hebt zo'n constructie:

PHP:

if () then {
  if () then { if () then {
               }
            else 
    { if () then {
    }
}

Zie dan nog maar eens de fout te vinden. Nu is dit in dit geval nog makkelijk, omdat er geen code tussen staat. Het kan dan wel werken en je zult de fout uiteindelijk wel vinden, maar dan ben je wel een uurtje verder.

Dat kan ook anders:

PHP:

if () then 
  { if () then 
      { if () then 
            {     
         else 
            { if () then 
                {
                }
            }

Dezelfde code, maar hier zie je praktisch in één oogopslag wat er mis is. 1 minuut debuggen en je bent klaar.

Refactoring (= het herschrijven van 'bad' code) kan daarom wel redelijk nuttig en kostenefficient zijn. Je bent minder tijd kwijt met debuggen en de programmeurs hebben meer lol in hun werk. Dit ongeacht of de broncode nu wel of niet functioneert.

[ Voor 8% gewijzigd door Verwijderd op 23-07-2005 15:35 ]

[flowerp]

EfBe schreef op zaterdag 23 juli 2005 @ 13:39:
Ik zie niet in waarom dat een goede leerervaring is, het is hooguit een domper voor je eigen zelfvertrouwen.

Nu ben ik niet zo'n enorme prof als sommige van de regulars hier, dus mischien haal ik zelf wel wat jullie structuur en code noemen door elkaar.

Iniedergeval toen ik lange tijd geleden voor het eerst stage liep moest ik wat in een web applicatie (J2EE) toevoegen. Ik had toen wat java code op de pagina gezet en aan de hand van request.getParameter() calls op de pagina keek ik wat ik moest doen. Ter plekke in de code controlleerde ik dan nog een beetje of de waardes wel klopte.

Iemand die al wat langer met web applicaties werkte heeft toen de java code die ik op de page gezet had in een bean gestopt, en onderverdeeld in functies, toen 2 functies bij geschreven: 1tje die eerst alle opgegeven waardes controlleerd, en een andere die aan de hand van 1 enkele page parameter (action) bepaalde welke functie aageroepen zou gaan worden. Op de pagina zelf stonden alleen nog maar hele simpele JSTL regels en html.

De eigenlijke logica van mij was niet veranderd (enkele suffe dingetjes stonden er ook nog gewoon in), het was alleen anders opgedeeld. Deze hele simpele structuur gebruik ik nu nog steeds in projecten waar men geen JSF, Struts, enz kan gebruiken.

Als stagiare of beginner zijnde vind ik zowieso logisch dat een meer ervaren programmeur jou een beetje helpt en laat zien hoe je het moet doen. Het doel van een stage (voor jezelf) is juist om te leren.

[alienfruit]

Ik vind ze allebei even ranzig

[riezebosch]

Volgens mij hebben we allemaal hier het idee dat we zelf überleet code schrijven. Maar ik ben eigenlijk wel benieuwd hoe m'n collega's over mijn code denken.

Heb afgelopen 3/4 jaar in m'n eentje aan een project gewerkt (doorgegaan na afstuderen). En ga het komende woensdag doorspitten met een collega zodat hij het kan onderhouden nu ik er na volgende week niet meer werk

[Verwijderd]

Het is net zoals met autorijden. Iedereen vind zichzelf een geweldige chauffeur

Niet helemaal waar tho. Van sommige code die ik schrijf weet ik op dat moment dat het dirty is. Soms wordt er gevraagd om 'quick-n-dirty' en dat komt er dan ook. Bijvoorbeeld voor een proof of concept of een prototype. Ik kan me voorstellen dat iedereen dat wel eens heeft, weten dat iets netter kan maar dit om diverse redenen niet doen.

[ Voor 19% gewijzigd door Verwijderd op 23-07-2005 15:59 ]

[Verwijderd]

De code is vaak het probleem niet. Die kan chaotisch, ongestructureerd en onefficient zijn, zonder dat dit problemen hoeft op te leveren.

Sorry, ben het verder met je eens, behalve je eerste opmerking.

Slechte code is altijd een probleem. Misschien niet als je het niet hoeft te onderhouden (je kan mazzel hebben natuurlijk), maar het punt is dat diegene die slechte code geschreven heeft, dat meestal door het hele systeem door doet.

Als je code werkelijk goed opzet, kun je het meerendeel van bugs etc in een heel vroeg stadium ondervangen, en ook makkelijk fixen omdat goede code zoveel mogelijk effecten lokaal maakt, onbedoelde uitbreidingen voorkomt zodat je makkelijk internals kan refactoren, enz.

Helaas ken ik meer programmeurs die vinden dat ze het al geweldig doen en niet openstaan voor kritiek op hun code dan programmeurs die serieus proberen vakmensen te worden. Kritiek van anderen op jouw code hoeft niet altijd terecht te zijn, en er zijn een aantal onderwerpen waar je eindeloos over kunt debatteren zonder dat het een duidelijk winnend standpunt oplevert. Maar het begint allemaal met het openstaan voor kritiek en ook zelf continue kritisch naar je eigen brouwsels willen kijken.

The end of the day moet er natuurlijk ook opgeleverd worden, dus je kunt niet altijd voor een 9 gaan, maar door zaken als methoden copy-pasten, helemaal niet documenteren en alles aan elkaar hangen met static methoden (heb het nu over Java) kom je meestal binnen een paar weken al vet in de problemen.

En helemaal eens met Alarmnummer. Van sommige code straalt het vakmanschap gewoon af. Hier kun je altijd van leren, ook als je al tien jaar programmeert, en het is gewoon plezierig om te zien als je om je vak geeft.

[Alarmnummer]

EfBe schreef op zaterdag 23 juli 2005 @ 14:53:
[...]
Maar wat is 'slecht opgezet' dan? Jij gaat er dan vanuit dat je met het kijken naar code het ontwerp en de denkpatronen erachter kunt achterhalen, maar dat is IMHO een grote vergissing. Als jij denkt dat jij dat kunt, kijk dan maar eens in de Hibernate sourcecode en probeer te ontwaren waar de functionaliteit zit die bepaalt welke instance te creeeren bij een hierarchical fetch.

Met Hibernate noem je ook zoiets Hibernate vind ik als product werkbaar maar ik probeer zo weinig mogelijk in contact te komen met de gemeenschap en de source. Ik ben zelf ook niet echt onder de indruk van de source, het forum etc. Maar check Spring eens. Vaak (niet altijd) kan je het idee achter iets goed achterhalen omdat ze gewoon goed verantwoordelijkheden van implementaties gescheiden hebben en omdat ze veel dependencies injecteren en je hierdoor sowieso al veel schonere code krijgt. Verder lees ik ook (uiteraard) de Spring boeken/documentatie, dus op papier achterhaal ik de hele grote lijnen. Maar ook de kleinere lijnen wil ik kunnen begrijpen, dit omdat ik vaak aanpassingen/toevoegingen doe aan die core... Ik wil helderheid en inzichtelijkheid. hierdoor kan ik mijn werk goed doen.

Omdat dat gewoon te lastig is voor een mens, kijk je naar onderdelen van een groter iets, en kun je wellicht conclusies trekken als "wat een gore troep", terwijl het helemaal niet een gore troep is.

Mwuah... ik vind dat op micro en macro nivo code gewoon goed opgezet moet worden. En sommige code is gewoon slecht opgezet.. *is ook grote zeiker op het gebied van code*

Nee, slechte code is ten eerste subjectief en kan worden gebruikt als aanduiding van een slechte implementatie van een ontwerp, maar alleen na grondige analyse.

Hmm.. tja... ik ben het gedeeltelijk met je eens. Maar een goed ontwerp dat kut geimplementeerd is, is nog steeds kut. Dus je zult een en en situatie moet hebben...

Je hebt heldere structuren in je ontwerp nodig, of beter: je hebt een helder ontwerp nodig, waarin dingen zijn afgewogen en beslissingen zijn verwoord met de redenen voor die beslissingen. Als je heldere code hebt, prima, maar 'heldere code' of 'begrijpelijke code' is afhankelijk van in hoeverre de lezer van de code begrijpt wat de context is van die code. Carmack's BSP traversal routine is onbegrijpelijke rotzooi voor mensen die niets snappen van bsp trees. Voor mensen die het wel snappen kan het mooie code zijn.

Ik zie veel code dat (ook al heb je kennis van de context) gewoon nog steeds bagger is. Kijk bv eens naar Lucene.. typisch zo`n product dat net niet door mijn slag developers is opgezet. Ik heb er een hele laag overheen gezet zodat ik die ellende een beetje weg kan werken, maar de code kan veel en veel logischer worden opgezet *heeft ook het een en ander aan kritiek op het forum geuit*. Ik vind het gewoon jammer dat mensen die uitstekende visie hebben over de zoekproblematiek, nog steeds slechte en misleidende code schrijven.

Verder worden hier 'buggy troep' en 'werkende troep' doorelkaar gehaald. Slechte code die buggy is of bug-gevoelig is slecht, en dat weten we allemaal wel (zie thedailywtf.com voor voorbeelden). Werkende code die 'beter kan' is iets heel anders en daar gaat het hier om IMHO. waar dat 'beter' op gebaseerd is is IMHO subjectief, vandaar dat ik zei: "slechte code is subjectief".

Mwuah.. ben ik niet met je eens. Op het moment dat code onduidelijk is (en er erg veel haken en ogen aan een bepaalde api komen te zitten) dan is er iets mis. Dit heeft gevolgen voor de onderhoudbaarheid, maar ook het gebruik ervan. Op het moment dat zoiets in een normale applicatie zit dan valt de scope van die ellende nog mee (tenslotte heeft alleen die applicatie er last van). Maar op het moment dat het om api`s gaat dat binnen andere systemen gebruikt moet gaan worden. Dan zal je keer op keer een prijs betalen voor iets dat totaal onnodig is. Ik ben met een aantal 'platform' achtige systemen bezig waar een aantal andere systemen gebruik van maken (dat zal in de toekomst alleen maar meer gaan worden). Ik ben hier heel kritisch op het gebruik en uitbreidbaarheid hiervan.

[ Voor 11% gewijzigd door Alarmnummer op 23-07-2005 16:13 ]

[misfire]

Om de context even scherp te zetten doe ik even de volgende aannames over de "reviewer" en de "knoeier" programmeur:

* Beide programmeurs werken aan hetzelfde product.
* De reviewer weet wat de doelstellingen van het product zijn.
* De reviewer heeft voldoende context informatie om een stuk code te kunnen begrijpen.

In dit geval denk ik wel degelijk dat een reviewer code zou kunnen herschrijven voor een "brakke collega". Het is de vraag of dit gewenst is.

Ten eerste: welke code review je? Kijk je alle code door van anderen? Waarom doe je dat? Heb je tijd over of vertrouw je het resultaat van anderen niet? Ik zou zelf liever niet hebben dat het hele programmeerteam continu elkaars werk zit te controleren. Dit kost heel veel tijd, levert een vreemde sfeer op en vereist dat het volledige team van alle ins en outs op de hoogte blijft.

Ten tweede: waarom schrijf je zelf de code opnieuw? Heeft de brakke collega hier geen tijd voor? Denk je dat je hem niet kunt uitleggen/overtuigen waarom iets beter anders kan? Waarom niet? Waarschijnlijk heb je een veel groter probleem dan een lapje rotte code als je niet in overleg mensen zelfstandig dit kunt laten oplossen.

Code kan wel degelijk slecht zijn zonder dat het "bugs" bevat in de normale zin van het woord. Een bug betekent normaliter dat de gecompileerde functionaliteit van de code een ander resultaat oplevert dan gewenst is. Code kan rare namen, onvoldoende commentaar, rare structuren bevatten en onvoldoende (robuust) performen, zonder dat het meteen leidt tot een nieuwe entry in de bug database. Met een code review kun je veel fouten vinden die tijdens het testen heel moeilijk zijn op te sporen: zoals foutafhandeling in bijzondere situaties, rare kronkels in code branches die 98% van de tijd goed gaan, en memory leaks die zich pas na een week manifesteren. De code op thedailywtf is wat dat betreft een prima voorbeeld: het is vaak productiecode dat doet wat het moet doen, maar wel op een manier dat je denkt: "grote grutjes".

Een goed ontwerp beschermt je niet tegen veel van dit soort fouten, omdat het ontwerp typisch slechts een abstracte beschrijving van de oplossing is. Een goed ontwerp wil dit niet eens, omdat het anders de eenvoud, flexibiliteit en abstractie zou verliezen die je juist nodig hebt om een goede overview te hebben. Binnen de kaders die een ontwerp biedt is er dus nog steeds veel ruimte voor de brakke collega om te prutsen in de code.

Bovendien kan een ontwerp ook natuurlijk gewoon overtreden worden. Dat is ook niet altijd fout, want soms zie je een probleem in het ontwerp pas als je het implementeert in code. In dit geval moet de programmeur wel zorgen dat het ontwerp zo snel mogelijk wordt bijgesteld, en niet te review af te wachten. Het is echter zeker zo dat een ontwerp net zo goed "slecht opgezet" kan zijn als code, en net zo min een heilige status verdient. Programmeurs zouden zeker het ontwerp ter discussie moeten (kunnen) stellen als ze vinden dat dit een goede implementatie in de weg staat.

De reviews die ik doe worden ondersteund door standaards en richtlijnen, algemene afspraken,het ontwerp en mijn eigen ervaring. Voor ieder probleem wat ik tijdens reviews aangeef heb ik een concrete argumentatie, ik geef aan wat er niet goed is, wat de risico's zijn als het zo blijft, en wat er zou kunnen gebeuren om het op te lossen. Dat is geen subjectieve mening, maar een objectieve analyse van de code. Over subjectieve dingen neuzelen als de curly brace op een nieuwe regel of het gebruik van ternaire operators vind ik ook zonde van de tijd, maar het is zeker niet zo dat per definitie iedere opmerking op een stuk code gebaseerd is op een subjectieve mening.

Het is volgens mij niet zo dat je in een project een situatie moet hebben van JOUW code en MIJN code, of JOUW bugs en MIJN bugs, maar ONZE code en ONZE bugs. Het hebben van goede code is een belang van het hele team, en je moet als team ook samenwerken en elkaar helpen om dat belang goed te dienen.

Elkaars code opnieuw schrijven is een uiterste maatregel die ik alleen doe als ik al geprobeerd heb het iemand anders zelf aan te laten passen, niet omdat het ZIJN code is, maar omdat ik normaal geen tijd om het werk van iemand anders over te doen. Bovendien is het opnieuw het belang van het team dat mensen van elkaar leren zodat ze niet steeds dezelfde fouten maken. Ik wil niet dat mensen leren dat als ze gaan prutsen misfire het wel even op komt lossen.

[Soultaker]

Hezik: dat klopt wel, maar ik bestrijd dat je dat moet doen zodra je de slechte server in de repository ziet komen. Je kunt refactoring best uitstellen tot je iets met de code moet doen, omdat 'ie bijvoorbeeld niet goed werkt, zeker als je het toch niet zelf geschreven hebt en de 'kosten' van het refactoren later net zo hoog zijn als nu.

De tijd die je aan het herschrijven van slecht geschreven maar werkende code besteedt kun je beter besteden aan het opleiden van je collega's zodat je in de toekomst minder code hoeft te herschrijven.

Je kunt het altijd nog refactoren als daar directe aanleiding toe is; dát is ook waar het vaak fout gaat met slechte code: als mensen het tegenkomen hebben ze geen zin om uit te zoeken hoe het wel moet en hacken hun wijziging er dan maar in. Dat is hoe procedures met honderden regels code die van her en der vandaan zijn gekopieerd ontstaan: niet doordat ze oorspronkelijk niet goed opgezet waren, maar omdat niemand de moeite heeft genomen om gemeenschappelijke en onafhankelijke functionaliteit af te splitsen toen dat mogelijk en noodzakelijk was.

[alienfruit]

Refactoring

[Verwijderd]

Soultaker schreef op zaterdag 23 juli 2005 @ 16:24:
Hezik: dat klopt wel, maar ik bestrijd dat je dat moet doen zodra je de slechte server in de repository ziet komen. Je kunt refactoring best uitstellen tot je iets met de code moet doen, omdat 'ie bijvoorbeeld niet goed werkt, zeker als je het toch niet zelf geschreven hebt en de 'kosten' van het refactoren later net zo hoog zijn als nu.

Ja natuurlijk, op dat punt zijn we het gewoon eens. Mijn opmerking was meer algemeen t.o.v. heel specifiek toegepast.

Een programmeur die code van anderen gaat refactoren bij het inchecken in een CVS, mag wat mij betreft een enkeltje WW krijgen, tenzij hier hele duidelijke afspraken over gemaakt zijn.

Immers, de code mag wel vies zijn, maar er bestaat geen automatiseringsproject met als doel 'schone code'. Het doel is om een bepaald probleem op te lossen. Daarbij ga ik er vanuit dat de oorspronkelijke programmeur contact heeft met de klant in kwestie. Daarnaast is het verdomd lastig testen als iemand zomaar een hele code gaat herschrijven. Zo kan iets bv. best echt een feature zijn, ipv een bug. Zulke zaken heb ik wel eens gezien, dat een klant een bepaalde foutmelding eiste onder bepaalde condities.

Krijg je van die situaties waarin een project de GAT al gehad heeft, en er toch ineens nieuwe bugs ontwikkeld omdat iemand nodig vond het te refactoren.

[ Voor 8% gewijzigd door Verwijderd op 23-07-2005 17:34 ]

[Alarmnummer]

Ik vind trouwens ook niet dat je zomaar code van collega`s kan gaan herschrijven.

[Verwijderd]

Ik vind trouwens ook niet dat je zomaar code van collega`s kan gaan herschrijven.

Soms is het geen probleem. Als je met elkaar hebt afgesproken dat het ok is, en dat het een soort discussie is op die manier, is het prima. Ik werk wel eens samen met een paar mensen om op die manier een harde noot te kraken.

En in het geval van refactoring van pruts code... als het /echt/ pruts code is, dan had het al nooit ingechecked moeten worden. Wie heeft er nu eigenlijk een ticket WW nodig dan?

Waneer je het niet moet doen, is natuurlijk als de 'overtreder' het allemaal nog aan het leren is, en openstaat voor kritiek. Dan kun je het beter gewoon aankaarten, en hem vragen z'n code te verbeteren. En ook zeker niet bij stijl/ komma neuk zaken. Als je met mensen samenwerkt is het gewoon onvermijdelijk dat je wel eens verschillend over zaken denkt.

[ Voor 4% gewijzigd door Verwijderd op 23-07-2005 19:41 ]

[Tomatoman]

Verwijderd schreef op zaterdag 23 juli 2005 @ 19:40:
Waneer je het niet moet doen, is natuurlijk als de 'overtreder' het allemaal nog aan het leren is, en openstaat voor kritiek. Dan kun je het beter gewoon aankaarten, en hem vragen z'n code te verbeteren. En ook zeker niet bij stijl/ komma neuk zaken. Als je met mensen samenwerkt is het gewoon onvermijdelijk dat je wel eens verschillend over zaken denkt.

Styl-/ kommaneukzaken zijn bij uitstek de zaken waar je prima afspraken over kunt maken. Veel ondernemingen hanteren een huisstijl, waar iedereen zich aan dient te houden. Verschil van mening met je collega of een { of begin op een aparte regel moet staan? Eenmalig in de gehanteerde stijlconventies vastleggen en er is nooit meer een welles-nietes-probleem.

Heel anders is het met de manier waarop iemand zijn code opzet. Als een collega houtje-touwtje-code schrijft terwijl jij juist prachtige design patterns gebruikt is dat gewoon een gegeven. Je kunt samen overleggen hoe je in het algemeen hiermee omgaat, maar that's it. Met het veranderen van de collega's code ben je alleen symptomen aan het bestrijden, die collega verandert er niet door. De volgende keer schrijft hij doodleuk opnieuw houtje-touwtje-code, ga je die dan ook veranderen?

[Soultaker]

tomatoman: ik zie het juist andersom. Over een niet naar jouw zin geïndenteerde regel of in jouw ogen verkeerde variabelenaam zeuren is juist niet echt productief; discussie over de structuur van de code juist wel.

Maar je moet hoe dan ook bij die discussie beginnen en niet zomaar code gaan zitten herschrijven, want dat is inderdaad symptoombestrijding. Om maar niet te spreken over de ijdelheid van jouw manier de enige juiste vinden.

[ Voor 35% gewijzigd door Soultaker op 23-07-2005 21:16 ]

[riezebosch]

Soultaker schreef op zaterdag 23 juli 2005 @ 21:15:
tomatoman: ik zie het juist andersom. Over een niet naar jouw zin geïndenteerde regel of in jouw ogen verkeerde variabelenaam zeuren is juist niet echt productief; discussie over de structuur van de code juist wel.

Maar je moet hoe dan ook bij die discussie beginnen en niet zomaar code gaan zitten herschrijven, want dat is inderdaad symptoombestrijding. Om maar niet te spreken over de ijdelheid van jouw manier de enige juiste vinden.

Z'n ondertitel zegt al genoeg

[Dennis]

Ik loop momenteel stage bij een software ontwikkelings bedrijf en ben zelf altijd alleen maar thuis bezig geweest met programmeren. Ik deed dat altijd in php en werk op mijn stage uitsluitend met c#. Ik was wel bekend met object geörienteerd programmeren maar dingen zoals design patterns waren voor mij tamelijk onbekend. Vanaf dag 1 ben ik op een groot project gezet en hoewel de logica laag en het design al was opgezet heb ik grote delen zelf moeten invullen.

Voor vragen kon ik altijd bij één van mijn ervaren collega's terecht. Ik heb ook vaak genoeg meegemaakt dat een collega een stuk ingecheckte code van mij heeft gezien en dacht dat het beter kon. Ik heb nooit meegemaakt dat hij dan zelfstandig de code ging wijzigen: ik werd altijd netjes geïnformeerd hoe het beter kon en kon dan, zodra ik het doorhad, zelf de code aanpassen. Daar leer je een hoop meer van want inderdaad, als een collega al je code gaat aanpassen omdat het iets beter kan, werkt dat niet echt motiverend.

[Tomatoman]

Soultaker schreef op zaterdag 23 juli 2005 @ 21:15:
tomatoman: ik zie het juist andersom.

Volgens mij zie je het juist precies hetzelfde als ik.

Over een niet naar jouw zin geïndenteerde regel of in jouw ogen verkeerde variabelenaam zeuren is juist niet echt productief;

Daarom moet je er geen tijd aan besteden en gewoon eenmalig vastleggen hoe het moet. Houd je aan de stijlregels, verder geen gelul.

Maar je moet hoe dan ook bij die discussie beginnen en niet zomaar code gaan zitten herschrijven, want dat is inderdaad symptoombestrijding.

Dat is precies wat ik schreef.

[Soultaker]

Ok, dan had ik je even verkeerd begrepen.

[D4Skunk]

hmmz, 't is al een tijdje geleden dat ik nog eens gepost heb, maar voor zo'n topic wil ik wel een uitzondering maken op een zaterdagnacht

Code is code, als het resultaat goed is, zie ik persoonlijk niet de nood om de hele zaak te herschrijven, tenzij ik echt niks om handen zou hebben (note to self : dream on ), of er bugs/security-/performantie-issues zijn.
De enige code die ik rewrite, is die van mezelf die ik tijdens een of andere tight deadline geïmplementeerd heb, en waarvan ik 'voel' dat ze niet optimaal is.

Zo heb ik eens een loonberekeningsprogramma moeten aanpassen mbt brugpensioenen, en dit met een deadline van 4 uur. Resultaat : ipv de hele logica door te pluggen -code met goto's en dergelijke, 1000- en lijnen, was onbegonnen werk binnen die tijdsspanne - heb ik gewoon een extra laag geschreven tussen business layer en berekeningsprogramma, die getriggerd werd door de property gets/sets. Ugly as hell, maar de boel werkte - bugvrij- en dat in 3 uur. Nadien heb ik dan een externe programmeur laten aantrekken om de code volledig te herschrijven.


Het probleem met zo'n aanpassingen is dat je initieel meestal slechts enkele lijnen wil vervangen, maar dat je uiteindelijk blijkt de hele proc/lib/... te hebben herschreven, en je planning naar de verdoemenis is...

[flowerp]

tomatoman schreef op zaterdag 23 juli 2005 @ 21:00:
[...]
Styl-/ kommaneukzaken zijn bij uitstek de zaken waar je prima afspraken over kunt maken. Veel ondernemingen hanteren een huisstijl, waar iedereen zich aan dient te houden. Verschil van mening met je collega of een { of begin op een aparte regel moet staan? Eenmalig in de gehanteerde stijlconventies vastleggen en er is nooit meer een welles-nietes-probleem.

Dat valt nog vies tegen in de praktijk. Ook wij hebben een styleguide, maar onze 'hippie' programmeur erkent die gewoon niet. Nu ga ik erzelf geen herrie over schoppen, maar ik zie af en toe wel eens een update in de cvs langskomen waarvan zelfs ik zie dat dat echt niet kan. Wij doen bijvoorbeeld veel met SQL die we in losse .sql bestanden hebben staan. In de styleguide staat zeer uitgebreid hoe bijvoorbeeld subqueries ge-indent en opgezet moeten worden. Maar deze ene persoon doet dat telkens anders. Soms helemaal zonder indenting, of soms met zo'n opmerkelijke indenting dat het precies lijkt alsof de clauses van de sub query bij the outer query horen.

Iets als:

code:

select 
    * from ( select a, b
from 
   c
where 
    a = b)

En dat dan in een query van 500 regels lang met subqueries tot wel 4 level diep. De editors die wij gebruiken hebben helaas geen automatische formatting voor SQL. Hoewel ik zeer zeker NIET code van andere wil gaan herschrijven (zeker niet omdat ik de jongste en minst ervarenen ben ) MOET ik toch dergelijke code eerst met de hand gaan formatten als ik de opdracht krijg om er een kleine aanpassing in te maken, omdat ik het anders gewoon niet kan volgen wat er gebeurd.

Af en toe krijgt de hippie dan wel even op z'n kop van de manager, maar dan is er even wat gerommel, en de volgende keer doet ie het gewoon weer. Als iemand anders er dan weer wat van zegt, is zijn reactie meestal iets van "maar ik HEB toch tabs gebruikt?", alsof ie er zelf heilig van overtuigd is dat als je maar een beetje willekeurig indent, dat het dan wel goed is. Is voorderest een harstikke aardige gozer hoor, dus niemand wil echt kwaad op hem zijn ofzo, maar het is wel een beetje opmerkelijk.

[Verwijderd]

Wie van jullie heeft er hier eigenlijk The Pragmatic Progammer (http://www.pragmaticprogrammer.com/ppbook/index.shtml) gelezen? Zo verschrikkelijk waar wat daar in staat...

[ Voor 26% gewijzigd door Verwijderd op 24-07-2005 16:43 ]

[Alarmnummer]

Verwijderd schreef op zondag 24 juli 2005 @ 16:41:
Wie van jullie heeft er hier eigenlijk The Pragmatic Progammer (http://www.pragmaticprogrammer.com/ppbook/index.shtml) gelezen? Zo verschrikkelijk waar wat daar in staat...

Die heb ik een tijd geleden gelezen. Maar ik snap je opmerking niet helemaal. Ik vond er wel aardige dingen in staan, oa broken glass (heeft zeker betrekking op dit topic imho).

[edit]
Ik heb je zin nog een keer goed gelezen. Ik had de 'waar' over het hoofd gezien. Je verhaal maakt nu wel sense Hmmm... misschien dat ik morgen iets scherper ben

[ Voor 17% gewijzigd door Alarmnummer op 24-07-2005 18:24 ]

[misfire]

Dont Live With Broken Windows, Keep It Small and Simple, Dont Repeat Yourself. Ik heb het ook gelezen. Overigens gaan deze principes verder dan het schrijven van code, maar ik neem aan dat brakke collega's ook op andere onderdelen worden gecorrigeerd.

[djengizz]

Op de eerste plaats gaat het om de manier hoe je dit brengt. Ik ben altijd verbaasd over de hoeveelheid weerstand die programmeurs hebben als hun code wordt gereviewd (of naar een externe partij wordt gebracht). Om ook een hand in eigen boezem te steken: heb laatst weer wat code van een oud 'hobby-projectje' bekeken uit de tijd dat ik net begon met programmeren: Oehmmf (was er toen best trots op). Breng het idd, zoals eerder genoemd, onder de noemer refactoring / redesign en neem een geautomatiseerde style / code checker.

Op de tweede plaats: 'If it's not broken, don't fix it' kan ik niet mee leven. Als jij werkelijk mogelijke problemen ziet in code of gewoon een zooitje aantreft, heb je imo de plicht om dit in ieder geval bespreekbaar te maken. Dit heeft voordelen voor zowel de kwaliteit van je app's als voor jezelf (blijkbaar heb je meer ervaring en kennis en dat mag je best laten horen).

Vaak komt slechte code niet eens zozeer vanwege laksheid maar vanwege gebrek aan ervaring...