Nieuwe IBM-tool herkent bugs tijdens programmeren
IBM heeft een tool vrijgegeven die er voor zou zorgen dat softwarecode 15 tot 20 procent minder bugs bevat. De Rational Software Analyzer kan daarmee bedrijven potentieel veel geld besparen.
De tool, die als een plugin beschikbaar is voor de veelgebruikte ontwikkelomgeving Eclipse versie 3.3 en hoger, scant de code tijdens het schrijven op kwaliteit en fouten. IBM stelt dat zijn geavanceerde 'spellingschecker' vooral in de beginfase van een ontwikkeltraject veel bugs vroegtijdig onder de aandacht kan brengen. Doordat de software sneller door de testfase rolt, zou dit bedrijven, die aan grote projecten werken, geld besparen, zo stelt Big Blue. De Rational Software Analyzer draait onder Windows en Linux, en ondersteunt standaard Java en C++. Daarnaast belooft IBM voor andere programmeertalen plugins beschikbaar te stellen. Tenslotte kunnen gebruikers ook zelf regels aan de code checker toevoegen.
Het aanschaffen van een controlefunctie voor ontwikkelpakketten als Eclipse kan, ondanks de forse prijs van 3500 dollar per gebruiker, een bedrijf veel latere kosten besparen. Volgens een studie van de firma Cigital kost het pletten van bugs tijdens de testfase zeven maal meer dan bij het schrijven van de code. Na de release van een product zouden de kosten, bijvoorbeeld voor het uitbrengen van een patch, zelfs tot veertien maal hoger liggen.
Reacties (46)
findbugs en pmd doen dit al lang en hebben ook een eclipse plugin
Enkel java.....
...Maar met een X-hoeveelheid werk, zoals de bovenstaande programma's ook ondervonden hebben, zijn die ook wel te converteren naar andere talen.
@ YopY
Helaas is X in dit verhaal een variabele factor van tijd en energie die iemand er wel gratis in moet steken.
Helaas is X in dit verhaal een variabele factor van tijd en energie die iemand er wel gratis in moet steken.
Op Wikipedia staat een aardige lijst met tools voore statische code analyse voor de meest populaire programmeer talen, waaronder: Java, C, C++, PHP. De meeste tools zijn niet geintegreerd met Eclipse, meer een paar wel (Bijv. Klocwork). Trouwens, voor software ontwikkelaars is statische code analyse, denk ik, iets waar je op zijn minst van op de hoogte moet zijn.
[Reactie gewijzigd door Gyske op woensdag 30 juli 2008 20:02]
't is jammer dat er blijkbaar maar weinig voor PHP zijn, en die twee die er zijn zijn heel specialistisch. PHP zit vol met valkuilen, ik had er heel graag een goeie analyse-tool voor gezien.
De meningen verschillen dan ook over het antwoord op de vraag of PHP wel een programmeertaal is 
Kan men over discussiëren, je kan er hoe dan ook mooie web applicatie's mee schrijven en er bestaan wel compilers voor. :-)
Maar het is inderdaad meer een script taal
Maar het is inderdaad meer een script taal
Ik vraag me af hoe dat werkt. Een deel fouten zijn inderdaad banale fouten zoals bijvoorbeeld een puntkomma vergeten, maar die haalt een beetje goede IDE er vanzelf uit (al dan niet tijdens het compileren).
Een heel groot deel zijn echter logische fouten, zoals bijvoorbeeld een variabele waarvan je denkt dat je de reference doorgeeft, maar dat het toch niet zo is. Deze lijken me erg moeilijk automatisch te vinden.
Een heel groot deel zijn echter logische fouten, zoals bijvoorbeeld een variabele waarvan je denkt dat je de reference doorgeeft, maar dat het toch niet zo is. Deze lijken me erg moeilijk automatisch te vinden.
Hier wat meer uitleg http://www.ibm.com/develo...al/library/08/0429_gutz1/
Het tool doet in de eerste plaats aan syntax checking die naast de toegelaten taal ook wat extra kijk heeft op wat goede schrijfstijl is. Daarnaast analyseert hij ook de dependancies tussen functies, compilation units, .. om organisatorische/pattern problemen te zoeken (en bad practices).
Deze structuur kan weer gebruikt worden om statistieken te trekken die de kwaliteit van code bepalen (commentaar, grote kleine functies, duplicatie, complexiteit, koppeling, errorchecking. ...)
Het tool doet in de eerste plaats aan syntax checking die naast de toegelaten taal ook wat extra kijk heeft op wat goede schrijfstijl is. Daarnaast analyseert hij ook de dependancies tussen functies, compilation units, .. om organisatorische/pattern problemen te zoeken (en bad practices).
Deze structuur kan weer gebruikt worden om statistieken te trekken die de kwaliteit van code bepalen (commentaar, grote kleine functies, duplicatie, complexiteit, koppeling, errorchecking. ...)
Klinkt als fxcop, maar een hoop bugs die inderdaad logische bugs zijn zal hij niet gaan vinden (tenzei de tool de gedachte van de programmer kan lezen om te zien wat nou eindelijk de bedoeling was). Een goed test driven design lijkt me daarom een stuk handiger, daar kun je namelijk precies opgeven wat de bedoeling is en structureel in de gaten houden of dat bij aanpassingen bijv. wel blijft werken zoals het hoort.
Hrm, als ik die pagina zo bekijk zijn er veel regels die ook al in andere programma's zoals FindBugs en PMD en dergelijke zitten. Ik heb nog lang niet alle regels gezien echter, dus ik ben er vrij zeker van dat er nog veel meer in zitten. En dat er nog meer in komen wanneer dit product verder uitontwikkeld wordt.
Maar om er nu 3500 dollar (oid) voor neer te leggen... Nee. Er zijn gratis alternatieven die grotendeels dezelfde controles uitvoeren, voor kleine tot middelgrote bedrijven is dit pakket daarom ook niet nodig lijkt me. Maar nogmaals, ik weet niet precies welke checks er allemaal inzitten.
Maar om er nu 3500 dollar (oid) voor neer te leggen... Nee. Er zijn gratis alternatieven die grotendeels dezelfde controles uitvoeren, voor kleine tot middelgrote bedrijven is dit pakket daarom ook niet nodig lijkt me. Maar nogmaals, ik weet niet precies welke checks er allemaal inzitten.
Een punt-komma vergeten is geen bug, zorgt gewoon voor een compileerfout.
Typische zaken waarop zoiets checked is bv. bij dit stukje java code:
Voor bovenstaand voorbeeld geeft eclipse nu ook wel al een warning, maar zal dus wel in die trend liggen.
Typische zaken waarop zoiets checked is bv. bij dit stukje java code:
Hier ga je gewoonweg de variabele vanuit de constructor reassignen aan zichzelf, en de class member 'foo' blijft null, wat later waarschijnlijk een NPE zal veroorzaken. Je moet dus uiteraard "this.foo = foo;" gebruiken.private String foo;
public Bar(String foo) {
foo = foo;
}
Voor bovenstaand voorbeeld geeft eclipse nu ook wel al een warning, maar zal dus wel in die trend liggen.
En waarschijnlijk checks als:
public string firstPart(string foo) {
return foo.substring(0,3);
}
waarbij veilig is:
public string firstPart(string foo) {
if(foo ==null || foo.length < 3) {
throw new ArgException("ERR_MESSAGE");
}
return foo.substring(0,3);
}
public string firstPart(string foo) {
return foo.substring(0,3);
}
waarbij veilig is:
public string firstPart(string foo) {
if(foo ==null || foo.length < 3) {
throw new ArgException("ERR_MESSAGE");
}
return foo.substring(0,3);
}
Het is helemaal niet zo zeker of je een check moet doen of 'foo' null is of niet. Hangt er volkomen vanaf of de data al onderdeel is van een module / laag / component in het programma (en derhalve al gecontroleerd), of dat hij een vorm van invoer is (typisch is gebruikersinvoer via velden, http requests, netwerk verkeer). Als 'foo' al door het programma is gecontroleerd op het moment van invoer zijn alle vervolg checks overbodig en een performance verlies. Daarnaast is het door de eerdere checks bijzonder onwaarschijnlijk dat de code ooit aan de throw new ArgException toekomt (lees: nooit).
Knappe analyse tool die dat voor me snapt. En voor een fout als foo=foo lijkt me dat je die wel vindt zonder tooling. Edit en continue zeg ik dan maar.
Knappe analyse tool die dat voor me snapt. En voor een fout als foo=foo lijkt me dat je die wel vindt zonder tooling. Edit en continue zeg ik dan maar.
Spec# kan dat: die loopt alle mogelijke aanroepen na om te zien of je hem ergens kan aanroepen met een null-pointer (ahum, variabele). De voorganger van Spec# deed dat voor Java.
Nadeel is dat je dan vaak pre- en post-condities toe moet voegen aan je functies, dit soort problemen blijft NP-hard.
Nadeel is dat je dan vaak pre- en post-condities toe moet voegen aan je functies, dit soort problemen blijft NP-hard.
Mee eens, het ligt er inderdaad aan waar je je 'firewall' hebt. Dit kan onder de interface laag zitten.
Maar in het dotnet framework zitten ook al deze checks, omdat zij de programmeur als input zien.
Op het moment dat je met verschillende teams werkt aan verschillende modules heb je andere vormen van input en geldt zekerheid boven performance, tenzij je tot in detail bespreekt wie wat doet.
Maar goed, ik denk idd dat zulke tools dit soort zaken er niet kunnen uithalen in zo'n geval.
Maar in het dotnet framework zitten ook al deze checks, omdat zij de programmeur als input zien.
Op het moment dat je met verschillende teams werkt aan verschillende modules heb je andere vormen van input en geldt zekerheid boven performance, tenzij je tot in detail bespreekt wie wat doet.
Maar goed, ik denk idd dat zulke tools dit soort zaken er niet kunnen uithalen in zo'n geval.
En wat is hier het voordeel van een ArgException ten opzichte van een NullPointerException? De java VM doet die check zelf wel voor je, dat hoef je niet nog eens met de hand te doen.
Eclipse geeft bij dit soort fouten anders gewoon een compile warning af. Maar als voorbeeld is het inderdaad wel aardig: dit soort problemen zal static code analysis ook aan het licht kunnen brengen.
In ieder geval in Java1.5/1.6
In ieder geval in Java1.5/1.6
Klinkt als een soort FxCop, een tool voor .NET software.
(Super handig overigens.)
(Super handig overigens.)
[Reactie gewijzigd door Franckey op woensdag 30 juli 2008 18:26]
Ja ik zat er ook aan te denken hoe ver deze tool gaat. over FxCop ben ik zelf ook erg enthousiast aan het begin dacht ik "wat een onzin" totdat je toch maar eens de honderden warnings gaat wegwerken en nog eens over je code moet gaan nadenken en het dan toch anders/beter implementeert.
Maat FxCop gaat niet verder dan statische code analyse, ik ben wel benieuwd of deze tool verder gaat dan dit.
Maat FxCop gaat niet verder dan statische code analyse, ik ben wel benieuwd of deze tool verder gaat dan dit.
Ik kan me bij C++ nog wel voorstellen dat er bugs kunnen worden gedetecteerd, maar wat moet ik me er bij voorstellen bij Java? De compiler is daar vaak al zo strikt....
Object foo = null;
if (bar())
// doSomething();
foo = new Object();
foo.getClass();
--> null pointer exception
(edit: initialisatie error fix)
if (bar())
// doSomething();
foo = new Object();
foo.getClass();
--> null pointer exception
(edit: initialisatie error fix)
[Reactie gewijzigd door elmuerte op woensdag 30 juli 2008 22:37]
Fatsoenlijke unit tests schrijven spoort dat soort problemen al op.
Zoek maar eens naar "Unit testing". Op het eerste gezicht lijkt het misschien veel werk om overal tests voor te maken, maar dat soort bugs zoals je hierboven noemt vind je dan VOORDAT je je complete programma runt.
Het zorgt er ook voor dat je code veel intensiever getest is:
Zonder unit tests run je je programma, moet je het eerst in een bepaalde staat brengen, en dan je nieuwe functionaliteit uitvoeren. Dit hele traject is veel handmatig werk en dus een drempel voor de developer om ook consistent te doen. Vooral voor oude functionaliteit is dit een probleem. In theorie, bij het implementeren van een nieuwe feature, zou je oude functionaliteit stuk kunnen maken. Dit zou betekenen dat je ook al die handmatige tests weer uit zou moeten voeren voor de oude functionaliteit.
Met unit tests is dit allemaal (op unit niveau in ieder geval) geautomatiseerd, en kan met een druk op de knop ook oude functionaliteit getest worden.
Samen met andere paradigma's (Test Driven Development en Continous Integration bijvoorbeeld) kan op relatief goedkope manier zeer solide code opgeleverd worden.
Zoek maar eens naar "Unit testing". Op het eerste gezicht lijkt het misschien veel werk om overal tests voor te maken, maar dat soort bugs zoals je hierboven noemt vind je dan VOORDAT je je complete programma runt.
Het zorgt er ook voor dat je code veel intensiever getest is:
Zonder unit tests run je je programma, moet je het eerst in een bepaalde staat brengen, en dan je nieuwe functionaliteit uitvoeren. Dit hele traject is veel handmatig werk en dus een drempel voor de developer om ook consistent te doen. Vooral voor oude functionaliteit is dit een probleem. In theorie, bij het implementeren van een nieuwe feature, zou je oude functionaliteit stuk kunnen maken. Dit zou betekenen dat je ook al die handmatige tests weer uit zou moeten voeren voor de oude functionaliteit.
Met unit tests is dit allemaal (op unit niveau in ieder geval) geautomatiseerd, en kan met een druk op de knop ook oude functionaliteit getest worden.
Samen met andere paradigma's (Test Driven Development en Continous Integration bijvoorbeeld) kan op relatief goedkope manier zeer solide code opgeleverd worden.
Unit tests verliezen veel aan kracht wanneer de context groter word.
In bovenstaand voorbeeld is de functie bar 100% foutloos. Maar op het test systeem zal bar altijd true terug geven. Sterker nog, in 99.99% van alle systemen zal het true zijn, maar op 0.01% is het false en gaat het programma stuk. En dan is er nog de compositie van units die fouten op kunnen leveren, iets wat ook niet volledig door unit tests gedekt word.
Statische analyse is niet te vervangen door unit tests (en ook niet vice versa).
In bovenstaand voorbeeld is de functie bar 100% foutloos. Maar op het test systeem zal bar altijd true terug geven. Sterker nog, in 99.99% van alle systemen zal het true zijn, maar op 0.01% is het false en gaat het programma stuk. En dan is er nog de compositie van units die fouten op kunnen leveren, iets wat ook niet volledig door unit tests gedekt word.
Statische analyse is niet te vervangen door unit tests (en ook niet vice versa).
Unit testing gaat maar tot zover. De kwaliteit van unit tests is maar net zo goed als degene die ze maakt. Daar komt bij, als ik dit programma / deze plugin bekijk wordt dit gedetecteert zodra je de fout maakt, ipv tijdens een testfase die al dan niet test voor dit soort kleine foutjes die moeilijk te vinden zijn.
In het voorbeeld dat je schetst is foo mogelijk niet geinitialiseerd. Eclipse 3.4 (3.3 misschien ook) heeft al standaard ingebouwde checks om potentiele NullPointerExceptions te detecteren.
Je voorbeeld is incompleet. 
Indien het hier om een instance variabele gaat, dan heb je gelijk, maar als dit geheel zich in een lokale methode bevindt dan krijg je een keiharde compilatie error, omdat je lokale variabelen moet initialiseren in Java. En if-statements zonder brackets zijn gevaarlijk (omdat alleen het statement direct na de if onder de if valt, de rest niet meer), nog zoiets waar een dergelijke tool voor waarschuwt. 
Indien het hier om een instance variabele gaat, dan heb je gelijk, maar als dit geheel zich in een lokale methode bevindt dan krijg je een keiharde compilatie error, omdat je lokale variabelen moet initialiseren in Java. En if-statements zonder brackets zijn gevaarlijk (omdat alleen het statement direct na de if onder de if valt, de rest niet meer), nog zoiets waar een dergelijke tool voor waarschuwt. [Reactie gewijzigd door NLxAROSA op woensdag 30 juli 2008 19:55]
klinkt mij als 'Parking Assist', 'Lane Assist' en 'Breaking Assist' bij auto's in de oren. Nog even en we doen zelf helemaal niets meer. Nog meer tijd over om de krant te lezen of je make-up te doen in de auto.
Nu weet ik ook wel dat er tegenwoordig steeds meer mogelijk is en dat sommige zaken steeds complexer worden, maar wat is er mis met het zelf schrijven van code en die zelf debuggen etc.?
* BlaTieBla heeft nog in assembly leren programmeren. Dat verklaart zijn 'afkeer' tegen dat soort tooling misschien
Nu weet ik ook wel dat er tegenwoordig steeds meer mogelijk is en dat sommige zaken steeds complexer worden, maar wat is er mis met het zelf schrijven van code en die zelf debuggen etc.?
* BlaTieBla heeft nog in assembly leren programmeren. Dat verklaart zijn 'afkeer' tegen dat soort tooling misschien
*Hier iemand van 17 die Assembly ook wel mooi vind* Het is echt niet zo dat programmeurs van nu staan te popelen voor zo'n dingen IMO. Maar het is wel handig voor kleine klusjes.
Pas als het echt meer dingen kan gaan doen, zoals injections en andere security flaws vinden, dan word het interessant. Maar zelfs dan zal je als programmeur daar niet blind op kunnen vertrouwen.
Pas als het echt meer dingen kan gaan doen, zoals injections en andere security flaws vinden, dan word het interessant. Maar zelfs dan zal je als programmeur daar niet blind op kunnen vertrouwen.
Klopt, en dat zie ik er maar al teveel van de nieuwe lichting doen. (jij zou waarschijnlijk de uitzondering zijn die de regel bevestigd -> 17 jaar een ASM?Maar zelfs dan zal je als programmeur daar niet blind op kunnen vertrouwen.
)Ik hamer het er meestal binnen een jaar wel bij ze uit om niet te vertrouwen op features uit IDE's en al dat soort fratsen. De coder is verantwoordelijk voor de kwaliteit van de code die hij / zij produceert, niet de IDE die gebruikt wordt. (fijn is het natuurlijk wel)
Klinkt als: Lekker zo'n computer met printer. Ik moest vroeger altijd alles met de typmachine doen...
ah computer techniek, ook toevallig in enschede gestuurdeerd?
in assembly iets schrijven is leuk voor een routine in een embedded omgeving omdat "je het beter weet dan de compiler" maar echt een programma er in schrijven is niet echt meer te doen.
Persoonlijk gebruik ik mijn assembly kennis nog wel eens om te debuggen, maar de tooling is wel erg volwassen geworden hoor en dan is het toch ook wel erg heerlijk om te zien wat er op de stack staat en op welke funcitie het is gecrashed.
En dan gaat de stelling "een luie programeur is een goede programeur wel weer op" je moet het jezelf zo makelijk mogelijk maken zodat je met belangrijkere dingen bezig kan houden dan een memory leak oplossen.
zelf heb ik alleen ervaring met statische code analyse en dat is in veel talen zeker iets om aan te raden de kwaliteit en onderhoudbaarheid van de code neemt grote sprongen voorwaards. Al is het alleen maar omdat niemand de code guidelines compleet leest als de precompiler gaat zeuren over errors en je eenbeetje perfectionistisch bent los je ze wel op.
Echter slaan veel tools soms door, als je 100 warnings hebt dan lost je die nog wel op, maar als het er 5000 zijn dan denkje vaak " whatever"
edit:
niet als je een project hebt van meer dan 1 milj regels code en halverwege het project denkt "goh statische code analyse is ook we handig".
Waardoor er veel onzinnige/minder zinnige regels worden uitgesloten in het project.
in assembly iets schrijven is leuk voor een routine in een embedded omgeving omdat "je het beter weet dan de compiler" maar echt een programma er in schrijven is niet echt meer te doen.
Persoonlijk gebruik ik mijn assembly kennis nog wel eens om te debuggen, maar de tooling is wel erg volwassen geworden hoor en dan is het toch ook wel erg heerlijk om te zien wat er op de stack staat en op welke funcitie het is gecrashed.
En dan gaat de stelling "een luie programeur is een goede programeur wel weer op" je moet het jezelf zo makelijk mogelijk maken zodat je met belangrijkere dingen bezig kan houden dan een memory leak oplossen.
zelf heb ik alleen ervaring met statische code analyse en dat is in veel talen zeker iets om aan te raden de kwaliteit en onderhoudbaarheid van de code neemt grote sprongen voorwaards. Al is het alleen maar omdat niemand de code guidelines compleet leest als de precompiler gaat zeuren over errors en je eenbeetje perfectionistisch bent los je ze wel op.
Echter slaan veel tools soms door, als je 100 warnings hebt dan lost je die nog wel op, maar als het er 5000 zijn dan denkje vaak " whatever"
edit:
niet als je een project hebt van meer dan 1 milj regels code en halverwege het project denkt "goh statische code analyse is ook we handig".
Waardoor er veel onzinnige/minder zinnige regels worden uitgesloten in het project.
[Reactie gewijzigd door Madcat op donderdag 31 juli 2008 09:17]
De 'whatever' los je gewoon op met check-in policies (je gebruikt toch wel source control?).
ASM is natuurlijk nog steeds handig, als het om snelheid gaat kun je niet om ASM heen. Een hoop essentiele routines in programma's die een hoop performance kosten zullen daarom nog vaak deels in Assembler geschreven worden.
Met betrekking tot de warnings: Als je eens kijkt naar Visual Studio van Microsoft; die laten die warnings zien terwijl je de code aan het schrijven bent, je hoeft niet te wachten op een build. Het zijn er welliswaar niet zo veel doorgaans, maar volgens mij kun je ook daar weer zelf regels toevoegen. Als je er tijdens het proggen af en toe naar kijkt, zul je dus nooit geconfronteerd worden met meer dan een paar warnings per keer. Het voordeel hiervan is is dat je zelf sneller de link legt tussen wat je hebt gedaan en wat de warninig veroorzaakt, als dat vaak genoeg gebeurd zul je je code automatisch anders gaan schrijven zodat je die warnings niet meer krijgt.
Met betrekking tot de warnings: Als je eens kijkt naar Visual Studio van Microsoft; die laten die warnings zien terwijl je de code aan het schrijven bent, je hoeft niet te wachten op een build. Het zijn er welliswaar niet zo veel doorgaans, maar volgens mij kun je ook daar weer zelf regels toevoegen. Als je er tijdens het proggen af en toe naar kijkt, zul je dus nooit geconfronteerd worden met meer dan een paar warnings per keer. Het voordeel hiervan is is dat je zelf sneller de link legt tussen wat je hebt gedaan en wat de warninig veroorzaakt, als dat vaak genoeg gebeurd zul je je code automatisch anders gaan schrijven zodat je die warnings niet meer krijgt.
Breaking assist kan anders soms ongelukken voorkomen hoor 
En ja, misschien maakt dit sommige programmeurs luier, maar als je er goed mee omgaat kun je meer doen in minder tijd zonder slechter bezig te zijn. Anders kan je net zo goed je auto/computer wegzetten, 'want ik heb nog leren rekenen zonder rekenmachines, vandaar mijn afkeer tegen dit soort 'tooling''. ^^
En ja, misschien maakt dit sommige programmeurs luier, maar als je er goed mee omgaat kun je meer doen in minder tijd zonder slechter bezig te zijn. Anders kan je net zo goed je auto/computer wegzetten, 'want ik heb nog leren rekenen zonder rekenmachines, vandaar mijn afkeer tegen dit soort 'tooling''. ^^
Niets mis met zelf debuggen, maar je baas is erg blij als het sneller en goedkoper kan. Zeker de wat eenvoudigere problemen heb je met dit soort tools veel sneller verholpen. Vervelende van dit soort tools is dat ze alleen de wat eenvoudigere zaken eruit halen en dat je alsnog aangewezen bent op een crack om de lastige dingen te vinden die de tool niet heeft gedetecteerd. Maar zonder was je zowiezo langer bezig geweest.
Zeker de wat eenvoudigere problemen heb je met dit soort tools veel sneller verholpen. Vervelende van dit soort tools is dat ze alleen de wat eenvoudigere zaken eruit halen en dat je alsnog aangewezen bent op een crack om de lastige dingen te vinden die de tool niet heeft gedetecteerd. Maar zonder was je zowiezo langer bezig geweest.Nou .. ik moet de eerste full-code-optimizer nog tegen komen dus ASM is nog steeds niet dood. Maar wel erg lastig bij hele grote projecten waarbij er soms ook maar middelmatige communicatie tussen developers is.
Ik denk dat je bij dit soort tooling moet denken aan een soort sandbox waarin je code een soort van interperter binnen loopt en aan alle kanten gemangeld wordt. Denk aan range-check's & overflow's op data variabelen. Testen of er dankzij typo of logische fout een contante/oneindige lus zou kunnen ontstaan etc. Het incorrect declareren en/of herdeclaren van variabelen waardoor andere codesegmenten dit misschien niet 100% threadsafe zijn vreselijk de mist in gaan waar ze hun data in overgooien Objecten dubbel aanmaken onder andere namen
Een hoop dingen die je veelal tegen komt tijdens debuggen van code die met meerdere mensen geschreven wordt. Daarom moet je het ook zeker niet zien voor de 'kleine' programmeur.
Begrijp me niet verkeerd... 'i just love 'bare-metal' coding' maar als ik mijn 'very tight loops' bekijk nadat de compiler eroverheen is geweest 
Wat nagenoeg alle compilers doen is de code parsen en optimising-compilers zullen loops waarin 'dure' microcode gebruikt wordt, proberen te herschrijven.
dus ASM is nog steeds niet dood. Maar wel erg lastig bij hele grote projecten waarbij er soms ook maar middelmatige communicatie tussen developers is.Ik denk dat je bij dit soort tooling moet denken aan een soort sandbox waarin je code een soort van interperter binnen loopt en aan alle kanten gemangeld wordt. Denk aan range-check's & overflow's op data variabelen. Testen of er dankzij typo of logische fout een contante/oneindige lus zou kunnen ontstaan etc. Het incorrect declareren en/of herdeclaren van variabelen waardoor andere codesegmenten dit misschien niet 100% threadsafe zijn vreselijk de mist in gaan waar ze hun data in overgooien
Objecten dubbel aanmaken onder andere namen Een hoop dingen die je veelal tegen komt tijdens debuggen van code die met meerdere mensen geschreven wordt. Daarom moet je het ook zeker niet zien voor de 'kleine' programmeur.
Begrijp me niet verkeerd... 'i just love 'bare-metal' coding'
maar als ik mijn 'very tight loops' bekijk nadat de compiler eroverheen is geweest Wat nagenoeg alle compilers doen is de code parsen en optimising-compilers zullen loops waarin 'dure' microcode gebruikt wordt, proberen te herschrijven.
Het boek Java Puzzlers laat zien dat ook in Java code een hele hoop bugs kunnen zitten. 9 puzzeltjes vind je in een sample chapter: http://www.javapuzzlers.com/java-puzzlers-sampler.pdf
"De spellingscontrole is voltooid."
Als je dat zou zien...
Een best handige functie dat je ook zelf je 'regels' in kan voeren. Zelf ben ik niet bekend met programmeertalen, dus weet ik ook niet of dit al bestaat.
Als je dat zou zien...
Een best handige functie dat je ook zelf je 'regels' in kan voeren. Zelf ben ik niet bekend met programmeertalen, dus weet ik ook niet of dit al bestaat.
hmmmz... spelling en grammatica dan ...
Zou je 3500$US per gebruiker uitgeven als je graag wil dat iedereen zijn eigen shortcuts toe voegt en het dus weer unsafe maakt.
Je kan namelijk zelf regels aangeven waaraan de code moet voldoen en zo dus ook dingen vrijgeven.
[ontopic]In de informatica, waarmee de structuur en de volgorde van programmaregels gedefinieerd worden, zie syntaxis (informatica), waarmee de structuur en de volgorde van programmaregels gedefinieerd worden, zie syntaxis (informatica)wiki: syntax/syntaxis
Zou je 3500$US per gebruiker uitgeven als je graag wil dat iedereen zijn eigen shortcuts toe voegt en het dus weer unsafe maakt.
Je kan namelijk zelf regels aangeven waaraan de code moet voldoen en zo dus ook dingen vrijgeven.
[Reactie gewijzigd door Atmosphere op woensdag 30 juli 2008 22:27]
Syntax checking kan heel makelijk, en is bijna overbodig met code-hinting (behalve als het juist door code-hinting in het 100 lopt, maar dat heb je dan snel door, en ram je een paar keer geiriteerd op ctrl-z)
Logics is bijna ondoenbaar om te checken. Mischien de hele simpile structuren. Als ze echt AI kunnen inbouwen, dan wordt het tijd dat men ook eens echte slimme robots gaat ontwerpen. Dan word het pas gaaf.
Juist 2 uur zit fokken op een (niet zo simpele) recursive functie. Hoewel de functie trouwens wel al meteen goed werkte, kreeg ik niet de gegevens in de gewenste vorm, waardeloos dus.
Als ik nu gewoon had kunnen zeggen aan de computer: Doe dit voeg samen doe dat output zo dan denk ik dat veel programeurs overbodig gaan worden... (oftopic)
Logics is bijna ondoenbaar om te checken. Mischien de hele simpile structuren. Als ze echt AI kunnen inbouwen, dan wordt het tijd dat men ook eens echte slimme robots gaat ontwerpen. Dan word het pas gaaf.
Juist 2 uur zit fokken op een (niet zo simpele) recursive functie. Hoewel de functie trouwens wel al meteen goed werkte, kreeg ik niet de gegevens in de gewenste vorm, waardeloos dus.
Als ik nu gewoon had kunnen zeggen aan de computer: Doe dit voeg samen doe dat output zo dan denk ik dat veel programeurs overbodig gaan worden... (oftopic)
Dit gaat niet over syntax checking, maar om bugs die syntactisch niet fout zijn, maar run-time voor erg veel problemen kunnen zorgen. b.v.
function foo(char d)
{
char c;
unsigned char u;
int i;
c=300; // fout 1 !!!
if ( d > 200) { // fout 2
}
u=d; // gevaarlijk, maar niet perse fout
if (u < 0) { // overbodige check
}
}
function foo(char d)
{
char c;
unsigned char u;
int i;
c=300; // fout 1 !!!
if ( d > 200) { // fout 2
}
u=d; // gevaarlijk, maar niet perse fout
if (u < 0) { // overbodige check
}
}
Tja, het lijkt wel fout, maar het is allemaal code die een voorspelbaar gevolg heeft,
en in sommige gevallen best kan werken.
Zo heb ik vrij recent ongeveer deze code geschreven:
wchar_t c = input[i]; // Uit std::wstring
if (c >= 0x10000) {
output += '?';
} else ...
Is dit een bug ? wchar_t is soms maar 16 bits. Een statische analyse zou dus kunnen klagen. Mijn code is alleen slimmer; die werkt voor 16 en voor 32 bits wchar_t.
en in sommige gevallen best kan werken.
Zo heb ik vrij recent ongeveer deze code geschreven:
wchar_t c = input[i]; // Uit std::wstring
if (c >= 0x10000) {
output += '?';
} else ...
Is dit een bug ? wchar_t is soms maar 16 bits. Een statische analyse zou dus kunnen klagen. Mijn code is alleen slimmer; die werkt voor 16 en voor 32 bits wchar_t.
Als je in .NET ontwikkelt kan ik je ReSharper aanraden.
Ook een super tool om sneller te ontwikkelen
Ook een super tool om sneller te ontwikkelen
Ik houd het toch maar bij Developer Studio. Ook erg duur maar niet zo duur als je bekijkt dat de controle gewoon standaard is.
[Reactie gewijzigd door E_E_F op donderdag 31 juli 2008 10:01]
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Android Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
