stevedee wrote: ↑Wednesday 29th March 2017 7:09pm
[...] But what I like about Gambas and VB is that code is easy to read if you don't take too many short-cuts. After all, if you like terse code, why not use Python, C or C++? [...] For beginners and the non-fluent (like me) the very wordy nature of Gambas is a big plus. [...] And using constants like gb.IgnoreCase saves having to remember what "0" or "1" means.
I didn't know about the "==" trick, but I have to say I don't like it for similar reasons. Where "==" crops up in other languages, it normally means a logical comparison. So I don't know why it means case-insensitive string compare in Gambas. [...]
Sorry if I dissapoint anyone, but I strongly agree with
stevedeee.
The very definition of a high level language, is
how close to native human language is.
This is why I chose RapidQ back in 2000's. It is very much like Gambas although there are important differences. Then I moved to Gambas: both allow wrtiting code that can be understood years after writing it, given the fact that you use a proper variable/ procedure naming system.
As you could see, all names I use are verbose and this is on purpose. This allowed me to find some snippets of code in a RapidQ project with 5,600+ lines of code, in less than 5 minutes when I was looking for a particular solution for DirLister. And this happened after 15 years of break. I never touched any RapidQ code since late 2005.
While using numbers instead of character names for various kinds of situations might be tempting at first sight, it makes the code highly unreadable.
While I was still active in RapidQ community, I needed to get info on some code and asked the authors. It turned out that they were unable to read and understand their own code, exactly for this reason: they thought that using short names is enough. Time, proves this approach highly counter-productive.
On the other hand, verbosity is time-consuming, I know and on the short term, it often looks a burden, or worse: a curse...
On the long run however, I had the chance to verify that on my own code:
- Clumsy naming, few (or worse: zero) comments: I had to rewrite the code from scratch.
- Verbose naming, verbose comments, where needed (long, complex procedures): I could easily improve, copy/paste the code, even after 15 years.
On top of that, I must mention one "small detail", but significant in this context.
I am the lazy kind. If there is a way/path that is 10 meters long and I can find a 9 meters long one, I'll go for the 9 meters. Might be risky? Yeah... Still... Far more than that...
I belive that all programmers go into that category.
Why else would they spent so much time coding, other than building a shorter path to a particular outcome?
For example: At first sight, I almost hated the so called "Hungarian notation". After a few weeks of working at a long code, it suddenly blew into my eyes: how was I supposed to give a meaningful name to a certain type of variable, inside a 300 lines procedure, with lots of types of variables? All related, all intertwinned?
Was awfully hard in the beginning, but... eventually I got used to that too...
So, instead of "
DirPath, IsDirPath", "
strDirPath, boIsDirPath" looks more obvious than the previous. While you are at the procedure's declaration line, you see what is what, but later, in code, everything gets blurred.