[Algemeen] Hoeveel fouten per 1000 regels code?

[Verwijderd]

Er is zo'n uitspraak "Er zijn x bugs per 1000 regels code". Dit gegeven wil ik in een presentatie gebruiken, maar nu kan ik niet precies vinden hoeveel bugs er precies zijn per 1000 regels code. Ik zie op internet getallen tussen 4 en 10.

Weet iemand hier misschien waar die uitspraak vandaan komt (is er een onderzoek geweest ofzo) of hoeveel 't moet zijn? Ik kan natuurlijk op 7 gokken, 't is ook niet zo belangrijk maar 't zou wel leuk zijn als 't klopt

[Haan]

Wat is er mis met het noemen van tussen 4 en 10? Dat is toch ook duidelijk genoeg? Ik vind dat eigenlijk beter dan het noemen van 1 bepaald getal.

[pjvandesande]

Hang denk ik ook helemaal van de ontwikkeling af, als jij je goed houd aan TDD dan blijkt iig bij me eigen code er nog maar weinig fouten zitten bij de release build.

[gorgi_19]

En wat definieer je als een fout?

[Verwijderd]

Voor zover ik weer zijn het er tussen de 5 en de 100 per 1000 regels code.

[Gé Brander]

Kan iemand verklaren waarom dat toch zo is? Waarom is het zo moeilijk om minder fouten te maken? Ik begrijp heus wel dat waar mensen werken, er fouten gemaakt worden, maar als je kijkt naar 5-100 fouten per 1000 regels code... Dat is maximaal 10% van de code fout. Onacceptabel toch?

Dus hoe komt het? Slordig programmeren? Niet goed met je hoofd bij je werk zijn? iets anders?

[Reptile209]

Het maakt ook nogal uit of het dan gaat om syntax-fouten, runtime-problemen of echte design-fouten, lijkt mij zo.

[PowerSp00n]

Als je rond de 100 fouten per 1000 regels code hebt vraag ik me af of je sowieso wel aan het testen bent geweest. Afhankelijk natuurlijk wanneer je de fouten meetelt als 'fout', voordat je gaat testen al beginnen met tellen of pas als je tot een 'stable' release bent gekomen.

[pjvandesande]

c70070540 schreef op zondag 20 februari 2005 @ 14:35:
Kan iemand verklaren waarom dat toch zo is? Waarom is het zo moeilijk om minder fouten te maken? Ik begrijp heus wel dat waar mensen werken, er fouten gemaakt worden, maar als je kijkt naar 5-100 fouten per 1000 regels code... Dat is maximaal 10% van de code fout. Onacceptabel toch?

Dus hoe komt het? Slordig programmeren? Niet goed met je hoofd bij je werk zijn? iets anders?

Ja, van elke 1000 regels code heb ik wel een hoop syntax fouten, maar deze zijn weg voor de release build. Bij de debug build worden ze al onderschept door de compiler.

Maar ik denk dat TDD hier een handje bij kan helpen. Hierdoor heb ik eigelijk nog maar weinig bugs in me software zitten.

Ik vind 10% wel heel erg veel eigelijk!

[NMe]

Ik heb laatst een presentatie van een ervaren tester bijgewoond, en die vertelde iets over 5-15 fouten per 1000 regels. Zijn bedrijf "eist" vaak maximaal 5 fouten per duizend regels, en dat is niet misselijk.

[T-MOB]

c70070540 schreef op zondag 20 februari 2005 @ 14:35:
Kan iemand verklaren waarom dat toch zo is? Waarom is het zo moeilijk om minder fouten te maken? Ik begrijp heus wel dat waar mensen werken, er fouten gemaakt worden, maar als je kijkt naar 5-100 fouten per 1000 regels code... Dat is maximaal 10% van de code fout. Onacceptabel toch?

Dus hoe komt het? Slordig programmeren? Niet goed met je hoofd bij je werk zijn? iets anders?

In één regel kun je natuurlijk meerdere fouten maken. Maximaal 10% van de code fout is dan een beetje overdreven.
Als ik zelf een scriptje van 300 regels in elkaar bak dan ben ik iig blij als er maar 10 foutjes in zitten. Een haakje vergeten hier, quote'je vergeten te escapen daar. En dan zijn die 300 regels ook nog eens inclusief comments en lege regels. Gok dat het aardig richting de "10%" gaat qua echte regels code. Na de eerste tests zijn die fouten er echter uit (en dan blijven alleen de fundamentale fouten over ... )

[GG85]

Zelf wel eens geprogrammeerd? Ik zou zeggen ga je gang en maak een programma van 100 regels.....

[Orphix]

Mijn ervaring is dat het veel moeilijker is om 5 fouten / 1000 regels na te streven bij een programma van 20.000 regels, dan bij een programma van 1000 regels. Je moet ook kijken naar de context. Daarnaast spelen de requirements ook een grote rol. Er wordt gewoon minder tijd (=geld) besteed aan het mooi anti-aliasen van excel diagrammen dan het positioneren van de hubble telescoop.

Trouwens misschien is het wel aardig om te kijken welke methodieken de NASA gebruikt, ik heb regelmatig gelezen dat zij zeer strenge eisen stellen aan hun software.

[Alarmnummer]

Bij ongecompileerde talen (lees scripttalen) zal het aantal fouten denk ik sowieso al vele malen hoger zijn dan gecompileerde talen. Het argument dat je in een scripttaal sneller kan werken dan een niet scripttaal zal met een krachtige ide ook totaal in het water vallen als je kijkt wat hier voor mogelijkheden beschikbaar zijn.

Tevens zal een stuk software dat goed geunit test is ook minder fouten bevatten dat een stuk software dat niet geunit test is. Ik heb nog niet veel script omgevingen gezien waarbij unit testen werd toegepast.. (getuigt imho ook al van de kwaliteit ervan)

[ Voor 14% gewijzigd door Alarmnummer op 20-02-2005 15:13 ]

[NMe]

Alarmnummer schreef op zondag 20 februari 2005 @ 15:12:
Bij ongecompileerde talen (lees scripttalen) zal het aantal fouten denk ik sowieso al vele malen hoger zijn dan gecompileerde talen. Het argument dat je in een scripttaal sneller kan werken dan een niet scripttaal zal met een krachtige ide ook totaal in het water vallen als je kijkt wat hier voor mogelijkheden beschikbaar zijn.

En waarom denk je dat een scripttaal zoveel meer fouten oplevert? Zonder onderbouwing is dit nogal een bullshit statement. Neem bijvoorbeeld C++ versus PHP. De syntax is vrijwel hetzelfde, met als kenmerkendste verschil dat PHP niet strongtyped is. Noem eens één reden waarom er dan in een PHP-script meer fouten zouden zitten dan in een C++ programma. Er is maar één ding waar het aantal fouten nog altijd grotendeels vanaf hangt, en dat is van de programmeur van het stukje software.

Tevens zal een stuk software dat goed geunit test is ook minder fouten bevatten dat een stuk software dat niet geunit test is. Ik heb nog niet veel script omgevingen gezien waarbij unit testen werd toegepast.. (getuigt imho ook al van de kwaliteit ervan)

Er zijn meer dan genoeg andere soorten testen die je uit kan voeren op een script.

Ik weet dat jij Java-fan bent, en af en toe druipt het van je posts af dat alles wat niet Java is, niet goed is. Ik ben bang dat je toch moet kijken naar waar een taal voor ontworpen is, en daarna pas oordelen over de kwaliteit. Bij Java kun je unit testen. Bij veel scripttalen niet. Dus? Scripttalen hebben weer andere voordelen.

[Peter]

Qua PHP zit ik op dit moment tussen de 4 en 8 foutjes per 1000 regels, toch best acceptabel =)

[edit] Waar de uitspraak vandaan komt? Ik denk gewoon dat een stel programmeurs dat als gemiddelde van hun programma's hebben "genomen"..

[ Voor 43% gewijzigd door Peter op 20-02-2005 15:29 ]

[OZ-Gump]

Define foutjes. Als je aan het werk bent zul je syntaxfouten maken, maar ik heb mezelf aangeleerd dat ik, als ik een procedure of een klasse af heb op CTRL + SHIFT + B te drukken: Build. Alle syntaxfouten worden direct gehighlight en dus verhelp ik ze direct. Vervolgens test ik datgene wat ik gemaakt heb en pas als dat naar behoren werkt ga ik verder met het volgende onderdeel. Dat soort fouten zijn dus al uitgesloten.

Als je het hebt over een verkeerde berekening, het aanspreken van de verkeerde variabele of andere zaken, dan snap ik wat je met foutjes bedoelt. Daar zou ik zo geen aantal aan kunnen hangen zonder een grote gok-factor. Maar ik ben het er wel mee eens dat je dat soort dingen uit je code kunt halen door een goed(e) test(team) op je software los te laten.

Ik vind 5 tot 15 fouten per 1000 regels redelijk aannemelijk klinken.

[gorgi_19]

-NMe- schreef op zondag 20 februari 2005 @ 15:21:
[...]

En waarom denk je dat een scripttaal zoveel meer fouten oplevert? Zonder onderbouwing is dit nogal een bullshit statement. Neem bijvoorbeeld C++ versus PHP. De syntax is vrijwel hetzelfde, met als kenmerkendste verschil dat PHP niet strongtyped is. Noem eens één reden waarom er dan in een PHP-script meer fouten zouden zitten dan in een C++ programma. Er is maar één ding waar het aantal fouten nog altijd grotendeels vanaf hangt, en dat is van de programmeur van het stukje software.

Als we ASP er bij pakken:

ASP:

<%
Response.Write "Hoi"
Dim blnValue
blnValue = True
If blnValue = False Then
   Response.Write 
End if
%>

(De fout zit hem in het feit dat Response.Write geen argumenten heeft, niet de onbereikbare code)

Deze draait perfect in ASP.

Een compiled language zal deze constructie echter nooit pikken en de fout direct opmerken.

[ Voor 15% gewijzigd door gorgi_19 op 20-02-2005 15:38 ]

[Gé Brander]

Ok, op welk moment praat je dan over die 5-15 fouten per 1000 regels code? Op het moment van releasen? Dan is er nog steeds niet goed getest en netjes geprogrammeerd. (Let op, ik kijk door een bril van een gebruiker. Als ik als database beheerder 10 promille fouten maak, dan ben ik niet goed bezig in ieder geval)

[gorgi_19]

c70070540 schreef op zondag 20 februari 2005 @ 15:39:
Ok, op welk moment praat je dan over die 5-15 fouten per 1000 regels code? Op het moment van releasen? Dan is er nog steeds niet goed getest en netjes geprogrammeerd. (Let op, ik kijk door een bril van een gebruiker. Als ik als database beheerder 10 promille fouten maak, dan ben ik niet goed bezig in ieder geval)

Wat definieer je als een fout, blijft nog steeds de vraag? Het gros van de fouten valt een gebruiker niet eens op.

[klinz]

.Peter schreef op zondag 20 februari 2005 @ 15:28:
Qua PHP zit ik op dit moment tussen de 4 en 8 foutjes per 1000 regels, toch best acceptabel =)

Zijn dat fouten die je zelf ontdekt, of fouten die door anderen ontdekt worden?

[NMe]

gorgi_19 schreef op zondag 20 februari 2005 @ 15:37:
Als we ASP er bij pakken:

ASP:

<%
Response.Write "Hoi"
Dim blnValue
blnValue = True
If blnValue = False Then
   Response.Write 
End if
%>

(De fout zit hem in het feit dat Response.Write geen argumenten heeft, niet de onbereikbare code)

Deze draait perfect in ASP.

Een compiled language zal deze constructie echter nooit pikken en de fout direct opmerken.

Dat is dan iets van ASP ben ik bang.

PHP:

echo "Hoi";
$blnValue = True;
If ($blnValue == False) {
   echo;
}

Bovenstaande code is vergelijkbaar voor PHP, en draait toch echt niet:

code:

Parse error: parse error, unexpected ';' in C:\Program Files\Apache Group\Apache2\htdocs\test.php on line 4

[ Voor 11% gewijzigd door NMe op 20-02-2005 15:50 ]

[Sybr_E-N]

gorgi_19 schreef op zondag 20 februari 2005 @ 15:40:
[...]

Wat definieer je als een fout, blijft nog steeds de vraag? Het gros van de fouten valt een gebruiker niet eens op.

