[Gambas-user] Better use of prefixes

[Cedron Dawg]

Let me try to answer.

The intent of the program is to be an instructional guide for newbies/programmers from other platforms.  So it is KISS, simple.

That should have been "rely" not "really".  You can't rely on your source code being viewed in an IDE.  For instance, when you post it to a site, email it to someone, etc.

The same is true for syntax coloring, nice, but you shouldn't rely on it for readability.

Ever heard of FOO?

Know what it means?

First-Of-One.

This FMain.class is a test cradle for the objects.  Set up to show that you can make many of the objects, but you only need one to test if it works.

I explained in my lengthy reply where the prefixes came from.

The capitalization of the prefix to indicate public is actually something I started with Gambas, so it is really new.  The "My" is actually a useful distinguisher.  If I have a Gambas Property in a class, let's call it LastName, then from the outside it looks like xxxxxxxx.LastName and you use it as if it were a data element, but it actually a front for a getter/setter pair.  On the other hand if it looks like xxxxxx.MyLastName then you know that you are dealing directly with a variable within the class.  If I see xxxxxx.myLastName I know something is wrong.  If I see xxxxx.theLastName something is really wrong because "the" should be a local routine variable and never be used as a property.

Good OOP design dictates that any variable that could cause "harm" not be exposed, but put behind a getter/setter pair.  Thus, many practitioners advocate only doing that and never exposing variables directly.  Those of us who code for performance know that often times that is unnecessary overhead.  Your shop standards may dictate how you have to do it.  If you are coding for yourself, do as you please, yes?

You seem to missing the distinction in the purposes of the prefix.  You could never use them and it wouldn't bother me.  Still, the purpose is to indicate the scope of the variable, so if I am deep in a long routine and looking at a line like

        theTotalAmount = myBaseAmount + argItemAmount
        
I know the first is a local variable, the second a private property, and the third a calling argument and I'm in a private routine, and I am adding Amounts.  Are they integer, float, complex?  Not really that important when you are studying an algorithm, the fact that they are numeric is.  I don't think anybody would think those were text.  If I'm vaguely aware of what the routine is doing, then I'll know the type.  But, I have error checking units.

        iTotal = iBase + iItem
        
Okay, I can see they are integers.  But they might be

        iTotalPrice = iBaseWeight + iItemHeight
        
I have no idea what the units are.  Did you ever carry units in Physics and Chemistry problems?  Yes, units are a "kind".

Even if you had, the "i" only tells me they are integers, marginal info at best.

        iTotalAmount = iBaseAmount + iItemAmount

Whereas the "my" does what a "$" does, the "the" and the "my" makes the code more readable.  Compare

        Return theTotalAmount

vs 

        Return iTotal

or     If theTotalAmount > myCutoffAmount Then
vs     If iTotalAmount > iCufoffAmount Then

The first reads almost like English and the second is clearly "code".  So not only does this choice of prefixes (numbering [the, my, arg, ret, our] x Capitalizaion - "The" = nine possibilities) give you valuable information about the nature of the variable it also makes your code more similar to natural language.  You can't see a benefit in that?

As a general rule, I never update calling arguments so "ret/Ret" is rarely used in my code, only when the routine needs to return multiple values.  This is because I code across various platforms in various languages and "call by value" is the least common denominator and if you want to translate algorithms from one place to another it is one less thing you need to worry about.  Having the Ret there allows the user of your routine know that they should expect that value to be updated, at least be aware it might get changed.

In VB, (like FORTRAN) calling is (pass by reference), so it used to be a practice to wrao a set of parentheses around a calling argument to protect it from being updated.  The reason that worked is that it made the compiler create a temporary variable to hold the result of the "expression".  Yeah, shaky is right.

For a form control, I would much rather see TemperatureScrollBar than scbTemp.  


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



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



It's very simple and have descriptive variable names, thus the choice of the naming convention doesn't really make any difference. But I would have preferred the official. 
Btw, why arrays of objects, when you use only one of each? 



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

BQ_END

Of course, but I don't see how this contributes to it. I see at best equivalent naming convention without any real advantage. 
You criticize prefixes example "scb" being unclear (it's simple abbreviation), but what you offer instead is only more unclear. Our, My, the... I have no idea how did you derive them or why you need them. I don't even like the use of $, but it's just one character so I don't really mind. 

"My"... public within class? What does that mean? Opposed to what? Public within module? They are all classes. 



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

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

BQ_END

Why? Why you need these? Something wrong with the IDE? 



Jussi 


----[ Gambas mailing-list is hosted by https://www.hostsharing.net ]----