'Vrouwelijke sourcecode is beter te begrijpen'

Volgens de vice-president van databasebedrijf Ingres schrijven vrouwelijke programmeurs begrijpelijkere programmacode dan hun mannelijke soortgenoten. Vrouwelijke sourcecode zou hierdoor gemakkelijker uit te breiden zijn.

De Ingres-topvrouw, Emma McGrattan, stelt dat vrouwelijke programmeurs veel attenter zijn richting diegenen die eventueel later met de code aan de slag moeten, schrijft The Wall Street Journal. Dit uit zich voornamelijk in het feit dat ze de code veel vaker dan mannen van behoorlijk commentaar en documentatie voorzien, maar ook uit de code zelf zou de functionaliteit ervan gemakkelijker kunnen worden afgeleid. Volgens McGrattan schrijven mannelijke programmeurs vaak cryptische code, waarmee ze volgens haar willen laten zien hoe slim ze zijn.

Bij Ingres is ongeveer een op de vijf werknemers vrouw, maar tot McGrattans spijt werkt slechts een handjevol van hen als programmeur. De vice-president heeft zich de laatste jaren beziggehouden met het verheffen van hun neiging tot behulpzaamheid aan anderen tot norm bij het bedrijf. McGrattan had graag gewild dat dit eerder was gebeurd, omdat er nog altijd behoorlijk wat 'van testosteron doorspekte code' moet worden gefikst.

McGrattan wil graag meer vrouwen interesseren voor het programmeursvak. Helaas voor de Ingres-topvrouw blijkt het al lastig om überhaupt aan voldoende programmeurs te komen gezien het feit dat de studentenaantallen aan technische opleidingen een neerwaartse trend vertonen. Om dan ook nog eens vrouwen aan te trekken blijkt volgens McGrattan een behoorlijke uitdaging te zijn.

Reacties (184)

[Pjerry]

Telkens val ik van de ene verbazing in de andere. Hierboven staat een artikel die gaat over het feit dat vrouwen begrijpelijker zouden programmeren dan mannen. In de commentaren zie je daar bar weinig van terug. Een stelletje programmeurs (kunnen mannen èn vrouwen zijn) willen vooral in hun commentaar laten zien hoe goed ze wel niet met C (++) om kunnen gaan. Absoluut niet de issue en jammer van de database, die ze met die verhalen vervuilen.

Ik stel voor dat we weer eens terug on-topic gaan.

Wat mij opvalt is ten eerste dat een vrouw de stelling poneert. Nu is een redelijk bekend feit dat vrouwen in topposities, om zich te handhaven in de mannenwereld, een verhoogd mannengedrag eigen maken. Wij mannen hebben een hoog macho gehalte (sorry voor de lange zere tenen), dat zie je terug bij vrouwen in topposities (wederom sorry voor de tenen). Dat wetende zorgt ervoor dat je de uitspraak met de nodige voorzichtigheid moet benaderen.

Stel dat het inderdaad zo is dat vrouwen betere code schrijven.
Niet in de zin van dat het programma betere zijn werk doet, maar in de zin van dat het onderhoud beter erop gepleegd kan worden.
Aan de basis liggen een paar uitgangspunten:

• Iedereen die wat van programmeren en de levenscyclus van programma's weet, weet dat het onderhoud factoren meer tijd vergt dan het oorspronkelijk ontwerpen en schrijven van de programmatuur.
• Ook, als je er wat vanaf weet (en dat betwijfel ik zo nu en dan als ik de commentaren lees) dat een uitgebreidere code niet altijd een slechter performende gecompileerde code oplevert.
• Het is dus zaak als programmeur dat je een beetje begrijpt hoe een compiler werkt, zodat je op die wijze een optimale code kunt schrijven. Het is namelijk mogelijk voor eenieder die dit leest, om met een beperkt aantal codestatements, een mainframe plat te leggen. Lengte van de code is dus (realtief) onbelangrijk.

Tot op heden is de computer wereld een mannenwereld, dat wil zeggen dat een vrouw die zich in deze wereld vecht en handhaaft betere prestaties moet leveren dan een man. M.a.w het gemiddelde niveau van een vrouw zal (tot op heden) hoger zijn dan die van een man.
Als dat zo is dan zullen zij ook wel beter werk afleveren. Ik in ieder geval werk(te) ik altijd graag met vrouwen in mijn team. Maar daar liggen ook andere redenen aan ten grondslag (overigens geen seksistische!) die buiten het kader van dit bovenstaand artikel vallen.
Door enerzijds de grote vraag naar IT-ers en anderzijds het gemak waarmee een man deze wereld kan betreden, zitten er m.i. nogal wat kneusjes tussen. Men schrijft thuis een programmaatje, dat werkt, en denkt het programmeren onder de knie te hebben. Hoe anders is de realiteit als je de "echte" programmeerwereld instapt. De hele discussies die hierboven gevoerd worden, bevestigen deze gedachtegang. De echte issues komen niet ter spraken, nee men discussieert over een klein stukje code.
Een vrouw kan zich hier nauwelijks aan bezondigen, het wordt gewoon niet geaccepteerd, zij moet namelijk echt goed zijn, dus een programmaatje thuis schrijven is niet toereikend.

