[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Naming conventions?
From:       Jason Keirstead <jason () keirstead ! org>
Date:       2004-10-12 16:42:58
Message-ID: 200410121342.58169.jason () keirstead ! org
[Download RAW message or body]

On October 12, 2004 01:16 pm, Guillaume Laurent wrote:
> > It is only more readable if it is the convention you like, which is all
> > about taste.
>
> I fail to see where personal taste matters between instantly knowing
> whether a variable is a member, or having to look up that information.

For one, you only "instantly know" if you know the convention being used. 
Assuming you do know this, instantly knowing if a variable is a member does 
not inherently make the code more readable. Which code is more readable 
below:

if( m_bFlag )
{
	// do magic stuff
}

or

if( isOutputEnabled )
{
	// do magic stuff
}

Both are using conventions. Reading the first, you instantly know that m_bFlag 
is a private member. But you don't know what that member's purpose is or why 
it is being checked there. Reading the second, you don't know for sure that 
the flag is a private member, but you do instantly know it's purpose and why 
it is being checked.

The question is, which is more important to the person reading the code's 
understanding. You imply that the first is more important. I disagree, and 
feel that the second is much more important - IMO the reader knowing the 
scope of a variable is not as important as them knowing what that variables 
purpose is. The scope of a variable is normally much easier for a reader to 
determine than it's purpose, if it is even required to be determined at all 
( someone trying to read your code more often than not is trying to figure 
out the logic sequence of the code, and thus is not concerned with the 
visibility of a given variable ).


-- 
There are two major products that came out of Berkeley: LSD and UNIX.
We do not believe this to be a coincidence.  ~Jeremy S. Anderson
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]