Hoofdcategorieën

[RSS] Index » Nieuws » Pro » Development » 'Vrouwelijke sourcecode is beter te begrijpen'

'Vrouwelijke sourcecode is beter te begrijpen'

Door Mick de Neeve, maandag 9 juni 2008 19:24, views: 29.136

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.

vrouwelijke nerd 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.

Volgende 20:27
Vorige 18:55

Categorieën

Gerelateerde artikelen

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 184 reacties zichtbaar1840 Neutraal: 131 reacties zichtbaar131+1 Meerwaarde: 33 reacties zichtbaar33+2 Verplicht leesvoer: 1 reactie zichtbaar1
«  1  2  3  4  5  6  »

Door sofilus, maandag 9 juni 2008 19:25

Score: 0
Misschien is dit gewoon omdat vrouwen dat nodig hebben om hun eigen programma te begrijpen? :D

Door starwave, maandag 9 juni 2008 19:46

Score: 0
Ik doe een poging:

'Mannelijke code':

OkButton.Enabled = !String.IsNullOrEmpty(PasswordTextBox.Text);

'Vrouwelijke code':

If(!String.IsNullOrEmpty(PasswordTextBox.Text)) {
OkButton.Enabled = true;
} else {
OkButton.Enabled = false;
}

Of sla ik nu de plank mis?

Trouwens vind ik het maar BS. Je hebt gewoon Nerdy wiskundig gefundeerde code en je hebt code van mensen met minder wiskunde-inzicht maar meer taalgevoel. Die laatsten schrijven weliswaar iets meer code, maar ze produceren sneller resultaat en 't is voor beginners makkelijker te begrijpen. Om dat nu vrouwelijk te noemen....

Wil je mensen trekken die begrijpelijke code schrijven? Begrijp dan dat code vaak taal is, en dat je voor veel dingen de wiskunde eruit moet gooien. Wie weet komen er dan ook eens andere mensen op IT opleidingen af dan de 'exacte vakken mensen'.

Edit: Else erbij

[Reactie gewijzigd door starwave]

Door Jaap-Jan, maandag 9 juni 2008 19:52

Score: 0
Die code is niet hetzelfde. ;)

Wat als OKbutton al enabled is? Dan wordt hij niet disabled bij de 'vrouwelijke code'.

Door starwave, maandag 9 juni 2008 19:54

Score: 0
Woops, en dat was juist het grote 'voordeel' van de eerste variant. :+

Door al-ahlex, maandag 9 juni 2008 20:00

Score: 1
De code doet wel hetzelfde, het enige verschil is dat de boolean rechtstreeks gebruikt wordt ipv via de overbodige if/else construct.

Het is een beetje typisch voor beginnende of minder vlotte programmeurs om constructs te gebruiken waar simpele assignments even goed werken. Dit komt vermoedelijk omdat je dan meer de "flow" van de code meer ervaart zoals de eindgebruiker die ervaart. Ik weet niet of dit iets typisch vrouwelijks is maar kan het me wel voorstellen.

Door Webgnome, maandag 9 juni 2008 20:23

Score: 0
of het typisch voor beginnende of minder vlotte programmeurs is kan ik geen oordeel over geven maar wat ik wel weet is dat het een stuk makkelijker leest. Nu is dit voorbeeld natuurlijk niet zo heel duidelijk maar er zijn situaties denkbaar waarbij 10 regels die hetzelfde doen als 1 regel de voorkeur hebben.

[Reactie gewijzigd door Webgnome]

Door Kevinp, dinsdag 10 juni 2008 08:35

Score: 0
ja, en dat is dus het precies. je moet die eerste regel 3x nakijken voordat je door hebt wat er gebeurd terwijl zo'n if then else constructie vele malen makkelijker leest voor een latere gebruiker. Zeker als hij/zij die eerste constructie niet gewent is.

En ik denk dat het qua performance ook niks uitmaakt. Zeker niet in normale windows omgevingen.

