Re: [boost] lhs/rhs ([Review] Type Traits Extension ending tomorrow)

Subject: Re: [boost] lhs/rhs ([Review] Type Traits Extension ending tomorrow)
From: Joshua Juran (jjuran_at_[hidden])
Date: 2011-03-22 11:05:54

On Mar 22, 2011, at 7:15 AM, Max Sobolev wrote:

> On 21.03.2011 16:10, Robert Jones wrote:
>>> On Mar 21, 2011, at 4:52 AM, Max Sobolev wrote:
>>>
>>> I /hate/ lhs/rhs identifiers :( (despite my respect to people that  
>>> use it
>>> (Scott Meyers etc.) :))
>>
>> How curious... despite all their demonstrable short comings  
>> (similarity,
>> redundancy, etc), I think
>> that pair of identifiers are some of the best, most instantly  
>> recognisable
>> and understandable identifiers
>> ever coined! Each to their own I guess.
>
> it's fine for asm, ........but in C++ we probably should write:

I don't see why asm needs shorter identifiers.  On the contrary,  
assembly instructions tend to be very brief, in contrast to C++  
statements whose readability sometimes improves with shorter  
identifier names.

> Type operator + (Type const& left_hand_side,
>                 Type const& right_hand_side) { . . . }

No, this is worse than 'lhs' and 'rhs'.  The two abbreviations are  
easily recognized for what they are (even if distinguishing one from  
the other takes some thought) but the spelled-out terms one must read  
and interpret, only to realize they mean nothing (other than to state  
what position they appear in).  For the same reason, I always write  
loop indices as 'i', not 'index', and especially not 'widget_index' --  
any information provided only serves to distract.

> (So far I don't confide that "left hand side" is a right decryption  
> for /lhs/)

I'm quite certain that's the phrase which 'lhs' abbreviates.  I  
suppose children have an easier time learning left from right if they  
use their body parts as cognitive training wheels instead of dealing  
directly with abstract concepts.  Adults don't need such devices, but  
'ls' and 'rs' would be worse identifiers (with the 's' still being  
redundant).  I think of 'r' as meaning 'radius', and 'l' is just  
asking for trouble because it's so similar to '1'.

> Type operator + (Type const& left, Type const& right) { . . . }

I associate left and right with graphics systems.

> left/right are too simple :( but not horrible names. Articulation  
> of /lhs/ and /rhs/ is much longer then /left/ and /right/ words,  
> because former consists of 3 syllables (l - h - s), and later  
> consists of 1 only.

I use 'a' and 'b'.  They're each one character and one syllable, and  
it's obvious without thinking which order they go in.  And they don't  
look like they might mean something more than they actually do.

inline bool operator<=( const Foo& a, const Foo& b )
{
     return !(b < a);
}

This is similar to Perl's use of $a and $b as the parameters to sort  
callbacks.

> i use left/right argument names for binary operators as free  
> functions, and /other/ for unary member functions (+ cctor) with an  
> argument of class type (This later is a boost convention).

I use 'other' in the same way.

Josh