Of course, GOTO can be used in a logical and non-problematic way.. The problem is to define when this is.. I prefer to simply try to avoid the use of GOTO - there are rarely situations where it's needed!
As for comments... it's one of those things, over-commenting *can* be as bad as not commenting at all, but I would prefer to have detailed comments than none at all.... Personally, I try to put a comment block at the top of each program which describes the use of the routine, how it is called and what it exits with (most of my programs are written as subroutines). A one-line comment precedes most subroutines within a program (though the subroutine name is also descriptive - and certainly not numeric!!!). The odd comment may also be thrown in if explanation is needed on anything else.... The underlying problem with multi-value programmers, is that they are often "business" people who learnt to program, rather than programmers who apply themselves to business.... This is what makes a lot of Multi-value applications very good - because they are written directly by people who understand the industry they are programming for... However, for the same reason, these same people often lack good programming techniques and application of standards. Simon -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mike Preece Sent: 04 March 2009 20:43 To: jBASE Subject: Re: Jbase programming query On Mar 4, 6:10 pm, Simon Verona <[email protected]> wrote: > Agreed about the long term benefits of rewriting! > > Also whilst we're at it - fire any programmer that uses goto, return > to, undescriptive variable names or seems incapable of writing > comments. Though I did work with a programmer who claimed comments > were unnecessary because the code was"self-documenting"!! Strangely > enough he also was a big "goto" user.... > > Simon > Perhaps controversially, I believe that comments are often a result of somewhat shabby work. We ought to think twice. Look at the code you've written and see if there are changes you could make to it that would make it self explanatory. That little bit of extra effort is, in my opinion, better than taking the easy way out by throwing in a comment or two. One argument in favour of this approach is that comments can end up misleading or extraneous after a code change. It'd be easy for a programmer to get in and fix or change something, get the code working as it should, and overlook that the comment should also have been changed. And - to add some extra heat to this discussion - GO can sometimes (although very rarely) have its place. I've seen code that has a flag set where a GO could have been employed, with multiple subsequent tests on that flag scattered through the code. In this particular example, use of a GO would have removed the need for the flag and simplified the code. OK - the alternative would be to rewrite the code, but that can be (and usually is) nowhere near cost-effective. Mike. --~--~---------~--~----~------------~-------~--~----~ Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24 To post, send email to [email protected] To unsubscribe, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jBASE?hl=en -~----------~----~----~----~------~----~------~--~---
Simon Verona.vcf
Description: Binary data
