> Yes, but too often this is not one-liners, but two-liners on one line:
>
> size_type size() const { Assert(...); return data_.size(); }
Those are gone now, aren't they? ;-)
Ok, I admit, my personal limit in such cases is about four lines, i.e.
usually one or two initializations, and call to an algorithm or a loop and
a return. But I was pretty sure you wouldn't accept any example with
more than one statement anyway...
> I also belive that the class definition in itself become a lot more
> cleaner when the inlines are put _after_ the definition.
It is certainly a religious matter. If I see only the declaration, I have
to guess what it does, or to read the describing comment (if available) and
hope that it is not outdated, or to scroll down to the definition.
There is no need to guess or to hope or to scroll if the code follows
immediately. It is simply there. And the chances that obviously
misleading comments pass review are pretty slim...
> _If_ the you have to scroll "far" to to get from the declaration to the
> definition there is probably something bad with the class' structure it
> should probably be split (and yes we have this problem in several LyX
> classes)
That's certainly true. And current LyX classes are too fat in most cases...
> ok... I don't have any wrist problem...
I have from time to time. No fun.
> I choose this way sine it is often what I see suggested by really good
> C++ programmers.
I accept all of your points, they have influence me as well. It is just
that I give some points another weight so the outcome is different. And as
I said, I could live with LyX's style _very_ well, too.
Andre'
--
André Pönitz ........................................ [EMAIL PROTECTED]