Ik kom nog uit de oude 3-de-generatie-taal-wereld. Tijdens mijn studie en promotieonderzoek werkte ik met talen als Pascal, Fortran en heel af en toe Basic. Mijn omscholing richting automatisering leidde er toe dat ik Cobol en later RPG leerde. Allemaal typisch procedurele talen. Een blauwe maandag heb ik nog in C en Oracle/SQL geprogrammeerd, maar op dat moment was ik ondertussen zover "uitgefaseerd" dat ik aan schrijven nog maar nauwelijks toe kwam. Oracle/SQL zijn vreemde eenden in de bijt, de andere talen kun je best op een hoop vegen. Waarbij opvalt dat C (en alle later afgeleide talen daarvan) zich kenmerkte door het feit dat je ontzettend veel statements in één coderegel kunt proppen. Een ontwikkeling die de leesbaarheid van de programmatuur negatief beïnvloedde. Zelfs voor de programmeur zaten er grote risico's aan, ook hij/zij overzag niet altijd wat er allemaal kon gebeuren ( de eenvoudige voorbeelden hierboven, met de correcties daarop in de reacties onderschrijven dit nogmaals).

Goede programmatuur onderscheidt zich in mijn ogen door het feit dat het goed is uitgedacht (niet: we beginnen maar en kijken waar het schip strand; maar: het (deel)probleem goed analyseren). Bij die analyse deel je het spul in hapbare brokjes. Wat er niet in thuishoort of meerdere keren gebruikt wordt eruit gehaald en ondergebracht naar (blackbox) functies of procedures. Die functies/procedures (via commentaar) dienen opruwweg twee niveaus goed omschreven te zijn. Ten eerste als blackbox: wat moet erin en wat komt eruit; ten tweede in de functie/procedure zelf, maar daar staat het technische verhaal; dus wat het doet en hoe. Afhankelijk van de functie/procedure kan het ook nog in het functionele ontwerp beschreven zijn, maar dat hoeft niet.

Door programmatuur op deze wijze op te zetten (is maar één van de punten voor goede programmatuur) zul je een goed te onderhouden systeem bouwen, zonder dat daar allerlei artefacten in komen als het systeem later gemodificeerd wordt.

Terug naar het artikel. Doet een vrouw dit beter dan een man. Ik denk het niet. Iedereen die een goede programmeeropleiding heeft genoten, er niet op kick dat hij een regel minder heeft gebruikt dan zijn collega, oog heeft voor het onderhoud, zal op deze manier programmeren. Blijft het feit staan, dat ik van mening ben dat het gemiddelde niveau van een vrouw hoger is (zal in de toekomst wel wijzigen) en dat ze daardoor betere code genereren. Wat de vrouw wel als voordeel heeft t.o.v. de man is het veel lagere macho-gedrag, hetgeen sterk in hun voordeel kan werken. Maar ik durf te stellen, dat ik als man, het best aan durf de competitie aan te gaan met elke vrouw , wat betreft onderhoudbaarheid en leesbaarheid van de code die ik produceer.
Waarmee ik wil zeggen, dat ik het niet typisch iets vrouwelijks vind!

[Reactie gewijzigd door Pjerry op 22 juli 2024 17:12]

[RoyBijster]

Ik ben zelf erg benieuwd naar de verschillen in snelheid en het aantal programmaregels (dus zonder commentaren) dat nodig is om een bepaalde functie uit te laten voeren.
Vrouwen zijn dan wellicht netter, maar is hun code ook logischer en sneller / korter dan die van mannen? Dat is iets waar ik naar benieuwd ben.

Voor beiden valt wat te zeggen. Code moet begrijpbaar zijn voor andere programmeurs, maar soms is snelheid net even wat belangrijker Ik ben benieuwd!

Overigens zie ik geen directe link tussen het aantal studenten aan technische opleidingen en het aantal beschikbare programmeurs. Als men een verband zou leggen tussen de neerwaartse trend voor het aantal studenten informatica oid, zou ik dat een stuk makkelijker volgen dan een algemeen verband met studenten aan technische opleidingen.
Iemand die een technische opleiding volgt of heeft gevolgd is niet per defenitie een programmeur.

[MicroVirus]

Ik ben zelf erg benieuwd naar de verschillen in snelheid en het aantal programmaregels (dus zonder commentaren) dat nodig is om een bepaalde functie uit te laten voeren.
Vrouwen zijn dan wellicht netter, maar is hun code ook logischer en sneller / korter dan die van mannen? Dat is iets waar ik naar benieuwd ben.

Voor beiden valt wat te zeggen. Code moet begrijpbaar zijn voor andere programmeurs, maar soms is snelheid net even wat belangrijker Ik ben benieuwd!

Doorgaands bij grotere projecten maakt leesbaarheid en begrijpbaarheid véél meer uit dan die één of twéé clock-cycles snelheid. Zeker met huidige compilers maakt het redelijk weinig uit voor de uiteindelijke binary hoe jij de code neerzet. Leesbaarheid door middel van logische opbouw en voldoende commentaar is echter iets wat de compiler niet voor je doet.

