Tag Archives: Refactoring

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”?

[poll id=”7″]

Is Refactoring Code Worth It?

This blog is an extension to my earlier blog on Removing Dead Code.  One of the benefits of removing dead code is to make future code maintenance easier, and therefore cheaper.  Recently I read a blog which reminded me of the proper definition of refactoring, and I realized that refactoring is a logical next step after removing dead code.  One problem is knowing what it costs to do it.

Let’s start with the original definition of refactoring, as defined by Martin Fowler and Kent Beck:

A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior… It is a disciplined way to clean up code that minimizes the chances of introducing bugs.

So the users will visually see no benefit from this kind of work.  Without a specific project mandate to improve the code, what developer will risk breaking a working module just to make it easier to understand?

I think that refactoring will mostly get used when it’s piggybacked on to other tasks, which could be from one of these categories:

  • Performance improvements, e.g. that batch job that’s taking too long to run.
  • Business rule changes that require modifications to a module that is known to be complex or difficult to understand.  Your resource estimates need to include both refactoring effort and business changes.
  • An existing module needs to be cloned for business reasons and some abstraction of that module will make future development, as well as maintenance, easier.
  • Learning new Uniface features.  You may be interested in some new functionality in a release of Uniface that you have recently upgraded to.  A genuine refactoring exercise is both a great learning tool, as well as a prototype for the new feature.
  • For new projects, the architecture design phase is a good time to try and improve your Application Model as well as your templates.  This is where you will probably get the highest payback from refactoring.

Choosing the scope of code for refactoring shouldn’t be too difficult.  Operations, included proc modules, validation triggers, or whole components are all candidates, based on their modularity.  This just means that they have a well-defined interface, use case, or unit test script.  Just be sure to complete the refactoring completely, before starting on any business rule related changes.  You should view refactoring and other changes as separate but serially executed tasks.  This will make the refactoring effort less error prone, and more measurable.

So do look out for opportunities to refactor modules of code.  You know that it will be faster than refactoring is in other languages.  Uniface’s high productivity will help during refactoring as much as much as it did during the original development.