Door divvid, maandag 9 juni 2008 22:09

Score: 1
Het is een beetje typisch voor beginnende of minder vlotte programmeurs om constructs te gebruiken waar simpele assignments even goed werken.
totdat je na 3 jaar ineens weer je eigen code nodig hebt. Dan ben je heeeel erg blij als er geen cryptische taal staat zonder comments.

Door graey, dinsdag 10 juni 2008 00:05

Score: 0
Dus: schrijf cryptische taal (als dat korter is en daarvoor korter duurt om uitgevoerd te worden zeker) en geef duidelijk commentaar.

Door Levvie, dinsdag 10 juni 2008 02:51

Score: 1
Let wel op dat er maar in beperkte mate een verband is tussen codelengde en uitvoeringstijd. bvb triviaal een boolean omzetten naar string:

public String b2s(boolean b) { return b ? "true" : "false"; }

of

// Functie die een boolean waarde omzet naar zijn string representatie
public String booleanToStringConvertor ( boolean aBooleanValue ) {
// We testen de waarde van aBooleanValue
if(aBooleanValue == true) {
// de waarde van aBooleanValue is waar, dus we geven "true" terug
return "true";
} else {
// als de waarde van aBooleanValue niet waar is moet ze dus vals zijn en geven we "false" terug
return "false";
}
}

Zal exact hetzelfde compileren en in uitvoeringstijd niets verschillen.

Bovendien is in software ontwikkeling uitvoeringstijd (meestal) van ondergeschikt belang tov leesbaarheid van code. Bij de initiële implementatie van code zal het langer duren om iets te schrijven, maar in de long run zal je er altijd bij winnen (debuggen, aanpassen code,...)

Door RoeLeerT, dinsdag 10 juni 2008 08:38

Score: 0
if(aBooleanValue == true) is een beetje dubbelop vind je ook niet?

doe gewoon if(aBooleanValue){

Door MSalters, dinsdag 10 juni 2008 11:02

Score: 1
Het is lastig uit te leggen waarom if (a==true) fout is. De meest makkelijke manier die ik gevonden heb is doorredeneren. Als if (a==true) goed is, dan is if ((a==true)==true) beter, en if (((a==true)==true)==true) nog beter.
Conclusie: een test op een boolean wordt minder leesbaar door er een overbodige ==true achter te plakken. Dus de simpele if(a) vorm is het beste.

Door breen, dinsdag 10 juni 2008 12:45

Score: 1
Daar ga ik niet met akkoord.

if (a==true) stelt duidelijk dat men op zoek is naar een waarde true in variabele a. bij if (a) wordt iedereen verondersteld te weten dat men op zoek is naar true als waarde.

Daar nog een ==true achter plaatsen heeft echter geen nut, en is niet het resultaat van dezelfde redenering als de eerste ==true.

if (a==true) is volgens mij weldegelijk duidelijker dan if (a).

Door Bobco, dinsdag 10 juni 2008 10:19

Score: 0
En ook hier kun je natuurlijk eindeloos commentaar op geven. Het commentaar in de tweede is heel erg uitgebreid en voegt, IMHO, ook niets toe. Bovendien zien sommigen een method met meerdere exit points als een 'fout'.

Door Wiegje, dinsdag 10 juni 2008 10:33

Score: 0
return aBooleanValue.ToString();

Door ffb, dinsdag 10 juni 2008 10:58

Score: 0
"...waarmee ze volgens haar willen laten zien hoe slim ze zijn."

Zit ik hier een pagina vol code te lezen... 8)7

EDIT: bovendien vraag ik me af of er nog een verschil zit tussen WO programmeren en HBO/MBO.. lijkt me dat de eerste nu eenmaal van een hoger niveau is.. Geen idee overigens wat jullie voor zooi hier neerzetten...

[Reactie gewijzigd door ffb]

Door Mic2000, maandag 9 juni 2008 22:44