Normaal is het zo dat je de code één keer schrijft, en dat deze dan twentig keer wordt gelezen/bekeken door anderen, en dan ben je blij als het 'makkelijk' geschreven is.

[n4m3l355]

Dat kan goed zijn maar ik denk dat er twee problemen zijn. Enerzijds een programmeur werkt zich als het ware in een project zodat die zichzelf er helemaal eigen mee maakt en kan dan ook moeilijk afstand nemen.
Anderzijds is het ook werkgarantie aangezien jij diegene bent die het in elkaar gedraait heeft en dus ook in staat is om hier aanpassingen aan te maken zonder al te veel problemen.
Verder is mijn ervaring dan ook wel dat vrouwe ordelijker werken en hoeft dit de effecientie zeker niet ten goede te komen echter is dit niet altijd van toepassing. Echter ik zet toch wel mijn kantekens bij het einde waar mij het verhaal haast als een verkoop verhaal overkomt om meer mensen aan te trekken.

[i-chat]

das natuurlijk BS,

werkgaranties doe je door goede referenties, niet door een soort, malware achtige practijken.. a la ransomware.

als je vandaag goed gedocumenteerde code leverd zal men veel eerder geneigd zijn je voor een volgende klus te vragen dan wanneer je een brak iets hebt... (dat zo snel mogelijk door iets nieuws van een andere programeur vervangen moet worden).

[Fiander]

Tja, ik zorg zelf meestal voor duidelijk leesbare code, met hier en daar een comment indien nodig. kleine korte functies die slechts één ding doen. ( uitzondering parsers )

op die manier kan de code makkelijk door een ander gebugfixed worden, terwijl ik op een ander leuk project zit.

[YopY]

Waarom zouden parsers daar een uitzondering op zijn? Met een goed ontwerp kun je hele strakke, flexibele en onderhoudbare code schrijven, ook voor een parser.

[Fiander]

omdat de gemiddelde parser over het algemeen enkele switch statements heeft welke enkele honderden regels code beslaan.

de uitzondering van parsers sloeg ook alleen op de uitdrukking klein en kort.

[DutchCommando]

Het is inderdaad maar net wat de doelstelling is van een programma. Hoe kritisch is de snelheid voor de applicatie? Een UI-applicatie die er net even 0,01s langer over doet is over het algemeen geen probleem. In dat soort gevallen is het dan ook beter om zo duidelijk mogelijke code te kloppen. Voor bepaalde snelheid-kritische applicaties kan enige optimalisatie echter wel handig zijn. Maar onthoud: meten is weten!

[Verwijderd]

Commentaar zal per definitie geen verschil uitmaken, aangezien dat gewoon wordt weggelaten door de compiler. Idem wat betreft netter inspringen e.d.
Zaken als i++ i.p.v. i=i+1 worden ook al door de compiler gelijk getrokken. Wat dat betreft betwijfel ik ten zeerste of je ooit enig verschil zal zien.

Maar veel belangrijker... De snelheid van een programma wordt vrijwel nooit bepaald door dergelijke 'slimme' code, maar door het gebruikte algorithme! Het gaat er niet om hoe snel je code is voor een sorteer algortihme, maar welk algorithme je gebruikt. Want dan gaat het niet om 1% snelheids winst, maar op tientallen, zoniet honderden procenten snelheids winst.

Duidelijk en logisch opgebouwde programma's zullen i.h.a. beter in staat zijn het beste algorithme voor een bepaalde situatie te gebruiken, dan onoverzichtelijk programma's.

[SPee]

Bij bv. Java zit er ook verschil in functionaliteit

Array.get( ++i ); <-- Hier wordt eerst i verhoogd, waarna de get() wordt uitgevoerd.
Array.get( i++); <-- Hier wordt eerst get(i) uitgevoerd en daarna wordt i verhoogd.

Groot verschil tussen beide en kan een verschil verklaren

[Rey Nemaattori]

Ik ben zelf erg benieuwd naar de verschillen in snelheid en het aantal programmaregels (dus zonder commentaren) dat nodig is om een bepaalde functie uit te laten voeren.

't eerste wat er gebeurd in een preprocessor in het verwijderen van commentaar.
De hoeveelheid commentaar heeft alleen invloed op de grootte van de files en daarmee de inleessnelheid van 't bestand tijden het compilen.

Overigens zie ik geen directe link tussen het aantal studenten aan technische opleidingen en het aantal beschikbare programmeurs. Als men een verband zou leggen tussen de neerwaartse trend voor het aantal studenten informatica oid, zou ik dat een stuk makkelijker volgen dan een algemeen verband met studenten aan technische opleidingen.Iemand die een technische opleiding volgt of heeft gevolgd is niet per defenitie een programmeur.

Nee, maar alle programmeurs met een Hoger of Technisch Informatica diploma hebben aan een technische school gestudeerd(hoewel dat ook steeds meer verwatert)

