Re: C++ fluency
On May 6, 3:15 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
Phlip wrote:
I TDD, and run the tests after every couple of edits. Much
less thinking is involved, and that's a Good Thing.
That's a good way to waste a lot of time, for very little
gain. Those tests don't tell you anything useful.
It depends on how much work you call an "edit". I'm not sure
what the unit of measure here is. I certainly run all of my
tests before releasing the code. If I'm bug fixing, that might
mean five minutes work (for tests that may easily run ten
minutes or more). If I'm developing new code, it will typically
be a lot, lot more---usually a day or two, sometimes even a
week, and very rarely, more. It's still one "edit", at least as
far as the source code control system is involved. (But to be
frank, I don't know what Philip means by an "edit".)
[...]
TDD tests exist as replacements for traditional specs.
That, of course, is ridiculous, and I don't think anyone would
be silly enough to claim it. It may exist as a replacement for
some very low level specs (and even then, I have my doubts), but
most places I've worked, the traditional specs have not been
written by programmers, or even people who know very much about
computers. Of course, such specs generally have to be "fleshed
out"---users rarely consider up front how the system should
respond to various error conditions, for example. There are
exceptions, and I've had, as a significant part of the "spec",
RFCs and ISO standards, spelling out in rigorous detail how to
respond to every possible error condition. But a significant
part of the specs is always from external sources.
The name itself is "design", not specification, and while I have
doubts about its effectiveness as a design tool as well, and
very serious doubts about its effectiveness when used as the
only design tool, that's a different issue. The people
recommending it seem to vary as well. For some, it is a silver
bullet: all we have to do is adopt TDD, and all of our programs
will be error free, perfectly maintainable, and delivered on
time and in budget. For others, it is simply a sneak linguistic
trick to get unit tests established where they are: management
accepts the necessity of design, but not of testing, so calling
tests design is the only way of getting them accepted.
(Hopefully, such extremes are rare. Realistically, however, it
wouldn't surprise me if they represented most of the TDD
proponents.)
[...]
And I spend just a little effort to type-safely _defeat_ C++
typechecking.
That's a very bad idea. If you can't even convince the
compiler that what you're doing is OK, then you really ought
to question it. C++ is pretty lenient, unless you take steps
to make it otherwise.
C++ is far too lenient, unless you take steps to make it
otherwise.
[...]
I realize you've come from Ruby, and it is clear from many of
your posts that your perceptions have been a little skewed by
some heavily marketed "agile methodologies" and "dynamic
languages."
I don't know about Philip, but buzz-words are a problem, and can
tend to serve to avoid the real issues. All successful
methodologies are "agile", and have been ever since I've been
programming. Today, of course, it's become a buzz-word, usually
meaning: "the way I do it, and not the way you do it". Even if,
in practice, your methods are just as agile as mine (using the
standard accepted meaning of the word in English). Ditto
"dynamic". (When applied to languages, I think it does have a
more or less commonly accepted technical meaning, but we all
know that a process has to be "dynamic". Even if we don't
always agree on how to achieve that dynamism.)
You'll probably end up a first-line manager who can't stop
talking about "industry best practices."
I like scripting languages as much as the next code-monkey,
but the stuff you're so gung-ho about shows a real lack of
experience on large projects, or frankly, projects with
cutting-edge requirements of any kind. You're describing a
design style that is OK for some small projects with very
limited scope, but grossly inappropriate most of the time.
The sooner you admit to yourself that you mostly don't know
what you're talking about, the sooner you'll be able to learn.
Forgive my being so harsh in a public forum, but I assure you,
I have your best interests at heart.
Now Jeff. And you're the one who criticizes me for sometimes
being too "direct".:-)
--
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