Re: C++ fluency
On May 5, 11:44 pm, "Phlip" <phlip2...@gmail.com> wrote:
Andy Champ wrote:
When I submitted through batch systems I used to spend hours
and hours hand-checking the code before for typos before it
went in. And I'd spend hours and hours writing extremely
detailed tests of each and every function, and making sure
I'd hit all the paths.
Writing the tests before compiling (or even writing) the code
has become in fashion again, at least in certain circles. Nice
to know that what I was doing 30 years ago is the latest
technology today.
The issue is actually complex. When interactive terminals, with
screens, started becoming standard equipment, we went through a
phase in which the programmer just sat down in front of the
screen, banged out his code without any thought, and then edited
it until it compiled, and called that a development process.
And a lot of "tools" have been developed to support
this---IDE's, for example. Clearly, this doesn't work either.
These days, I get it about right, feed it to the compiler
(which will pick up some of my silly errors), then step
through it making sure it does all it should do with a much
more basic test harness. Perhaps I'll realise that some
part isn't tested, and add some more tests; perhaps I'll
even throw some away. Now that a meg of RAM and a gigacycle
of CPU cost so little I can ignore them, why not make use of
them?
I TDD, and run the tests after every couple of edits. Much
less thinking is involved, and that's a Good Thing.
Less thinking is a good thing? I'm not sure I agree.
And of course, tests may prove that code doesn't work, but they
can't prove that it does work. There are just too many aspects
which can't be reasonably tested. Not to mention that you
still have the problem of determining whether the tests are
right, and complete.
And I spend just a little effort to type-safely _defeat_ C++
typechecking. Sometimes it feels like typechecking is
negative reinforcement - denying what your code should not do
- whereas TDD is positive reinforcement - rewarding your code
for doing the right thing...
It's a point of view. Having code compile without errors first
try is a very satisfying positive reinforcement for me. As is
having code which works correctly on first link is as well. The
way I've usually seen TDD used is to not write any code except
in reaction to a failing test---and a failing test is a negative
input.
Test software: Tests to check for problems you've already
fixed.
Including the problem of the non-existence of each line of
code...
You don't need a test to know that something that isn't there
won't work.
In general, there are many different levels of tests. In the
well run places I've worked (far from all of them), any errors
found in integration or acceptance tests resulted in an analysis
of the process---they should never occur. On the other hand,
you couldn't check code in that didn't pass the unit tests,
which basically left it entirely up to the developer how he
organized his own work (writing the code and the tests, etc.): I
generally expected my unit tests to run first time (and don't
use a debugger), but others preferred a more interactive
procedure, debugging errors found in the unit tests. On the
whole, however, those who used such techniques tended to take
more time to produce poorer code.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34