[Reactie gewijzigd door Rey Nemaattori op 22 juli 2024 17:12]

[Sponge]

Blijkbaar heb ik dan een overschot aan vrouwelijke hormonen . Zelf zie ik commentaar als een essentieel onderdeel van het programmeren. vooral zodat je na een half jaar nog eens terug kan kijken wat je toen in je hoofd had, en daar weer verdere aanpassingen op kan maken.

Verder werkt het niet om comments achteraf te gaan schrijven, je hebt er meestal geen tijd meer voor (volgende project begint) en het kost ook meer tijd dan als je het meteen gedaan zou hebben.

Helaas wordt het belang van comments vaak onderschat, ook bij opleidingen. Overigens ben ik voorstander om alle comments in het Engels te doen, ik zag hierboven wat Nederlandse. Is dat puur omdat het dummy code is? Ben benieuwd . Engelse comments geven eigenlijk alleen maar voordelen in de wereld die steeds meer internationaliseerd.


En overigens ben ik tegen het verlijken van strings met "" om te checken of ze leeg zijn, doe dan strlen($val) == 0, maar dat zal wel persoonlijk zijn .

[Fiander]

Deze post kwam vrijdag al op codeproject langs in het forum,
en als ik het goed onthouden had, dan wilde deze mevrouw dat ELKE regel code voorafging aan een regel commentaar, tevens zou iedereen die ooit aan de sourcecode gewerkt hebben verplicht worden op deze alsnog te documenteren.

das toch echt wat overkill lijkt mij.

[Johny58]

Ik ben volledig voor vrouwenbashen als grap (op een website waar ze toch bijna niet komen reageren ). Maar ik vraag me af hoeveel IT'ers hier rond lopen die in de praktijk wel eens in een project team met een vrouwelijke programeur hebben gezeten...

Bij mij is het één keer voorgekomen... en ik moet zeggen dat ik nog nooit zo een mate van nauwkeurigheid heb gezien. Om naar te zwijgen over de organisatie van het eigen werk en het werk van de rest (van de mannen) in het project team.

Uiteraard kan het toevallig net die ene zijn. Maar als ik die ene vrouw vergelijk met de vele tientallen mannen waar ik mee heb gewerkt is het verschil op net die gebieden gigantisch.

Kan niet anders zeggen: I'm a believer...

[Reactie gewijzigd door Johny58 op 22 juli 2024 17:12]

[flowerp]

Maar ik vraag me af hoeveel IT'ers hier rond lopen die in de praktijk wel eens in een project team met een vrouwelijke programeur hebben gezeten...

Bij ons op het werk zitten we in een development team met maar liefst 3 vrouwen En die zijn dan allemaal van het type die Linux op hun desktop installeren, hex kunnen lezen en weten wat het MVC model is om maar eens wat termen te noemen.

Hoewel het inderdaad zo is dat vrouwen -zwaar- in de minderheid zijn. Bij de laatste solicitatie rondes die we hielden is er zeggen en schrijven 1 vrouw langs geweest op misschien wel tegen de 100 mannen. Die vrouw was toevallig wel goed in haar vak en we hadden haar graag aangenomen zodat we bijna met 4 vrouwen hadden gezeten. Helaas was een andere bedrijf net wat interessanter voor haar en ging er mee vandoor...

[MBV]

Ik heb tijdens mijn studies samengewerkt met 2 studentes. De eerste heb ik via MSN niet kunnen uitleggen hoe PHP-array's werken (dat je een array in een array zou kunnen stoppen, hoe bestaat het ) terwijl ze toch echt dezelfde programmeerlessen had gevolgd als ik. De andere kwam van een minder technische opleiding de master binnen, en kondigde aan het begin van het project aan dat ze niet kon programmeren. Ik heb haar toch gevraagd wat simpele dingen te doen, wat achteraf niet de handigste zet was.

Verder helaas niet met vrouwen in de IT gewerkt, ik hoop dat dit twee uitzonderingen waren

[Johny58]

Denk wel dat er verschil moet worden gemaakt tussen studenten en professionals. Als ik eens een boekje zou opentrekken over de mannelijke studenten met wie ik projecten heb gedaan zou je ook dit soort verhalen krijgen...

[Verwijderd]

Ik denk dat het begrijpen van sourcecode vooral met je eigen opleiding te maken heeft. Als je geen C++ kent bijvoorbeeld kun je beter het programma stroom diagram (PSD) erop na slaan want dat is (computer-) taal onafhankelijk en voor iedereen leesbaar.

Ik heb bij de faculteit techniek ooit les gehad van vrouwelijke docenten... daar begreep je dus geen ene snars van. 1 artikel uit de larousse encyclopedie van 4 regels maakte mij in 1 minuut duidelijk wat een decibel is.

Daarnaast moet je bekijken of de leesbaarheid ook echt te productiviteit verhoogt.
Ik kan ook in proza programmeren... maar dan kun je misschien net zo goed romanschrijver worden.

Presentatie moet je los zien van inhoud in sommige gevallen.

