When does that self documentation come out. I have been waiting for 20 years for a copy. :-)
Also add programmers that use long variable names. I had one joker who came from the A, B, C world of variables and was so infatuated with Multi-value that he started using variable names such as QUANTITYONHANDFORTHESTORE or LASTDATEITEMWASCHANGED. The re-writing is a good idea. I have done that on some code written by one of my former assistant programmers. But it can be cost prohibitive for clients that we are brought into after the fact and have 50k lines of code for an order entry screen that is fairly complex. It is hard to explain to them why it will cost them a few thousand dollars to re-write the code before I can add one little change to a screen. I speak from experience as I had a client like that. I had to pass on doing any changes for him. Simon Verona 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 > > --------------------------------- > Simon Verona > Director > Dealer Management Services Ltd > > Sent from my iPhone > > On 4 Mar 2009, at 17:27, concern shoko <[email protected] > <mailto:[email protected]>> wrote: > >> At times the best way to debug is to write your own program. Honestly >> the average time we spend perusing the endless uncommented lines is >> more than the time we need to write the whole program from scratch.... >> >> Food for thought.... >> >> On Wed, Mar 4, 2009 at 4:12 PM, Richard Kann <[email protected] >> <mailto:[email protected]>> wrote: >> >> The old I learned basic programming in school. Who needs those >> new fangled large variable names or comments. Try this for size: >> >> >> L=5 >> GOSUB 9000 >> A5=VAR >> L=30 >> GOSUB 9000 >> A7=VAR >> . >> . >> . <some 300 lines later> >> 9000 INPUT VAR >> IF LEN(VAR)>L THEN GO 9000 >> RETURN >> >> This was a 15000 line program, the variables were all defined way >> up at the top (at least 1/2 were, the new fields were left out). >> There were actually 8 or 9 different subroutine areas for common >> inputs, prints, etc. I got whiplash trying to read the code. >> >> >> Richard Kann >> >> >> Simon Verona wrote: >>> >>> I think that good programming techniques don’t change.. nice, >>> clear, concise code (with comments) is massively easier to >>> develop, debug and has less bugs inserted with ongoing >>> maintenance and updates... >>> >>> >>> >>> My nightmare is code like (I was looking at code similar to this >>> earlier in the week)... >>> >>> >>> >>> IF X=2&Y=1&Z=3 THEN >>> >>> A=A+1 >>> >>> J<X,Y>=R<Z> >>> >>> GO 100 >>> >>> END ELSE >>> >>> GO 200 >>> >>> END >>> >>> >>> >>> This is just a snippet of the kind of code I was debugging – >>> about 1000 lines of code in the same vein, without a single >>> comment! >>> >>> >>> >>> Such fun! >>> >>> >>> >>> Simon >>> >>> >>> >>> <mime-attachment.jpg> >>> >>> >>> >>> *From:* [email protected] <mailto:[email protected]> >>> [mailto:[email protected]] *On Behalf Of *Richard Kann >>> *Sent:* 03 March 2009 23:49 >>> *To:* [email protected] <mailto:[email protected]> >>> *Subject:* Re: Jbase programming query >>> >>> >>> >>> I've seen worse though I agree on the return to's. The other >>> issue is goto statements that jump all over the world rather >>> then using if then's or other more smooth routines. Maybe it's >>> my age, but back in the old days it caused massive frame >>> faulting making the disc run constant. These days I guess it is >>> not as important though still a pain to debug. >>> >>> Simon Verona wrote: >>> >>> I think it's a case of "you're fired " if you use return to !!! >>> >>> I can only agree having had to historically debut code with lots of >>> return to's in! >>> >>> Simon >>> >>> --------------------------------- >>> Simon Verona >>> Director >>> Dealer Management Services Ltd >>> >>> Sent from my iPhone >>> >>> On 3 Mar 2009, at 17:38, Richard Kann < >>> <mailto:[email protected]>[email protected] <mailto:[email protected]>> >>> wrote: >>> >>> >>> >>> You said: >>> >>> Never, ever, ever, ever, ever, ever, ever, ever,ever, ever, ever, >>> >>> ever,ever,ever, use RETURN TO. That's ever, ever, ever, ever, ever, >>> >>> ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, >>> >>> ever, >>> >>> ever, ever, ever, ever, ever, ever, ever, ever ad infinitum. >>> >>> But how do you REALLY feel about it Jim? >>> >>> >>> >>> Richard Kann >>> >>> Comp-Ware Systems, Inc. >>> >>> >>> >>> Jim Idle wrote: >>> >>> >>> >>> Dhaya wrote: >>> >>> >>> >>> >>> >>> Hi >>> >>> >>> >>> I am using jbase 4.1 release with T24. I have a query >>> regarding >>> >>> the >>> >>> usage of 'recursive return" statement >>> >>> in Jbase programming language. I understood we can >>> recursive >>> >>> return >>> >>> to come out of subroutine to calling program. I have a >>> requirement >>> >>> where when the recursive return is executed, program >>> control should >>> >>> not come out >>> >>> the subroutine used. It is that is there any way to code >>> such as >>> >>> >>> >>> PROGRAM.ABORT: >>> >>> >>> >>> RETURN TO (PROGRAM.ABORT - 1) >>> >>> >>> >>> Because, i want this recursivee return to be executed 1 >>> level down. >>> >>> Can i use (PROGRAM.ABORT - 1) in jbasic >>> >>> or Is there any alternate way to use. >>> >>> >>> >>> >>> >>> >>> >>> Never, ever, ever, ever, ever, ever, ever, ever,ever, ever, >>> ever, >>> >>> ever,ever,ever, use RETURN TO. That's ever, ever, ever, ever, >>> ever, >>> >>> ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, >>> ever, >>> >>> ever, >>> >>> ever, ever, ever, ever, ever, ever, ever, ever ad infinitum. >>> >>> >>> >>> For a start you will never debug it. Wanting to do this is a >>> sign >>> >>> that >>> >>> your design is very wrong. >>> >>> >>> >>> jBC is a compiled language, therefore the line numbers have no >>> >>> meaning >>> >>> except in the debugger. There are some compiled languages that >>> >>> annotate >>> >>> lines but they are compiling broken languages. >>> >>> >>> >>> The reason that you are wanting to do this is either that you >>> have >>> >>> used >>> >>> GOTO elsewhere in this program, or that you have called nested >>> >>> subroutines, discovered an error and now want to back out of >>> all the >>> >>> GOSUBs until you can return from the subroutine. Either way, >>> it >>> >>> means >>> >>> that you need to redesign your subroutine. Each GOSUB should >>> check an >>> >>> error return and back out accordingly. This type of thing is >>> why more >>> >>> modern languages have exceptions that can cascade back up the >>> chain >>> >>> and >>> >>> be caught at an appropriate point. However jBC does not have >>> this >>> >>> functionality so you must program accordingly. >>> >>> >>> >>> Now, personally, I think that the language should have had >>> separate >>> >>> notation for subroutine vs gosub return, but it doesn't, so you >>> are >>> >>> stuck with it. Review your design here - when you have to ask >>> how >>> >>> to do >>> >>> something like this, it means the program is broken. >>> >>> >>> >>> Jim >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> -- >> C. Shoko >> Temenos GLOBUS Developer >> |Nedbank Africa|South Africa| >> >> >> > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