Eensch. Fouten in een programma kunnen ook fouten zijn die je 1 2 3 niet ziet, die kwa syntax wel kloppen, copileren en werken. Bijvoorbeeld als je bepaalde ideen van je opdrachtgever verkeerd interpreteert of een glitch in je klassediagram. Moeten die 'fouten' ook worden meegerekend?

[nIghtorius]

gorgi_19 schreef op zondag 20 februari 2005 @ 14:25:
En wat definieer je als een fout?

Ik definieer 't altijd als "ongewilde functionaliteit"

[whoami]

Reptile209 schreef op zondag 20 februari 2005 @ 14:41:
Het maakt ook nogal uit of het dan gaat om syntax-fouten, runtime-problemen of echte design-fouten, lijkt mij zo.

Een design fout weerspiegelt zich niet in de code.
Waarmee ik bedoel: als het design verkeerd is, wil dat niet zeggen dat er daarom fouten zitten in de 'code', maw, een designfout leidt niet noodzakelijk tot een 'bug' in algoritme.

Syntax fouten worden er door de compiler uitgesloopt.

Je kan er imo trouwens gewoon geen getal op plakken.

[whoami]

-NMe- schreef op zondag 20 februari 2005 @ 15:21:
[...]

En waarom denk je dat een scripttaal zoveel meer fouten oplevert? Zonder onderbouwing is dit nogal een bullshit statement. Neem bijvoorbeeld C++ versus PHP. De syntax is vrijwel hetzelfde, met als kenmerkendste verschil dat PHP niet strongtyped is. Noem eens één reden waarom er dan in een PHP-script meer fouten zouden zitten dan in een C++ programma. Er is maar één ding waar het aantal fouten nog altijd grotendeels vanaf hangt, en dat is van de programmeur van het stukje software.

Bij een gecompileerde taal haal je er zowiezo al alle syntax-errors uit vooraleer je het programma kan opleveren; bij een script-taal niet, omdat je code dan at - runtime geinterpreteerd wordt.
Als je je scrpt dus niet goed test, kan het een hele hoop runtime errors spuien als het in productie is.

Er zijn meer dan genoeg andere soorten testen die je uit kan voeren op een script.

Zoals integration testen , etc... Maar Alarmnummer heeft wel een punt. Unit-testen zorgen ervoor dat je (mits je ze goed gebruikt), al een hele hoop bugs uit je code kunt halen.
Als je unit-tests failen, dan weet je zowiezo dat er ergens een bug zit, en als je ze goed opgesteld hebt, dan weet je ook snel de locatie waar je moet zoeken.

.Peter schreef op zondag 20 februari 2005 @ 15:28:
Qua PHP zit ik op dit moment tussen de 4 en 8 foutjes per 1000 regels, toch best acceptabel =)

[edit] Waar de uitspraak vandaan komt? Ik denk gewoon dat een stel programmeurs dat als gemiddelde van hun programma's hebben "genomen"..

Wat definieer je als een fout? Syntax-fout? Logische fout ?
Voor mij is een 'fout' in de software een bug; dwz een logische fout.

Ik vind de term' x aantal fouten per x regels code' eigenlijk redelijk stom en onzinnig.
Eigenlijk zou men moeten nagaan hoeveel fouten een 'opzichzelf staande module van een systeem' heeft.

[ Voor 22% gewijzigd door whoami op 20-02-2005 16:11 ]

[Swerfer]

gorgi_19 schreef op zondag 20 februari 2005 @ 15:37:
[...]

Als we ASP er bij pakken:

ASP:

<%
Response.Write "Hoi"
Dim blnValue
blnValue = True
If blnValue = False Then
   Response.Write 
End if
%>

(De fout zit hem in het feit dat Response.Write geen argumenten heeft, niet de onbereikbare code)

Deze draait perfect in ASP.

Een compiled language zal deze constructie echter nooit pikken en de fout direct opmerken.

Door niet de complete code te compilen, maar alleen datgene wat wel moet worden uitgevoerd, win je natuurlijk wat snelheid. blnValue is immers true, dus waarom zou je de code in het if-end if blok gaan controleren/compilen?

Nadeel is dus wel, dat als er zich een situatie voordoet waar blnValue wel false is, dat je dan pas achter je bug komt...

edit:

Als je overigens de code in bijvoorbeeld Visual Web Developer 2005 Express Edition Beta invoert, dan komt hij dus wel meteen met een foutmelding...

[ Voor 11% gewijzigd door Swerfer op 20-02-2005 16:19 ]

[whoami]

Compilen hoeft maar één keer....

[gorgi_19]

Swerfer schreef op zondag 20 februari 2005 @ 16:13:
Nadeel is dus wel, dat als er zich een situatie voordoet waar blnValue wel false is, dat je dan pas achter je bug komt...

Wat dus de stelling onderschrijft dat je makkelijker fouten maakt in in ieder geval een aantal scripttalen

[NMe]

whoami schreef op zondag 20 februari 2005 @ 16:09:
Bij een gecompileerde taal haal je er zowiezo al alle syntax-errors uit vooraleer je het programma kan opleveren; bij een script-taal niet, omdat je code dan at - runtime geinterpreteerd wordt.
Als je je scrpt dus niet goed test, kan het een hele hoop runtime errors spuien als het in productie is.

Zoals mijn codevoorbeeld hierboven al liet zien in tegenstelling tot het codevoorbeeld van gorgi_19, is dat afhankelijk van de taal. PHP loopt blijkbaar eerst alle regels af en controleert op syntaxfouten, waar ASP dat niet doet. Het is dus niet iets dat specifiek opgaat voor alle scriptingtalen, en dat was het punt dat ik probeerde te maken.

Zoals integration testen , etc... Maar Alarmnummer heeft wel een punt. Unit-testen zorgen ervoor dat je (mits je ze goed gebruikt), al een hele hoop bugs uit je code kunt halen.
Als je unit-tests failen, dan weet je zowiezo dat er ergens een bug zit, en als je ze goed opgesteld hebt, dan weet je ook snel de locatie waar je moet zoeken.

Zeker, ik onderschat ook zeker niet het nut van unit testing. Maar bij gebrek daaraan zijn er voldoende andere manieren om op een geslaagde manier je code te kunnen ontdoen van fouten.

[Swerfer]

gorgi_19 schreef op zondag 20 februari 2005 @ 16:16:
[...]

Wat dus de stelling onderschrijft dat je makkelijker fouten maakt in in ieder geval een aantal scripttalen

Zie de edit in mijn post. Alleen als je in notepad oid gaat programmeren kan je zulke bugs over het hoofd zien...

[JayVee]

offtopic:
Bug or feature?

[OZ-Gump]

JayVee schreef op zondag 20 februari 2005 @ 16:28:

offtopic:
Bug or feature?

offtopic:
Als je dan naar een image linkt, check dan ook even of hij werkt

Ik wil trouwens nog steeds wel weten wat de TS nou een fout in code vindt?

[Alarmnummer]

-NMe- schreef op zondag 20 februari 2005 @ 15:21:
[...]

En waarom denk je dat een scripttaal zoveel meer fouten oplevert?

Omdat het domweg niet compileerd. Je ziet pas runtime fouten..

Zonder onderbouwing is dit nogal een bullshit statement.

Ik heb laatst ergens in een topic over scripting een aantal redenen geplaatst waarom script talen foutgevoeliger zijn dan non script talen.

Neem bijvoorbeeld C++ versus PHP. De syntax is vrijwel hetzelfde, met als kenmerkendste verschil dat PHP niet strongtyped is. Noem eens één reden waarom er dan in een PHP-script meer fouten zouden zitten dan in een C++ programma.

Omdat het niet compileerd.

Als een scripttaal niet al te veel onduidelijke features heeft en volledig kan worden 'gecontroleerd' op een door mij uitgekozen moment heb ik er 0.0 problemen mee.

Er is maar één ding waar het aantal fouten nog altijd grotendeels vanaf hangt, en dat is van de programmeur van het stukje software.

Onzin.

Je hebt 2 soorten fouten:
fouten die een compiler eruit kan halen
semantische fouten.

Ik maak fouten van beide types. Alleen zorgt de compiler ervoor dat al mijn 'compile' fouten worden gevonden. Nu hou ik alleen nog fouten van het andere type over. Dat is de onweerlegbare reden dat ongecompileerde talen foutgevoeliger zijn dan gecompileerde talen.

Ik weet dat jij Java-fan bent, en af en toe druipt het van je posts af dat alles wat niet Java is, niet goed is.

Als java niet was gecompileerd had ik java ook volledig afgezeken. Ik heb verder bv ook erg weinig op met al die scriptingtalen voor Java. Deze talen kunnen van dezelfde api`s gebruik maken als Java (en vaak nog meer).. maar zo lang het niet controleerbaar is.. tja...

Ik ben bang dat je toch moet kijken naar waar een taal voor ontworpen is, en daarna pas oordelen over de kwaliteit.

Hmmm.. niemand kan mij wijsmaken dat een taal ontworpen is voor een doel waarbij compilefouten toelaatbaarbaar zijn. Ik heb alleen problemen met ongecompileerde talen. Ik heb bv dezelfde problemen met JSP (wat trouwens echt wordt gecompileerd maar pas op een later tijdstip.. kan wel een week na het opstarten van het systeem zijn). En verder heb ik problemen met bv de XML config files waarbij je pas runtime achter bepaalde fouten komt. Ik gebruik bv maverick als weblayer voor java waarbij ik een XML mapping file heb voor de requests. Als ik een typefout maak, krijg ik het pas te zien als ik op een pagina druk. Ik kan dus niet de garantie geven dat 'compile' fouten niet aanwezig zijn. Dit probleem had trouwens eenvoudig verholpen kunnen worden als Maverick het bestand tijdens het opstarten van het systeem volledig had gecontroleerd (op oa bestaande pagina`s).

Bij Java kun je unit testen. Bij veel scripttalen niet. Dus? Scripttalen hebben weer andere voordelen.

Kan wel.. gebeurt niet.. Dat is mijn probleem ermee. Met scripttalen heb je domweg meer fouten dan bij een gecompileerde taal. Het gaat me niet om de api`s of de architectuur en taalfeatures, maar puur om zo vroeg mogelijk fouten te achterhalen.

Ik werk zelf zo nu en dan met Prolog en ruleengines. Prolog is bv ook zo`n taal waarbij je voor geen meter achter fouten kan komen. Ik heb daardoor een extra semantische controle toegevoegd aan de compiler zodat deze mij erop wijst dat ik vermoedelijk iets fout heb gedaan (het zijn warnings). wow.. dit scheelt zo godsellendig veel tijd... Ongecontroleerde talen horen niet in serieuze omgevingen thuis imho.

[ Voor 15% gewijzigd door Alarmnummer op 20-02-2005 17:01 ]

[NMe]

@Alarmnummer: Ik kan me, na je laatste post hier, wat meer vinden in je argumenten. Maar toch vind ik nog steeds dat het feit dat een scriptingtaal niet compileert geen extra bron van fouten is. Als je in Java zit te programmeren, dan druk je op Compile, en kijkt wat de compiler wel en niet kan maken van je code. Als je in PHP een script schrijft, dan sla je op, en kijk je wat de browser maakt van je code. Wanneer er een syntax error in zit, zal je code simpelweg niets doen, behalve het weergeven van die error. Exact hetzelfde gedrag als datgene wat jij te zien krijgt als je op het knopje "compile" klikt, alleen moet je er bij het scripten meestal voor van applicatie wisselen.

Verder is bijvoorbeeld PHP ook vooraf te compileren.

[Alarmnummer]

-NMe- schreef op zondag 20 februari 2005 @ 17:39:
@Alarmnummer: Ik kan me, na je laatste post hier, wat meer vinden in je argumenten. Maar toch vind ik nog steeds dat het feit dat een scriptingtaal niet compileert geen extra bron van fouten is. Als je in Java zit te programmeren, dan druk je op Compile, en kijkt wat de compiler wel en niet kan maken van je code. Als je in PHP een script schrijft, dan sla je op, en kijk je wat de browser maakt van je code.

Hmm tja. Ik ben regelmatig aan het refactoren (gelukkig helpt mijn ide me enorm), maar als ik iets verhuis of rename dan kan dit gevolgen hebben omdat een stuk code er gebruik van maakt. Deze code die was goed.. maar nu deugt het niet meer. En ik heb geen zin om iedere keer helemaal door de site heen te klikken op zoek naar dingen die het deden en nu niet meer. Ik heb trouwens dezelde problemen met code dat niet is getest. Op het moment dat je het schreef werkte het (ff goed geprobeerd in de browser). Maar na verloop van tijd wil er wel eens iets veranderen.. en dan zit je weer zo van.. godverd*mme.. dit werkte de vorige keer nog wel!.. Het geeft mij een gevoel van ongrijpbaarheid... dat ik mijn code niet meer onder controle heb.. en daar heb ik hekel aan.

