[Gambas-user] Better use of prefixes

[Cedron Dawg]

The manual work isn't that hard really.  I simply defined "'=" in the [Tools\Preferences\Code Snippets] for new routines.  Most routines I get from copying/pasting/modifying other routines so bringing along the divider is really no cost at all.

I actually do most my coding (C/C++/Python/Java) in a text editor.  Faster that way.  Gambas is the first IDE I've preferred over that since VB.

"my", "our", and "the" are words they are not cryptic.  "arg" and "ret" are the only abbreviations, and they are easily understood, so they aren't really cryptic either.  They are used as modifiers to the actual variable names which generally remain the same as they move between scopes.  And that is the full set.  Include capitalization as a public/private indicator and you have all you need.  

I have no problem using simple one or two character names within a routine instead of theFormalName.  However, the arguments should be formal names.

e.g 
		DoTheCalculation( ta )

		DoTheCalculation( theTotalAmount )
.
.
.
Sub DoTheCalculation( argTotalAmount as Integer )

If you think TotAmt would be a better name, so be it, but it is more cryptic.

When I speak of the complexity of the code, I am talking about the number of operations and such, the length of the names has no bearing on that metric.

No, I gave you two possible names as an example: TemperatureScrollBar and scbTemp.  Without the former, no inference could be made about the latter.  Indeed the usage would likely be within the context of developing an application for which it would be understood, but that is an assumption.


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




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. 



Why should I care?? I only provide the code as it is meant to be used, if someone chooses to mess with the code, it is their problem and fault. 
There is no way to prevent messing of your code if it is open source. Nor there should be a way. 



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

BQ_END

You turn the automatic feature off, so that you could do all the unnecessary work manually. Not interested. 


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

BQ_END

Well, it is not clear from the code that it is merely a test for the classes. 


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

BQ_END

And yet it's you who wants the cryptical stuff; my, ret, Our, etc, which doesn't really add anything usable. 



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

BQ_END

They are abbreviations, thus they can be figured out from reading code. Everything requires learning. It's not immediately clear what is ComboBox until you see one. What you suggest doesn't really change the learning curve. 


BQ_BEGIN
..., is an abstraction made to be human readable. 

BQ_END

Of course, but what you don't seem to be able to understand, is that your convention does not do that in opinion of other programmers. 


BQ_BEGIN
... building "complicated" lines is a bad idea, and you are better off breaking it apart and introducing a few local variables for clarity. 

BQ_END

Yes, but it doesn't need to be that complex, when long variable names turns into nuisance. 


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

BQ_END

Depends on context, which you gave me (temperature). Normally the context comes from the code. 


Jussi 


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