Open-sourcecode netter volgens wetenschappers

Uit een studie van de Aristoteles Universiteit van Thessaloniki in Griekenland blijkt dat open-sourcecode vaak netter is opgezet dan closed-sourcebroncode. Deze conclusie trekt de universiteit na het onderzoeken van vijf miljoen regels code van diverse softwareprojecten, waaronder een project dat deels met open en deels met gesloten bron werkte. Hieruit werd geconcludeerd dat open-sourcecode minstens even goed, zo niet beter, was dan closed-sourcecode met dezelfde functionaliteit. Volgens de onderzoekers is de prestatie van open-sourcecode te verklaren door het grote aantal ontwikkelaars en testers van de code, waardoor deze beter ontbugd en getest wordt. Een nadeel van open-sourcecode is volgens hen echter het gebrek aan documentatie en technische ondersteuning. Men is van plan de kwaliteit van de onderzochte projecten in de toekomst te blijven bijhouden om zo de analyse van open- en closed-sourcecode te kunnen verfijnen.

Reacties (57)

[BarôZZa]

Dat ze hier vijf miljoen regels code voor nodig hadden. Net zoiets als dat ze vijf miljoen grassprietjes gaan analyseren om te kijken of het groener is dan de lucht.

Dit is natuurlijk nogal logisch, opensource code wordt geschreven met een hele community in het achterhoofd, waardoor er logischerwijs meer aandacht wordt besteed aan de overzichtelijkheid en netheid van de code. Closedsource software wordt meestal ontwikkeld in kleinere teams, waardoor alleen zij de code hoeven te zien en het voor hun duidelijk moet zijn.

Als ik een stukje code of script op het internet post zorg ik ook altijd dat het er netjes uitziet. Al is het alleen maar om minder amateurisch over te komen. Als ik de enige ben die in de source kan kijken, dan maak ik er nogal eens een onoverzichtelijk zooitje van, zolang ik het maar begrijp.

@ erikdenv & Michali: het gaat erom dat ze dingen gaan onderzoeken waarvan vrijwel iedereen de uitkomst wel kan raden. Dat het de wetenschappelijke manier is is leuk, maar dan kan je alles wel gaan onderzoeken.

Iedereen die wel eens geprogrammeerd heeft snapt volgens mij wel dat je met de netheid van de code vooral rekening houdt met hoeveel mensen de code in zullen kijken.


@ mawashigeri:
Dat is het logische gevolg van hoeveel mensen de code moeten begrijpen. Bij een langdurig project moet je de code later nog kunnen begrijpen waardoor het duidelijker moet zijn. Bij een simpel applicatietje is het belangrijker dat het snel gerealiseerd wordt en goed functioneert. Een perfect opgemaakte sourcecode is dan gewoon in veel gevallen niet nodig en zou onnodig veel tijd in beslag nemen.


@ Otis:
Je bent een prutser, omdat wanneer je een applicatie voor jezelf schrijft, je de sourcecode niet netjes opfleurt met tabjes, de variabelen namen van 1 letter geeft etc? Wat een onzin. Ik maak ook geen strakke userinterfaces uitgebreide helpfunctiess en degelijke voor mezelf. Tijdsbesparing is op zo'n moment belangrijker dan een perfect opgemaakte code.

[erikdenv]

Dat iets logisch lijkt wil niet zeggen dat het ook zo is. Zij hebben bewijs verkregen door onderzoek te doen. Dat is de wetenschappenlijke manier.

[Verwijderd]

Err, nee. Zo gesteld is 'wetenschappelijk' een magisch woord dat de discussie zou stoppen.

Ik mis een verwijzing naar het onderzoek (en ben nu even te lui :-)). Maar waar ik benieuwd naar ben is de *objectieve* normen die ze stellen om tot dit oordeel te komen. Hoe meet je of twee functies hetzelfde doen? Hoe meet je dan of de ene beter is dan de ander? Veel commentaar kan zowel helpen als tegenwerken. Veel code kan generieker zijn; weinig code kan helderder zijn. En simpelweg een club ervaren programmeurs om een oordeel vragen is ook niet voldoende vanwege de kans op subjectiviteit.

Geen idee dus of dit goede wetenschap was!

[mawashigeri]

Iedereen die wel eens geprogrammeerd heeft snapt volgens mij wel dat je met de netheid van de code vooral rekening houdt met hoeveel mensen de code in zullen kijken.

Ik denk niet dat jij veel porfessioneel programmeerwerk doet... De netheid wordt voornamelijk bepaald door de verwachte levensduur van de code en hoe kritiek deze is.

Bij ons wordt alle productiecode door 2 mensen gereviewed, dus als je rommel aflevert dan krijg je het gewoon ongelezen terug--en terecht.

[Verwijderd]

Ik voorzie mijn code, zelfs shellscripts, php en zo, toch van commentaar en duidelijke structuur, ook als ze alleen voor eigen gebruik zijn. Door schade en schande wijs geworden, te vaak weet je een jaar later al niet meer wat voor slimme ingeving je ooit in je programma gestopt had, of wat voor aannames er aan ten grondslag lagen.

[Michali]

Beter dat ze het gewoon goed doen in plaats van 100 regels code van 1 programmeur gaan vergelijken oid. En gras met lucht vergelijken staat iets verder van elkaar dan code met code vergelijken lijkt me.

[EfBe]

Als ik een stukje code of script op het internet post zorg ik ook altijd dat het er netjes uitziet. Al is het alleen maar om minder amateurisch over te komen. Als ik de enige ben die in de source kan kijken, dan maak ik er nogal eens een onoverzichtelijk zooitje van, zolang ik het maar begrijp.

Dan ben je een prutser. Niet erg, maar een professional maakt gewoon code zoals hij denkt dat het hoort, of het nu voor hem/haarzelf, open source projectje of demo is, dat boeit niet.

Er zijn veel prutsers bezig software te schrijven, closed source, voor veel te veel geld en hebben visitekaartjes met 'software engineer' of nog erger 'senior ... ' erop, zonder dat ze veel opleiding hebben genoten of weten waar het over gaat. Code van dat soort wanhoopproducenten zie je dagelijks terug op www.thedailywtf.com . Echter in open source land kom ik net zoveel ellende tegen. Pak een willekeurig projectje van sourceforge en kijk in de code. Veelal mist er veel, "// here it goes wrong, don't know why..." crap en geen beschrijving waarom het zo is opgezet. Als dat dan 'netter' is dan kunnen we als beschaving niets anders doen dan vrezen voor de toekomst...

[wica]

eigelijk wel vreemd. dat er gebrek aan documentatie is. bij opensource.
Aan gezien er zeveel mensen aan werken.

Ok, er is wel documentatie. Maar of die altijd even duidelijk is

[SuperNull]

Het hangt van het project af.

De grotere bekendere OSS projecten zijn aardig goed geducumenteerd. Overige Informatie voor de developers staat in de source.

Je hebt echter een boel kleinere projecten met heel summiere documetatie. De programmeur(s) hadden gewoon geen zin om een uitgebeide duidelijke, ook voor n00bs leesbare, document te tikken.
Een mooit voorbeeld is Darkplaces, de Quake1 engine update/mod (dikke aanrader btw, zeker voor Linuxers).
Echt een gewelding programma maar een onoverzichtelijke site, en de enige documentatie is een featurelist, die je aandachtig door moet lezen om de info eruit de pikken over hoe je em moet gebruiken of uberhoupt compilen.

[wzzrd]

Sterker nog, het gaat juist om de documentatie die in de code zelf staat. Een los beschrijvend document waarin staat dat die functie vanaf regel 7592 iets doet is veel minder praktisch (als je gaat hacken althans) dan:

/* Deze functie doet dit en dit en wordt daar en daar voor gebruikt */
public function deze_functie(input) {
/* Let op met bla bla bla */
[...]
return true;
}

[wica]

Niet geheel mee eens.
Documantatie die beschrijft hoe je een functie moet aan spreken en welke @param's je kan gebruiken. IS denk ik toch handiger dan in de source te kijken.
Maar gelukkig zijn hier voor genoeg programma's die source omzetten naar documentatie.

Als ik in de source moet kijken hoe iets werkt. Krijg ik de indruk. Dat het nog vaak kan veranderen.

[Verwijderd]

De reden is: Documentatie schrijven is lang niet zo spannend als het uitdenken van een elegant stukje code.

[LauPro]

Dat lijkt me nogal een logisch gevolg. Wanneer je commercieel software aan het ontwikkelen bent dan is er vaak een deadline. En over het algemeen is de opdrachtgever er niet in geïnteresseerd dat de software de laatste libaries bevat met de laatste technieken.

