[Gambas-user] Better use of prefixes

[Cedron Dawg]

No, you have no control over where your code may end up, nor how intact.  Believing that it will always be whole and an appropriate IDE available is tenuous at best.

You should expect that any piece of code to be excerpted, without the declaration of the variables included, so any information that is inherently available is beneficial.

Having procedure separators explicitly in the code is more powerful.  They are there.  Obviously they are useful or the IDE wouldn't provide them *as an option*.  I shut then off in VB, and I shut them off in Gambas, and rely on the text for the separator.  If you believe your code will only ever be viewed in an appropriate IDE, well then that's not necessary, is it?

A test cradle is for development and unit testing.  That is exactly what that one does.  How would you structure one any differently?  The classes need a form to be tested on.

The main benefits of my convention, compared to the current one, are specification of variable scope and a reduction of "symbols" and "cryptic abbreviations" to improve comprehensibility.  If you don't know what abbreviations stand for, then the code becomes undecipherable.

Your ease of reading shorter names argument is premised on a foreknowledge of abbreviation meanings.  To me, that is a faulty assumption.  And a burden on the reader to make them learn them.

The use of the "$" specifier for private class level variables I suspect came along to distiguish the Property (name) from the private variable that supported it $(name), and then became general from there due to its utility.

There are really three places where variables are declared:  Class level, routine level, and calling arguments.

In each of those places, a few flavors are available, e.g. static or not, public or not.

My prefixing system arose to identify those.  It came out of practicality and utility.  Currently you have two of the three covered with "$" and "none".  As I suggested to Hans Lehmann, perhaps "$$" or "$_" would be good for arguments.  That gets you the scope, the flavors aren't as important.

If you want to do "real programming" in a "real Programming language", as "close to the metal" as you can get, I suggest that you give hand coding opcodes (i.e. real machine language) by hand.  Then you will understand that any higher "programming language", including Assembly, is an abstraction made to be human readable.

If your preference is for symbols over words, then maybe C is a better fit for you than a BASIC dialect.  Why use words like "and", "or", and "not" when there are perfectly good symbols, widely used and understood, for that?

https://forum.gambas.one/viewtopic.php?f=4&t=669

The more you program, and the more you maintain code, and the better understanding you have about how compilers and optimizers work, the more you will realize that building "complicated" lines is a bad idea, and you are better off breaking it apart and introducing a few local variables for clarity.

Ummm, "Temp" usually means "Temporary", gotcha.




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




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. 



... 

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

BQ_END


Of course you should rely on that. There is absolutely no good reason to separate any RAD language from its IDE (or compatible IDE). 
Only very trivial code is ever viewed outside of IDE. And even then the source code should be posted as archive, if it is meant to be executed. 


BQ_BEGIN
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. 

BQ_END

Very bad programming habit. These should be in separated unit tests or they shouldn't exist at all. 


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

BQ_END

Exactly. 

BQ_BEGIN
... it also makes your code more similar to natural language. You can't see a benefit in that? 

BQ_END

I don't see the benefit in your convention. However long descriptive variable names generally do that, but sometimes it is not beneficial for the readability (in complex lines). 
Programming is fundamentally different from natural languages and thus the similarity on surface doesn't always convey benefits. 


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

scbTemp has the same information, but in much more concise way. So, if there are long lines I would strongly prefer "scbTemp", otherwise I don't mind at all. 


Jussi 



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