Ik kan ook geweldige rapporten schrijven, maar dat kost veel tijd en die rapporten belanden toch in het archief om stof van de planken te houden. Daarom is er ook een trend om documentatie en rapportage zeer beknopt te houden en tijd te besparen.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 17:12]

[Verwijderd]

Heb idd ervaring mee. Mooie onliners maar totaal niet onderhoudbaar. Doe mij maar fatsoenlijke code ... liever 0,1 seconde trager dan de zooi die ik van sommige lui zie.

Dames go go go ... de wereld van het code kloppen ligt voor jullie open.
Goede code is nooit dom, en iedereen is vervangbaar dus kan je beter het fatsoen hebben iets begrijpelijk te fabrieken.

Heb er veel te dure en "slimme" codekloppers de deur voor gewezen, doet dat thuis maar ... hier schrijven we echt programma's. Had je hun gezicht moeten zien alsof ze water zagen branden, "maar het werkt toch?" .... lol.

[Sfynx]

Heb idd ervaring mee. Mooie onliners maar totaal niet onderhoudbaar. Doe mij maar fatsoenlijke code ... liever 0,1 seconde trager dan de zooi die ik van sommige lui zie.

One-liners als het voorbeeld hierboven is niets slechts aan, dat is gewoon een een if-constructie overbodig maken omdat je hetzelfde toewijst als de uitkomst van de expressie... Dergelijke dingen hebben weinig met onderhoudbaarheid te maken, het is pas slecht als je een zootje maakt van de architectuur van je applicatie (bijvoorbeeld HTML en PHP in 1 bestand zetten om even een heel erg voorbeeld te noemen, ofttewel je niet houden aan scheiding tussen presentatie en model/controller etc etc.... of geen testsuite gebruiken zodat je niet weet wat er mogelijk aan de andere kant kapot gaat na een wijziging).

Dat heeft een veel slechtere invloed op de onderhoudbaarheid van je code dan one-liners die wel te maken hebben met hetzelfde deel van je applicatie. Zeker als er gewoon een duidelijke comment boven staat die vertelt wat er gebeurt (dat is wel altijd verplicht bij dergelijke code!)

[Reactie gewijzigd door Sfynx op 22 juli 2024 17:12]

[Sfynx]

Documentatie van je code gooi je maar lekker in 'n los pdf'je of text bestandje oid, niet in de code zelf.

En daar ben ik het niet mee eens. Comments in je code is beter, want:

- Je kan comments duidelijk van code onderscheiden door het op de goede manier neer te zetten en door het gebruik van dingen als syntax highlighting (wat tegenwoordig in elke editor zit). Dus dat kan je niet als nadeel aanvoeren.
- Het staat bij de code waar het om gaat. Het wordt lastiger refereren aan een stuk code als het in een apart document staat.

Ik heb het hier over de documentatie die hoort bij een bepaalde functie (betekenis van parameters en return value, samenvattinkje van wat de functie doet, e.d).... of bepaalde regels code. Tijdens het lezen van de code zie je direct de docuentatie die erbij hoort, en als je dan toch alleen de documentatie wil lezen, dan haal je er een tool als javadoc of phpdocumentor o.i.d. overheen.

Documentatie als requirements analyse en design documenten zijn natuurlijk wel apart

[Reactie gewijzigd door Sfynx op 22 juli 2024 17:12]

[Fiander]

Ik heb het hier over de documentatie die hoort bij een bepaalde functie (betekenis van parameters en return value, samenvattinkje van wat de functie doet, e.d).... of bepaalde regels code. Tijdens het lezen van de code zie je direct de docuentatie die erbij hoort, en als je dan toch alleen de documentatie wil lezen, dan haal je er een tool als javadoc of phpdocumentor o.i.d. overheen.

En nou heb je het net over dingen die door het ontwerpteam opgepakt moeten worden, of in de functie beschrijving thuis hoort. en naar aanlijding daarvan maak je de code. Als het goed gedaan word, is als eerste de documentatie klaar, als tweede de testcases, en als laatste pas de code. En aangezien een goede naamgeving van functies belangrijker is dan documentatie, kan ik best begrijpen dat het voor vrouwen lijkt alsof zei beter documenteren.

[YopY]

En als je eerst je documentatie afhebt betekent dat ook dat je je hele programmaontwerp afhebt, wat betekent dat je een ongelofelijk log monster van een programma aan het maken bent. Je wilt, als je nozel bent, niet het hele ontwerp van een programma vastleggen als je een 3-jarig programmeerproject hebt.

[Fiander]

klopt, dan gebruik je baby-steps / mile-stones.
het grote project word in kleine milestones van ongeveer 3 weken opgesplitst.
waarbij eerst de milesones bepaalt worden in must-haves, like-haves, nice-haves.
Als een bepaalt ontwerp niet werkt, ben je hooguit 3 weken werk kwijt.

Als je een drie jarig project hebt, wil je zo snel mogelijk dingen opleveren, zodat de klant zo snel mogelijk kan beginnen met controleren of het is wat ie wil, en eventueel zo snel mogelijk kan beginnen met invoeren van data.

[GoBieN-Be]

