> Hello,
>
>
> // get foo
> f = myclass.foo();
>
>
> Note that there's no "get" or "set" prepended to the method names,
> since it's redundant and does not help understanding what the code
> is doing any better.
Sorry, but I disagree with you at this point - I'm using different style
and I think its better and so it will not change - the idea goes here:
method should have the 'action' in its name - thus Get & Set makes
it clear what is happeing - if I will use just foo() then I actually
don't know what I'm doing - I would have to look at the class declaration
itself to know, than I'm just modifying attribute - it it the funtion to read
some attributes or anything else.
Btw - this is the same style as in Java - and I think its better
then what you are proposing (also I don't like Qt style where
there is Set methods - but there is no Get)
2nd. Btw - I'm making the interface now consistent across all the
aviplay classes as you might have noticed.
> Also note that the attribute name must now be called something else
> because the word "foo" is already used. If you like Ungarish notation,
> you can call it "m_foo", otherwise the best choice is "_foo", because
Yes we are using m_foo.
> it makes it clear that nobody should ever need to access this member.
> To be honest, the book suggested to use "foo_" to avoid clashes with
> names used in the standard library.
Well there is a lot of books around the world and I think that
the current style is the best - but certainly this will be subjective all
the time. We simply can't build the code which will everyone like.
But we are trying to do it as much clean and as readable as possible.
(as you might have noticed)
> use the foo() methods instead of accessing directly to _foo. The code
> would get inlined anyway, so there's no speed penalty and it makes
Well usually you need virtual methods anyway...
bye
--
Debian GNU/Linux maintainer - www.debian.{org,cz}
Zdenek Kabelac http://i.am/kabi/ kabi@{i.am, debian.org, fi.muni.cz}
Resistance is futile. You all will be packaged
_______________________________________________
Avifile mailing list
[EMAIL PROTECTED]
http://prak.org/mailman/listinfo/avifile
