[Oberon] a module a page (keeps the mind sane)?

John R. Strohm strohm at airmail.net
Sun Nov 4 08:52:25 CET 2018


Jörg said:
> I don‘t know whether NW or another person once really said „one page, one 
> module“.
> I personally don‘t follow that guideline; I’m rather follower of Chris‘ 
> guideline „one page, one procedure“.
> It‘s anyhow difficult as the word „page“ is vaguely defined and heavily 
> depends on the screen size, resolution and font used😀
>
> Whenever a procedure doesn‘t fit on one „page“ I try to split it. But I‘m 
> not absolutely consequent on this guideline either. There are cases where 
> a procedure is longer than a page. Cases that come to my mind where I 
> break my own guideline:
> A) long CASE statement. But I try to at least fit one CASE on one page
> B) HW drivers, where speed is king and I don‘t want jumps an inner loop

I've been in this crazy racket, as student and then professional, since 
about 1970.

In all of that time, close to half a century now, with the specific 
exception of CASE statements implementing finite state machines parsing 
things (source code files, event trace sequences), I've seen exactly one 
procedure [*] that NEEDED to be more than one printed page (about 60 lines) 
long.  I've seen a LOT of run-on stream-of-consciousness procedures that 
were a lot longer than 60 lines, and ALL of them could have been made a lot 
simpler with some judicious refactoring.  (One in particular was a HUGE 
cut-and-paste mess, that I reduced DRAMATICALLY by undoing the cut-and-paste 
and making about half a dozen short procedures for the common fragments.)

Elizabeth Rather and I agreed that FORTH was powerful and good, but we 
disagreed on why.  She was convinced it was the interactive nature.  I 
remain convinced that it is because it is NOT POSSIBLE in the typical FORTH 
system to write a procedure longer than 16 lines x 64 characters.  (Yes, the 
language is extremely concise, compared to common languages, but the point 
remains the same.  FORTH *FORCES* modularization.)  I also observe that I 
saw long run-on stream-of-consciousness modules written by people using a 
FORTH that allowed longer things.

[*] The module in question was actually a FORTRAN IV subroutine, from the 
CDC 6600 STARTRK game.  It was the photon torpedo handler.  It had to set up 
a loop, to handle firing either one or three torpedoes, around a loop that 
simulated the torpedo flightpath, around setting up a stack to simulate 
recursion and do 8-way connectivity, to detect nova chain reactions. 
FORTRAN IV didn't support recursion, so the programmer had to fake it.  I 
suspect that it would have been a bit simpler in a language that supported 
recursion.

--John R. Strohm


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



More information about the Oberon mailing list