Examples of proper extension organization


Were you responding to @john_drivenupthewall or to some other earlier post?

Assuming the former, I have to agree with John, and I don’t think this practice has anything to do with the coder’s level of experience or knowledge of the syntax. It is all about what makes the code more readable, understandable, and easier to write. To cite the common cliche, “you write code once but read it many times later”. So, you don’t do anyone a favor by making your code cryptic.

I don’t find sensible short names such as mod, defs, ents, and sel to be cryptic (as opposed to your possibly made-up infqr and hrbnf). For me they require less mental bandwidth than more descriptive but long names (look at typical Objective-C code if you want to see that carried to the extreme!). With them the only issue I see is when there is more than one variable handling the same kind of object in the same context, in which case I agree that names such as ents1 and ents2 create needless ambiguity. And, on the other hand, unless the descriptive naming is very consistent I find myself constantly asking “oh d***, what did I name the Entities collection this time?” I note that “very consistent” is a different issue than “self-descriptive”.


When people chose not to name a variable selection specifically because they mix it up with the call to Model#selection I absolutely think it’s based on a lack of knowledge about the syntax.

Regarding readability I think model and selection reads infinitely better than mod or ss. Mod could mean module, modulus, modification or any other word starting with those 3 letters. The only way to know what it means is to scroll to its definition and see where the value came from, or learn that it usually means a certain thing in this developer community. On the other hand, someone who has never written, or read, a SketchUp extension before could easily tell that a variable called selection refers to the selection, and one called model refers to the model.


When you go to work as one of many programmers in a large company you must follow corporate standards. Logically and consistently named variables may be part of that standard.

When I started programming in assembler we had an 8 character restriction for variable names. Early C compilers forced us to create well documented legends containing variable names and their usage.

Personally I fully agree with John and Steve. I use mod for model since it is used so many times in a program. In your example I would spell out modulus because it is not used very often. And I wouldn’t dream of ever using mod to represent modification. Yes - someone can cite examples to why and why not. But in the end stylistic choices are just that - choices.

If I am sharing code on the forum or to an individual I then tend to write code in a more formal manner. But when I’m writing code for my self I want to be able to speed read and succinct consistent brevity is the only way I go.


I take the opposite position: I think that using the same name for a variable and a method is unnecessary and doesn’t add anything to code clarity. Unless you always qualify all method calls with an explicit receiver, including when they are to self, you rely on full understanding of how Ruby handles ambiguous cases. To me that’s not code clarity, it’s showing off your expertise, somewhat like C programmers like to do (see “The C Puzzle Book”).

But equally to the point, regardless of whether the variable is named “sel” or “selection”, if you don’t remember when it was assigned, you can’t assume anything about what it refers to.

Edit: By the way, I wonder how many Ruby coders actually remember how the interpreter handles situations when a method and a variable have the same symbolic name? There is a rule, but it is not obvious and has at least one interesting subtlety!


Naming culture changes.

There were times when the biggest bottleneck was memory (small programs) or screen width (shorter line length). Nowadays, computers are fast and memory is ubiquitous (and used to speed up applications with caching), while the main bottleneck is network throughput.

If you do low-level programming without using optimizers/compilers you have rather fixed space constraints (short, cryptic assembler instruction names).

When people were not using IDEs, they ruined variable names by prepending a type abbreviation (hungarian notation).

Now we have IDEs with static analyzers that give type information in real time. And during the history of computing, humanity has collected such a legacy of old code so that maintainability and readability are focus (meaningful naming). We write code in high-level languages and avoid manual optimizations where ever they make algorithms harder to understand because powerful compilers can do a much better job at that.

Ruby aims to be read fluently like human language and it makes sense to follow that practice.

Why not introduce abbreviations in a comment like you do in official documents, reports, thesis? (Also there are Yardoc tags to include such comments in documentation).


If you are abbreviating a word to distinguish it from itself I think you are doing something wrong. If you have a method and a variable called the same thing (but one abbreviated) you should probably use more descriptive names, like add a verb to the method name, not just purge a few letters within it.

However that isn’t the case with the API. With the API it you always use a receiver, and can this easily distinguish e.g. model.selection from selection as defined in your own namespace.


In my opinion manual optimizations are a different issue compared to naming conventions. Even in the early days I was never a fan of Hungarian notation.

There were a few situations where I needed to manually optimize code because the visual studio compiler was not optimizing it well enough. This wasn’t too long ago but was on an embedded processor working with real time data. And it was only when the processor couldn’t keep up with the data flow.


This convo (# conversation) has gotten away from the intended subject. :wink: