Comments for erik dörnenburg

Comment on How toxic is your code? by Metrics based Refactoring for cleaner code

Metrics based Refactoring for cleaner code — Mon, 02 Jan 2012 19:53:00 +0000

[...] Toxicity charts have proved very useful in quantifying the amount of technical debt in a code-base. The magnitude of the debt is quantified by comparing a value against an arbitrary threshold. The toxicity is expressed as a score against the threshold. [...]

Comment on How toxic is your code? by Srivatsa Katta

Srivatsa Katta — Sun, 01 Jan 2012 05:23:16 +0000

Excellent post, we wanted to calculate toxicity on every checkin and monitor how we are improving the legacy code base. The excel sheet import needed some manual effort, so I wrote a small java utility which runs based on the checkstyle report and generates the toxicity (for all the important checks mentioned in this post).

Yes the report generated is just numbers doesn’t have fancy visual representation of toxicity using graphs and all, but serves the purpose of hooking it up to the continuous integration tool.

More details : https://github.com/katta/toxicity

Thanks Erik again for this post which helped me understand how toxicity is calculated.

Comment on How toxic is your code? by How Toxic is your Code? | OnTechnicalDebt | The Premiere Technical Debt Online Community

Thu, 15 Dec 2011 22:25:06 +0000

[...] Erik Bornenburg has an excellent post on his blog about how you can visualize your code and understand which part of it is part, compared to the rest of the code. This can be extremely useful in helping managers and non-developers understand the internal quality of the code. This post shows us how Toxicity Charts can help you see the technical debt that has been built up in your software: http://erik.doernenburg.com/2008/11/how-toxic-is-your-code/ [...]

Comment on How toxic is your code? by My Testing and Code Analysis Toolbox | The Agile Radar

My Testing and Code Analysis Toolbox | The Agile Radar — Mon, 12 Dec 2011 09:13:12 +0000

[...] CheckStyle: A static code analysis that finds lots of bad practices and can check lots of coding conventions too. Integrates in IDEs and CI server. There are other tools in this area which are worth considering: FindBugs and PMD. You can also use Checkstyle in order to gather simple metrics about your code. [...]

Comment on How toxic is your code? by Schauderhaft » My Testing and Code Analysis Toolbox

Schauderhaft » My Testing and Code Analysis Toolbox — Sun, 11 Dec 2011 06:42:02 +0000

Comment on Testing Cocoa Controllers with OCMock by Using OCMock with Mac OS X Lion, Xcode 4, to Mock and Unit Test Cocoa Desktop Apps « Procbits

Tue, 29 Nov 2011 17:07:30 +0000

[...] Testing Cocoa Controllers with OCMock [...]

Comment on How toxic is your code? by What am I thinking about? Visualising your technical debt « On The Job Alliance

Mon, 21 Nov 2011 11:23:10 +0000

[...] find out more about these visualisation methods check out Erik’s blog article and his excellent presentation of Software Quality – you know it when you see [...]

Comment on Builder pattern in Objective-C by Jay Fields

Jay Fields — Tue, 01 Nov 2011 12:54:09 +0000

Just a note on the builder pattern in general – returning self can lead to some weirdness if you ever create a builder and use it in two different places. To avoid confusion, all of our Java builders always create a new instance of the builder with each call to any “with” method.

Comment on Builder pattern in Objective-C by Oliver Jones

Oliver Jones — Tue, 01 Nov 2011 09:58:42 +0000

Hi,

Just a wee point on Objective-C naming conventions/style.

Don’t do this:

Car *c = [[Car alloc] initWithMake:make andModel:model];

do this:

Car *c = [[Car alloc] initWithMake:make model:model];

Similarly don’t do this:

Car *hotHatch = [builder carWithMake:@"VW" withModel:@"Golf GTI" withOwner:@"Bob"];

Do this:

Car *hotHatch = [builder carWithMake:@"VW" model:@"Golf GTI" owner:@"Bob"];

For more information on idiomatic Objective-C naming conventions read these:

* Apple Coding Guidelines: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingMethods.html
* Matt Gallagher on Objective-C Method Names: http://cocoawithlove.com/2009/06/method-names-in-objective-c.html

Comment on How toxic is your code? by Erik Doernenburg

Erik Doernenburg — Fri, 28 Oct 2011 15:44:14 +0000

Danny, what “stack size” are you referring to? That article doesn’t mention it.