jdow@earthlink.net wrote:
From: "John Summerfied" debian@herakles.homelinux.org
Mike McCarty wrote:
John Summerfied wrote:
Mike McCarty wrote:
I'd be ashamed if my C code were so incomprehensible and poorly documented.
We obviously have different ideas about what good programming really means. To almost quote Hoare: There are two ways to write programs. One can make them so simple that there obviously are no defects, or one can make them so complicated that there are no obvious defects. The former is much more difficult.
and nobody does the latter.
If you don't understand the language, you're not qualified to judge the quality or qualities of the code.
Negative. Undocumented code is "a bad thing." Sadly, we all seem to commit to much of it. We presume the next poor sod who gets to play with the code will understand the subtleties of the language and see what we're doing instantly. We discover, when we are the next poor sod some years down the line that we've forgotten that language after picking up 7 others.
Regular expressions are a feature that could use more documentation than they usually get.
{o.o}
Ever since serving said sentence, I have been of the opinion that all newly minted programmers should first serve time in the purgatory known as "software maintenance programming." Only after getting an appreciation for how hard it is to divine someone else's obscure code should they be unleashed on the world and allowed to create their own inscrutable incantations.
That being said, I probably do most of my current development in perl which has been described as a "write only" language. I prefer to call it the Swiss Army Knife of programming languages.
Cheers, Dave
On Sun, 2006-01-01 at 00:56, David G. Miller (aka DaveAtFraud) wrote:
Regular expressions are a feature that could use more documentation than they usually get.
{o.o}
Ever since serving said sentence, I have been of the opinion that all newly minted programmers should first serve time in the purgatory known as "software maintenance programming." Only after getting an appreciation for how hard it is to divine someone else's obscure code should they be unleashed on the world and allowed to create their own inscrutable incantations.
Very good point. The thing that needs to be documented is what the routine is expected to do and perhaps any quirky side effects, not the step by step operations which are obvious from the code itself. The maintainer needs to know what the code is supposed to be doing, not so much what it actually does or how it does it because the reason he's in there in the first place is to fix it. And the really messy parts (and very common) are where someone else already changed the logic but left some old misleading comments.
That being said, I probably do most of my current development in perl which has been described as a "write only" language. I prefer to call it the Swiss Army Knife of programming languages.
The great thing about perl is that nearly everything you might need is already done as a module on CPAN, so your own code ends up being just a control loop calling existing, already documented functions.
David G. Miller (aka DaveAtFraud) wrote:
Ever since serving said sentence, I have been of the opinion that all newly minted programmers should first serve time in the purgatory known as "software maintenance programming." Only after getting an appreciation for how hard it is to divine someone else's obscure code should they be unleashed on the world and allowed to create their own inscrutable incantations.
Agreed. Hewlett-Packard used to have a policy that, for 1 month a year, all sowftware development engineers had to work answering field problems doing phone-in support.
That being said, I probably do most of my current development in perl which has been described as a "write only" language. I prefer to call
Nah, that's APL. The first high-level programming language I learned.
it the Swiss Army Knife of programming languages.
Mike
-
David G. Miller (aka DaveAtFraud) -
Les Mikesell -
Mike McCarty