Tag Archives: Deprecated

Should GoTo Become a Deprecated Statement?

 

I recently read an article that referred to “Structured Programming”.  That struck a nostalgic chord with me as that programming method was being taught, and strongly encouraged, by my first I.T. employer, when I was a COBOL programmer.  Three historical papers by some computing heroes of their day preface the following discussion:

The first paper from 1966 introduced the notion that you can write programs (or express an algorithm) using only 3 control structures, which are:  (1) sequentially executing subprograms, (2) selection of one subprogram over another based on a Boolean value, and (3) the iteration of a subprogram while a Boolean value remains true.  That’s the basis of Structured programming.

The second paper from 1968 drew on the experiences of structured and unstructured programming and concluded that the go to statement is evil (my interpretation).  The third paper from 1974 tried to find a middle ground, i.e. do stick to structured programming, but if go to statements solve a problem that the language cannot address with existing statements, or are used at the correct level of abstraction, they aren’t so evil.  I haven’t read all 3 papers completely, and have used other writers’ summaries and interpretations, but only where I saw consistency in those writings.

Well, Uniface is a mature language, and so it comes as no surprise that there is a GoTo  proc statement in its vocabulary.  For completeness, I’ll add that the library reference gives a polite suggestion that while and repeat statements are better for structured programming.  The GoTo statement references a label; not the type that is displayed along with fields, but at least the GoTo target is not a statement line number as some languages used.  If you turn on compiler information messages, you might also discover unused labels and obsolete proc statements (that are never executed by virtue of being bypassed by GoTo).

Over the years you will have seen new proc statements introduced that assist with meeting the requirements for subprogram definition, sequential processing, selection and iteration.  In the past, the absence of statements like selectcase, for, forentity, callfieldtrigger and so on, legitimised some use of the GoTo statement.  It is possible to write good structured code today with GoTo statements, though it is easier to write “spaghetti code”.  Thus the question now becomes: is there any need to use GoTo at all these days?  If the answer is NO, then should the GoTo statement become a deprecated statement for the reason of “Obsolete feature”?

Should GoTo Become a Deprecated Statement?

View Results

Loading ... Loading ...

Why you should clean up Dead Code

I regularly help out our smaller customers with tasks that might be a thorn in their side, and which would drag them away from their normal business priorities.  These tasks often involve that I have a cursory look at their Uniface repository, and a gain a general knowledge of their application architecture.

Whilst performing some of these tasks, I often see all kinds of objects that are dead wood in the application.  There are the warning signs … objects that start with TEST, objects with developer’s first names embedded, last updated in 1998, obsolete objects (UVCS model), and so on.  It is so tempting to delete these objects, but I act professionally, and wouldn’t load that kind of regression testing burden onto customers, unless instructed to.

So does anything happen to this dead wood?  I do hope that the developers spend just a little time cleaning up their repositories, but inevitably this requires more than a little time, and developers are handed higher priorities.  This I understand; our work has to be able to demonstrate added value to our masters.  If the work does not obviously show savings or improved performance in some way; if there is nothing that visibly changes, why invest in the work?

This is the answer to that question: because you are building up “technical debt”, and it might be cheaper to fix it sooner than later.  For a wider explanation, have a look at Ton Blankers’ white paper on “CONTAINING AND MANAGING TECHNICAL DEBT WITH UNIFACE”.  Your masters may argue that they’ll never need to repay that technical debt, but there is a lot of current discussion on modernizing applications, and cleaning up your code, and understanding your assets, are important process steps in modernization.

I do know how dead code gets created, and there is a respectable amount of time that it can remain in the repository … “just in case”.  Rather than put a use-by date on dead code, it might be better to schedule a little time when you can review your code, maybe straight after a major maintenance release you could get rid of last year’s dead code (as distinct from the latest dead code), or in those quiet weeks of the summer holidays.  It also makes sense to do it whilst the original author can remember the code, or particularly whilst the author is still employed by your masters.  It can only cost more to do it later.  Besides, if a business case is drawn up for modernization, it would be great to start doing some new development ASAP, rather than spend a lot of time rediscovering the ancient history of your application.

I mentioned some of the obvious ways to spot dead code earlier on.  There are tools for a more deterministic approach to code coverage analysis.  You can turn on proc tracing and run it for a while.  This should be avoided in production, but with a good suite of regression tests, it should be possible to capture the traces in a test environment.  Don’t forget to add a line like this to the assignment file:  $PROC_TRACING_ADDITION=”%%$componentname  >>>>”.   There could be more done to automate the examination of these trace files, but it shouldn’t be too hard to match trace files against a list of components.  There will always be some manual investigation to be done, and the Uniface Cross Reference tools will be helpful here.

So, don’t shy away from pruning that dead code out of your application, even if it’s a branch at a time.  If you have some ideas or tool strategies for finding dead code, please share them with us.