Wanneer er een syntax error in zit, zal je code simpelweg niets doen, behalve het weergeven van die error. Exact hetzelfde gedrag als datgene wat jij te zien krijgt als je op het knopje "compile" klikt, alleen moet je er bij het scripten meestal voor van applicatie wisselen.

Ik zou graag zien dat je bij het opstarten van een php app de mogelijkheid hebt om de code helemaal door te laten fluiten. Als php standaard op deze manier wordt toegepast dan heb ik er veel minder problemen mee.

Verder is bijvoorbeeld PHP ook vooraf te compileren.

[/quote]
De vraag is: doet iedereen dit ook? Hetzelfde geld voor testen. In iedere taal is het mogelijk om te testen, alhoewel het bij sommige talen wel een stuk lastiger kan zijn. Maar de vraag is: hoe gebruikelijk is dit? Ik koop niets voor een... ja... het zou kunnen.. ik wil een: veel mensen doen het.

[ Voor 8% gewijzigd door Alarmnummer op 20-02-2005 17:49 ]

[Creepy]

Het statement van het aantal fouten per 1000 regels code heb ik ooit eens gehoord van een docent van me en luidt ongeveer: "Goede software bevat 15-20 fouten per 1000 regels code". En dat is dus software die in gebruik is genomen en "correct" of goed genoeg is bevonden. Dit statement is al vrij oud (lees: meer dan 10 jaar oud). Geen idee dus of dit statement nog enigzins klopt. Waar het statement vandaan komt kan ik in m'n boeken niet zo 123 terugvinden..

Code bevat nagenoeg altijd bugs. Mensen maken nu eenmaal fouten. Zoals Dijkstra ook al eens zei kan testen wel aantonen dat er bugs in de code zitten maar kan het niet aantonen dat er geen bugs in de code zitten

[JayVee]

OZ-Gump schreef op zondag 20 februari 2005 @ 16:30:
[...]

offtopic:
Als je dan naar een image linkt, check dan ook even of hij werkt

( >< ) Hier dan: Bug or feature?

offtopic:
ik had hem bekeken en hij deed het. Als je via een referrer naar de pagina komt werkt het niet. Copy paste link in browser werkt wel... maar goed, dan ff op eigen webspace gezet

[ Voor 14% gewijzigd door JayVee op 20-02-2005 18:18 ]

[Genoil]

ik hoorde een keer in een documentaire over de software in on-board vliegtuig-computers dat daar gemiddeld slechts 1 bug op 7000 regels code zit. waar ze dat getal vandaan halen is natuurlijk een beetje vaag...

[Verwijderd]

Wow wat een discussie! Tnx voor de reacties iedereen.

Wat ik bedoelde met fouten in de code was fouten die in het programma zitten nadat het gereleased is. Dit zullen dus logische fouten zijn die niet vaak optreden, anders waren ze er bij het testen wel uitgekomen. Zo las ik net een stukje over een aantal grote systemen die door IBM waren gebouwd. Uit analyse naderhand bleken er een hoop fouten in te zitten die ongeveer eens in de 5000 jaar zouden optreden. Deze fouten totaal waren ongeveer 1/3 van de onontdekte fouten bij release...

[Alarmnummer]

Genoil schreef op zondag 20 februari 2005 @ 18:18:
ik hoorde een keer in een documentaire over de software in on-board vliegtuig-computers dat daar gemiddeld slechts 1 bug op 7000 regels code zit. waar ze dat getal vandaan halen is natuurlijk een beetje vaag...

Ik neem aan dat testen een ongelovelijk belangrijk onderdeel is van het geheel. Voor standaard applicaties kan het niet uit om bv 50% aan het testen te zijn.. Maar ik denk dat bij dat soort applicaties testen het grootste gedeelte is.

[Verwijderd]

Als je weet hoeveel fouten er in 1000 regels code zitten ga je ze zoeken en ze er uit halen, lijkt me

Point being, dit getal is statistisch bepaald en 97,3% van alle statistieken is verzonnen.

[NMe]

Alarmnummer schreef op zondag 20 februari 2005 @ 18:27:
Ik neem aan dat testen een ongelovelijk belangrijk onderdeel is van het geheel. Voor standaard applicaties kan het niet uit om bv 50% aan het testen te zijn.. Maar ik denk dat bij dat soort applicaties testen het grootste gedeelte is.

Dat 50% van je projecttijd besteden aan testen geen overbodige luxe is, dat vertelde die ervaren tester die ik hierboven noemde ook in zijn presentatie. Toch zijn er veel bedrijven die veel minder tijd bieden; waardoor de beschikbare tijd variëert van 10 tot 60% van de projecttijd. Voor een project waarin code wordt geschreven om een vliegtuig aan te kunnen sturen, hoop ik toch dat er wat meer getest wordt ja. Zelfde voor een nucleaire krachtcentrale.

Hij vertelde trouwens ook dat er in een bepaalde Airbus wel ongeveer 100 bugs zaten, en hij wenste ons veel plezier bij onze eerstvolgende vliegreis.

[Genoil]

-NMe- schreef op zondag 20 februari 2005 @ 20:49:
[...]

Hij vertelde trouwens ook dat er in een bepaalde Airbus wel ongeveer 100 bugs zaten, en hij wenste ons veel plezier bij onze eerstvolgende vliegreis.

die docu waarin die 1/7000 werd genoemd ging idd o.a. over de Airbus 320, het eerste FBW (flybywire) lijntoestel dat soms bij piloten reacties losmaakte als "what is it doing now?!"

[Alarmnummer]

-NMe- schreef op zondag 20 februari 2005 @ 20:49:
[...]

Dat 50% van je projecttijd besteden aan testen geen overbodige luxe is, dat vertelde die ervaren tester die ik hierboven noemde ook in zijn presentatie. Toch zijn er veel bedrijven die veel minder tijd bieden; waardoor de beschikbare tijd variëert van 10 tot 60% van de projecttijd.

Als het budget er niet op afgesteld wordt dan niet. En verder als je unit testen goed aanpakt dan ben je sneller klaar dan zonder testen. Niet geautomatiseerde testen moet je met de hand herhalen (dat kost tijd) en geintroduceerde bugs kosten tijd. Trouwens.. naarmate ik meer richting generieke classes ga, des te meer ik ga testen. Al mijn software dat ik in mijn vrije tijd ontwikkel onderwerp ik zwaar aan testen.

Hij vertelde trouwens ook dat er in een bepaalde Airbus wel ongeveer 100 bugs zaten, en hij wenste ons veel plezier bij onze eerstvolgende vliegreis.

[/quote]
Wat je niet ziet bestaat niet

[Verwijderd]

Dat het aantal fouten bij talen die niet direct gecompiled worden veel hoger ligt is natuurlijk een bullshit argument

Als ik kijk binnen ons eigen bedrijf, ligt het aantal fouten bij c# code velen velen malen hoger als bij de talen die niet direct gecompileerd worden. Je haalt bij het compilen niet alle fouten eruit die runtime worden getriggerd. Als je een syntax fout hebt met compilen kun je dit weer vergelijken met een pagina die in web languages direct al een error geeft (en het lijkt me sterk dat je zaken direct deployed zonder testen). Dus of ik nu een F5 doe van de webbrowser, of mijn applicatie opnieuw compile, who cares

Unit testing, het idee is leuk, maar ik ken maar 2 bedrijven die er actief mee bezig zijn, maar die stoppen ook miljoenen euro's in productontwikkeling. Dan valt de overhead van unit testing ook recht te praten. Hoe kleiner de projecten hoe groter de overhead van unit testing, en hoe kleiner het werkelijke nut van unit testing kostentechnisch gezien.

Terugkomend op het aantal bugs per code, ik vermoed dat dat wel gestegen is. De complexiteit van projecten is de laatste jaren aanzienlijk gestegen met meer technieken, meer wensen, meer verwachtingen, en lagere marges. Daartegenover kun je dan wel weer plaatsen dat deze technieken een hoop werk uit handen hebben genomen van programmeurs, maar ik denk dat de eisen, wensen en de complexiteit tegenwoordig zo hoog zijn dat die hulpverlenende technieken de x bugs per 1000 regels code het niet meer kunnen bijbenen.

[djluc]

Is het dan ook niet zo dat je eigenlijk tegenwoordig met minder regels code hetzelfde resultaat kunt verkrijgen? De kans op design-fouten is dan groter per 1000 regels maar blijft eigenlijk gewoon hetzelfde.

[OZ-Gump]

Als ik kijk binnen ons eigen bedrijf, ligt het aantal fouten bij c# code velen velen malen hoger als bij de talen die niet direct gecompileerd worden.

Nu ga jij de balans de andere kant in doen uitslaan en dat lijkt me helemaal moeilijk te verdedigen. Hiermee zou je bijna opmerkingen in de hand werken als 'Hoe goed is de C# kennis binnen jullie bedrijf dan?'

Ik denk dat, als je kijkt naar de doorsnee developer (en 'doorsnee' blijkt een redelijk goed referentiekader te zijn ), je er vanuit kunt gaan dat een gecompilede taal minder fouten in de hand werkt als een niet gecompilede taal. Al is het bijvoorbeeld alleen maar de code in het catch-gedeelte die bij een niet gecompilede taal niet door een compiler wordt gechecked op syntax. Als je dan in de uitzonderlijke situatie komt dat de catch nodig is, heb je een probleem. Een dergelijke syntactische fout zou er bij een compiled language wel uit komen voor de release.

Ik denk niet dat je puur op basis van syntax, en dus los van compiled of niet, kunt roepen dat een taal meer of minder bugs in de hand werkt. In een dergelijk geval gaat het namelijk om de kennis van zaken van degene die ermee werkt...

just my € 0,02

[Soultaker]

Die "X fouten per Y regels" uitspraken zijn echt alleen goed voor borrelpraatjes en voor op de sheets bij inhoudsloze presentaties. De hoeveelheid fouten hangt af van een heleboel factoren, zoals de kennis en ervaring van de programmeurs, de tijd die beschikbaar is, de programmeertaal, de eigenschappen van het domein waarin gewerkt wordt, de manier waarop getest wordt, het ontwerptraject, de gebruikte libraries en niet in de laatste plaats de definitie van een 'fout'.

Het enige nuttige van de regel is dat je je er bewust van moet zijn dat een grote hoeveelheid code altijd een aantal kleine foutjes zal bevatten en als je pech hebt ook een aantal grote. Het is zinnig om daar bij het beheren van een softwareproject rekening mee te houden, zodat je tijdig plannen maakt om fouten op te sporen en de schade van eventuele fouten waarvan je het bestaan niet weet tot een minimum te beperken.

Je kunt dus prima wat gokken, want de regel zelf is met elk getal wat je invult onzin, maar je kunt 'm gebruiken om een ander (zinniger) punt te ondersteunen.

[JayVee]

Soultaker schreef op zondag 20 februari 2005 @ 23:29:
[...]

amen

[Alarmnummer]

Verwijderd schreef op zondag 20 februari 2005 @ 21:59:
Dat het aantal fouten bij talen die niet direct gecompiled worden veel hoger ligt is natuurlijk een bullshit argument

Ik vind het erg jammer dat je het domweg neit begrijpt.

Programmeurs maken fouten... zowel inhoudelijke als fouten die door een compiler/checker eruit gehaald kunnen worden. Fouten van het laatste type zitten dus niet in mijn programma`s. Alleen fouten van het 1e type.. In jouw programma`s zullen hoe dan ook fouten van het 1 en het 2 type voorkomen. Daarom zal in jouw code per definitie meer fouten voorkomen dan die van mij... of jij moet gewoon zo slim zijn dat je geen fouten maakt.. maar dat betwijfel ik. En je argument dat je een page view doet om te controleren of iets nog werkt is natuurlijk een ongelovelijk amateuristisch argument.

Ik kan de garantie geven dat nagenoeg alle fouten van het 1e type uit mijn code is verwijdert. Zelf als is het systeem een jaar geleden geschreven. Deze garantie kan jij niet geven.. Het is toch niet zo moeilijk om te begrijpen??