Het moet gewoon werken, punt. Dat zorgt er voor dat je als ontwikkelaar concessies moet doen. Bij open source is deze tijdsdruk er over het algemeen genomen niet en kan men dus tijd uit trekken voor een technische goede oplossing ipv een commercieel verantwoorde oplossing.

[Gondor]

En over het algemeen is de opdrachtgever er niet in geïnteresseerd dat de software de laatste libaries bevat met de laatste technieken.

Daar gaat deze studie helemaal niet over. Ze hebben het niet over "laatste technieken/libaries" maar over het "beter ontbugd en getest" zijn van open-source code.

Bij open source is deze tijdsdruk er over het algemeen genomen niet en kan men dus tijd uit trekken voor een technische goede oplossing ipv een commercieel verantwoorde oplossing.

De ene sluit de andere niet uit.

En als je goed had gelezen zag je dat ze ook hebben gekeken naar een project wat deels open en deels closed code is. Of het nou commercieel was of niet, maakt dus niet uit.

[Skyclad]

Wat je vaak zal zien binnen software bedrijven is dat oudere code wordt 'gerecycled' wanneer een deadline nadert. Door de combinatie oude en nieuwe code kunnen dan onverwachte nieuwe bugs ontstaan, en wanneer het te vaak gebeurd is er niemand meer die echt precies weet hoe het in elkaar zit.

[coller]

vijf miljoen regels code

Inmiddels zijn de onderzoekers volleerde programmeurs

[Verwijderd]

Dat zijn ze sowieso al anders kan je niet over de kwaliteit van code oordelen?

[XyritZz]

Dat hoeft niet lijkt mij. Ik ben bezig Java te leren, en als ik code van iemand anders zie zou ik de kwaliteit ervan kunnen beoordelen aan de hand van de tijd die nodig is voordat ik het snap.

Goed opgestelde code, die goed gedocumenteerd is is een stuk makkelijker te begrijpen, ook voor de non-professional.

[Yoshi|IA2]

Das niet altijd waar denk ik...
Ik neem aan dat je al kennis hebt met een andere OO taal? Dan is het alleen syntax die je moet leren en ben je al een programmeur.
Maar het wilt niet zeggen dat goed opgestelde en gedocumenteerde code ook tegelijk begrijpbaar is voor iedereen...
Het is natuurlijk wel een feit dat goed opgestelde en gedocumenteerde code leesbaarder is dan dezelfde code zonder commentaar en documentatie.

[intGod]

Dat is niet waar. Met Syntax alleen kan je niet programmeren. Syntax leer je in een week - het maakt niet uit of het RPG II, Cobol, Pascal, Python of C# is. En dan ben je echt geen programmeur, hoor.

Je bent echt programmeur in een taal als je een paar jaar in die taal hebt geprogrammeerd, de limieten en de mogelijkheden kent en de API onder de knie hebt.

Je gaat iemand toch geen programmeur noemen omdat 'ie netjes een object kan aanmaken en vervolgens niet weet in welke library de teken-tools zitten?

[Olaf van der Spek]

Dat zijn ze sowieso al anders kan je niet over de kwaliteit van code oordelen?

Kunstkenners hoeven toch ook geen schilders te zijn?

[Verwijderd]

Kunstkenners hoeven toch ook geen schilders te zijn?

De meeste kunstkenners hebben toch wel een opleiding genoten die te maken heeft met kunst; dus om het werk van een schilder (programmeur) te beoordelen kan een opleiding wel degelijk helpen... Code kan er misschien wel mooi uitzien, maar daarom is de opbouw/structuur het nog niet.

[Verwijderd]

Ze hebben die code natuurlijk door zo'n tooltje gehaald wat de kwaliteit van de code beoordeelt. Niet dat ik RTFA (er staat ook geen link bij), maar dat lijkt me wel zo logisch.

Ik vraag me alleen af hoe ze aan 2,5 miljoen regels commerciele code zijn gekomen. Of zouden ze de SCO code die in Linux zit hebben geanalyseerd?

[Verwijderd]

De titel is een beetje misleidend. Het onderzoek concludeert dat Open Source code "minstens even goed is", zo niet beter. Overigens vind ik het gebrek aan documentatie en technische support VEEL zwaarder wegen dan "minstens net zo goede code"...

