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

List:       kde-devel
Subject:    Re: Naming conventions?
From:       Richard Dale <Richard_Dale () tipitina ! demon ! co ! uk>
Date:       2004-10-13 12:27:03
Message-ID: 200410131327.03363.Richard_Dale () tipitina ! demon ! co ! uk
[Download RAW message or body]

On Tuesday 12 October 2004 16:08, Richard Smith wrote:
> On Tuesday 12 October 2004 15:30, Richard Dale wrote:
> > I don't personally like the 'm_' convention at all (although Hungarian is
> > much worse). You should know what is a member variable because if you're
> > using a really good IDE that should be entirely obvious.
>
> Huh? You're saying we *need* a really good IDE to be able to read your
> code? I personally don't tend to use the m_ convention, simply because it's
> just as readable to use d-> and that way has other advantages too.
Well, it's worth thinking about why a naming convention is needed. Ruby 
doesn't need this naming convention because instance variables are named 
'@foo' and are always private. If you want to access them outside the current 
class you define accessor methods. For example:

class MyClass
    attr_accessor :foo, :bar

    def initialize
        @foo = "a value"
        @bar = 5
    end
end

obj = MyClass.new
obj.foo = "another value"
puts obj.foo
obj.bar += 6

The line beginning with 'attr_accessor' automatically generates the accessor 
methods.

"simply because it's just as readable to use d-> and that way has other 
advantages too."

Well if you do that outside the current class it breaks OO encapsulation.

> > These naming conventions are also likely to mess up things like
> > refactoring too.
>
> How hard is it to do a search-and-replace across one C++ source file? I've
> done quite a lot of refactoring C++ code and I've never had problems with
> renaming things or moving variables around. It takes time, but whether or
> not the variable name starts with m_ has little effect on that time.
I was thinking more of the Hungarian notation. I now think 'm_' convention is 
fine. The code for QtRuby that I'm currently working on uses the underscore 
at the start of name convention. It was derived from someone else's code, and 
I've stuck with their scheme. 

If I start a C++ project from scratch I think I'd use 'm_' because there seems 
to be a consensus on this list that it seems to be a good idea and will seem 
familar to other people reading my code.

> > They just make up for an inadequate programming environment in my
> > opinion.
>
> Or, looked at another way, they allow you to code without using fantastic
> tools. That's good, isn't it?
Yes, it is good. But it's still worth thinking about whether or not it's 
needed only as a consequence of the development environment and language 
being used.

> > I like to make all member variables private, with names starting with an
> > underscore
>
> But that's the same as starting with a m_, only less explicit.
>
> > and only accessible via accessor methods.
>
> Adding loads of _private_ foo()s and setFoo()s to a class which doesn't
> gain any benefit from them? Why? If you want to refactor, do it like the
> book[1] says and do a Self Encapsulate Field first. It's just one
> search-and-replace.
I'm not advocating _private_ foo accessor methods. Within the current class I 
think 'd->' is fine, and much the same as referencing @foo in the ruby code 
above.

-- Richard
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]