Bill Sux

They didn't call it "code" by accident.

John

Yup. I do that, too. But I don't think that, on the whole, it takes time. The act of commenting is a sort of check in itself, and makes the code better, and reduces debug time. I hate debugging, so I code so that I have to do very little of it.

John

A very wise man and former manager (and one of the early developers of MVS) had a profound "word" he kept on the top of his black/white board: "Xenocryptophobia" - fear of other's code. I don't like reading my own code after a week, so I comment the crap out of it. Every module has a long "purpose" statement, and every line tries to tell others (and myself) wht the hell it's doing. Yes, it takes time to do, but it takes a lot more time to figure out what the hell happened whent it does (and it will).

One line a day? Good grief. I heard the statistic of 10/day once, from IBM maybe, and it astounded me. I average about 300-400, and I know guys, real programmers, who are faster and rarely make a mistake.

John

It's not that hard, if you use decent variable names and a well designed set of macros. Macros make ASM come together.

No, if I were doing a WinBlows Gui, I wouldnt use ASM. ...but given that I'm an engineer working on the metal, I'm not about to use a language that only masks screw-ups ('C', in case you couldn't decode the above).

It takes time. Whether that time is otherwise spent elsewhere is another issue. I'm told that our programmer productivity on OS types of things in on the order of one line per day. No, it' snot because there is only

I hate debugging too. While I make numerous mistakes, most are trivial to find. The just stand out, because there are no branches into la-la-land. Functions return (or post) status, so it's easy to track back to the failure. Most are , that was certainly dumb!

Comments should come first, coding later. I often use the routine headers as the design document. Of course if they don't keep up they're worse than useless.

Pithy? ;-)

IMO, it's almost always better to do things in the most obvious way. When any tricks are played it takes mroe time to explain the tricks than any time gained. ...though I have seen comments like "DON'T TOUCH THIS OR YOU'LL BE SORRY" in other's code. THe generally mean it too. ;-)

selection.

Having spent last 3 months back engineering the C code in a product range. I prefer to think of it as "F$%#*^& *£#%e".

regards john

I certainly comment a fair bit but I prefer to see my code as largely 'self-documenting'.

Try doing that in asm !

Graham

I'm actually no fan of C either. It appears to me to be almost deliberately obscure in its syntax for one thing.

I recall a colleague who had a C 'test' that he used during interviews. It was something obscure and could be misinterpreted. That was the idea behind it being used as a test of course. My attitude was that I'd rather not use a language that had such obvious drawbacks.

Btw - I once ended up coding a microcontroller type application ( it used a Z80 actually ) in Pascal of all things ! The software tools came from an Australian company IIRC. The name Avocet rings a bell.

Nice language actually. Conceptually as different from C as you could imagine.

Graham

Better still, actually analyse the problem first !

I once worked on this project where the entire system was analysed as a purely theoretical state machine.

Once the states were defined, coding it was simply a case of typing in a list of conditions.

I had to write the I/O of course.

It worked rather better than the asm ! that the original 'consultants' had provided to the client.

To this day I tend to use 'state machine-like' methods.

Oh.... the service guys loved it too since we also provided them with a manual that showed all the conditions and how you got there.

Graham

will).

Comments can occasionally also be a bit of a millstone. In a fit of enthusiasm I wrote a small routine in PIC assembler last Wednesday evening. It converts a 9 byte integer inductance value into a rounded 7 digit ascii display string (c/w engineering units). The code 'appears' to use 5 moving place markers and a look up table. Also has lots of pithy comments (or so I hoped). Come to make a small addition this morning and find I haven't a f****** clue as to what I was up to. :-). Maybe sometimes it also pays to do things the longer but more obvious way.

regards john

IIRC, one line per day was an IBM statistic for MVS development programmer productivity, but that included the architects, designers, and support people. That wasn't a "coder" productivity number. By the time the "coders" got ahold of the specification the lines came out rather fast, since all the decisions had been made.

I don't remember the numbers for the Shuttle OBS project, but it's in that range too. One of the lead guys used to post such information on the intranet years back but I can't remember the specifics. Maybe I can search the archives.

I know a guy who would crank out over 500 lines of working PL/I a day, but it wasn't "production" code. I've touched that in assembler, I think, but that wasn't working, tested code. Testing takes far longer than writing. I couldn't keep up that productivity without my brain turning into something resembling Bemelman, either.

I don't know how to measure "lines" in VHDL, but I cant get anywhere near that even on a good day, unless one counts the entities, component specifications, and port maps. ;-)

:-)

of

I'll bet it worked too.

I discovered this myself years ago. Almost all my code is either case/when (VHDL) or jump tables (Asm) and work quite well. It's easy to tell my code form others in the group. To be fair, the others are quite used to structural VHDL and think in components and connections.

That works.

Coding is kind of boring, I'd hate to see comments indicating what all I was thinking about when I wrote the code. ;-) I'd sooner be pithed.

Design is a lot more intensive-- you have to look at things from various angles and often go down a few dank blind alleys before you emerge into the sun-drenched piazza (after which everything seems obvious, so that's the time to write it all down in gruesome detail).

Best regards, Spehro Pefhany

In article , john jardine wrote: [...]

That's your problem. You have to comment the pith out of it. You need to not so much comment what it does but what you are thinking at the time you are writing it. I've often put ASCII art schematics of circuits into comments to show what I was thinking about when I wrote the code.

lots

Agreed. It's the overview thinking that is essential to be recorded. After much effort figured what the PIC routine is actually doing. With hindsight, best described as a must-never-be-repeated-gruesome-obscenity. Written when in one of those master of the universe moods, it does the job quickly with few instructions but as there is no 'logical flow' it would take a full 2 (non pithy :) pages to clearly comment all the gory ifs and buts. Not ever going -there- again, so scrapped it and starting afresh with a figurable (but boring) approach. regards john

I was applying for a job once, and there was a test: "write a program that prints out the prime numbers from 1 to 1000." I wasted about an hour with divisions and crap - essentially, I panicked, and didn't get the program written, or the job.

Then, a couple of days later, at the bus stop, on the back of a piece of scrap paper, I came up with this:

/* sieve.c */ /* /* a sieve of Eratosthenes. I start with only odd numbers, duh: /* 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 /* 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 /* then, of course, wipe out everything that's not prime

int m[BUFSIZE]; int n;

int main(int argc, char **argv) { int i, j, k; for (i = 0, j = 1; i < BUFSIZE; i++, j+= 2) m[i] = j; /* fill up the array */ for (i = 1; i < MAXFACTOR; i++) if (j = m[i]) for (k = j + i; k < BUFSIZE; k += j) { m[k] = 0; } for (i = 0; i < BUFSIZE; i++) { if (k = m[i]) { printf("%d ", k); n++; } } printf("\\nN = %d\\n", n); } /*END*/

I've strung the loops across the page, so I can say, "I've written a Sieve of Eratosthenes in THREE LINES!" ;-) (or _one_, if you consider that one is to fill the array and one is to just print them.)

Cheers! Rich

Google for the obsfuscated C contest. I don't know if they still do it.