Oh Christ, I'm doomed....

From the top of Linux's implementation of vsprintf:

/* vsprintf.c -- Lars Wirzenius & Linus Torvalds. */
/*
* Wirzenius wrote this portably, Torvalds fucked it up
*/

 

He won't last long . Although a lot of developers do seem to think
like that. Test driven development is incredibly hard to do, but it
really pays.

 

Quite so. We had a battle not so many years back to persuade some
senior statisticians to accept the need for independent QA[1] for all
programs. One in particular happily accepted it for most of their
junior people, but was adamant that his own code shouldn't be subject
to it. He actually asked me to build an exception into the QA system
something like "if programmer=god then no QA required', and was most
annoyed when I told him no, he'd have to let other people look at his
code too.

In some types of development, yes. In others, like producing stats
analysis reports, it can lead to a great deal of additional work for
little if any benefit, so post-hoc testing is much more appropriate.

[1] Which is not the same as testing, of course, although many of the
people involved refused to accept the difference as well.

 

#include <stdio.h>

main()
{
for(;
{
printf ("Hello\n");
}
}

Pah - programmers... always the same thing.

 

Fail - brackets in wrong place.

 

Now that's what I call a useful compiler error message. Makes a change
from useful hints like “Error 113: Error in Statementâ€.


--
+-------------------------------------------------------------------+
| Pete Fisher at Home: |
| Voxan Roadster Yamaha WR250Z/Supermoto "Old Gimmer's Hillclimber" |
| Gilera GFR * 2 Moto Morini 2C/375 Morini 350 "Forgotten Error" |
+-------------------------------------------------------------------+

 

Which tools do you use? We can take it to email if you don't want to
reveal secrets to the world at large. I'm specifically looking for
something in this area.

 

Oh it's no secret. This is all Java related...

Currently I'm using a Hudson build server running Ant scripts that pull
from CVS, build and then execute Checkstyle, PMD, Cobertura (which
measures the coverage of JUnit and Concordion automated tests), plus
Fortify to check for security weaknesses. Googling should find you info
on all those tools. All we've done is tweak a few of the rulesets to
cater for house style and a couple of other things.

I do need to port all that lot to run on IBM Rational Team Concert build
server at some point to tie in with RTC source control and distributed
Agile planning tools.

 

Did you compare Cobertura with Clover before making a decision? I quite
like the latter for its coverage analysis and integration with Hudson.

 

1. I didn't get it. 2. He's away doing placement visits, I'm sure
he'll pick up on whatever geeky code thing it is when he gets back.

<ruffles hair> Poor little chap, is no one playing with you?

 

No, I didn't. Hudson and Cobertura were the client's choice in this
instance. We would have gone direct with RTC (as we're an IBM business
partner). It seems to be ok, gives some nice graphs for the business
peeps and more crucially, allows us to fail builds if test coverage is
below a certain percentage (we go with 70%). Seems to play nice with
Hudson as well.

 

Tsk, clients eh!

Super. I've not seen if Clover does that yet. So little time.

 

it isn't a code thing. Much worse - maths geekyness.

what hair?

 

It's not that hard as long as you accept it has to be done and you
keep doing it. It is a lot easier than looking t a pile of wrong
results (and all your results will be wrong) and trying to work out
whether the error is an error in your analysis or in your coding, or
normal numerical error.

 

I love the way that he no longer even tries to explain maths stuff.
It's all squiggles that look like fractions (only with letters and
brackets) to me.

Hey, I was trying to be nice. It doesn't happen often, make the most
of it.

 

Some of our dev team looked at me like I was daft[1] when I told them
to stop writing pages of long and frankly incoherent specs (unless
there was a specific reason to do so) and create a short self testing
spec that could fit on a postcard instead. Worked wonders for their
first time pass rate though. Not to mention the fact they spend more
time coding and less writing bullshit specs that no-one would ever read.


[1] yes yes.

 

I do insist that my guys write a short high level design for review
before they start coding, more as a way to avoid them coding themselves
down rabbit holes and coming over a week later and saying "er, I just
need to do a bit of refactoring", ie, they need to rewrite the whole
fucking lot. Also means we can just check they're sticking to the
architectural decisions again before they churn out loads of stuff.
Seems to work well enough with the Agile thing.