Clarity over brevity in variable and method names

Re:Clarity over brevity in variable and method names by typicalrunt on Monday September 10, 2012 @01:40PM (#4500965)

I agree with David's sentiment and I have been doing this for years... except that I have been consistently told by other developers that I am doing the wrong thing. One of the issues in our industry is that there are no right answers, everyone seems to be correct and the biggest, loudest person in the room wins the debate. Obviously, moderation is key for anything, but it'd be nice to have a good, clear set of rules to live by (that won't change in 10 years).

For me, clear and concise method names have always help me understand code that I'm reading, as well as understand a stack trace.

[ Parent | on HN ]

Re:Clarity over brevity in variable and method names by recursive on Monday September 10, 2012 @01:53PM (#4501049)

> that won't change in 10 years

I'd settle for six months.

[ Parent | on HN ]

Re:Clarity over brevity in variable and method names by typicalrunt on Monday September 10, 2012 @02:07PM (#4501133)

Heh. Yeah I wanted to give a long enough timespan, but you are absolutely correct, even 6 months would be nice.

<rant class='mini'> When I talk with friends in other industries (e.g.: civil engineering), they have a very specific way of doing things. These fundamental activities do not change very often because they're based on decades of experience (and, I assume, because bugs in their process could kill people). That doesn't mean things don't change: concrete mixtures and such are always improving and sometimes it sounds like the IT industry with all the new tech coming out, but that's just materials technology, not how specs and processes are written. </rant>

[ Parent | on HN ]