Trouwens de compiler genereert toch dezelfde binaire code, comments worden niet gecompiled en korte if/else of volledige if/else worden op dezelfde manier gecompiled !

Dus vrouwelijke code genereert niet bij definitie tragere binary's

[PrisonerOfPain]

Korte if statements kunnen makkelijk naar een CMOV gecompileerd worden; daarbij introduceren if statements nog gewoon jumps terwijl lange conditionals dat niet doen.

Niet dat het verder ook maar iets uit maakt in de meeste gevallen; maar toch.

[.oisyn]

Onzin, semantisch is er niets anders aan een if-statement dan aan een conditional expression. Als de compiler besluit om bij de ene een conditional move te kunnen genereren dan kan ie dat bij de andere ook.

[latka]

Alle voorbeelden die ik tot nu toe heb gezien zijn, als ze al langzamer zijn, geen orde langzamer dus zou de impact minimaal zijn. Ik heb daarentegen code gezien van mannen die (per ongeluk) quadratische looptijden introduceerden door zo slim te programmeren dat niemand het door had (tot de profiler erop gezet werd...).

[Verwijderd]

Nee, Norton is gemaakt door een bende Spanjaarden - Mañana mañana. Tegen dat ze zelf opgestart zijn is Norton ook klaar, en de vertraagde werking van de computer komt hen ook goed uit. Tis niet voor niks dat ze tegen mij zeiden dat ik te snel werkte toen ik hier pas begon Hier gebruiken ze McAffee, al niet veel beter moet ik zeggen.

OT:
Comments dragen zeker bij tot overzichtelijkheid en goede naamgeving van variabelen ook. Ben een tijdje geleden bezig geweest met functionaliteit toevoegen aan een access applicatie gemaakt door amateurs. Ze hebben da nie slecht gedaan, maar de code is nie te volgen, zit erg onlogisch in mekaar, en er wordt enkel comments gegeven bij messageboxes (alsof die niet duidelijk maken wat er gebeurt ). Ik kan je verzekeren, het is een hels karwei om daar wijs uit te worden.

[Corrit]

Het hoeft nog niet perse langzamer te zijn, zeker niet bij de voorbeelden die hier in de reacties zijn genoemd. Maar inderdaad, als je kijkt naar de huidige pc's dan maakt de manier van coden qua snelheid weinig uit.

Daarnaast is het onderhoud van de code vaak minstens zo belangrijk, dus een beetje logische en begrijpbare code is nooit verkeerd.

[Keypunchie]

Luxe...in de huidige markt is het moeilijk genoeg om uberhaupt aan gekwalificeerde programmeurs te komen.

[MSalters]

Liever 0.1 seconde trager? We hebben het hier over database programmeurs. Als elke query 0.1 seconde trager is, dan is de onderhoudbaarheid irrelevant.

Kijk, voor een rapport dat je 1x per maand uitdraait maakt het niet uit. Dat is code waar je misschien 1x per jaar naar kijkt, dat moet onderhoudbaar zijn. Je moet alleen niet aannemen dat die norm universeel is.

[WhiteDog]

begrijpelijker != beter

Voor een beetje gevorderde programmeur leest die "cryptische" code even makkelijk als de "leesbare". Natuurlijk is breed uitgeschreven code makkelijker uit te breiden; maar het kan er wel trager op worden omdat je vaak onnodig checks zit uit te voeren.

[Verwijderd]

Onleesbare code schrijven wil niet zeggen dat je gevorderd bent. Je moet code leesbaar en herbruikbaar houden, ook voor minder gevorderden. Hedendaagse compilers zouden ervoor moeten zorgen dat leesbare code net zo efficient gecompileerd wordt als onleesbare geniale constructies van warrige coders. Voor die laatste zijn stoffige wedstrijden waarin je binnen bepaalde tijd een stuk onleesbare code in pseudo taal moet beschrijven. Het enige waar je voor op moet passen is dat je door je implementatie niet de complexiteitsklasse verhoogt van je algoritmes. Anders dan dat moet de compiler er maar wat moois van maken.

[MBV]

Vergeet ook niet dat je sneller een typfout maat in lange code. Maar ook compacte code kan duidelijk of onduidelijk zijn, afhankelijk van functie- en variabelenamen etc. Uiteraard moet je niet in de klassieke fout van veelTeLangeMethodNamenZoalsDatInJavaNogWelEensGedaanWordt(int metLangeVariabeleNamen) vallen, dat is dan weer het andere uiterste.

[Verwijderd]

Hmm, ik heb één keer met een vrouwelijke programmeur samengewerkt maar dat was niet zo'n goede ervaring ... als je moet werken met deadlines & stress, dan moet het gewoon werken je code dan heb je geen tijd om alles structureel te doen etc ... kgeef toe, je hebt dan wel dubbel werk achteraf maar als de baas wacht ...

[Sfynx]

als je moet werken met deadlines & stress, dan moet het gewoon werken je code dan heb je geen tijd om alles structureel te doen etc ... kgeef toe, je hebt dan wel dubbel werk achteraf maar als de baas wacht ...

