[Gambas-user] Better use of prefixes

Cedron Dawg cedron at exede.net
Sun Mar 17 02:41:06 CET 2019


No, you must have missed the beginning of the thread.  I have a set of prefixes to indicate the locus/scope of the variables.  I am very much against cryptic names, crowded code, and nested #defines

Is there anywhere in the CoconutThrower project that you think Hungarian notation would be beneficial?

Code readability/comprehensibility is not nothing, it is quite important.

=========
Property/Variable Prefixes
---------
(none1)     Simple local variables, e.g. i, x, N, etc.
(none2)     Gambas Property Declaration
(none3)     Subroutine Names
(none4)     Control Names on Forms

the         Within a Sub

My          Public - Within a Class
my (or $my) Private Property/Variable

Arg         Argument in Public Routine
arg         Argument in Private Routine

Ret         Updatable Argument in Public Routine
ret         Updatable Argument in Private Routine

Our         Static Public Property/Variable
our ($our)  Static Private Property/Variable
=========

* I just added (none4), but it's how I've always done it.

None of them are really cryptic except for maybe "Ret" and "ret".  And the set is small and immediately interpretable, no secret decoder ring needed.  Though, there it is in twenty lines.  It also clearly identifies all your variable names against keywords and function names.

The prefixing is a relatively new (since Java naming conventions came about) innovation.  So about twenty years maybe.  The rest of my coding style goes back about forty years.  The commenting style comes from the original PC BIOS assembly language listings.

Using names like "FirstName", "LastName", "(Instance)(Kind)" is quite common in all programming languages, *and* the most prevalent in database naming conventions for fields and tables.  (think variables and classes)  Any DBA worth his salt is not going to allow cryptic names or type prefixes.

When (the very stupid) Java naming conventions came along, yeah let's not capitalize names, but capitalize things, opposite of natural usage, it presented a problem.

  String lastName  // Looks stupid, no?

  ...

  void setLastName( String lastName )
  {
     this.lastName = lastName
  }

  void getLastName()
  {
      return lastName;
  }

Clear as *fine* mud.

Now try to program that with copy and paste, search and replace.  Doesn't work very well.

  String myLastName

  ...

  void setLastName( String argLastName )
  {
     myLastName = argLastName
  }

  void getLastName()
  {
      return myLastName;
  }

Now all the "LastName"s are proper case, Java naming conventions followed, and copy/replace makes for efficient coding.

In the old days, when I first started (punch cards and teletypes, monitors were a novelty) then source code space was at a premium.  FORTRAN only allows six character names.  With 64K of RAM, yeah you needed to watch the size of your symbol tables.  That ain't happening anymore.

The test of code readability is can you see it clearly in a plain text editor without relying on syntax coloring.  Can you print it out in a listing, hang it on the wall, and point to the various logic pieces form across the room without having to parse a single word.  The same is true for how you write your math, BTW, says the former Calculus TA.

Speaking of FORTRAN, it is the original type prefixing language.  Variables beginning with I-N are integers, and the rest are REALS (aka Single).

I just figured out how to call a shared library written in FORTRAN from Gambas and will be posting that on Gambas.ONE.

I have used my coding style successfully in just about every language.  It even works in C/C++.

You should have explicit procedure separators, don't really on an IDE to show you them at display time.  Hence

'=============================================================================

They should go to column 79 so they don't cause a CR in a terminal display.  This also gives you a guideline to keep your syntax in bounds.  Not always possible without a line continuation character.

I love having GOSUBs available.  A super advantage of BASIC over any other language (except assembler).  If you looked at my code, you would have found a few.

'-----------------------------------------------------------------------------

These make nice separators for Gosubs.

'---- BASIC

C---- FORTRAN

//--- C++ / Java

/*--- True C
*/

;---- Assembly

#---- Python

etc.

These little markers in your code let you state the purpose of each block of code within a routine.  They are easy to scan for so creating an overview of your code is simple.

Here is part of the overview from the ScrollBarThrower Class

  Public Sub Throw(ArgCoconut As CoconutClass)
     - Bail if already Throwing
     - Store and Prepare the Coconut
     - Set the State to Attack

When you are maintaining code, or trying to follow it, they are a tremendous help.

By indenting the code eight spaces underneath, it makes the whole form like an outline.  A tried and true organizational methodology.



----- Original Message -----
From: "Jussi Lahtinen" <jussi.lahtinen at gmail.com>
To: "user" <user at lists.gambas-basic.org>
Sent: Saturday, March 16, 2019 8:53:28 PM
Subject: Re: [Gambas-user] Better use of prefixes

So, basically you are against prefixes, and instead you want suffixes. Also you do not like the current abbreviations. 
To me that sounds like too much work for nothing. 


Jussi 



More information about the User mailing list