On 1/9/2014, 11:48 AM, Milan Sreckovic wrote:
if the goal of the styles is the readability, do we know that people actually care which
one of the described approaches we use, or is it also the "look, not all of these
things are the same" that offends us?
For example, I find the consistency of the positioning of {} for the loops and
conditionals extremely important for readability. On the other hand, the
positioning of the opening { in the function definition is just about the
consistency, but doesn't bother me if there are different usages.
It's all about consistency. All I want is for us to have one way of
writing functions as opposed to a whole bunch of exceptions for things
such as empty functions, ctors, etc.
As another example, I wish we didn't allow this kind of inlining in the first
place; I find having that makes it difficult to read (it takes longer to scan
the class to see what it has in it, because there are the implementation
details in there.) So, it's already hard for me to read, and the white space
doesn't really make any difference at that point.
Unfortunately, C++ makes that kind of hard to avoid for performance reasons.
Cheers,
Ehsan
On 2014-01-08, at 14:37 , Trevor Saunders <trev.saund...@gmail.com> wrote:
On Wed, Jan 08, 2014 at 02:24:46PM -0500, Ehsan Akhgari wrote:
On 1/7/2014, 7:00 PM, Cameron McCormack wrote:
Ehsan Akhgari wrote:
Exactly. If we require braces on their own lines for function bodies
everywhere, we wouldn't need to solve this!
Are you sure? :) There are a bunch of instances of
class A
{
A(int aMember)
: mMember(aMamber)
{}
};
through the tree. Depends how the "braces on new line" rule is written,
of course.
I guess the "close braces for function bodies on their own line"
rule is implied. But you're right, we should be explicit about
that!
I'd argue we should have some sort of exception here because otherwise
short ctors are unreasonably long and less readable because there's more
there. For example you go from
public:
Foo() mFoo(0) {}
to
public:
Foo()
: mFoo(0)
{
}
which takes a lot more lines for no good purpose.
Trev
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