[Bobco]

Mja, wat is 'gebrek aan support'? Het bedrijf waar ik voor werk doet veel met Oracle spullen, maar af en toe moet je hemel en aarde bewegen (en lang wachten) voordat het Oracle behaagt om iets op te lossen.

De wat grotere OSS projecten hebben allemaal mailing lists waar ook de developers op meelezen. Daar kun je binnen een paar uur een antwoord en een oplossing krijgen, zonder dat je eerst langs iemand van 1e lijns support moet wiens enige toegevoegde waarde bestaat in het maken van typefouten in de ticket die ze moeten aanmaken

Als je zelf ontwikkelt is direct contact met ontwikkelaars vaak veel meer waard dan contact met de 'ondersteuning' van een commerciele software-verkoper.

[ILUsion]

Maar dit weerlegt natuurlijk het argument dat open-source gebouwd is op een 'stelletje amateurs'. Natuurlijk is het evident dat OSS nette kan zijn qua source, vooral bij grote projecten, omdat die ook eisen stellen aan de vorm van de code. Met closed source heb je natuurlijk een beperkte input van programmeurs en dus ook beperkte controle op de kwaliteit van de code zelf.

[EfBe]

Op wat baseer je je redenatie? In een closed source project hangt het lot van het bedrijf wellicht af van het project en doet men meer zn best. Bij open source werkt men eraan wanneer men zin heeft en dat kan wel eens lang duren waardoor het project erg lang in een slechte staat verkeerd.

Ook is het aantal mensen dat aan een gemiddeld open source project werkt niet zo bar groter dan bij closed source: ga jij maar eens 'even' wat bijbouwen aan een willekeurig open source projectje van, zeg, 100.000 regels. Voordat je alles snapt van die code en dus weet WAAR jij je spullen moet bijbouwen ben je wel even zoet.

[GeniusDex]

Het grote verschil zit hem dan ook in de 'community' die veel open source projecten hebben, die zelf ook meehelpen door een aantal patches te maken en door te sturen naar de ontwikkelaars.

[Little Penguin]

Nog geheel onlogisch dat open source code netter is dan closed source code. Als ik aan closed source coe werk, dan ben ik bezig voor een bedrijf en moet ik targets halen. Ik zal dan niet snel code van een ander herschrijven en ook eigen code die werkt niet verbeteren - dat kost namelijk tijd en als het werkt is het goed genoeg.

Ben ik echter voor mezelf bezig, dan is het niet erg om een stuk werk opnieuw te doen - er is niemand die mij verbied dat te doen en als ik er op korte of langere tijd beter van wordt is dat voldoende reden om de code te herschrijven. Open source is vaak hobby programmeren en de targets zijn vaak minder hard - kijk bijvoorbeeld maar eens naar de releases van Linux of Mozilla, er is wel een richtdatum maar dat is alles...

[Verwijderd]

Ik zal dan niet snel code van een ander herschrijven en ook eigen code die werkt niet verbeteren - dat kost namelijk tijd en als het werkt is het goed genoeg.

En JUIST als bedrijf moet je dat niet te veel doen. Een profesioneel zal een gedeelte van haar tijd inruimen om zo nu en dan wel code te gaan herschrijven alleen om helderheid, modulariteit, etc te verbeteren. Zou zij dat niet doen, dan zal het project naar verloop van tijd een steeds grotere spaghetti brei worden. (toekomstige) collega's van haar zullen dan steeds meer en meer moeite hebben om dingen toe te voegen, te wijzigen of te hergebruiken.

Ik zit momenteel op een project waarvan de programmeurs ook nooit het nut inzagen van code herschrijven zonder dat dit de functionaliteit veranderde. Precies jou gedachte gang dus: "Als het werkt, dan werkt het, maakt niet uit hoe ranzig de code eruit ziet".

Nu na een aantal jaren(!) begint zich dat zich enorm te wreken. Er kon bijna niets meer toegevoegd of veranderd worden. Door de onduidelijkheid van de code heb je tig versies van dezelfde functionaliteit dubbel in de code, gewoon omdat het te lastig is om bestaande code te hergebruiken.

