From: Sung Pae Date: 2012-01-16T14:06:48+09:00 Subject: Re: The Better Code 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.