En het feit dat unit testen meer tijd zou kosten is al helemaal een uitspraak door iemand die totaal neit weet waar hij het over heeft. Als je unit testen vanaf dag 1 gebruikt, en je zethet goed op.. dan gaat het je tijd besparen. Ik hoef geen pageview te doen om te controleren of mijn code goed werkt, dat doet mijn test. Zelfs nadat er wijzigingen gedaan zijn, kan ik zonder inspanning deze tests blijven herhalen. Ik hoef dus geen dingen iedere keer opnieuw te testen.. Trouwens.. echt serieuze software zitten bij mij erg zwaar onder de tests. Als je nagaat hoeveel bugs ik op deze manier er nog uitvis (zijn vaak kantelpunten binnen functies). Deze fouten zitten dus standaard in ongeteste software. Unit testing heeft niet alleen zijn toegevoegde waarde bij het testen, maar ook om beter na te denken over wat een functie precies moet doen (oa weer die kantelpunten kan je er goed mee ontdekken).

[ Voor 45% gewijzigd door Alarmnummer op 21-02-2005 08:51 ]

[Verwijderd]

Alarmnummer schreef op maandag 21 februari 2005 @ 08:43:

Nee jij denkt nog teveel vanuit een Java oogpunt Ik snap wel wat je bedoelt, maar die punten slaan niet aan bij alle web languages zoals jij dat probeert voor te spiegelen. Je hebt het over fouten die door de compiler eruit worden gepikt, die worden bij web languages bij first request opgepakt. Je vergeet totaal even de toegankelijkheid van dergelijke talen.

Je opmerking over unit testing stop ik maar even diep in de lade aangezien hij behoorlijk overbodig laag is en je mijn achtergrond mbt unit testing totaal niet kent. Ik heb unit testing gedaan, en ook projecten geleid met intensieve unit testing en ik meen daar wel genoeg vanaf te weten om ook buiten het oogpunt van een developer er naar te kijken.

Een unit test geeft niet aan of business logic correct werkt, een unit test, zoals de naam al aangeeft test alleen individuele onderdelen. Maar hoe die onderdelen nog samen werken, of end user functionaliteit is zoals verwacht dat weet je niet totdat je praktijkgericht gaat testen. Unit testing wordt in mijn ogen te vaak gezien door developers als the holy grail, maar vergeet niet dat de echte test pas plaatsvind op het moment dat je de applicatie gebruikt. Het hangt geheel af van de applicatie of de voordelen van unit testing, voordat je begint met praktijk gerichte tests, uiteindelijk ook testtijd dermate verkorten dat de tijd die je steekt in het schrijven van unit test kunt verantwoorden.

Jij kijkt alleen naar je tests, je methodieken, aanpak zoals jij vind dat het als developer moet gaan, maar je maakt een enorm grote fout door eventjes de budgetaire kant van het verhaal te vergeten. Tenzij jij werkt aan projecten met reeele kapitaalinjecties, vraag ik me serieus af hoe jullie in vredesnaam marge halen met oneindig testen.

Unit tests hebben zijn nut, maar wel in verhouding met het project en het budget.

[ Voor 8% gewijzigd door Verwijderd op 21-02-2005 09:30 ]

[Alarmnummer]

Verwijderd schreef op maandag 21 februari 2005 @ 09:26:
[...]
Nee jij denkt nog teveel vanuit een Java oogpunt Ik snap wel wat je bedoelt, maar die punten slaan niet aan bij alle web languages zoals jij dat probeert voor te spiegelen. Je hebt het over fouten die door de compiler eruit worden gepikt, die worden bij web languages bij first request opgepakt. Je vergeet totaal even de toegankelijkheid van dergelijke talen.

Die toegankelijkheid zal me worst zijn. Het gaat mij erom hoe snel een ervaren programmeur stabiele software kan afleveren (ook al doet hij het in brainfuck of assembler). Dat de taal toegankelijk is of niet is imho oninteressant.

Een unit test geeft niet aan of business logic correct werkt, een unit test, zoals de naam al aangeeft test alleen individuele onderdelen.

Het testen van de business logic is onderdeel van het unit testen. Ik versta trouwens onder unit testen ook integration testen. Kijken of de componenten ook goed met elkaar samenwerken. Ik kom dan nog maar al te vaak achter gekke bugs.

Maar hoe die onderdelen nog samen werken, of end user functionaliteit is zoals verwacht dat weet je niet totdat je praktijkgericht gaat testen. Unit testing wordt in mijn ogen te vaak gezien door developers als the holy grail, maar vergeet niet dat de echte test pas plaatsvind op het moment dat je de applicatie gebruikt.

Tuurlijk.. helemaal mee eens. Maar ik ben blij met alles wat ik kan krijgen om mijn bugs eruit te vissen. Unit/integration testen en het compileren is een van mijn tools om al een heel skala aan bugs uti mijn systeem te verwijderen. En je pakt idd niet alles eruit.. maar iets is beter dan niets. Perfectie in de software ontwikkeling bestaat niet, maar ik ben blij met alles wat ik krijgen kan om het in ieder geval beter te maken. Unit testing en compilatie zijn een paar van die dingen..

Jij kijkt alleen naar je tests, je methodieken, aanpak zoals jij vind dat het als developer moet gaan, maar je maakt een enorm grote fout door eventjes de budgetaire kant van het verhaal te vergeten. Tenzij jij werkt aan projecten met reeele kapitaalinjecties, vraag ik me serieus af hoe jullie in vredesnaam marge halen met oneindig testen.

Dat is geen faire opmerking. Als jij een unit test opzet tijdens het developen van het stuk code zal het je niet veel extra tijd kosten. 1) het zorgt ervoor dat je beter over de functie nadenkt (vooral de kantelpunten). 2) je moet toch testen... jij drukt op een pagina, ik druk op mijn testsuite. Het voordeel bij mij is dat deze test geautomatiseerd gedraait kan worden, en dat kan die van jou niet. Ik moet in code dat geen testen heeft vaak nog een keer door de site heen lopen, op zoek naar dingen die misschien stuk zijn gegaan. Met een unit test heb je hier minder last van...

Unit tests hebben zijn nut, maar wel in verhouding met het project en het budget.

Als je unit testen pas na afloop gaat toevoegen dan krijg je 'niet functionele' kosten. Maar op het moment dat je vanaf de 1e dag een unit test gaat schrijven bij het stuk code dat je ontwikkeld gaat dit enorm meevallen.

[ Voor 6% gewijzigd door Alarmnummer op 21-02-2005 10:37 ]

[Sjaaky]

Verwijderd schreef op maandag 21 februari 2005 @ 09:26:
Je hebt het over fouten die door de compiler eruit worden gepikt, die worden bij web languages bij first request opgepakt.

Nee want tijdens een request worden niet alle executiepaden gecontroleerd.
Bijvoorbeeld:

PHP:

if ($var == true) {
    echo "geen fout";
} else {
    echo "geeft fout";
    deze_methode_bestaat_niet_meer(a,b,c);
}

Omdat de syntax klopt krijg je geen foutmelding tijdens een request als $var true is. Pas als $var false is wordt er een foutmelding gegeven. Een compiler zal deze code nooit accepteren. Om dit soort dingen te voorkomen kun je of je scriptcode compileren of unittesten om te zorgen dat er meer (alle is lastig) executiepaden gecontroleerd worden.

[Night-Reveller]

Het eerste wat ik mij juist bedacht is niet dat de ene fout de andere fout niet is, maar juist dat de ene regel code de andere niet is.
Correct me if i'm wrong (Mijn C kennis laat me even helemaal in de steek ). het volgende moet C voorstellen:

code:

TempVar = {1;a=b;2};
for {i=0;12;i++}

terwijl in Object Pascal dit ongeveer hetzelfde moet voorstellen:

code:

If a=b then
  TempVar := 1
else
  TempVar = 2;

For i:=0 to 12 do
begin 
  [...] 
end

C is een veel krachtiger taal dan Object Pascal; je kan in 1 regel veel meer kwijt. (In dit geval ongeveer 4x zoveel). Aangezien de semantiek van de code hetzelfde is, zijn het te verwachten aantal fouten ongeveer even groot.

De gebruikte taal is zeker van belang als je een schatting wil maken van het aantal fouten per 1000 regels code. En als ik prestatieloon zou krijgen per regel code, weet ik zeker dat ik een hoop bs-code zou toevoegen, dat geen fouten zal veroorzaken

Alarmnummer schreef op maandag 21 februari 2005 @ 10:26:
[...]
Als je unit testen pas na afloop gaat toevoegen dan krijg je 'niet functionele' kosten. Maar op het moment dat je vanaf de 1e dag een unit test gaat schrijven bij het stuk code dat je ontwikkeld gaat dit enorm meevallen.

Helemaal correct. Sterker nog; de tijd die het programmeren kost wordt ook minder. Je programmeert alleen die dingen die voor het behalen van de test noodzakelijk zijn.

[Creepy]

Night-Reveller schreef op maandag 21 februari 2005 @ 12:36:
Het eerste wat ik mij juist bedacht is niet dat de ene fout de andere fout niet is, maar juist dat de ene regel code de andere niet is.
Correct me if i'm wrong (Mijn C kennis laat me even helemaal in de steek ). het volgende moet C voorstellen:

code:

TempVar = {1;a=b;2};
for {i=0;12;i++}

terwijl in Object Pascal dit ongeveer hetzelfde moet voorstellen:

code:

If a=b then
  TempVar := 1
else
  TempVar = 2;

For i:=0 to 12 do
begin 
  [...] 
end

C is een veel krachtiger taal dan Object Pascal; je kan in 1 regel veel meer kwijt. (In dit geval ongeveer 4x zoveel). Aangezien de semantiek van de code hetzelfde is, zijn het te verwachten aantal fouten ongeveer even groot.

Dus C is een krachtigere taal omdat je meer in 1 regel kwijt kan? Dat je iets korter kan opschrijven wil niet zeggen dat de taal ook krachtiger is. Het zegt waarschijnlijk wel iets over het gemiddeld aantal fouten per x regels code ja

[.oisyn]

Alarmnummer schreef op zondag 20 februari 2005 @ 15:12:
Tevens zal een stuk software dat goed geunit test is ook minder fouten bevatten dat een stuk software dat niet geunit test is. Ik heb nog niet veel script omgevingen gezien waarbij unit testen werd toegepast.. (getuigt imho ook al van de kwaliteit ervan)

Helaas is een unittest niet altijd toepasbaar

-NMe- schreef op zondag 20 februari 2005 @ 15:21:

En waarom denk je dat een scripttaal zoveel meer fouten oplevert? Zonder onderbouwing is dit nogal een bullshit statement. Neem bijvoorbeeld C++ versus PHP. De syntax is vrijwel hetzelfde, met als kenmerkendste verschil dat PHP niet strongtyped is. Noem eens één reden waarom er dan in een PHP-script meer fouten zouden zitten dan in een C++ programma. Er is maar één ding waar het aantal fouten nog altijd grotendeels vanaf hangt, en dat is van de programmeur van het stukje software.

Je moet het meer zien als strong typed vs. loose typed. Een string assignen aan een int lukt niet in een taal als C++ zonder expliciet gedefinieerde conversion operators (dus: compile error). In PHP moet je hier tijdens runtime achter komen, en dat betekent dus dat je tijdens een run al je code moet coveren wil je ze kunnen vinden.

[Tomatoman]

Het aantal fouten per 1000 regels code is op zich geen maatstaf of een programmeur zijn werk goed doet of niet. Een paar voorbeelden.

Als je 10.000 regels code schrijft voor een maanlander met maar één fout erin, resulteert dat in maar 0,1 fout per 1000 regels code. Is dat niet fantastisch? Dat de maanlander door die ene fout te pletter slaat op de maan mag de pret niet drukken.

Stel dat een programmeur een heel simpel programmaatje maakt (250 regels code) dat uitrekent wat je benzineverbruik is. De gebruiker moet de verbruikte hoeveelheid benzine invullen en de afgelegde afstand. Het programma deelt beide getallen op elkaar en geeft netjes je verbruik aan in kilometers per liter en ook in liters per honderd kilometer. Nu vult een gebruiker in dat hij 0 liter benzine heeft verbruikt en 0 kilometer heeft gereden. Oeps, delen door nul, daar had de programmeur even niet aan gedacht. En het verbruik berekening in liters per honderd kilometer berekenen produceert ook al een fout. Het programma geeft een automatische foutmelding dat delen door nul niet mogelijk is. De gebruiker van het programma weet precies waar hij aan toe is en er is niets ernstigs gebeurd. De programmeur heeft 2 fouten in zijn programma van 250 regels code zitten. Dat geeft een foutratio van maar liefst 8 fouten per 1000 regels code. Heeft de programmeur nu slecht werk afgeleverd?

Laatste voorbeeld: een programmeur heeft 25 fouten in zijn code van 5000 regels zitten. Er zaten er aanvankelijk honderden fouten in, maar de meeste heeft hij zelf al gevonden (het grootste deel werd door de compiler ontdekt). Het gaat om een grote applicatie waar een heel team aan werkt. Tijdens het testen vinden de testgebruikers 15 fouten. Vervolgens vindt de afdeling die de compatibiliteit van het programma test ook nog 4 fouten. Dan zijn er nog twee foutjes in de lay-out, die worden gevonden die de ontwerper van de user interface. Ten slotte worden er tijdens betatests nog 3 fouten uitgehaald. Als het eindproduct wordt opgeleverd, resteert welgeteld 1 fout van de programmeur. Is het nu een goede of een slechte programmeur? Hoeveel programmeerfouten heeft hij nu gemaakt? Honderden? Vijfentwintig? Eén?

UIt de gegeven voorbeelden kun je tenminste 3 conclusies trekken.[list]• Eén kritieke fout kan al genoeg zijn om een ramp te veroorzaken. Of dat nou 1 fout in 100 regels code is of 1 fout in 1 miljoen regels code is irrelevant.
• Een programma met veel programmeerfouten hoeft helemaal geen probleem te zijn. Als de gebruiker duidelijk geïnformeerd wordt over het opgetreden probleem (dialoogvenster met foutmelding of zo), kan hij daar in veel gevallen rekening mee houden. Lang niet alle programma’s hoeven 100% fool proof te zijn.
• Het hoeft niet erg te zijn als een programmeur relatief veel fouten maakt en die fouten tijdens volgende stadia van het ontwikkelingstraject worden ondervangen. Vaak is een tester een stuk goedkoper dan een programmeur. Laat de tester dan maar lekker de fouten opsporen, zodat de programmeur dat niet zelf hoeft te doen. De kwaliteit van het eindproduct komt het testen door meer dan 1 persoon alleen maar ten goede. Als de fouten echter door de nog veel duurdere ontwerper van de user interface moeten worden opgespoord (de tester heeft daar geen kaas van gegeten), gaat er iets niet goed.

[Verwijderd]

C++:

if (a = 3)
{
    // prutser
};

btw 3 minuten voor de lancering van Apollo I kwam men erachter dan de zwaartekracht van de maan als afstotend geprogrammeerd was .

[.oisyn]

bloog: een goede compiler geeft een warning. Daarnaast is dat natuurlijk net zo'n domme fout als wanneer je + gebruikt ipv - oid

[ Voor 47% gewijzigd door .oisyn op 21-02-2005 17:01 ]

[Swinnio]

een goede reden om dergelijke checks te schrijven als

C++:

if (3 = a) {
  // prutser
};

Dat zal elke compiler melden.

[ Voor 14% gewijzigd door Swinnio op 21-02-2005 21:53 ]

[Kayshin]

Ik denk ook dat het niet erg iis om fouten te maken, je leert hier alleen maar van. Ik neem ook aan dat zogauw je een functie hebt geschreven je deze controleert en kijkt of deze ook doet wat hij moet doen.

Ik ben bijvoorbeeld iemand die steeds, na een stuk code geschreven te hebben, controleert of het compiled en of het werkt.

Bij scripttalen is dit hetzelfde, je bouwt toch ook niet een huis en kijkt dan of de losse stukken wel verbinden?

Scripttalen zijn voor mijn gevoel goed te testen en te debuggen. Gooi wat alertjes erin (oid) en let gewoon goed op wat er gebeurt.

[Verwijderd]

Sjaaky schreef op maandag 21 februari 2005 @ 12:09:

Dat klopt inderdaad, daar ben ik het ook zeker eens mee, maar wat er nu wordt gedaan, is dat men de complete impact van fouten voorkomen teveel neerlegd bij de compiler Tuurlijk voorkomt de compiler dergelijke problemen door voortijdig daar melding van te maken. Maar omdat je dit soort fouten voorkomt, betekend het opeens dat compiled languages minder fouten bevatten? Men vergeet compleet de lagere learning curve van web languages. Er komen veel meer factoren bekijken bij de impact van een taal op het aantal fouten dan een compiler. Een compiler is bij het voorkomen ervan maar een piepklein stukje

[Alarmnummer]

Verwijderd schreef op dinsdag 22 februari 2005 @ 11:32:
[...]
Dat klopt inderdaad, daar ben ik het ook zeker eens mee, maar wat er nu wordt gedaan, is dat men de complete impact van fouten voorkomen teveel neerlegd bij de compiler

nee hoor. Als ik alle fouten eruit kon halen met een compiler zou ik niet unit testen. Als ik alle fouten eruit kon halen met unit testen, zou ik niet meer andere testtechnieken toepassen. Compilers/unit testen ed halen niet alle fouten eruit... maar wel een hele zwik. En daar gaat het om...

Tuurlijk voorkomt de compiler dergelijke problemen door voortijdig daar melding van te maken. Maar omdat je dit soort fouten voorkomt, betekend het opeens dat compiled languages minder fouten bevatten? Men vergeet compleet de lagere learning curve van web languages.

Dit argument is niet interessant voor productie omgevingen. Je mag er daar vanuit gaan dat mensen voldoende kennis van zaken hebben om een goed product neer te zetten.Die leercurve is dus niet interessant voor deze mensen. Het gaat om hoeveel fouten ze uiteindelijk in hun code hebben.

Er komen veel meer factoren bekijken bij de impact van een taal op het aantal fouten dan een compiler. Een compiler is bij het voorkomen ervan maar een piepklein stukje

Ben ik niet met je eens. Ik denk dat het merendeel van de fouten die ik maak fouten zijn die door de compiler (en mijn IDE die mijn source syntactisch en semantisch controleerd) eruit gevist worden. Het aantal 'diepere' fouten (fouten die eigelijk alleen een mens kan begrijpen) is veel minder dan de helft.

Als wij in dezelfde taal zouden moeten werken, en ik had de mogelijk om te compileren en jij niet, kan ik je de garantie geven dat mijn code veel sneller minder fouten zal bevatten dan jouw code.

[Verwijderd]

Alarmnummer, jij leest echt selectief

Ik gaf aan dat er wel rekening moest worden gehouden met de lage learning curve van web languages, en de invloed daarvan op uiteindelijke foutproduktie, en wat doe jij, jij ragt er overheen met "dat is voor produktieomgevingen niet interessant".

Inderdaad, de taal is voor de produktieomgeving niet interessant, maar volgens mij ging het hier om het resultaat dat een soort taal kan hebben op de hoeveelheid te maken fouten. Niet of het in produktie draait of niet

[EfBe]

Unittesten is goed, maar niet zaligmakend. In je tests, die ook gewoon code zijn, mogen ook geen fouten zitten. Dit vergeet men wel eens. De simpele tests zijn nog wel te overzien, maar wanneer complexere tests moeten worden geschreven, loop je het risico dat je OF code goed verklaart wat dat niet is, OF code fout verklaart wat dat niet is.

In blogpost http://weblogs.asp.net/fbouma/archive/2003/08/01/22211.aspx beschrijf ik 4 bug types (er zijn er wellicht meer):
# Functionality bugs. These are the ones at the highest abstract level: in the functionality the software has to provide. An example of this kind of bug is the ability to execute script in an email in Outlook (Express) and enable that feature by default.
# Algorithmic bugs. These are the ones at the abstract level below the functionality bugs. An example of this kind of bug is the (now patched) flaw in Microsoft's TCP/IP stack which marked the TCP/IP packets with numbers that weren't random enough which then could lead to data exposure via sniffing. The code was good, the algorithm used was bad.
# Algorithm implementation bugs. This is the kind of bug you'll see when an algorithm is implemented wrong. This type shouldn't be confused with the next category, however. Algorithm implementation bugs are bugs which originate in the developers mind when the developer thinks s/he understands how the algorithm to implement works and starts cranking out code, however the developer clearly didn't fully understand the algorithm so a piece of code was written which will not function as expected, although the developer thinks it does.
# Plain old stupidity bugs.. Everyone knows them: forget to update a counter, add the wrong value to a variable, etc. etc.

Welke van deze 4 is te achterhalen met een compiler? geen. Wel met testen enerzijds en vooraf goed nadenken anderzijds. Programmeurs zouden wanneer ze een routine af hebben, een stap terug moeten doen en gewoon moeten gaan nakijken wat ze hebben gebouwd en of dat conform de spec is, of het algorithme wel klopt etc.

Ik denk dat het merendeel van de fouten die ik maak fouten zijn die door de compiler (en mijn IDE die mijn source syntactisch en semantisch controleerd) eruit gevist worden.

Jouw IDE controlleert jouw code semantisch? Lijkt me heel sterk, of je moet in eiffel programmeren en daarnaast algorithmen abstract invoeren en de code daaraan toetsen.

Door allerlei IDE hulpmiddelen maken we minder syntactische fouten, dat houdt echter niet in dat een veelvoud aan fouten tot het verleden behoort. Immers: bij een scriptingtaal zie je de syntaxerrors vaak at runtime, wat hooguit meer tijd vergt om te fixen (en dat is echt zo) maar niet minder fouten oplevert qua implementatie, je weet wel, de fouten waar de gebruiker juist last van heeft.

[Alarmnummer]

EfBe schreef op dinsdag 22 februari 2005 @ 12:24:
Unittesten is goed, maar niet zaligmakend. In je tests, die ook gewoon code zijn, mogen ook geen fouten zitten. Dit vergeet men wel eens. De simpele tests zijn nog wel te overzien, maar wanneer complexere tests moeten worden geschreven, loop je het risico dat je OF code goed verklaart wat dat niet is, OF code fout verklaart wat dat niet is.

Niemand heeft beweerd dat unit testing de heilige graal is. Het is een van de dingen die ik gebruik om bugs eruit te vissen.

Jouw IDE controlleert jouw code semantisch? Lijkt me heel sterk, of je moet in eiffel programmeren en daarnaast algorithmen abstract invoeren en de code daaraan toetsen.

