Re: [Gm2] Re: LENGTH() on Solaris 10/sparc

[Fischlin Andreas]

Hi all from the gm2 community,

Please listen very carefully to this:

I would like to make a VERY, VERY, VERY strong recommendation in terms of style 
how to write Modula-2 programs. There are a few naming conventions for 
identifiers that have proven to be VERY, VERY, VERY helpful in writing Modula-2 
code. I just realized that gm2 is unfortunately written largely in a style that 
ignores those rules. What a pity! Note that the rules have a long tradition at 
ETH and originate from Niklaus Wirth's group.

The important rules to adhere to always are:

1) Start identifiers of variables and constants always with a lower case letter 
2) Start identifiers of types and procedures always (if possible including 
function procedures) with an upper case letter

the most important is already said, but then you get code that is even better 
to read when you

3) Use always verbs for procedures
4) Use nouns for variables, for function procedures the noun for what the 
function returns, and try to favor for constants if possible other word 
categories than nouns to emphasize the difference to variables
5) Use adjectives, adverbs or descriptive nouns for types

Together these rules greatly enhance the readability of Modula-2 code. 

For instance you can tell procedure and type identifiers easily apart from each 
other and all other objects: their identifiers are capitalized, yet procedures 
always use a verb, but types don't. 

If function procedures are not capitalized, procedures and function procedures 
can be easily told apart, since only the latter occur in expressions and have 
always parentheses. If function procedures are not capitalized, e.g. because 
the convention in mathematics differ, say 'sin(x)',  there are always the 
parentheses in an expression that help to tell them apart and are therefore 
also easy to distinguish from any other term or factor that starts with a lower 
case letter.  

Constants and variables are the least easy to tell apart, but if you try to 
follow rule 4, that may help. Moreover, having some difficulties with this 
distinction is not that severe, since they can often be used interchangeably in 
an expression and knowing whether a term is a constant or a variable is of less 
significance when studying an expression. Finally, when the object is on the 
left side, there is of course no issue in telling them apart ( '=' vs. ':=').

Some people have suggested other rules such as using an additional letter such 
as 'C', 'T', 'V', or 'P' at the end of the ident to characterize whether it is 
a constant, type, variable or procedure. Of course, one may argue that this all 
just a question of style, but I do personally not like to read such code, 
whereas above rules give much more freedom to name objects and let you write 
code that reads quite naturally. 

