Recording the Screen?

My life as a contract coder taught me that. Above all make sure the idiot thick permies who have to maintain it are told in words of one syllable why it does what it does. Avoid advanced constructions that may not be understood, or, if there is no alternative write a PARAGRAPH of comments to explain .

And break all the conventions and rules if it makes the code clearer. I wrote some telex communications software once, as a multitask under DOS 2.

the structure turned out to be nested subroutines down to the 'receive a byte' level. Involving lots of other set up routines like dial, check acks from the far end etc etc. At any stage something could go fatally wrong.

Structured programming insists that you pass errors up through the nested routines to the main loop and then put the error handler there.

Bollocks to that. For the first and only time in my life I used setjmp() and longjmp() to simply crash out of the subroutines and pass an error code to the error handler, and put all the error handling in one place.

That way the program flow was all about just the process of successfully receiving a telex. All the error handling was in one place set up by the setjmp(). If the language had had a global goto, I'd have used that.

Solid simple workmanlike code.

No one writes that any more.

I think the key is not incrementing a variable in two different places in the loop...

Nothing wrong with having a while(1) with stuff incrementing inside it, and an explicit break clause, if that makes it *easier to understand*.

That is modern best practice - except that it's now called exception handling with all the grubby bits hiding under throw and catch.

Depends what language you're writing in and what the program is expected to do with errors: if, like Java, the language has the ability to throw and catch errors, then you have maximum flexibility without any need to distort the program structure just to pretty-print the error log. Its easy to do any of the following:

- report invalid data etc and continue by building an error log thats output and cleared when this suits the user - just as you'd do in languages without an exception handler such as C, COBOL, PL/1, assembler or whatever...

- use the try{ ... }catch exception handling mechanism to deal with non-fatal errors in code which merely reports errors and continues

- or putting a try...catch exception handler outside the main loop so that any exception thats not caught and handled as a non-fatal will abandon the run and report reasons etc. without having to distort the program's logic or structure or going to the trouble of building circular trace buffers, etc just to produce a readable error report.

Teach users about how not to code things susceptible to buffer overruns.

OBS

Yes, any array subscript or any value that is added to a pointer should be range-checked, and any loop which auto-increments a pointer should have an emergency exit if it iterates too many times, to prevent the "do ... while (condition which is never met)" situation. Standard defensive programming.

And we *all* do that, children, don't we, every time we write a program? ;-) No, me neither!

They probably were once - and then there were numerous change requests, many of which required that the code be re-ordered. That was what cured me of numeric statement labels. (In my case it was assembly language, and almost an unwritten shop standard - but the principle is the same.)

Arrgh. I managed better than that even with our primitive assembler which only supported 4-character labels.

I found myself working on an assembly language program which went one better. Not only was the destination address of a conditional branch instruction modified, even the condition code test was altered; it could be a branch if equal, branch if not equal, or branch unconditionally.

Cute. One of my favourites (assembly language again) followed a subroutine call with what looked like an ordinary instruction, but which was interpreted by the subroutine as a set of parameters (e.g. address and length). The subroutine would increment the return address to jump over this instruction.

"My code is so readable that it doesn't need comments!" Grrr...

(Language zealots substitute "language" for "code" in the above statement.)

In any event, it should be well commented. If I'm in a situation where I'm forced to do nasty things, I'm not above confessing in the comments that the code is ugly, while trying to explain just what it's up to.

Guilty as charged. I just can't resist saving a line...

Function pointers are my stumbling block.

Hear, hear!

I once heard some wise words: "You're not writing those comments for yourself; you're writing them the next person to work on the program. And that person might be you, six months from now."

One factorial? :-)

Even that won't save you if your program contains a line like

if(*s == '}')

In those cases I'll insert a comment line containing a '{' ahead of this line so the "%" command doesn't get confused.

And rehearse it, dammit, rehearse it! I've watched too many YouTube videos where someone is obviously fumbling through something for the first time. Run through it until you can do it smoothly - with a clear, coherent narrative - and don't record it until you've got it right. And then, if you stumble, do another take. Have the pride to polish your result.

If you don't have the time to do it right, save yourself the effort and don't do it at all. I have neither the time nor the inclination to decipher a half-baked effort.

I recently discovered the joys of getline() - I'm starting to phase in the concept in my own string functions.

-- /~\ Charlie Gibbs | They don't understand Microsoft \ / | has stolen their car and parked X I'm really at ac.dekanfrus | a taxi in their driveway. / \ if you read it the right way. | -- Mayayana

Yes, it's great.

If I don't know something I need to know and somebody takes the time to explain it all for me, then I'm grateful and don't insist on my free lilies being gilded as well.

Of course I hate all those Youtube instructions and would take a written manual every time -- but when I can't have one any more, then I take whatever crumbs I can find. I paid several thousand for a new car and all the manual I get is from some volunteer or other doing it for free on YT -- the maker can't be arsed.

The only thing in C that ever gave me real trouble was near and far pointers in 80286 days - only Intel could manage to create a processor that distorted C. So go on try and write the declaration for a near pointer to an array of far pointers to functions returning far pointers to arrays of near pointers to characters. If you can do this have mercy on the code reviewers and maintainers and find a better approach to the problem.

One comment I would make about Youtube videos that use screen shots: if you use the mouse arrow pointer to direct the viewer's attention to part of the screen or a particular line of code, make it bigger than normal and maybe solid black rather than black outline on white. Or at the very least, get into the habit of waggling the pointer in a circle when you first move it to the part of the screen which you are referring to - anything to get their eyes there *quickly* so they don't miss anything you are saying while they play "hunt the cursor" and "whereabouts on the screen is he talking about". Maybe even say "top left of the screen" as you move the pointer to what you're talking about. And try not to scroll the text up and down on the screen - one big movement (maybe even with a jump-cut) is better than lots of little indecisive in-vision "random" scrolls.

What seems very obvious when *you* are in control of the mouse and the scrolling can become very hard on the eyes when someone else is in control.

And plan what you are going to say to avoid lots of ums and errs and "hang on, I've got that wrong, what I mean is...".

But that's the ideal. As you say, a badly-presented tutorial is better than none at all ;-)

Ouch. It was bad enough having to write a function to normalize far pointers so that the offset wouldn't wrap around in the middle of an array. To hell with the 640K limit - it was the 64K limit that I found more bothersome.

relatively simple to avoid.

Not when I already know the size of the object being fitted into memory

Back in the day when I was programming with 16K of RAM, I cared, but today char[1000000]; doesn't even dent the stack

In general if your object exceeds that, something else has already gone badly wrong...

And there is always malloc, and free...

Oh, no - the manual is not the same.

Its seeing how he gets the screwdriver to all the screws and exactly what levering off the case back or te car door card involves...