Ik weet niet wat voor ide`s jullie voor .net hebben, maar intellij idea, eclipse, jbuilder, codeguide/x-develop doen niet alleen syntactische check maar ook semantische check. Semantiek bestaat er op verschillende nivo`s. int a = true is iets dat mijn programmeeromgeving eruit vist. Alles wat een compiler eruit kan vissen, vissen moderne ide`s er ook al uit. Je hoeft dan niet meer te compileren. Je ziet meteen tijdens het typen wat er niet deugt..

Door allerlei IDE hulpmiddelen maken we minder syntactische fouten, dat houdt echter niet in dat een veelvoud aan fouten tot het verleden behoort. Immers: bij een scriptingtaal zie je de syntaxerrors vaak at runtime, wat hooguit meer tijd vergt om te fixen (en dat is echt zo) maar niet minder fouten oplevert qua implementatie, je weet wel, de fouten waar de gebruiker juist last van heeft.

Stel dat we php als voorbeeld nemen. Als ik de php code kan compileren heb ik sneller een systeem goed draaiend dan als ik het niet kan. Uiteindelijk zullen er evenveel bugs in zitten (stel dat je het een jaar hebt draaien). Maar door de compilatie slag (in ieder geval de code helemaal door laten fluiten) heb ik het systeem sneller bugvrij. Verder moet je er ook rekening mee houden dat er nog wel eens iets aan code wil veranderen. Met een compiler en unit tests heb ik hier minder last van.. ik zal minder snel runtime bugs voor de kiezen krijgen...

Ik snap gewoon niet dat jullie het niet begrijpen. Dat die hard scripters het niet willen begrijpen kan ik em voorstellen. Maar dat had ik van jou niet verwacht.

[.oisyn]

Verwijderd schreef op dinsdag 22 februari 2005 @ 11:32:
Men vergeet compleet de lagere learning curve van web languages.

Alsof alle web languages een lage learning curve hebben, en alsof alleen niet-web languages gecompileerd worden. Ik vind dit nogal een generalisatie van heb ik jou daar . Je kunt ook best een taal compileren met een lage learning curve, dan heb je het beste van beide werelden. Zoals ik al eerder zei, maar daar is niemand op ingegaan, is het meer een verschil tussen strong typed vs. loose typed. Syntax fouten kunnen in beide gevallen opgelost worden, semantische fouten voornamelijk in de eerste. Late binding zorgt voor de meest rare bugs en dient imho in een productieomgeving ook zoveel mogelijk vermeden te worden zolang het niet nodig is. Alleen jammer genoeg heb je de keuze vaak niet.

En uiteraard bestaan er nog wel meer fouten, van belang is imho echter zoveel mogelijk bugs in een zo vroeg stadium te exposen zodat ze opgelost kunnen worden. Een semantische controle (compilatie) helpt daar gigantisch bij.

[ Voor 12% gewijzigd door .oisyn op 22-02-2005 12:54 ]

[Verwijderd]

Dat proberen we je dus uit te leggen Een zegge Java is veel complexer dan een PHP, dit resulteerd er dan wel in dat je die compilatie ronde uitvoert, maar dat de taal van nature meer in fouten resulteerd door de complexere aard. Uiteindelijk zal het aantal fouten dus niet afhankelijk zijn van compilatie, maar van taal complexiteit. Ik heb daarbij de 1001 externe variabelen nog even buiten beschouwing gelaten.

[Alarmnummer]

Verwijderd schreef op dinsdag 22 februari 2005 @ 12:51:
Dat proberen we je dus uit te leggen Een zegge Java is veel complexer dan een PHP, dit resulteerd er dan wel in dat je die compilatie ronde uitvoert, maar dat de taal van nature meer in fouten resulteerd door de complexere aard. Uiteindelijk zal het aantal fouten dus niet afhankelijk zijn van compilatie, maar van taal complexiteit. Ik heb daarbij de 1001 externe variabelen nog even buiten beschouwing gelaten.

Hmm tja.. met dit soort argumenten kunnen we net zo goed meteen weer basic gaan programmeren. Minst complexe taal.. minste bugs... hatsjakidee..

[Verwijderd]

.oisyn schreef op dinsdag 22 februari 2005 @ 12:50:

Ja het was zeker een generalisatie, maar puur bedoeld om een punt neer te zetten van
lage learning curve = geen compilatie
tegen
hoge learning curve = compilatie

De andere mengeling met hoge learning curve, en geen compilatie heb je ook nog, en vice versa. Maar zoals ik al aangaf, het was puur bedoeld om een punt neer te zetten tov het compilatie aandeel in het totale proces van foutoplossing.

[Verwijderd]

Alarmnummer schreef op dinsdag 22 februari 2005 @ 12:53:
Hmm tja.. met dit soort argumenten kunnen we net zo goed meteen weer basic gaan programmeren. Minst complexe taal.. minste bugs... hatsjakidee..

Hoezo, jij pakt een taal natuurlijke eigenschap als referentiepunt voor jouw mening, ik doe hetzelfde alleen op basis van moeilijkheidsgraad.

[EfBe]

Alarmnummer schreef op dinsdag 22 februari 2005 @ 12:39:
Niemand heeft beweerd dat unit testing de heilige graal is. Het is een van de dingen die ik gebruik om bugs eruit te vissen.

Je komt anders over alsof een compiler + unittests het wel zo'n beetje is wat je nodig hebt.

Ik weet niet wat voor ide`s jullie voor .net hebben, maar intellij idea, eclipse, jbuilder, codeguide/x-develop doen niet alleen syntactische check maar ook semantische check. Semantiek bestaat er op verschillende nivo`s. int a = true is iets dat mijn programmeeromgeving eruit vist. Alles wat een compiler eruit kan vissen, vissen moderne ide`s er ook al uit. Je hoeft dan niet meer te controleren.

Je verwart syntax bugs met semantische bugs. Iets niet ophogen haalt jouw IDE er niet uit, een algorithme achterstevoren implementeren ook niet, iets vergeten te saven ook niet. Dat zijn wel fouten. int a = true kan syntactisch ook fout zijn, ik zie dat niet echt als semantische error checking.

Stel dat we php als voorbeeld nemen. Als ik de php code kan compileren heb ik sneller een systeem goed draaiend dan als ik het niet kan.

Je moet beter lezen, ik zei ook dat dat langer gaat duren, en geloof me, ik weet waarover ik het heb, na jaren asp gekrast te hebben van tijd tot tijd . Daarin vervloek je ook vbscript wanneer je 3 schermen diep ineens een syntax fout tegenkomt.

Uiteindelijk zullen er evenveel bugs in zitten (stel dat je het een jaar hebt draaien). Maar door de compilatie slag (in ieder geval de code helemaal door laten fluiten) heb ik het systeem sneller bugvrij.

Uit de lucht gegrepen conclusie. Je bespaart tijd met het eruit halen van de syntaxfoutjes, klopt. Maar als je nakijkt wat je schrijft, haal je die er zelf ook al aardig snel uit (of door de color coding), en wat ookal gezegd is hierboven, bij gebrek aan tools gebruik je de middelen die je resten. Ik weet niet of je het tijdperk van de commandline C debugger nog kent, maar dan weet je dat je soms ook met een compiler gewoon zeer spartaans moet gaan testen, maar dat dat wel werkt.

Dus de enige tijd die jij bespaart is de syntaxfoutjes eruit halen. Na een paar keer testen heb je die er wel uit. Het voordeel van scriptingtalen is weer dat je de pagina / script in een editor ernaast open hebt, en met een paar aanpassingen en een save ben je weer klaar, daar bespaart de scripter weer tijd, hij hoeft niet te compileren. Maar beide analogieen gaan mank aan het feit dat het voorbij gaat aan het feit dat fouten IN de code pas aan het licht komen door het nakijken van je code of je wel het juiste hebt geimplementeerd. Als jij quicksort moet bouwen en jij bouwt een foute quicksort want je hebt bv het algorithme verkeerd begrepen zodanig dat bij een even aantal entries het fout gaat, en jouw unittest test met oneven aantal entries en het sorteert, kan jij niet concluderen dat het goed is, je snapt nl. (stel) dat algoritme niet.

Dit scenario heeft niets met scripting of compilers te maken, maar met de projectie van wat je MOET maken op wat je het geschreven in executeerbare vorm.

Verder moet je er ook rekening mee houden dat er nog wel eens iets aan code wil veranderen. Met een compiler en unit tests heb ik hier minder last van.. ik zal minder snel runtime bugs voor de kiezen krijgen...

Met late binding heb je ook minder last van wijzigingen, ik denk zelfs minder dan met strong typed code.

Maar je maakt het een wedstrijd tussen scripting vs. compiled code, wat onzin is. De fouten die in de code blijven zitten zijn niet syntactisch van aard, dus het onderscheid boeit niet.

Ik snap gewoon niet dat jullie het niet begrijpen. Dat die hard scripters het niet willen begrijpen kan ik em voorstellen. Maar dat had ik van jou niet verwacht.

Wat snap ik niet? Ik wilde alleen maar aangeven dat de discussie niet moet ontaarden in gezemel over "jij gebruikt geen compiler en/of unittests dus je code is minder goed" of daaromtrent want daar komt het zolangzamerhand wel op neer, en dat is dus echt onzin.

Menigeen hier begint gewoon met kloppen van code en heeft niet meer dan een vaag idee van wat hij/zij denkt te moeten implementeren. Na afloop kijkt de programmeur niet in detail na wat hij heeft gebouwd met wat hij had moeten bouwen (een gecontrolleerd! algorithme) zodat hij semantische fouten kan opsporen (bugs), het zou ook niet zinvol zijn, het algoritme zit in de persoon's hoofd en staat niet vast zwart op wit.

Je kunt dan die code wel door een compiler trekken en controlleren met een unittest maar als jij ook die unittest schrijft test jij je code zoals jij denkt hoe het algoritme moet werken, niet zoals het wellicht zou moeten werken en tegen alle pre-/post condities. Je syntaxfoutjes zijn dan wellicht wel weg (alhoewel ook in java je runtime casting hebt die menig uurtje kosten) en je unittest zegt dat het goed is maar of het WERKELIJK goed is is maar de vraag. Een unittest zegt mij echt geen ene biet.

Voorbeeldje hebben? nhibernate's v0.3 alpha liep door bijna alle unittests heen (stuk of 300 dacht ik) maar intern was die code echt een zootje en menig "What does this do?" comment kwam je tegen. Solide code, bugfree? Geen idee. Maar ik zou de unittests en compiler niet vertrouwen voor 100%. Want wat als jij het gebruikt in situatie X die niet gecovered wordt door een unittest?

TDD kan goed werken, wanneer je eerst met mocks alleen je tests schrijft, je algorithmen controlleert en wanneer je alles hebt gecontrolleerd tot implementatie van je mocks overgaat. Wie doet dat in dat detail?

.oisyn schreef op dinsdag 22 februari 2005 @ 12:50:
En uiteraard bestaan er nog wel meer fouten, van belang is imho echter zoveel mogelijk bugs in een zo vroeg stadium te exposen zodat ze opgelost kunnen worden. Een semantische controle (compilatie) helpt daar gigantisch bij.

Compilatie is geen semantische controle. het controlleert op syntax en genereert code aan de hand van rules, weet jij ook Semantische controle zou zijn het testen van pre/post condities bijvoorbeeld.

In talen zonder generics heb je veel fouten die zijn gerelateerd aan het gebruik van 'general' data structures zoals een list van object objects. At compiletime kunnen die niet worden getest op type safety. At runtime wel en dan heb je dezelfde problemen als bij late bounded talen zoals de meeste scripting talen. In C heb je dat bv ook, in C#, in java maar in C++ met templates weer niet.

Men snapt kennelijk niet dat 'bugs' meer is dan syntactische errors oplossen. Een compiler is erg zinvol voor tijdsbesparing, maar ook maar tot op zekere hoogte.

[ Voor 10% gewijzigd door EfBe op 22-02-2005 13:05 ]

[.oisyn]

Verwijderd schreef op dinsdag 22 februari 2005 @ 12:54:
Ja het was zeker een generalisatie, maar puur bedoeld om een punt neer te zetten van
lage learning curve = geen compilatie
tegen
hoge learning curve = compilatie

Wat is je punt dan precies? Want wat je hier zegt klopt gewoon niet . Een compilatiestap betekent niet meteen een hoge learning curve, en het zou ontzettend handig zijn voor een PHP developer (ik noem maar een voorbeeld) als hij bijvoorbeeld op zijn development machine een soort van php semenatic analyser heeft draaien die net voor de run even een check doet en alle fouten controleert. Een compilatiestap is, naast dingen als unittesting, gewoon een methode om bepaalde fouten eruit te halen, waarom moet daar zo tegen geargeerd worden?

Zo had ik in m'n ubb parser ergens een symantische fout zitten die tijdens een run gewoon doodleuk een fatal error uitpoepte. Ik kwam er echter pas na 3 maanden achter toen iemand in zijn post ineens die special case gebruikte waarin de bug optrad. Het had fijn geweest als deze van tevoren al eruit was gehaald, want dat had gewoon gekunt.

[Alarmnummer]

Verwijderd schreef op dinsdag 22 februari 2005 @ 12:55:
[...]


Hoezo, jij pakt een taal natuurlijke eigenschap als referentiepunt voor jouw mening, ik doe hetzelfde alleen op basis van moeilijkheidsgraad.

Hmm tja... ik kan je schijnbaar niet duidelijk maken dat een gecompileerd programma (in ieder geval een die helemaal is doorgefloten.. codegeneratie even niet belangrijk) altijd minder fouten zal bevatten dan een ongecompileerd programma. Het is een van de manieren om bugs eruit te vissen. En dat is dus mijn argument tegen scripttalen in productie omgevingen (afgezien van dubieuze taalconstructies).

En het maakt mij verder ook niet uit dat ik zelf op een compile knop moet drukken, of dat de 'server' zelf gaat checken bij het uploaden van een nieuw php bestand. Als de garantie maar aanwezig is, dat zo gauw het systeem draait, fouten eruit zijn gehaald die automatisch opgespoord hadden kunnen worden.

[.oisyn]

EfBe schreef op dinsdag 22 februari 2005 @ 13:00:
Je verwart syntax bugs met semantische bugs. Iets niet ophogen haalt jouw IDE er niet uit, een algorithme achterstevoren implementeren ook niet, iets vergeten te saven ook niet. Dat zijn wel fouten. int a = true kan syntactisch ook fout zijn, ik zie dat niet echt als semantische error checking.

Ongeacht hoe jij het ziet heet dat gewoon een semantische bug, aangezien de parser (die de syntactische controle doet) het er niet uithaalt, maar de fout pas wordt gevonden tijdens de semantische analyse van het compilatieproces (maar idd, een compiler zal nooit alle semantische bugs kunnen vinden)

