[EMAIL PROTECTED] wrote: > We also use "xnn.meaningful.name" type labels. One advantage is that our > editor can recognise a label and putting the cursor on a line that > includes a GOSUB and pressing one function key will move the cursor > directly to the correct paragraph. > > One thing I've never agreed with (except in COBOL) is "every internal > subroutine should only have on exit point" - why? > Because it makes "flow of control" so much easier ... but mostly where I've seen it, it DOES make an exception for error handling. Maybe rephrase it - "every internal subroutine should only exit from one point if it completes successfully".
My two favourite rules were "if a single logic-block won't fit on one screen, it's too big", and "if a single section of code won't fit on one page of printout, it's too big". One of my colleagues tends to work to the mantra "if it's only used once, it should be in-lined". Leads to huge programs where you enter at the top, fall out at the bottom, and get hopelessly lost in the detail. As the OO guy said, "three lines is too big" (I think that's an exageration :-) but DON'T start using trees to hide the wood! The ONLY time I would agree with inlining stuff like that is if your program doesn't have flow-control (ie, there are no loops (or backwards gotos in FORTRAN :-). So I tend to program with each section controlling a layer and calling subroutines (CALL or GOSUB, doesn't matter, usually GOSUB) to handle the tasks in the layer below. Which may themselves actually do something, or be a control layer. Actually, to sum up both my rules above, "if there's a backward jump (LOOP, GOTO, FOR NEXT, whatever), and you can't see *both* the *start* *and* *end* at the same time on your preferred medium for making changes (screen for a small block of code, printout for the entire function, for me), then it's too big. (That's why it's *one* *page* of printout - I don't consider sheets of printout strewn over my desk as a preferred way of editing something! :-) Cheers, Wol ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
