On 15 Jan 2012, at 6:30 PM, Intransition wrote:

> Which would you judge to be the better code?
> 
> The concise:
> 
>     def self.assert(*a, &b)
>       o = Hash === a.last ? a.pop : {}

...

> Or the more explicit:
> 
>     def self.assert(*arguments, &block)
>       options = (Hash === arguments.last ? arguments.pop : {})

http://news.ycombinator.com/item?id=840331

Quoting IsaacSchlueter:

> There's a lot of "short vs long" going on in the comments here. That
> seems silly to me.
>
> Code should be written so as to completely describe the program's
> functionality to human readers, and only incidentally to be
> interpreted by computers. We have a hard time remembering short names
> for a long time, and we have a hard time looking at long names over
> and over again in a row. Additionally, short names carry a higher
> likelihood of collisions (since the search space is smaller), but are
> easier to "hold onto" for short periods of reading.
>
> Thus, our conventions for naming things should take into consideration
> the limitations of the human brain. The length of a variable's name
> should be proportional to the distance between its definition and its
> use, and inversely proportional to its frequency of use.
>
> Global config setting that gets specified once and used in 4 places
> throughout the program? 10-20 characters is probably appropriate.
> Might wanna go with UPPER_SNAKE_CASE to make it stand out a bit more,
> even.
>
> Iterator variable that you define in a 3-line for loop and then never
> see again outside of it? Call it "i".
>
> Another way to look at this: The first time you meet someone, you
> learn their full name. When discussing them with someone else who
> knows them, you use just a single name. If they're standing right
> there, you don't bother using their name, but just make eye contact,
> and maybe a "Hey". Should be the same way with variables.