[ Voor 9% gewijzigd door .oisyn op 22-02-2005 13:05 ]

[EfBe]

.oisyn schreef op dinsdag 22 februari 2005 @ 13:03:
Ongeacht hoe jij het ziet heet dat gewoon een semantische bug, aangezien de parser (die de syntactische controle doet) het er niet uithaalt, maar de fout pas wordt gevonden tijdens de semantische analyse van het compilatieproces

Alle talen die naar een VM compileren doe die analyse al niet, en ook die analyses zijn vaak niet echt diep, botweg omdat er te weinig informatie omhanden is. Als jij een routine maakt die een pointer krijgt naar een array met een setje vectorstructs en je wil daar mee bezig kan die pointer naar van alles wijzen. De compiler kan echt niet achterhalen of alle code de juiste structuur aan jouw routine meegeeft.

Simpele dingen als object freeing, of buffer overflows, die zijn pas at runtime te checken, bv met stackframe guards. Zodra een cast gedaan wordt kan een analyseprogramma er al niets meer mee, want het is niet voor 100% zekerheid te zeggen dat wat de source is voor de cast de cast ook echt ondersteunt, behalve in sommige gevallen, bv wanneer je het type weet van de source' objects. Maar als die afkomstig is van een cast van uchar* of in java/C# vanaf een object type, ben je het haasje. het is allemaal maar betrekkelijk hoor, wat men kan at runtime.

[Alarmnummer]

EfBe schreef op dinsdag 22 februari 2005 @ 13:00:
Je verwart syntax bugs met semantische bugs.

Ik denk dat jij dan de definitie voor syntax en semantiek erbij moet pakken Grammaticale fouten zijn syntax fouten. vb.. int int a + b b b ;

Dat is een syntax fout...

int a = true

Dat is een semantische fout

Iets niet ophogen haalt jouw IDE er niet uit, een algorithme achterstevoren implementeren ook niet, iets vergeten te saven ook niet. Dat zijn wel fouten. int a = true kan syntactisch ook fout zijn, ik zie dat niet echt als semantische error checking.

Idd.. diepere semantische fouten kan een systeem er niet uihalen. Maar ik ben blij met alles wat ik kan krijgen om bugs eruit te halen. En een compiler over sourcecode heenhalen om al een hele zwik fouten eruit te peuteren zonder dat ik hier ook maar eenige vorm van inspanning voor hoef te doen (afgezien van een knop indrukken) is dus aan nagenoeg gratis aanwinst om al een zwik bugs eruit te peuteren.

Uit de lucht gegrepen conclusie. Je bespaart tijd met het eruit halen van de syntaxfoutjes, klopt. Maar als je nakijkt wat je schrijft, haal je die er zelf ook al aardig snel uit (of door de color coding), en wat ookal gezegd is hierboven, bij gebrek aan tools gebruik je de middelen die je resten. Ik weet niet of je het tijdperk van de commandline C debugger nog kent, maar dan weet je dat je soms ook met een compiler gewoon zeer spartaans moet gaan testen, maar dat dat wel werkt.

Die periode ken ik zeker nog. Ik ben zo nu en dan wel eens bezig in andere talen en daarbij erger ik me ook aan het feit dat ik alles zelf uit moet zoeken. Vooral talen die extreem vergevingsgezind zijn, zijn een ware hel om mee te werken. Prolog is bv zo`n taal waarbij je er nauwelijks achterkomt wat er fout is gegaan, want ieder programma is meteen data en data is nooit incorrect. Daarom zijn programma`s ook nooit incorrect omdat het programma zelf nooit expliciet gedraait hoeft te worden.. leuk en fijn.. maar programmeert gewoon totaal kut. Daarom heb ik er een semantische slag aan toe gevoegd die mij al een hele zooi warnings geeft als ik iets fout doe.. wauw.. wat een winst...

Slimmere omgevingen maken je productiever... Een goeie ide (met on the fly error checking) en een goeie compiler (en unit tests) maken mij productiever. Uiteindelijk zal iemand die rechtstreeks in bytecode programmeert wel hetzelfde stuk software kunnen schrijven als ik... maar hij doet er veel langer over... en daar gaat het om... Het zo snel mogelijk afleveren van software waarbij de meeste bugs uit zijn verwijdert.

Dus de enige tijd die jij bespaart is de syntaxfoutjes eruit halen. Na een paar keer testen heb je die er wel uit.

Ga maar eens refactoren. Methode een betere naam, andere signature, verplaatst naar een andere class.. De compiler pikt foute aanroepen bij mij eruit.. jij zult altijd de site door moeten klikken. Klikken kost tijd.

Dit scenario heeft niets met scripting of compilers te maken, maar met de projectie van wat je MOET maken op wat je het geschreven in executeerbare vorm.

Lees mij verhaal nu even goed. Diepere semantische fouten kan een compiler er niet uithalen. Deze fouten moet ik er dus zelf uithalen.. maar het scheelt mij wel een enorme lading werk als dit de enigste bugs zijn die ik eruit moet halen. Dat is toch niet zo lastig om te begrijpen?

Maar je maakt het een wedstrijd tussen scripting vs. compiled code, wat onzin is. De fouten die in de code blijven zitten zijn niet syntactisch van aard, dus het onderscheid boeit niet.

Dan moeten we 2 teams laten programmeren in exact dezelfde taal en met dezelde tools. Het ene team krijgt als extraatje een 'code checker' en het andere team niet. Ik weet wel waar ik mijn geld op in moet zetten.

Je kunt dan die code wel door een compiler trekken en controlleren met een unittest maar als jij ook die unittest schrijft test jij je code zoals jij denkt hoe het algoritme moet werken, niet zoals het wellicht zou moeten werken en tegen alle pre-/post condities. Je syntaxfoutjes zijn dan wellicht wel weg (alhoewel ook in java je runtime casting hebt die menig uurtje kosten) en je unittest zegt dat het goed is maar of het WERKELIJK goed is is maar de vraag. Een unittest zegt mij echt geen ene biet.

Tja... ik neem aan dat jij geen unit tests gebruikt dus. Je geeft in unit test aan wat een stuk functie hoort te doen. Op het moment dat jij ook niet aan kunt geven wat die hier hoort te doen, had je gewoon geen software moeten schrijven. Ik weet bij een unit test precies wat een functie hoort te doen. Ik test hem daarop. En vaak kom ik ook nog allerlei kantel punten tegen... die soms zijn vergeten in de te testen code. En dat je fouten kan maken in de tests zelf is zeker mogelijk (gebeurt mij ook vaak genoeg), maar ik ben blij met alles wat ik kan krijgen om bugs uit mijn code te halen.


Unit testen, compilatie etc zijn niet de heilige graal... Het zijn tools die mij helpen om bugs eruit te halen. Als jullie betere alternatieven hebben, en toevoegingen, zal ik ze met uitzonderlijk veel plezier opnemen in mijn ontwikkeld proces.

[ Voor 3% gewijzigd door Alarmnummer op 22-02-2005 13:22 ]

[EfBe]

Alarmnummer schreef op dinsdag 22 februari 2005 @ 13:17:
Ik denk dat jij dan de definitie voor syntax en semantiek erbij moet pakken Grammaticale fouten zijn syntax fouten. vb.. int int a + b b b ;

Dat is een syntax fout...

int a = true

Dat is een semantische fout

In C# niet, de left operand van type int kan geen boolean bevatten. Dit is bv ook een syntax fout in C#: if (a=3) {}. De expression van een if mag geen assignment zijn.

Niet om te zeuren, maar wat wellicht in C++ een semantische fout is (het kan wel, maar is niet goed, bv bytes schrijven naar memory en die casten naar een BSTR) is in een andere taal wellicht een syntactische fout.

for(int i=0;i<max;i++)
{
//...
i++;
}

dat is een semantische fout.

Idd.. diepere semantische fouten kan een systeem er niet uihalen. Maar ik ben blij met alles wat ik kan krijgen om bugs eruit te halen. En een compiler over sourcecode heenhalen om al een hele zwik fouten eruit te peuteren zonder dat ik hier ook maar eenige vorm van inspanning voor hoef te doen (afgezien van een knop indrukken) is dus aan nagenoeg gratis aanwinst om al een zwik bugs eruit te peuteren.

Ik geloof niet dat iemand dat bestrijdt, echter je moet het niet overdrijven. Het heeft ook nadelen, je moet nl compileren. Dat duurt bij java of C# niet zo lang, bij C++ wel.

Slimmere omgevingen maken je productiever... Een goeie ide (met on the fly error checking) en een goeie compiler (en unit tests) maken mij productiever. Uiteindelijk zal iemand die rechtstreeks in bytecode programmeert wel hetzelfde stuk software kunnen schrijven als ik... maar hij doet er veel langer over... en daar gaat het om... Het zo snel mogelijk afleveren van software waarbij de meeste bugs uit zijn verwijdert.

Maar als de scripter nu een week korter nodig heeft om hetzelfde te bouwen en 3 dagen om alle syntaxfouten eruit te halen, dan is de scripter nog sneller klaar. De scripter hoeft bv geen checked exceptions troep te bouwen en meer van dat al, heeft een grote lib ter beschikking (noem maar iets) die veel doet en ga zo maar door.

Het topic is ook niet 'hoe zo weinig mogelijk fouten in 1 uur', maar per regels code. Zodra tijd erbij betrokken wordt is het einde zoek.

Ga maar eens refactoren. Methode een betere naam, andere signature, verplaatst naar een andere class.. De compiler pikt foute aanroepen bij mij eruit.. jij zult altijd de site door moeten klikken. Klikken kost tijd.

Ik zei 2 keer al dat ik echt wel weet dat dat waar is. Echter dat neemt niet weg dat per 1000 regels code jouw code niet foutlozer hoeft te zijn: jouw hulpmiddelen helpen je nl. niet bij de fouten die resten of het nu script of java of assembler is.

Lees mij verhaal nu even goed. Diepere semantische fouten kan een compiler er niet uithalen. Deze fouten moet ik er dus zelf uithalen.. maar het scheelt mij wel een enorme lading werk als dit de enigste bugs zijn die ik eruit moet halen. Dat is toch niet zo lastig om te begrijpen?

Ik snap dat wel, maar jij maakt ervan dat wat rest zo'n 10% is of iets dergelijks. Mijn schatting (ik heb net zoweinig bewijs als jij) is dat de meerderheid van de fouten die blijven zitten in mijn code geen reet met syntax te maken heeft, want zoveel compiler errors krijg ik echt niet na het typen van code.

Dan moeten we 2 teams laten programmeren in exact dezelfde taal en met dezelde tools. Het ene team krijgt als extraatje een 'code checker' en het andere team niet. Ik weet wel waar ik mijn geld op in moet zetten.

Ik zet mijn geld op het team dat nadenkt voordat het code gaat kloppen, zoals het nakijken of het algoritme echt klopt, na afloop checkt met het algoritme of de code inderdaad de executeerbare vorm van dat algoritme is etc. Daar heb je geen code-checker voor nodig, die pakt nl. dat soort fouten niet.

Tja... ik neem aan dat jij geen unit tests gebruikt dus.

Jawel hoor, veel zelfs. Ik heb hier echter een paar 100,000 regels code waar unittests geen reet mee kunnen. Wat wel helpt is nadenken vooraf, checken achteraf. En andere tests schrijven. Unittests zijn lang niet altijd mogelijk, nadenken over wat je MOET maken en wat je hebt gemaakt zijn echter wel altijd mogelijk

Je geeft in unit test aan wat een stuk functie hoort te doen. Op het moment dat jij ook niet aan kunt geven wat die hier hoort te doen, had je gewoon geen software moeten schrijven. Ik weet bij een unit test precies wat een functie hoort te doen.

Altijd humor dit soort opmerkingen. HOE weet jij wat een functie behoort te doen? Door de code te lezen? Mijn metafoor met quicksort gaat erover dat jij een algoritme leest, DENKT dat je weet hoe het werkt, het implementeert en dat die implementatie dus wel klopt, maar hij klopt met wat jij DACHT dat het algoritme zou doen, niet wat het werkelijk doet. Alleen door de beschrijving van de functie (functie doet xyz, pre condities a, postcondities b) te weten, algorithme te testen en te kijken of dat is geimplementeerd weet jij of een functie doet wat deze doet. DAT moet jouw test belichamen.