Sterker nog, door die instelling zijn er genoeg projecten gefaald door overschrijding van budget of gewoon een niet onderhoudbare spaghetti applicatie terwijl het nog niet eens opgeleverd kan worden. Dat is altijd het gruwelscenario dat je bij "softwarekwaliteit en testen" colleges te horen krijgt

Verplichte deadlines en tijdsdruk zijn funest voor een softwareproject, omdat een goede architectuur en testplan uitwerken nou niet bepaald hoog op het prioriteitenlijste van de baas staat ("want dan komt er geen functionaliteit bij maar kost het me wel geld"). Terwijl dit het belangrijkste proces is van de hele rit.

Bijvoorbeeld geen testsuite bouwen "omdat het tijd en dus geld kost". Vervolgens wil de klant een aanpassing, jij fikst dat, je test wat je hebt aangepast (maar niet de rest, want geen testsuite!) en zet het in productie. Klant belt een paar dagen later op dat nu functie Y niet meer werkt en voor jouw aanpassing nog wel. Oeps

Maar meestal krijg je je baas niet aan het verstand dat zoiets kan gebeuren

[Fiander]

Ik ben echt blij dat ik een slimme baas heb.
Eerst een net ontwerp, daarna een volledige specificatie, gevolgt door testcode gescheven volgens de specificatie, gevolgt door de echte code.

ja, het kost meer ontwikkeltijd, maar er word zeer veel op debugtijd bespaart dat het gewoon rendabel is. ( volgens de baas dan.) verder is het natuurlijk voor hem ook heel makkelijk dat een nieuw iemand erg snel in de code kan inwerken.

[arjankoole]

waar kan ik soliciteren?

serieus, als ieder software huis zo'n baas aan het hoofd had dan waren bugs veel sneller gesquashed, en exploits een stuk zeldzamer.

[painkill]

Dit toont alleen dat vrouwen socialer zijn, een man maakt het zo dat het werkt, en dat hij het zelf snapt.

Een vrouwe maakt het zo dat het makkelijk te veranderen is, goed ingedeeld is, en met veel commentaar.

Ik zelf vindt het al goed als het goed werkt, en eerlijk gezegd, ik heb ook geen zin om bij elke actie een heel verhaal te typen waarom ik dat heb gedaan en wat het doet...

[Verwijderd]

Jij hebt dan waarschijnlijk ook niet zo vaak het 'genot' gehad om andersmans code te mogen bewerken....

Het is geen kwestie van veel commentaar, maar om uberhaupt commentaar toe te voegen! Een enkel regeltje commentaar kan ongelooflijk verhelderend zijn.

[? ?]

ach weet je, als je iemand anders zijn code moet aanpassen, dan moet je de code eerst begrijpen

ik heb een hekel aan mensen die eventjes vlug wat aanpassingen willen doen zonder te snappen wat de code eigenlijk doet of het het werkt.

als je mijn code wil veranderen, dan moet je moeite willen doen. goede code heeft trouwens weinig comments nodig imho, tenzij er iets gebeurd dat je niet zou verwachten. een toString() retourneert een string, als je daar een comment voor nodig hebt, dan hoor je hier niet thuis

en als je moeilijkheden hebt met schrijfwijzen of ternary operators, ga dan wat anders doen..

[Reactie gewijzigd door ? ? op 22 juli 2024 17:12]

[Sakkesa]

Kan jij me dan zeggen wat de toString methode van mijn klasse 'persoon' teruggeeft?
Dit kan de voornaam, achternaam, identiteitskaartnummer, adres, telefoon, geboorte- plaats en datum en alle combinaties ervan zijn.

[SPee]

In de meeste gevallen gaat het niet erom wat voor data je terug krijgt, maar meer welk type.
Als jij een toString() op Persoon doet, dan moet je er niet vanuit gaan dat deze een 'voornaam', 'achternaam','identiteitsnr', oid teruggeeft. Dan ben je gewoon fout bezig.
Als je die data wilt, moet je de betreffende functie op Persoon aanroepen.
Persoon.getVoornaam(), etc..

Wat als het gewoon de standaard waarde is? (bv. in Java classnaam@hash)

[Verwijderd]

als ik de methode naam goed lees is dit een Java methode die de toString() van java.lang.Object overschrijft. De methode Object.toString beschrijft wat jou methode min of meer zou moeten terug geven. Commentaar bij jou code is dus hoogstwaarschijnlijk dubbel, zinloos en overbodig.

Veel belangrijkere informatie lijkt mij dat je toString niet per ongeluk recursie introduceert, dat deze niet misbruikt wordt anders dan voor informatieve doelen (dus bijv. niet als een getKey() methode gebruiken), de context waarover de toString informatie verzamelt niet gewijzigd wordt en het liefst ook geen blokkades veroorzaakt (met bijv een synchronized).

Kortom een berg commentaar kan heel zinvol zijn, maar als de code die er tussen staat bagger is dan heb ik liever geen commentaar.

[Verwijderd]