Score: 0
Toch zou ik graag een voorbeeld willen zien van vrouwelijke programmeurs, en dan bedoel ik uiteraard die vrouwen die genoemden worden in dit artikel. Ergens mee pronken is leuk, maar harde feiten geef ik iets meer om.

Door tuXzero, dinsdag 10 juni 2008 11:41

Score: 0
Net zulke harde feiten als: "Vrouwen kunnen twee dingen tegelijk" of "mannen rijden beter" ?

Door SuperDre, maandag 9 juni 2008 21:49

Score: 0
uhm.. als de OKbutton al enabled is dan wordtie OF disabled, OF Enabled ofwel de button is na het if statement altijd in de correcte stand..

Door Tiara, dinsdag 10 juni 2008 00:47

Score: 0
Naast de hierboven al gemelde commentaar-commentaren (hah, ik ben man), zit ik qua code te denken aan een ingewikkelde maar oh-zo-slimme! (?) constructie van geneste ternary operators door mannen tegenover overzichtelijke if/then/elsjes door het schonere geslacht.

Door RocketKoen, maandag 9 juni 2008 19:54

Score: 0
denk aan man:
*OK button enabler
OkButton.Enabled = !String.IsNullOrEmpty(PasswordTextBox.Text);

vrouw:
* Enables the OK button when the password field is not empty
OkButton.Enabled = !String.IsNullOrEmpty(PasswordTextBox.Text);

Door PuzzleSolver, maandag 9 juni 2008 20:13

Score: 0
Denk aan

"Vrouwelijk code"
try
{
   Boolean WachtwoordIsLeeg = (PasswordTextBox.Text == "")
   Boolean NaamIsLeeg = (NameTextBox.Text == "");

   //Als de naam of het wachtwoord nog niet is ingevuld dan mogen we niet verder
   if (WachtwoordIsLeeg | NaamIsLeeg)
     OkButton.Enabled = false;
   else
     OkButton.Enabled = true;
}
catch
{
   //Hier ging iets mis ?
   OkButton.Enabled = false;
}

"Mannelijke code"
OkButton.Enabled = !(String.IsNullOrEmpty(PasswordTextBox.Text) ||
         String.IsNullOrEmpty(NameTextBox.Text)) ;

:+

[Reactie gewijzigd door PuzzleSolver]

Door Jorden Verwer, dinsdag 10 juni 2008 00:33

Score: 0
Ah, dus vrouwen gebruiken het vreselijke concept van software exceptions terwijl mannen gewoon fatsoenlijk programmeren.

Conclusie: mannen programmeren beter. :Y)

Door L4m0r, dinsdag 10 juni 2008 00:55

Score: 0
Als je op basis van dat voorbeeld die conclusie trekt hoop ik dat jij NOOIT voor je werk gaat programmeren.
De 2e versie is totaal zonder foutcontrole, de 1e is weliswaar bloated.. maar wel stukken beter dan de 2e.

Door MadEgg, dinsdag 10 juni 2008 11:46

Score: 0
Exceptions zijn werkelijk verschrikkelijk en je code wordt er bloated en onoverzichtelijk van. Een van de redenen dat ik een hekel heb aan java, waar ze je opgedrongen worden.

Foutafhandeling kan je op een veel nettere manier doen. En zeker in het gegeven voorbeeld is het waardeloos, want er wordt een foutafhandeling gedaan.

Dit zou net zo goed zo kunnen:

if (PasswordTextBox.Text
Boolean WachtwoordIsLeeg = PasswordTextBox != null ? WachtwoordIsLeeg = PasswordTextBox.Text == "" : false;
Boolean NaamIsLeeg = NaamIsLeeg != null ? NameTextBox.Text == "" : false;

//Als de naam of het wachtwoord nog niet is ingevuld dan mogen we niet verder
if (WachtwoordIsLeeg | NaamIsLeeg)
OkButton.Enabled = false;
else
OkButton.Enabled = true;


Vooruit, de ternary operator zou je nog uit kunnen schrijven, maar die exceptions zijn echt zwaar overbodig. Het gebruik van exceptions geeft eigenlijk gewoon aan dat je niet weet hoe je code in elkaar steekt en waar er fouten op kunnen treden, zodat je gewoon alle fouten maar lekker bij elkaar gooit en de boel blokkeert als er iets 'onverwachts' optreedt.

Door Jorden Verwer, dinsdag 10 juni 2008 16:41

Score: 1
Of foutcontrole hier wel of niet noodzakelijk is is totaal afhankelijk van de context, die er niet is. Maar waar het mij om gaat is dat exceptions:

-Lelijke, onleesbare code opleveren.
-De programmeur uitnodigen om niet na te denken over wat er allemaal mis kan gaan en per geval de juiste aanpak te hanteren, maar gewoon alles op een hoop te gooien.
-Het verband eruithalen tussen de plaats waar een fout kan optreden en de plaats waar de fout wordt afgehandeld.
-Het mogelijk maken dat je program flow compleet vernaggeld wordt, waardoor je daar weer rekening mee moet houden in talen die je verplichten exceptions te gebruiken of als je een library gebruikt die aan exceptions doet. Om dan nog een beetje een normale programmeerstijl aan te kunnen houden wordt je eigenlijk gedwongen wrappers te schrijven voor elke functie die eventueel een exception zou kunnen opleveren.
-Slecht zijn voor de performance.

Dat punt wilde ik op een ludieke manier maken, zonder meteen een hele discussie aan te zwengelen. Maar ja, dat is natuurlijk ook eigenlijk gewoon onvermijdelijk.... ;)

Door barfieldmv, dinsdag 10 juni 2008 08:00

Score: 0
Ah nee status code 3 en 4 afvangen werkt veel beter.

Ach weet je niet wat status code 3 en 4 beteken jammer voor je.......

^
Exception based werkt gewoon lekker
3 TripleLoginFailedException
4 IllegalSourceIpException

Door Ghoztmaster, maandag 9 juni 2008 23:55

Score: 0
Snap jouw voorbeeld niet echt, vindt namelijk de bovenste code gemakkelijker te lezen dan de onderste.

Door kemphaas, maandag 9 juni 2008 19:26

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

Door kiang, maandag 9 juni 2008 20:12

Score: 0
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.:)

Door XyritZz, maandag 9 juni 2008 22:55

Score: 1
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.

Door MBV, maandag 9 juni 2008 23:10

Score: 1
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]

Door XyritZz, maandag 9 juni 2008 23:18

Score: 1
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.

Door DAN900, dinsdag 10 juni 2008 00:46

Score: 0
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.

Door RoeLeerT, dinsdag 10 juni 2008 08:43

Score: 0
java in ieder geval wel met JavaDocs dacht ik.

Door Bobco, dinsdag 10 juni 2008 10:24

Score: 0
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.

Door aegiz, maandag 9 juni 2008 19:34

Score: 0
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.

Door Keypunchie, maandag 9 juni 2008 19:36

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

Door Sfynx, maandag 9 juni 2008 20:12

Score: 1
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 :P

[Reactie gewijzigd door Sfynx]

Door Fiander, maandag 9 juni 2008 20:41

Score: 1
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.

Door YopY, maandag 9 juni 2008 23:12

Score: 0
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.

Door Fiander, dinsdag 10 juni 2008 08:40

Score: 0
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.

Door GoBieN-Be, maandag 9 juni 2008 20:20

Score: 1
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

Door PrisonerOfPain, maandag 9 juni 2008 20:39

Score: 0
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.

Door .oisyn, maandag 9 juni 2008 23:11

Score: 0
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.

Door latka, maandag 9 juni 2008 22:52

Score: 0
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...).

Door Fangta, dinsdag 10 juni 2008 12:49

Score: 0
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.

Door Sfynx, maandag 9 juni 2008 20:20

Score: 1
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]

Door Corrit, maandag 9 juni 2008 20:32

Score: 1
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.