Unit testen, compilatie etc zijn niet de heilige graal... Het zijn tools die mij helpen om bugs eruit te halen. Als jullie betere alternatieven hebben, en toevoegingen, zal ik ze met uitzonderlijk veel plezier opnemen in mijn ontwikkeld proces.

Ieder beetje helpt. Echter zolang men niet begrijpt wat werkelijk de oorzaak is van vele bugs, kun je nog zoveel tools gebruiken, maar een design flaw in je algoritme zal hij niet oppikken, en dat zijn juist de bugs die tellen. Dat je ergens een tellertje niet ophoogt, daarvoor hoef je echt geen unittest te schrijven, dat moet je kunnen achterhalen mbv je algoritmebeschrijving en je code analyse (en code analysis tools pikken dat vergeten tellertje er niet uit)

[Alarmnummer]

EfBe schreef op dinsdag 22 februari 2005 @ 13:41:
[...]
Ik snap dat wel, maar jij maakt ervan dat wat rest zo'n 10% is of iets dergelijks. Mijn schatting (ik heb net zoweinig bewijs als jij) is dat de meerderheid van de fouten die blijven zitten in mijn code geen reet met syntax te maken heeft, want zoveel compiler errors krijg ik echt niet na het typen van code.

Syntax fouten niet.. semantische fouten maar al te vaak. Gelukkig helpt mijn ide me enorm maar als ik die niet heb.. tja... dan toch wel heel wat fouten.

Ik zet mijn geld op het team dat nadenkt voordat het code gaat kloppen, zoals het nakijken of het algoritme echt klopt, na afloop checkt met het algoritme of de code inderdaad de executeerbare vorm van dat algoritme is etc. Daar heb je geen code-checker voor nodig, die pakt nl. dat soort fouten niet.

Als beide teams even goed over hun algoritme nadenken heeft het team met de code checker nog steeds een voorsprong.

Jawel hoor, veel zelfs. Ik heb hier echter een paar 100,000 regels code waar unittests geen reet mee kunnen. Wat wel helpt is nadenken vooraf, checken achteraf. En andere tests schrijven. Unittests zijn lang niet altijd mogelijk, nadenken over wat je MOET maken en wat je hebt gemaakt zijn echter wel altijd mogelijk

Je kunt idd niet overal unit testen. En je zult goed moeten nadenken over wat je wilt maken. Maar goed nadenken sluit testen niet uit. Ik specificeer een stuk functionaliteit (meestal in de documentatie). Deze specificatie is dus het contract waaraan mijn functie zich moet houden. Op basis van dit contract kan ik een functie/systeem controleren. Hiermee zie ik dus of de functie zich houd aan contract.

Altijd humor dit soort opmerkingen. HOE weet jij wat een functie behoort te doen? Door de code te lezen?

Meestal zie ik dat door de documentatie of de naam van de functie

Mijn metafoor met quicksort gaat erover dat jij een algoritme leest, DENKT dat je weet hoe het werkt, het implementeert en dat die implementatie dus wel klopt, maar hij klopt met wat jij DACHT dat het algoritme zou doen, niet wat het werkelijk doet. Alleen door de beschrijving van de functie (functie doet xyz, pre condities a, postcondities b) te weten, algorithme te testen en te kijken of dat is geimplementeerd weet jij of een functie doet wat deze doet. DAT moet jouw test belichamen.

Ja.. en dat doen mijn unit testen ook. In het geval van een soort zou ik een aantal test draaien.. en dan vooral ook extremen.. werkt het bv ook goed met een lege lijst. Wat gebeurt er met de volgorde van 'gelijke' elementen.. Wat gebeurt er als er een fout element aanwezig is..

Ieder beetje helpt. Echter zolang men niet begrijpt wat werkelijk de oorzaak is van vele bugs, kun je nog zoveel tools gebruiken, maar een design flaw in je algoritme zal hij niet oppikken, en dat zijn juist de bugs die tellen.

Hmm.. is niet mijn ervaring. Met unit testen pak ik nog vaak genoeg een bug die niet altijd een extreem diepe oorzaak hebben. Een check vergeten.. een toestand vergeten.. etc.. Kleine dingetjes.. maar kosten wel vaak tijd om achteraf te herhalen.

Dat je ergens een tellertje niet ophoogt, daarvoor hoef je echt geen unittest te schrijven, dat moet je kunnen achterhalen mbv je algoritmebeschrijving en je code analyse (en code analysis tools pikken dat vergeten tellertje er niet uit)

Hmm tja.. ik wil niet iedere keer mijn code aflopen of daar misschien een fout is geintroduceerd... Kost veel tijd. Ik draai liever een testsuite om te controleren of de code nog doet wat het hoort te doen.

[Verwijderd]

Dit wordt een kansloze discussie, met opmerkingen als "vage taalconstructies" ontstaat al direct een bevooroordeelde positie die een discussie niet eens verdiend. Wellicht zou het je sieren eens wat tijd te steken in andere talen dan Java, wellicht dat er dan wat flexibiliteit naar buiten komt in je mening

[Alarmnummer]

Verwijderd schreef op dinsdag 22 februari 2005 @ 14:07:
Dit wordt een kansloze discussie, met opmerkingen als "vage taalconstructies" ontstaat al direct een bevooroordeelde positie die een discussie niet eens verdiend.

Nee hoor.. er zijn bepaalde taalconstructies die nogal dubieus zijn. Java heeft er trouwens ook een aantal...

Wellicht zou het je sieren eens wat tijd te steken in andere talen dan Java, wellicht dat er dan wat flexibiliteit naar buiten komt in je mening

Hmm.. ik heb een paar regeltjes Python/Jython gedaan.. Nice, c/c++, Pascal/Delphi, ook wel wat assembler vroeger, Prolog, JESS/Clips, Java, c#, en uiteraard beetje haskell/clean. Ik denk dat ik genoeg andere talen heb bekeken.

Er zijn gewoon dubieuze taalconstructies. Constructies die in de praktijk alleen maar tot onduidelijke code leiden.

[ Voor 4% gewijzigd door Alarmnummer op 22-02-2005 14:14 ]

[.oisyn]

EfBe schreef op dinsdag 22 februari 2005 @ 13:16:

Alle talen die naar een VM compileren doe die analyse al niet, en ook die analyses zijn vaak niet echt diep, botweg omdat er te weinig informatie omhanden is. Als jij een routine maakt die een pointer krijgt naar een array met een setje vectorstructs en je wil daar mee bezig kan die pointer naar van alles wijzen. De compiler kan echt niet achterhalen of alle code de juiste structuur aan jouw routine meegeeft.

http://dictionary.reference.com/search?db=*&q=semantics
se·man·tics
[list=1]• Linguistics. The study or science of meaning in language.
• Linguistics. The study of relationships between signs and symbols and what they represent. Also called semasiology.
• The meaning or the interpretation of a word, sentence, or other language form: We're basically agreed; let's not quibble over semantics.

Als jij het volgende stukje code hebt:

C++:

class Bla
{
private:
    Bla();
    ~Bla();
};

Bla bla;

Dan is dat syntactisch correct. Er is een klassedefinitie, en een variabeledefinitie. De parser zal dan ook geen fouten rapporteren. Semantisch is het niet correct, De constructor en destructor van Bla zijn private en dus kan die variabele niet geconstruct worden. Dit wordt opgevangen tijdens de semantische controle, en vrijwel elke compiler heeft zo'n controle, ook de .Net compilers.

Daarnaast zijn er uiteraard een hoop semantische dingen die een compiler er niet uit kan halen, puur omdat de compiler de achterliggende gedachte erachter niet kan achterhalen.

[.oisyn]

EfBe schreef op dinsdag 22 februari 2005 @ 13:41:
[...]

In C# niet, de left operand van type int kan geen boolean bevatten. Dit is bv ook een syntax fout in C#: if (a=3) {}. De expression van een if mag geen assignment zijn.

Dat wordt pas ontdekt tijdens de semantische analyse, de parser zal het zo zien:

code:

if_statement:
    "if" '(' expression ')' statement;

expression:
    assignment_expression |
    function_call |
    identifier;

(Bij wijze van spreken, in het echt is een expression natuurlijk wat ingewikkelder )
De parser zal geen rekening houden met type-informatie. Een a = b zal altijd op dezelfde manier geparsed worden, ongeacht de typen van a en b. Als tijdens de semantische analyse blijkt dat het type van a een int is, terwijl die van b een string is, krijg je een semantische error.

[EfBe]

waar wordt de semantische fout ontdekt in die class van je? Bij Bla bla; Die regel kan niet, want er is geen public constructor, ergo: type wordt fout gebruikt. Ik weet niet of dit wel in een after analyse wordt gevonden, ik denk gewoon tijdens de parsing van de rules, want de constructor kan niet worden gevonden voor Bla. (dwz handling van de creation nonterminal geeft een error want type Bla heeft geen accessable constructor)

Maar dit wordt een wordgame . Ik vind een regel code die door foutief type gebruik/constructie niet compileert een syntax fout, en een algoritmische fout een semantische, maar goed, daar zijn de meningen over verdeeld, dus dat is dan nu hopelijk uit de wereld (is ook intens niet belangrijk in deze discussie)

.oisyn schreef op dinsdag 22 februari 2005 @ 14:20:
Dat wordt pas ontdekt tijdens de semantische analyse, de parser zal het zo zien:

code:

if_statement:
    "if" '(' expression ')' statement;

expression:
    assignment_expression |
    function_call |
    identifier;

(Bij wijze van spreken, in het echt is een expression natuurlijk wat ingewikkelder )
De parser zal geen rekening houden met type-informatie. Een a = b zal altijd op dezelfde manier geparsed worden, ongeacht de typen van a en b. Als tijdens de semantische analyse blijkt dat het type van a een int is, terwijl die van b een string is, krijg je een semantische error.

Nee, een if is expliciet als if (booleanExpression) gedefinieerd, dus wel degelijk een syntax fout. a=b is geen boolean expression (syntactisch kan die expression niet worden omgeschreven tot de nonterminal booleanExpression).

Zeikerig, geef ik meteen toe, maar ik doelde erop om aan te geven dat de verschillen in wat de een semantiek vindt en de ander syntactisch niet eenduidig bepaald zijn voor alle talen, dus dat dat in deze discussie er eigenlijk niet toe doet.

[ Voor 4% gewijzigd door EfBe op 22-02-2005 14:47 ]

[.oisyn]

a=b is geen boolean expression (syntactisch kan die expression niet worden omgeschreven tot de nonterminal booleanExpression).

In C# is een assignment expression óók een expression, namelijk een die de lhs returnt. Een if (a = b) kan dus prima, als zowel a als b boolean zijn. Daarnaast vraag ik me af waar je die definitie van die if vandaan haalt; waarschijnlijk uit de documentatie waar de werkelijke grammatica is aangepast om het voor de gebruiker duidelijker te maken wat er verwacht wordt. Het lijkt mij namelijk stug dat ze aparte grammatica rules hebben voor aparte typen. Een identifier blijft waarschijnlijk gewoon een identifier, en een a = b parset gewoon als een assignment operator op 2 identifiers (ongeacht hun type). Maar goed, ik ken C# niet goed genoeg om dit soort uitspraken te doen, en daarnaast weten we nu gewoon wat we bedoelen en dat is uiteindelijk waar het om gaat

[EfBe]

Je hebt inderdaad gelijk!
bool a=false;
bool b=true;
if(a=b)
{
Console.WriteLine("aarg");
}
werkt idd.

Ik kwam hier nl. op omdat je bij alle andere expressies errors krijgt, dat je een boolean expressie moet definieren voor de if expression.

Ik zou me wel kunnen voorstellen dat ze een aparte boolean expression definieren in de grammar om de parser makkelijker te maken, hebben ze niet gedaan kennelijk. Het voorbeeldprogrammaatje levert gewoon "aarg" op, wat eigenlijk raar is want het is IMHO undefined wat er gebeurt, naja. Maar idd, we weten waar het over gaat nu,

[Woudloper]

Om even terug te komen op de vraag van de topicstarter. Ik heb zo'n uitspraak ook weleens voorbij zien komen op een presentatie, maar kon hem helaas nergens meer vinden in mijn archief.

Overigens is het wel belangrijk om te bepalen wat de definitie van een fout is. Je heb overigens op het gebied van testen het welbekende V-Model. Daarin zie je de verschillende fasen van een ontwikkelproject en hoe eerder de fout bevinding wordt geconstateerd (dat kan dus ook in de specificaties o.i.d. zijn) des te beter het is...