4

I have often wondered about the implications of shortening code by assigning temporary variables with shorter names to data accesses with long names. It's best illustrated by an example (in Ruby, but not that it matters):

This long code is ugly, IMO:

# Trim the description to MAX_LENGTH characters followed by "..."
# if the description is MAX_LENGTH characters or longer
def shorthand_description
    return (some_object.nested_hash.description.length >= MAX_LENGTH)
           ? "#{some_object.nested_hash.description[0..MAX_LENGTH]}..."
           : some_object.nested_hash.description
end

This seems to be a lot more readable:

def shorthand_description
    desc = some_object.nested_hash.description
    return (desc.length >= MAX_LENGTH)
           ? "#{desc[0..MAX_LENGTH]}..."
           : desc
end

Personally I almost always shorthand variables if the long access chain is more than about 20 characters and it's repeated. Is creating a variable only to make the code more readable acceptable? Does it depend on style guidelines for the language, or is it a language-agnostic concept?

  • 2
    r = readable; s = symbols; sn = shorthand names; t = the; u = use; U t sn if they make your s more r, as r'ty is arguably t only reason for u'ng s in t 1. place. But don't u sn just for t sake of u'ng sn. It is not always more r. – Brandin Jun 23 '16 at 6:54
4

(My answer ignores the effects of optimization - I'm assuming there is a machine processing your code that can do decent optimization so that the extra variable being created for readability will not make a difference in performance.)

In my experience, write your code to be understood. A short, meaningful name is definitely more acceptable than repeating a too-long string of characters, whatever the language. When you come back to the code again in a week/month/year, you'll appreciate that small bit of clarity you added to help you understand it better.

That being said, if you're enhancing existing code, follow the conventions that are already being used. If your code looks too 'different' for no good reason, it'll be hard for the person who looks at it next to understand why. And If the conventions truly are too terrible and troubling, refactor the code (make sure there are tests) or at least add a really good comment explaining what's going on. This isn't the 1960s when storage was too expensive to afford clarifying comments in source code.

The Best Rule: Write your code as if the next developer assigned to work on it is really mean and angry, and knows your home address.

4

When you see a good move, look for a better one.
—Emanuel Lasker, 27-year world chess champion

It's a very good readability enhancement, but always look for the better move. In this case, you are likely often covering up problems with your responsibilities being misplaced. The principle of seeking to avoid those chains of identifiers has its own name: the Law of Demeter.

Perhaps this would fit better as description.shorthand(), or as truncate_to_length(string, length). Yes, there are exceptions to every rule, as that C2 page I linked to explains, but if this is a regular occurrence, you are probably introducing a lot of unnecessary coupling into your architecture.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.