Simpel voorbeeld: functies die meer doen dan ze moeten doen zoals het setten van een key en deze dan meteen naar kleine letters zetten omdat dat in een bepaalde context handig was. Als je dan in een andere context zit waar je juist hoofdletters moet hebben kun je die functie niet gebruiken. Je kunt hem zo zonder meer ook niet veranderen omdat er nog code is die juist verwacht dat de key automatisch kleine letters wordt. Dus wordt de key setting functie maar nogmaals geschreven in een andere versie. Vermenigvuldig zulke toestanden met 1000, en je hebt aardig rottige code.

Wat men al vanaf het begin had moeten doen is alle clients van bovengenoemde functie opsporen en herschrijven in 2 stukken: kleine letters maken, en dan het resultaat aan de key setting doorgeven.

Dergelijke simpele refactorings veranderen nix aan de uiterlijke functionaliteit en zou dus volgens Little Penguin nooit gedaan mogen worden voor produktie code.

Als je refactoring regelmatig doet blijft je code clean. Blijf je het uit stellen (de klant ziet het toch niet), dan is het op een gegeven moment te laat en mag je je hele systeem overnieuw gaan schrijven.

[EfBe]

Rare conclusie. Ik heb nogal wat open source code bekeken in mn leven en ik kan me alleen de Linux kernel herinneren als zijnde wel aardig clean opgezette code, de rest was echt pure wanhoop qua kwaliteit.

Wat ik ook mis is het aantal projects dat ze hebben bekeken en of dat representatief is. Niet het aantal regels code maar het aantal projecten is interessant EN of dat aantal een significante steekproef is. Anders kun je geen uitspraken doen. Immers: hun conclusie kan ook het gevolg zijn van de kwaliteit van de programmeurs die aan de projecten hebben gewerkt die ze toevallig hebben uitgekozen. Dus in feite kun je hun conclusie uitleggen als: de mensen die aan de geteste closed source projecten hebben gewerkt zijn grotere prutsers dan de mensen die aan de open source projecten hebben gewerkt.

Als laatste is 'netter' subjectief. Code zonder documentatie is sowieso niet 'netter', omdat het ontwerp niet duidelijk is, je moet daarvoor de code 'interpreteren'. Voor de slimmerikken onder ons: een mens is daar erg slecht in. "De code IS de documentatie" is een veelgehoorde kreet in open source land. Mensen die dat roepen hebben nog nooit code van anderen moeten aanpassen ZONDER een beschrijving wat het deed en waar wat en vooral WAAROM het zo werd gedaan.

[RetepV]

Het gaat natuurlijk wel om de code van NU.

"rendementen uit het verleden zijn geen garantie voor de toekomst"

enzo

En met 'de code IS de documentatie' bedoelen ze voornamelijk dat de documentatie in de code zit. Door middel van vaste constructies, die iedereen wel kent en die niet uitgelegd hoeven te worden (tenzij je weinig ervaring met programmeren hebt). En door middel van strategisch commentaar plaatsen.

Jij hebt wel veel kritiek op te weinig commentaar, maar in mijn ervaring is TE VEEL commentaar veel slechter. Zeker als er meerdere mensen aan de sources werken. Wat gebeurt er namelijk? De commentaren worden vrijwel NOOIT aangepast en zeker niet als het hele verhalen zijn. Commentaar wordt daardoor langzamerhand steeds misleidender.

Er is niks erger dan misleidend commentaar. Liever onleesbare code dan misleidend commentaar. Een beetje programmeur heeft genoeg ervaring om onleesbare code op te schonen zodat het wel leesbaar wordt. En als de code er lelijk uit ziet maar wel leesbaar/begrijpelijk is hoeft er dus ook niks opgeschoond te worden.

Tenzij je een Pietje Precies bent die meer waarde hecht aan netheid dan aan 'tijd=geld'. Tja, in dat geval moet je niet in de commercieele sector gaan werken, kan ik je alvast vertellen. Er zijn sectoren waar jouw karakter in dat geval VEEL meer gewaardeerd wordt.

Allemaal zelfopgedane ervaring hoor.

[Verwijderd]

De commentaren worden vrijwel NOOIT aangepast en zeker niet als het hele verhalen zijn. Commentaar wordt daardoor langzamerhand steeds misleidender.

Daarvoor is een simpele oplossing:

Gewoon WEL het commentaar mee aanpassen.

