> > And there's *lots* of research equating bug rates with lines of code
> > *regardless* of programming language (from assembler for so-called 4GLs).
>
> I'm quite certain I've read or seen references to several other more
> recent and directly applicable in recent years but I've never had need
> to record details of them. Sorry I can't be of more help now. Perhaps
> others can.
Bugs are generally taken to be proportional to the number of "function points"
in a piece of code, unfortunately the metrics people can't agree what makes up a
function point.
Within a single system written in a single language by a single team, bugs will
therefore equate to lines of code (and it's an easy metric) but across
languages, systems, projects and teams the comparisons are meaningless.
Tom DeMarco talks long and hard about these sorts of metrics ... "Why Does
Software Cost So Much..." is a good book to start with as at this point he
starts realising that metrics are in fact harmful and misleading if overdone
(it's often good to start reading "the gurus" a few years down the line when
they're big enough to admit their own failings !).
As for "obfuscation" etc. - the real problem in code being hard to read is the
number of abstract thoughts the author is manipulating at once. A good friend of
mine that I deeply respect as a programmer unfortunately can hold too many
abstract thoughts in his head at once, and writes his code with that assumption
(eg lots of different obejcst / structures in flux at one time). His code is
superb and rarely wrong, but very hard to maintain as any one part takes you a
long time to read into, to the point where you're happy with 10 or 20 objects
(non-OO use here) he is manipulating. He writes primarily in Lisp, C and C++,
and has written world beating systems, but his code is hard to read because of
its complexity, not because it's badly written, obscure, uses side effects etc.
Compare this to say the writings of Marcel Proust or Julius Caesar, beautiful
text that says so much in so little once you're learnt to hold 5 abstract
sub-clauses open in a single sentance that lasts a page and a half. (James Joyce
on the other hand is just plain obfuscated !!).
Perl to a large degree can encourage this degree of "lots of abstract thoughts
on the go", a line like
@a = sort { $a->[0]->{value}->($a->[1]) <=> $b->[0]->{value}->($b->[1]) }
$fred{abc};
is very powerful and very concise, but assumes that you know that %fred is a
hash of lists of etc. etc...... and the purpose of each member in the data
structure.
Similarly it's very powerful to be able to build these things up on the fly, but
in a language like C++ (or if you're using Class:Struct or similar) you, the
reader, can go and look at the definition of what an object is.
You don't have to write this way, but once you're deep in a problem and you're
juggling all those abstractions, they're all at your fingertips (tm), you're in
"the flow", then the single line that does exactly what you want is as clear as
a bell, and in Perl you often have the ability to express that single conceptual
action in a single logical line (eg a Schwartzian Transform). But to a reader
entering the scene later, not understanding what concepts are dealt with by the
code, never mind the relationships between them all, the code is "obscure".
The Waste Land by TS Eliot is one of my favourite poems, but it's been sinking
into my brain for 20 years, I've had the concepts it juggles explained, the
imagery drawn-out, and the "tribal memories" (some would say "pardigms") it uses
elaborated. I'd love to write code like that, but not everyone has got 20 years
to spend reading and admiring my code before changing it.
Poetry, Prose or Perl - you pick your own compromise between spelling it out
every step in full or evoking just the right line to fit the purpose.
Tim
_________________________________________________________________________
The information contained in this message is intended for the addressee
only and may contain confidential and/or privileged information.
If you are not the addressee, please delete this message and notify the
sender; you should not copy or distribute this message or disclose its
contents to anyone.
Any views or opinions expressed in this message are those of the author
and do not necessarily represent those of WestLB or any of its affiliates.
No reliance may be placed on this message without written confirmation
from an authorised representative of its contents.