As I said, one can argue on style issues forever, I wish only to share with you 
something that has proven to be very, very helpful. We have written within the 
many RAMSES software layers (http://www.sysecol.ethz.ch/ramses/index) 
everything according to those rules and I believe we have greatly benefitted 
from following these rules in terms of readability of the code. 

Regards,
Andreas
 


ETH Zurich
Prof. Dr. Andreas Fischlin
Systems Ecology - Institute of Integrative Biology
CHN E 21.1
Universitaetstrasse 16
8092 Zurich
SWITZERLAND

address@hidden
www.sysecol.ethz.ch

+41 44 633-6090 phone
+41 44 633-1136 fax
+41 79 221-4657 mobile

             Make it as simple as possible, but distrust it!
________________________________________________________________________



On 02/Aug/2010, at 22:25 , Fischlin Andreas wrote:

> Dear Gaius,
> 
> One last attempt. Afterwards I will give up. Promised. ;-)
> 
> ___________________
> 
> Gaius wrote:
> 
> ok - I'll change this - probably to use a procedure function returning
> TRUE on success.
> 
> 
> ___________________
> 
> af writes: Excellent
> 
> ___________________
> 
> Gaius wrote:
> 
> I'll rename Terminate to ExecuteTerminationProcedures.  Maybe we need
> a procedure function to determine whether we are in the Termination
> phase as well.
> 
> 
> 
> ___________________
> 
> af writes: In my understanding not quite the same or not necessary the same. 
> I expect Terminate to be a really low level call to the hardware halting the 
> currently running process. However, ExecuteTerminationProcedures does nothing 
> of the sort. It merely executes all installed termination procedures. A 
> typical sequence would then be
> 
> ExecuteTerminationProcedures; Terminate;
> 
> In particular in a dynamic loader situation, Terminate would merely abort the 
> current level and leave the rest of the process stack intact.
> 
> The question also arises what is the relationship to HALT. HALT may be the 
> same as Terminate, in particular in a single level system as all statically 
> linked run-time environments such as that of C are. But as a n implementer 
> you are free to also interpret HALT as simply first breaking the program, as 
> any other break point set, and allow the user the choice of either calling 
> the debugger or perhaps continuing the process if no abnormal condition was 
> encountered or to abort the program. Only in the last situation you would 
> then call
> 
> ExecuteTerminationProcedures; Terminate;
> 
> This would allow to debug the running data/code BEFORE the termination 
> procedures have made their garbage collection.
> 
> ___________________
> 
> Gaius wrote:
> 
> Agreed there is no dynamic module loading possible, since our times
> entrench on us the stone age of only static linking and unmodular
> programming style, but nevertheless I am not sure whether it would
> not be beneficial for having the symmetrical procedures available as
> well.
> 
> PROCEDURE InstallInitProcedure (p: PROC; VAR done: BOOLEAN) ;
> PROCEDURE ExecuteInitProcedures;
> 
> sure I'll implement this - the ExecuteInitProcedures will be called by
> default just before the main program module BEGIN code.
> 
> ___________________
> 
> af writes: Exellent and exactly what is needed.
> 
> ___________________
> 
> Gaius wrote:
> 
> I believe the StrLib.StrEqual code behaves in the same way as StrEqual
> above.  (It uses StrLen to determine the length of the strings under
> comparison which handles the ASCII.nul case).  Unless I've
> misunderstood something?
> 
> 
> ___________________
> 
> af writes: You are right, I read this code too quickly. What confused me is 
> the use of the variable name Higha and Highb, which are basically wrong 
> names. The names are misleading, since a statement like
> 
> Higha := StrLen(a) ;
> 
> should rather be written as
> 
> lena := StrLen(a) ;
> 
> since HIGH and LENGTH have little to do with each other. My problem was just 
> the poor variable naming. Thus the code should better be written as
> 
> 
> PROCEDURE StrEqual (a, b: ARRAY OF CHAR) : BOOLEAN ;
> VAR
>   i, lena, lenb: CARDINAL ;
>   equal: BOOLEAN ;
> BEGIN
>   lena := StrLen(a) ;
>   lenb := StrLen(b) ;
>   IF lena=lenb
>   THEN
>      equal := TRUE ;
>      i := 0 ;
>      WHILE equal AND (i<lena) DO
>         equal := (a[i]=b[i]) ;
>         INC(i)
>      END ;
>      RETURN( equal )
>   ELSE
>      RETURN( FALSE )
>   END
> END StrEqual ;
> 
> 
> But above routine is IMHO still not a particularly good one, since it is very 
> inefficient. It makes at least 2 and up to 4 passes through the 2 string 
> variables, while my proposals make up to a max of 2 passes as unavoidable. If 
> the two strings differ in the first char, that first char comparison is all 
> what is needed and the routine already returns FALSE. Please replace above 
> routine with one of mine's. That may quite matter with large string arrays.
> 
> Regards, Andreas
> 
> 
> ETH Zurich
> Prof. Dr. Andreas Fischlin
> Systems Ecology - Institute of Integrative Biology
> CHN E 21.1
> Universitaetstrasse 16
> 8092 Zurich
> SWITZERLAND
> 
> address@hidden<mailto:address@hidden>
> www.sysecol.ethz.ch<http://www.sysecol.ethz.ch>
> 
> +41 44 633-6090 phone
> +41 44 633-1136 fax
> +41 79 221-4657 mobile
> 
>             Make it as simple as possible, but distrust it!
> ________________________________________________________________________
> 
> 
> _______________________________________________
> gm2 mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/gm2