Ik erger me nog het meest aan code waarbij excepties niet gedocumenteerd zijn...
Het kan maar zo makkelijk zijn:
<exception cref="SomeCustomException">Is thrown when...</exception>
(niet dat ik me er anders niet aan erger dat er geen commentaar aanwezig is, maar toch...)

[Reactie gewijzigd door Verwijderd op 22 juli 2024 17:12]

[Verwijderd]

Jij hebt dan waarschijnlijk ook niet zo vaak het 'genot' gehad om andersmans code te mogen bewerken....

Je opdrachtgever moet er ook nog voor willen betalen/investeren om dat te doen (!). Het zijn (helaas) niet allemaal professionele ict bedrijven.
'Als het maar werkt' 'het doet het toch' 'security is voor ons geen issue' 'dan vragen we jou toch'. En ik heb het allemaal mogen horen als ik aandrong om iets meer tijd in de code te steken en de reeds bestaande code eens te reviewen.
_{Maar het moest allemaal gisteren af en mag niks kosten, en zo'n handige jongen (of meid) die het snel werkend maakt is toch veel voordeliger dan iemand die wat neerzet waar je over 3 jaar nog wat aan hebt want dan is het allemaal toch al verouderd.}

[kemphaas]

Dat vrouwen in het algemeen wat netter en overzichtelijker werken is geen nieuws, dus waarom dan niet tijdens het programmeren?

[kiang]

Inderdaad: ik bv voeg bijna nooit comments toe aan mn code, dus ik verval al in het 'mannelijke' patroon, en dat vrouwen netter zijn geloof ik ook wel.:)

[XyritZz]

Het gaat hier over code die in bedrijfsmatige context geproduceerd wordt, ik neem aan dat elk bedrijf wel richtlijnen heeft met betrekking tot de hoeveelheid commentaar in code.

'Bijna nooit comments' toevoegen is er dan niet bij, omdat je dan wordt teruggefloten zodra je een commit doet.

Persoonlijk ben ik voorstander van elke methode voorzien van commentaar, ook al is het maar een getter of een setter. Daarnaast probeer ik mijn code er netjes uit te laten zien, if statements op één regel durf ik nog wel, maar zodra er een else bij komt ga ik er toch braces omheen zetten.

[MBV]

Ok, ik gebruik wellicht wat weinig comments, maar zoiets:

class person {
//...

String getFirstName() {
return firstName;
}
}

Dit vind ik nou niet echt slechter te lezen dan:
class person {
//...

/**
* Returns the first name of this person
* @return returns the first name
*/
String getFirstName() {
return firstName;
}
}

Sterker nog: zodra een functie niet meer op 1 scherm past, ben je het overzicht veel sneller kwijt. Bijzondere constructies moeten van commentaar worden voorzien, eens, maar om nou elk wissewasje van commentaar te voorzien... ik kan zo een bestand geven van 300 regels, waar niet 1 regel commentaar nodig is, mits voorzien van duidelijke variabelenamen. Als ik dat niet op mijn werk kan vinden laat ik wel wat automatisch genereren door een goeie IDE

offtopic:
waarom zijn al die forum-tags verwijderd

[Reactie gewijzigd door MBV op 22 juli 2024 17:12]

[XyritZz]

Klopt, dat is een discussie die ik vaak hoor maar ik heb mijn redenen om gewoon alles te voorzien van commentaar.

• 'Bijzondere constructies' wordt door iedereen anders gedefinieerd, dus waar leg je de grens en hoe beschrijf je die grens dat die bij iedereen duidelijk is? 'Alles' is veel duidelijker.
• Zodra je automatisch documentatie laat genereren zodat je het in een browser kunt bekijken is het prettig wanneer die gegenereerde documentatie compleet is.
• In talen als bijv. PHP zijn er IDE's die de documentatie blokken gebruiken voor auto completion, ook dan is het fijn om te weten dat de auto completion ook compleet is zodat je geen functies over het hoofd ziet.

[Verwijderd]

Zit er in editors geen onMouseOver Comment-functie? of show/hide comment functie?
Zodoende hou je het overzicht en is er toch ruimte voor heel veel commentaar.

[RoeLeerT]

java in ieder geval wel met JavaDocs dacht ik.

[Bobco]

Bijvoorbeeld NetBeans kan dat doen met JavaDoc. Het nadeel van veel commentaar is dat je het ook moet onderhouden. Als je een aanpassing in de code maakt waardoor het commentaar niet meer klopt zul je ook het commentaar aan moeten passen. Veel quick fixers slaan dit over waardoor er iets ontstaat dat helemaal erg is: code met commentaar dat niet klopt.

Wat dat betreft gaat er niets boven een peer review waarbij een stuk code kritisch bekeken wordt door de collega's. Zo'n review, mits serieus gedaan, kan een boel ellende afvangen. Het grote nadeel is natuurlijk dat het veel tijd en dus geld kost.

[peterh]

Vrouwen netter????
Ga maar eens op een openbaar vrouwentoilet kijken of op een mannentoilet, ik weet zeker dat elk vrouwentoilet smeriger is :-) (met hun 'gehang' boven de pot)