Oh Christ, I'm doomed....

Hehe. You're not wrong.

 

I have had someone not be able to tell me why they were incrementing
the variable.

 

Ah, right you are. I misread your post, we are talking at cross purposes
again. I was actually going to suggest TDD as a possible solution to MJC.

 

That is now a euphemism. If I do it, does it get bigger?

 

oh, I can believe it.

What's ludicrous is when they can't tell you why they're trying to
increment a constant.

 

imagine that.

 

To make it bigger, DUR!

--
Catman MIB#14 SKoGA#6 TEAR#4 BOTAFOF#38 Apostle#21 COSOC#3
Tyger, Tyger Burning Bright (Remove rust to reply)
116 Giulietta 3.0l Sprint 1.7 GTV TS GT 3.2 V6
Triumph Sprint ST 1050: It's blue, see.
www.cuore-sportivo.co.uk

 

"more", FFS.

 

******

--
Catman MIB#14 SKoGA#6 TEAR#4 BOTAFOF#38 Apostle#21 COSOC#3
Tyger, Tyger Burning Bright (Remove rust to reply)
116 Giulietta 3.0l Sprint 1.7 GTV TS GT 3.2 V6
Triumph Sprint ST 1050: It's blue, see.
www.cuore-sportivo.co.uk

 

I knew a guy that used to write (really bad) 8085 assembler. Every
single line had a comment, that was just the mnemonic, expanded.

MVI A, 3 ;Move 3 into the accumulator

etc.

 

When I code review the standard is every public method must have a
comment that describes what the method does, how it does it, and how it
is to be used. I don't care about comments within the method, if the
code doesn't have that, and an equivalent class level comment, it gets
rejected. As far as the code within methods and class design, I have a
bunch of automated tools that run on build servers that check for best
practise, anti-patterns, house style, security weakness, etc. Not
infallible, but take a load off the manual code reviews.

Doesn't make a lot of friends with new developers on my teams, but they
soon get beaten into shape and without fail they've all said ultimately
it's made them better developers <proud>.

 

My guys have to produce very high level software designs for me before
they can start. I don't expect detailed UML models and the like, but a
rough overview of stuff to find the rabbit holes first.

Test driven development. You must write a unit test before you write
the code. Test is based on the acceptance criteria for the code, code
is then written to pass the test.

 

For me that test is `does it produce the right list of numbers' (which
will often be generated by another piece of code).

 

bah.

 

Perfectly reasonable test. Exercises the other piece of code,

 

I once had a fair row with a student who believed that testing by
trying to break the code was psychologically wrong. God save me from
self-esteem.

 

In the source I looked at :

blah ... blah ;now starts the clever bit ...

Paul.

 

Nice.
I liked this

// Dear maintainer:
//
// Once you are done trying to 'optimize' this routine,
// and have realized what a terrible mistake that was,
// please increment the following counter as a warning
// to the next guy:
//
// total_hours_wasted_here = 32

from this

http://stackoverflow.com/questions/...ment-in-source-code-you-have-ever-encountered

Paul.

 

Using the patented Mavis Beacon "Hunt&Peck" Technique, zymurgy

Hah! Like it. I quite recently added:

* This doesn't work for transaction dates before
* Thursday, 14 September 1752.

to a piece of date-handling code. (Us COBOL guys are a tad sensitive
about date limitations...).

I also had a section of code marked:

* Danger, Will Robinson! This doesn't work if one of the
* replaced characters appears in a replacement string.

but I decided that was sloppy, and fixed the restriction instead.

 

Mine just made the border cycle colours and produce a high pitched whine by
outing to the border/sound port. Once I'd done that I added a conditional
that detected when the caps shift key was pressed so it'd return to BASIC.
(otherwise you had to reset the machine)
Apart from a little bit of computer game pokery (found and disabled the
colour card anti-piracy thing from jetset willy), that's as far as my
machinecoding went (I used the op-codes in the back of the manual method
too)
--
| |What to do if you find yourself stuck in a crack|
| |in the ground beneath a giant boulder, which you|
| |can't move, with no hope of rescue. |
| Andrew Halliwell BSc |Consider how lucky you are that life has been |
| in |good to you so far... |
| Computer Science | -The BOOK, Hitch-hiker's guide to the galaxy.|