Ik weet ook wel dat dit iets makkelijker gedaan is dan gezegd, en dat je inderdaad altijd het risico hebt dat code en commentaar uit elkaar gaan lopen; het zijn nou eenmaap 2 verschillende dingen met dependencies die je meestal niet automatisch kan laten checken. (bv, de javadoc comments kunnen wel tot op beperkte hoogte automatisch gecontrolleerd worden).

Zowieso moet je commentaar ook als deel van je ontwikkeling zien. Niet zomaar ff slordig erbij pleuren omdat 'de baas vindt dat het moet', maar echt even voor gaan zitten en over nadenken voor een strategisch geplaatste comment is wel aan te raden. Wil of kun je dat niet doen dan kan de code inderdaad beter voorzich spreken en kan men beter geen comments neer zetten;

[Verwijderd]

De enige juiste beschrijving van wat code doet, is de code zelf. Dat is een onbetwistbaar feit, aangezien het deze code is die uitgevoerd wordt.

Bijgeleverde documentatie moet geen alternatieve 'leesbare' code zijn, maar achtergrond informatie leveren om de functie van de code in de juiste context te plaatsen. Het heeft immers totaal geen nut om programma code, ook nog eens in begrijpelijk engels om te zetten. Er zullen dan altijd grote verschillen tussen documentatie en code ontstaan, aangezien engels niet op dezelfde concepten is gebaseerd, minder expresief en minder expliciet is.

Het is heel belangrijk te leren hoe je code moet opschonen / lezen. Standaarden opleggen aan programmeurs m.b.t. hoe code geformat en beschreven moet worden zijn volledig zinloos. Dit is weer omdat formatering en de best code construktie van case tot case verschillen en elkaar beinvloeden. Praktiche technieken aanleren die je beter leren lezen, patronen herken of meer expliciet leren coderen zijn daarintegen extreem belangrijk.

Ter informatie, zeer weinig mensen zijn in staat code te lezen, maar ze schrijven het wel dagelijks als onderdeel van hun werk. Je hoeft niet geniaal te zijn om te realiseren dat er iets verschrikkelijk mis is. Dit 'iets' is namelijk het niet kunnen lezen, niemand leert het meer tegenwoordig. Realiteit is dat de meesten van ons code kloppen zonder werkelijk te weten wat we ingelkopt hebben. We denken het te weten, weten echter alleen de intentie, maar niet wat er werkelijk geschreven is. Gemaakte fouten blijven dan verborgen (tot de fout zich openbaard ).

Ik heb al heel wat code van onder handen gehad, en alleen door de code te lezen en globaal te weten wat het zou moeten doen, spoor ik dan fout op fout op. Heel knullige dingen meestal, totaal onnodig gemaake fouten, maar o zo duur om als bedrijf achteraf mee geconfronteerd te worden.

Toen ik leerde programeren (op 12 jarige leeftijd) waren er tal van tijdschriften die vol stonden met programma code. Deze code moest je dan overtypen om ze op je computer te laten werken. Werkelijk jaren heb ik (en vele van die tijd met mij) dit gedaan. Tijdens zo'n actie leer je een hoop, maar vooral leer je lezen wat het werkelijk is dat je typt en je herkend goede en slechte patronen in code.

Eenmaal op mijn opleiding heb ik iedereen alleen nog horen praten over hoe je code moet schrijven en de idiologische poeha daaromheen.

Maar code lezen.....wat is dat?

[EfBe]

De enige juiste beschrijving van wat code doet, is de code zelf. Dat is een onbetwistbaar feit, aangezien het deze code is die uitgevoerd wordt.

De grootst mogelijke onzin. Code is de executeerbare vorm van je functionele beschrijving. Als er geen functionele beschrijving is, is de code de enige leesbare functionele beschrijving. Er is echter een nadeel: programmacode is inmens slecht leesbaar voor de mens. Ga jij maar eens 100.000 regels code lezen en dan verklaren waar elke regel voor is. Dat kun je bij lange na niet, daarvoor moet je de code interpreteren alsof je het runt. Laat de mens daar nu net inmens slecht in zijn.

[Verwijderd]

Dit ontkracht mijn opmerking niet, je hebt de zin niet goed gelezen of begrepen. Ik vertelde dat mensen slecht code lezen omdat ze er niet in geoefend zijn. Nederlands leren lezen op school kost ook heel wat werk hoor, en dan ben je nog kind en leer je relatief snel!

