OpenEuphoria

RE: fixed windows

• Posted by Peter Willems <peter at integratedmoves.com> Aug 06, 2003
• 384 views

kbochert at copper.net wrote:

<snipped a bit>

> Many of these are a page long (even when written with macros!) and
> contain additional structures.
> When, inside a for, inside a switch, inside a  while, on page 36, I see
>
>     if ( x != 0 )
>         goto type_error;

> I know immediately the programmers intentions.
> It is as clear, concise and meaningful as 'get_cnt();'
> would be.
> The structured equvalent:
>
>     if ( x != 0 ) {
>         type_error = TRUE;
>         break;
>         }

   How about this:

   if ( x != 0 )
       type_error()
       break

   As for readability it is the same as your first example.
   The only difference is that the program will return to this
   code so your break is processed here instead of where you
   jumped to with the goto. And *that* is exavctly what I like:
   I know from my version instantly that after executing the 
   type_error handler (or whatever) I will still return to this
   specific place in the program's logic. That goes a long way
   for maintainability. In your example with goto I'm forced to
   check out the code that is actually handling the type_error
   to see where it will lead me, while my concern was with the code
   where type_error was called. Again, this also reflects largely
   on how the program is modularized.

> If I need to know what happens on type_error, it is
> located in a single place.

   Same with my example.

> Replace 50 'goto type_error's; and 'goto range_error;'s'
> with the equivalent flags and structured code is a mess.

   ... and not needed, even without a goto.

> A compiler back end is very complex. It can be structured
> to put the complexity in in-line code, or in macros, or in
> objects, or in structures, but it remains hard to grasp.

   I'm doing a lot of (commercial) work on dynamically loaded
   parsers. Such a parser does not implement a certain language,
   but instead it can parse any language or structured file based
   on a language description. This is even more complex then to have
   the parser understand a fixed instruction set. So I do know a 
   little bit about this matter 

> I will admit that since adding goto to Bach, I have found not a
> single case where I have wanted to use it. (But then I haven't
> written a complex program with Bach, either)

   Just today I found that WinDev actually also has goto... after
   working with that language in commercial development for several
   years it shows how many times I have been wishing for goto...
   ... zero times 
 
> I have far too often seen complex code which is so well
> clarified with sometimes incorrect comments, that only a few
> lines of code remained on each page. This was just barely
> acceptable when the code was correct, intolerable if it had
> bugs. (Its also very! hard to erase a comment )

   I agree that sometimes people can get carried away with
   commenting code. Documenting code with comments is as much
   a skill as writing clean code.

> In-line comments can be invaluable, but they can also be a trap.
> In-line comments that recapitulate the code are an abuse.

   So what do you think about inline comments that contain special
   tags to load a document generator ?
   In this case the inline documentation becomes the sole place
   for documentation maintenance. I actually like that.
 
> goto's can be easily abused, but in my experience, 
> incorrect comments and mis-indenting are far more serious
> problems.

   As you say, *incorrect* comments are indeed.... incorrect.
   But that is a bit stating the obvious.
 
> I think that Dijkstra has scared programmers enough that
> they use goto verrry carefully.

   I'm curious how many people here on the list ever heard of him 

Hans Peter Willems