Clarity over brevity in variable and method names

Many programmers have a natural preference for short variable and method names. I doubt many would recognize this preference as a trade of brevity for clarity, but that’s often exactly the result. This is especially true if you subscribe to the ridiculous Church of 80-character Lines.

It need **t be that way. Writing terse code can be a joy even if you spell things out in abundant detail. Modern programming languages are expressive e**ugh that what you save in laborious boilerplate can be spent on clarity — and you’ll still have plenty of lines left over for a dance.

And most certainly, you’ll hardly ever need to abbreviate anything. I cringe when I see ext for extension, cp for copy, or worse, application-specific abbreviations sure to be forgotten two months after you left the project.

At times being exceedingly clear will seem almost silly at first glance. The name of the method or variable can be longer than the operation being performed! But the silliness quickly dissipates the first time you return to a piece of code and k**w exactly what it does.

Here are a few examples of long method names from the new Basecamp code base:

def make_person_an_outside_subscriber_if_all_accesses_ revoked person.update_attribute(:outside_subscriber, true) if person.reload.accesses.blank? end def shift_records_upward_starting_at(position) positioned_records.update_all "position = position - 1", ["position >= ?", position] end def someone_else_just_finished_writing?(document) if event = document.current_version_event !event.by_current_creator? and event.updated_at > 1.minute.ago end end If you work hard at being clear in your naming, you’ll also rarely need to write comments for the code. Comments are generally only needed when you failed to be clear e**ugh in naming. Treat them as a code smell.

http://feeds.feedburner.com/~ff/37si...?d=yIl2AUoC8zA http://feeds.feedburner.com/~ff/37si...?d=7Q72WNTAKBA
http://feeds.feedburner.com/~r/37sig...~4/v9SBU28OT-Y

أكثر...