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”? [poll id="7"]


  1. Hi Eddy, you will find a lot of uniface code outside in production where you find lots of "goto end" to have a common final processing before the proc is left. So let me rephrase your poll to "do you, the uniface coder and his management, have superflouus time and money to rewrite vital parts of your existing codebase without any gain?" In the software industry, you will see "deprecated infos" only to tell the developer there is an enriched way now to do the same job. But the old way is rarely deleted. Because it is only one more line in their parser definiton or a simple delegation; they will never force their customers to modify the existing code from "go_to" to "goto" argumenting the later one is more stylish. Please read some books about the creation of APIs and the fate to keep "old promises": Finally: the "structured programming" you refer to has died out with the years: too many nested control structures only for structogram sake; it has not got the the "proof of time". You will not find too many structograms either in nowadays documentations, there are better concepts now. Having deeply nested IFs instead (and each new option will cause another nest level) makes the code completely unreadable, at lest with the currently available support we enjoy from the uniface editor. Have a look at some books on PASCAL with examples which are more than a simple "Hello World" and you will see what I mean. Todays coding paradigms are far away from these, just to mention the "GoF", design patterns and functional programming, DSL and MDD.
  2. I copied the above to the forum so it becomes tracked on the what's new page of uniface.info
  3. I have to say I didn't even know goto existed in Uniface. I generally program in a 'structured' manner even in languages I am forced to use GOTO in, and wouldn't miss it if it went. I tend to deal with code confusion by using local procs to subroutine stuff out, thus my controlling code is clearer, and with well named procs, some semblance of object oriented methodology is retained.
  4. Hi Iain, please think about all the existing hundreds of manyears worth of code from the early 90s which uses goto. Why do you want to take away what other uniface supported license holders use in their code? We have seen a lot on broken compatibilities on documented functionality in the past making new versions a nightmare; "artifical deprecating" can be seen as another way to draw money for professional services ("one day or two of professional service to cure what CPWR has damaged firsthand"). Other 4GL provider supply a script or tool to solve these situations as part of their standard support FOC.
  5. A postscript to this article: I had not intended this blog to be related to earlier blogs on refactoring etc. The question posed stands alone. A lot of people saw the use of the deprecated statement warnings when they migrated to Uniface 9, for statements like file_load and so on, and so people had to think about whether the warning was useful or annoying, or just not worth thinking about. It doesn’t follow that you must act when a statement is deemed deprecated. The discussion was orientated towards what people do in new development today. The references to Structured Programming were nostalgic, as I indicated. It might have interested younger developers that what appears to be common sense good practise programming today, has some roots in academic study in he past.
  6. HI Eddy, Thank you for your additional statements on your intent. immediately after these "deprecated" warnings came up, there was a wishlist entry for an option to disable this kind of warnings. A lot of customers still have QA rules which say "no warnings at all" so a simple "ignore it" will not work so easily. Warnings after a compile is associated with "code smell" and is an indicator something is not right. This rule is much easier to follow than the: have in mind the last compile flaged 15 warnings; if the actual on does not show the same number of warnings, something is wrong and needs to be checked. And all the new warnings you have to verify after a simple new patch/servicepack is installed costs a lot of time as well. There are a couple of static code analyzers in the market (especially but not limited to java) which scan the code and match it against a lot of design rules the customer can set up as they think good code should look like. Wouldn't it be better to give uniface an adapter to plug-in this functionality? And leave it to the customers which standard they want to follow? BTW: why customers have to go through all their code replacing file_load with fileload, item with $item ? Other software providers just append the new names to their compiler to keep their old promises.
  7. let's be more detailed on 'plug-in': you can set a component-name as a post-compile-hook which gets some arguments. Imagine a component which expects among others the filename of the proc listing as argument. One customer may want to run a GREP against this file to check for "banned words" like GOTO, another on fileloads the proc listing and use the uniface $SCAN for checks, another may use even AI for QA. There will be other meaningful hooks where customers can link in their additional processing. Expl. pre-change (to check check-out status of the object), pre-compile, post-precompile (where you may run your static code-analysis and stop even the creation of "wrong" artifacts), pre-writeartifact, ... I mentioned this demand in a presentation for the german usergroup back in 2008.