En zoals ik reeds vertelde, de functie twee keer beschrijven (code en equivalent in commentaar) is onmogelijk .

Volgende keer de moeite nemen de gehele post te lezen, ok?

[JeroenTheStig]

Volgens mij mist in het stukje code wat onderaan het artikel staat na die if statement een ')'. Dan was dit zeker closed-source?

[Freee!!]

Nog een keer tellen, er ontbreken twee ")" (afgaande op wat ik kan zien) en volgens mij hoort er eerst nog minimaal één argument achter die komma op regel 35, dus ik denk dat er slechts een deel van die regel gepubliceerd is (slechte c/p-actie waarschijnlijk).

[Verwijderd]

het getoonde fragmentje in het tweakers artikel vind ik niet bepaald het summum van nette code:

meerdere returns in de functie!

waarom niet een if-else met een gemeenschappelijke return na de if-else?

of nog beter draai de if conditie om (neem het ! teken weg) en voer de 3 regels boven de laatste return alleen uit als de if waar is (niet alles overgetikt maar je krijgt het idee) :

if (THXMDIServer::WillBeMDIServer(THXA...)
{
THXApp* app...
assert...

app->Run...
}
return 0;


zal wel een closed source voorbeeldje zijn..

[Michali]

Dat heet gewoon een guard clause. Persoonlijk vind ik het prettiger om het wel op de eerste manier te doen. Anders kun je al snel te maken krijgen met meerdere indents wat je code er niet echt leesbaarder of uitbereidbaarder op maakt. En extra condities zijn dan vrij lastig toe te voegen.

[Verwijderd]

En zie hier waarom open source code netter is. Zelfs in reacties hier op de frontpage kunnen mensen het niet laten om commentaar op code of commentaar op het commentaar op de code te geven.... En waarschijnlijk over een paar uur nog vaker commentaar.

Pak al die commentaren bij elkaar en herschrijf je code... Tada ! Nettere code...

[Verwijderd]

Nee hoor... Veel coding technieken zijn geheel subjectief aan de persoon die ze programmeerd, zoals uit dit kleine voorbeeld ook blijkt. Dan kan er nog zo veel over gediscussierd worden, maar zal er nooit tot overeenstemming tussen de programmeurs gekomen kunnen worden.

[Michali]

@Wabbe:

Als je goed je je redenen goed onderbouwt, dan kun je echt wel iemand overtuigen over een betere manier van code schrijven. Anders was refactoring ook nooit ontwikkeld/ontdekt. Natuurlijk zitten er ook grenzen aan en kun je tot een bepaald niveau komen dat het niet meer (of veel minder iig) intresant is om de code verder te herstructureren. Dan komt het meer aan om simpele dingen als het plaatsen van de accolades en haken en naamgeving van variabelen en functies etc. Maar dat was in dit geval niet zo.

[jurrie]

Nou, zelf werk ik ook meer op de manier zoals die hierboven staat afgebeeld.

Je kunt natuurlijk met if-else blijven doorgaan, maar als het wat dieper gaat wordt het er niet duidelijker op..

krijg je van die leuke zooi als

if (a)
{
# code 1
if (b)
{
# code 2
if (c)
{
# etc etc
}
}
}
return 0;

Dan maak ik zelf liever

if (!a)
{
return 0;
}
# code 1
if (!b)
{
return 0;
}
# code 2

etc.

*edit* jemig, had ik dit artikel al meer dan 30 minuten open staan voor ik reageerde?

[Verwijderd]

"meerdere returns in de functie!"

Er zijn objectieve argumenten die in het voordeel van 'early exits' (returns/break) spreken, te weten:

* Je isoleert je code beter met als gevolg minder verborgen / onbedoelde afhankelijkheden.

Toelichting:

De techniek voorkomt dat onbedoeld andere code van invloed kan zijn op de werking van je functie. Je hebt tenslotte reeds bepaald dat je de loop of functie moet verlaten en met welk resultaat. Er is geen enkel praktisch of fuctioneel argument om dit uit te stellen tot aan het einde van de functie.

* Door betere code isolatie is gemakkelijker te bewijzen wat het effect van een wijziging is in een de deel van de code.

Toelichting:

Als iemand code moet toevoegen aan een routine die niet op de early exit manier geschreven is, zal dit meer tijd kosten. Het kan ze;fs onmogelijk vanweke zijn door onduidelijkheid over welke deels verborgen afhankelijkheden met opzet uitgevoerd worden en welke niet. Early exits zijn veel explicieter en dus duidelijker.

* Code met early exits is explicieter en leesbaarder door minder gebruik van indents. De stuctuur van de code is ook nog eens eenvoudiger!

Toelichting:

Je hoeft alleen het deel van de functie maar te bekijken waarvan je met zekerheid kan vaststellen dat het wordt uitgevoerd. Dit is dus de code voor de exit, en niet verder.

* De combinatie van scoping en deterministic termination van objecten (zoals met C++ objecten), maken efficienter coderen mogelijk.

Toelichting:

Het doel van een programeertaal is om te beschrijven wat wanneer en in welke volgorde uitgevoerd moet worden. Vanzelfsperekend met zo min mogelijk code en onvoorspelbaarheden.

Dit betekend dat je als programmeur slechts de minimaal benodigde 'informatie', van belang voor de werking vast moet leggen. De rest is functionel gezien overbodige bagage, en genereerd alleen maar risico's op bugs en onduidelijkheden tussen ontwikkelaars.

De combinatie van scoping en deterministic termination van objecten maakt het mogelijk objecten zelf te voorzien van voorspelbaar en configureerbaar gedrag. De scoping en early exits geven de compiler de informatie wanneer wat opgeruimd/uitgevoerd moet worden. De compiler genereerd dan alle benodigde code in de juiste volgorde, gegarandeerd foutvrij.

Opletten: Wat er dan precies uitgevoerd moet worden zit opgebroken in de code van het object, op 1 enkele plek. In plaats van 100 keer op verschillende manieren door het hele programma heen geplakt!

Hoe complexer het probleem des te meer voordeel je heb met deze technieken. Helaas leert men dit niet, alles gaat om de hype rondom commerciele produkten tegenwoordig.

De mythe van het niet moeten gebruiken van meerdere returns in een functie (en anderen) stamt uit de tijd dat scholen mensen leerden "programmeeren" door ze diagrammetjes te laten maken voor ze mochten coderen. Het zelfde werk twee keer dus, maar gebaseerd op de expressie mogelijkheden van een diagram op papier.

Lessen van toen waren puur op theorie en ideologie gebaseerd (veel ervaring was er niet). Helaas is het tegenwoordig niet veel beter, maar anders is het wel! Er is nu vooral veel aandacht voor puur ideologische features van talen en produkten, en nog steeds te weinig invloed van ervaring uit de praktijk.

Het bedrijfsleven blijkt ondertussen in opperste staat van verwarring gebracht te zijn. Ze is afhankelijk van opleidingen voor nieuwe mensen, maar weten ook niet meer op basis van opleiding wie ze nodig hebben. Men eist dus maar zo veel en hoog mogelijk, omdat het maar al te vaak tegen lijkt te vallen. Benodigde visie in de IT branche ontbreekt om dit te veranderen. Wij zijn tenslotte een handelsnatie met een handelsgeest en niet een kennis economie zoals vaak geroepen. De cultuur en de besluitvorming is er gewoon niet naar. Altijd willen verkopen op prijs en een voorspelde goed verkopende droom en niet op basis van kwaliteit en werkelijk resultaat.

Vanuit dit standpunt zijn vooral de hogere IT opleidingen en de bijbehorende leerstof dus een soort van zichzelf vervullende legende aan het worden. Een soort van success by failure situatie.....

[Verwijderd]

Deze code vind ik niet netjes. Kijk maar naar het accolade gebruik en de haakjes. Niet consequent.

[endless]

Misschien is dit een voorbeeld van closed source software...
Lijkt mij best logisch dit, open source is open source omdat het dan bewerkt kan worden, en bewerken doe je makelijker als je weet wat er staat.

Dit hoeft bij closed source software dus niet.

[mjtdevries]

Bewerken doe je ook makkelijker als de code goed gedocumenteerd is.
Daarom is het dan weer erg vreemd dat dat juist bij open source weer slecht gedaan schijnt te worden.

(Wellicht toch weer het oude spreekwoord: if it was hard to code, it should be hard to read)

[Verwijderd]

in de zin van complexiteit ja, niet door er een ranzige on overzichtelijke zooi van te maken.