Thanks, this is an interesting topic for us “code geeks”.
Don’t know, as I try to avoid C myself. But as I remember there are those sources that promote the type prefixing of variable names. Yes, they do tend to be very terse. But this doesn’t matter much to Ruby. (You can see many of Ruby’s underlying C code in the official Ruby docs. Each method has a “click to toggle source” link that appears when your mouse is hovering over the method documentation.)
As an example, this is the C source for Ruby’s
rb_file_owned_p(VALUE obj, VALUE fname)
struct stat st;
if (rb_stat(fname, &st) < 0) return Qfalse;
if (st.st_uid == geteuid()) return Qtrue;
Well, I suppose then it is what a person has become accustomed to. If they first read the very “wordy” examples in the SketchUp API, then they’d think that was the “convention”.
Exactly! It is subjective. I just do not agree with forcing a “new coder” to abide by a subjective style rule “strongly promoted” in an informal learning (forum) situation, … whilst formal learning situations (books or classes,) are discouraged (slapped down) each time I suggest it.
The basic problems these “new coders” are having stem from an absolute lack of the basic programming concepts, common to any programming language. Namespacing, loop constructs, indentation, recursion, etc.
It would not take that much time to read an Ebook on basic programming concepts.
Anyway, … I am not against asking coders who post “help me” code, to explain whats happening and what is intended, and making the code readable (correct indentation, etc.)
I am against enforcing subjective personal preferences upon everyone.
I know this is not something I follow nor see anyone else following, even in the Ruby Standard Library.
Don’t get me wrong. I am not for obfuscating code just to make it hard to read.
I DO go above and beyond to make my code understandable if it’s a library that others will use.
BUT I do not go to verbosity extremes with variable names. Never will.
I looked through “Ruby Best Practices” and even searched for “naming” and found nothing regarding verbose variable names.
Gregory Brown does say in Conclusions, p297 …
When it comes to design, much can be gained by simply reducing complexity. If the
path you’re on seems too difficult, odds are that it can be made a lot easier if you just
think about it in a different way. As for “clever” implementation tricks and shortcuts,
they can be more trouble than they’re worth if they come at the expense of clarity or
maintainability of your code.
Put simply, the worst practices in Ruby are ones that make you work much harder than
you have to.
He did not expand or describe “clarity” anywhere in the preceding book, but as he said on pg
This book isn’t really written with the Ruby beginner in mind, and certainly won’t be
very useful to someone brand new to programming.
… he began that Preface with the following, pg
Some programming languages excel at turning coders into clockwork oranges. By
enforcing rigid rules about how software must be structured and implemented, it is
possible to prevent a developer from doing anything dangerous. However, this comes
at a high cost, stifling the essential creativity and passion that separates the masterful
coder from the mediocre. Thankfully, Ruby is about as far from this bleak reality as
you can possibly imagine.
As a language, Ruby is designed to allow developers to express themselves freely. It is
meant to operate at the programmer’s level, shifting the focus away from the machine
and toward the problem at hand. However, Ruby is highly malleable, and is nothing
more than putty in the hands of the developer. With a rigid mindset that tends to
overcomplicate things, you will produce complex Ruby code. With a light and unencumbered
outlook, you will produce simple and beautiful programs. In this book, you’ll
be able to clearly see the difference between the two, and find a clear path laid out for
you if you choose to seek the latter.
A dynamic, expressive, and open language does not fit well into strict patterns of proper
and improper use.