less cryptic variable names in Dojo

[psowden]

Dojo is full of cryptic variable names such as tn, lf, ghm, etc.. which makes it hard to debug and hard to understand for folks unfamilier with the code.

The build system has variable renaming for compactness and obsfucation or what have you, there is no need for cryptic names.

[[email protected]…]

While this may seem trivial, I think it is incredibly important that variable names be easily understood, even internal ones. Especially if the public version of Dojo is going to be compressed, we really have no business saving space. Now, if you want to use a short name with abbreviations locally to save keystrokes, that's fine.

[alex]

no one has volunteered criteria for success on this widget. Punting to 0.3 unless someone lands a patch or a set of success criteria which would allow it to be closed for 0.2.

[alex]

still no success criteria. closing.

[skinner]

Looks like this bug was closed for lack of success criteria, so let me offer an idea...

The Dictionary Criteria: A dojo package qualifies as having "less cryptic variable names" (and this bug no longer applies) at the point when 80% of the variable names include at least one word that you can find in an ordinary english dictionary.

Examples of variable names that pass the Dictionary Criteria:

width
offset
delay
findLast
ptype
method 

Examples of variable names that fail the Dictionary Criteria:

wh
ns
cb
farr
e
kwArgs
lvl

With the cool new doc parser, it would also be possible to write a simple unit test that would pass or fail based on the Dictionary Criteria.

[skinner]

Or, simpler but less robust than the Dictionary Criteria...

The Five Letter Criteria: A dojo package qualifies as having "less cryptic variable names" (and this bug no longer applies) at the point when 80% of the variable names are at least 5 characters long.

[skinner]

one more thought...

This might be an especially good bug to leave open as "low hanging fruit" for someone who's just getting involved in the project and looking for a useful way to contribute as they're reading through the code. (It's maybe similar in spirit to the notion in the Wikipedia community that fixing typos is a good first step toward getting involved.)

[tk]

Was this ticket taken into consideration with the 0.9 rewrites? I hope so...

in comment to the 5 letter rule, that would allow vars like kwArgs to be used where the dictionary one would not... and we might end up with vars like 'abcde' and 'fghij' :P

[dylan]

I think it is actually much worse for local and private vars now...

[tk]

I was afraid of that... we really should establish some guideline for policing tickets... so this doesnt happen all the time.. .I wrote a custom query to order the tickets by last modified time... its pretty interesting to see... its query 32 I believe...

[Adam Peller]

I think the age of this ticket and lack of progress proves that a ticket is the wrong way to address this. Let's move discussion to the forums and update the style guide, if needed, and encourage people to make improvements in their code. Leaving bugs open deliberately is not a good idea, IMO.