Door MSalters, dinsdag 10 juni 2008 11:09

Score: 0
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.

Door painkill, maandag 9 juni 2008 19:36

Score: 0
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...

Door AHBdV, maandag 9 juni 2008 20:22

Score: 1
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.

Door SMa, maandag 9 juni 2008 21:35

Score: 0
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 SMa]

Door era.zer, maandag 9 juni 2008 21:55

Score: 0
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 era.zer]

Door Sakkesa, dinsdag 10 juni 2008 09:54

Score: 0
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.

Door SPee, dinsdag 10 juni 2008 10:24

Score: 0
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)

Door DikkeDouwe, dinsdag 10 juni 2008 18:04

Score: 0
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.

Door friek25, woensdag 11 juni 2008 06:19

Score: 0
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.

Door Thav881, maandag 9 juni 2008 19:36

Score: 0
De meeste spaghettie programma's zijn door mannen gemaakt, zij beginnen vaak zomaar en zien dan wel waar zij eindigen, terwijl vrouwen eerst alles op een rijtje zetten.

Door Selsery, maandag 9 juni 2008 20:25

Score: 0
Dat is natuurlijk een wan argument. Ik denk persoonlijk dat beginnende programmeurs dezelfde fouten maken, zei het man of vrouw. Mannen hebben inderdaad meer spaghetti code gemaakt dan vrouwen. Simpelweg omdat er meer code is geschreven tot op heden door mannen dan door vrouwen. (Naar mijn idee)

Door Beelzebassie, maandag 9 juni 2008 19:38

Score: 0
"Real Programmers don't comment their code. If it was hard to write, it should be hard to understand and even harder to modify."

;)

Door RocketKoen, maandag 9 juni 2008 19:56

Score: 0
wel goed voor je baanzekerheid ;) als ze het zonder je niet meer snappen blijven ze je altijd nodig hebben.
niet goed voor je promotie kansen, aangezien ze je op de plek waar je zit nodig hebben. en code die niemand snapt niet handig is in je portefolio ed

Door Fiander, maandag 9 juni 2008 20:43

Score: 1
Nee hoor, als we het niet snappen, staat vanaf morgen je bureau in de gangkast, en herschrijven we alles.

Door RoyBijster, maandag 9 juni 2008 19:39

Score: 1
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.

Door MicroVirus, maandag 9 juni 2008 19:52

Score: 1
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.

Door n4m3l355, maandag 9 juni 2008 20:07

Score: 1
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.

Door i-chat, maandag 9 juni 2008 20:38

Score: 1
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).

Door Fiander, maandag 9 juni 2008 20:46

Score: 0
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.

Door YopY, maandag 9 juni 2008 23:15

Score: 0
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.

Door Fiander, dinsdag 10 juni 2008 08:45

Score: 0
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.

Door DutchCommando, maandag 9 juni 2008 19:57

Score: 0
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!

Door AHBdV, maandag 9 juni 2008 20:29

Score: 1
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.

Door SPee, dinsdag 10 juni 2008 10:32

Score: 0
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 :)

Door Rey Nemaattori, maandag 9 juni 2008 21:45

Score: 0
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]

Door freedzed6, maandag 9 juni 2008 19:39

Score: 0
vrouwlijke broncode is helemaal niet makkelijker, ze begrijpen mannen gewoon niet.

Door arjankoole, maandag 9 juni 2008 21:09

Score: 0
wel, ik lees de sourcecode van de (helaas vrij zeldzame) vrouwelijke programmeur bij mij op m'n werk een stuk makkelijker dan dat van de heren. De code van de enige dame bij ons op dat gebied zit duidelijker en eleganter in elkaar, en ik persoonlijk kan er vrijwel nooit iets op aanmerken. (maar, ik kan code lezen, ik ben geen developer)
«  1  2  3  4  5  6  »

Op dit item kan niet meer gereageerd worden.

Volgende 20:27
Vorige 18:55
VNU Media logo Powered by True

© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden

Uitgever van: