Doesn't it just hurt your eyes...

[chrisname]

@LB
I put spaces before the opening parentheses in statements (if, while, for, switch) but not function calls. You say you put spaces before the parentheses that indicate construction to distinguish them from function calls, and not before statements. This is totally backwards - construction is (usually) a function call and statements are not functions, so you're trying to distinguish a function call from function calls, but you're not trying to distinguish non-function calls from function calls. You have it completely the wrong way around.

[LB]

@hamsterman
1. It is a different style that I do not understand, and because of the way my mind works, it distracts me every time I see it because I keep trying to gather more information in the hopes of understanding. It's not really something I can turn off.
2. I'm not sure how this is a response to my #2
3. foo(bar, baz);
The parameter list belongs to foo, so they are related.
Each parameter is part of the parameter list, so they are related.
Each parameter is not related to each other, so they are separated.
The semicolon marks the end of the function call/declaration, so it is related.

I agree with the second part of your original #2.

@chrisname

Type t1 = Type(blah);
Type t2 (blah);

[chrisname]

@LB
I don't see your point. The first one is calling two methods: the assignment operator and the constructor, the second one is just calling the constructor. It's different for primitive types, e.g. int i(4); isn't calling a constructor because int is not a class, but for complex types which have constructors, such as std::string, it would be a constructor call: std::string s("hello world");.

[hamsterman]

@LB
2. Meaning is semantics and the function of making things more obviously separate is only syntax. Maybe I should have said "form is not meaning"? You found the contradiction by freely applying the word "meaning" where it should not be applied.
3. I guess that works, if for you parentheses have a higher priority than spaces. I was going to point out that this is the only case where two identifiers are not separated by a space (unless you write foo+bar, which I'd rather you didn't). But then I'm okay with your rationale behind having no space.
1. Having run out of auxiliary points to make, I return to my original one. In reality, not only is no one style more rational than all others, but, I believe, no one style should be used with perfect accuracy. As a specification cannot fully embody the human concept of readability, you should allow variation when both writing and reading code. If you can't, you have a bit of a problem.

[3qX21hU5]

1. Having run out of auxiliary points to make, I return to my original one. In reality, not only is no one style more rational than all others, but, I believe, no one style should be used with perfect accuracy. As a specification cannot fully embody the human concept of readability, you should allow variation when both writing and reading code. If you can't, you have a bit of a problem.

This is actually a very good point. From what I hear from some people I know who work in various programming positions, is that most of the time you won't have a choice on which style you wish to use. You must adapt to whatever style is chosen for that project. So its best to be comfortable with all different types of styles of formatting.

[moorecm]

You always have to use the formatting that was already used when maintaining a codebase. Reformatting it can be useful for readability in a limited scope but beyond that introduces problems for reviewers and merges.

[LB]

@chrisname: I wasn't saying that the were doing the same thing, I was pointing out that when I call the constructor using the functional syntax I don't put a space, but when I call the constructor as part of a variable declaration, I put a space because the parameter list is not related to the variable, it is related to the type. I use constructor syntax with primitives just for consistency reasons.

@hamsterman
2. You're right, I did warp your grammar when I thought you meant it that way.

"the function of making things more obviously separate is only syntax"
Maybe that's true for the compiler, but certainly not for human readers. Unless you're using syntax from that perspective and not the compiler's perspective.

3. Identifiers are not separated by spaces. Identifiers are separated by delimiters, and a space is a delimiter just as a paren is. In some cases I write foo+bar and in other cases foo + bar - it depends on whether foo and bar are related or not. strlen+1 + offset

2. Yeah, I'm not saying any one is more rational, I'm just saying I don't know the rantionale for some.

[hamsterman]

@LB, in 2. (and everywhere else), I do mean human readers. And I am referring only to the case of space before "(" - for humans spaces are somewhat semantic at indentations and maybe somewhere else. If the space before "(" was in fact semantic, you would be able to find (slightly) distinct interpretations for foo(bar, baz) and foo (bar, baz). Surely you can't.

[LB]

hamsterman wrote:

you would be able to find (slightly) distinct interpretations for [w/o space] and [w/ space]. Surely you can't.

LB wrote:

when I call the constructor using the functional syntax I don't put a space, but when I call the constructor as part of a variable declaration, I put a space because the parameter list is not related to the variable, it is related to the type.

LB wrote:

The parameter list belongs to [the function], so they are related.

somefunc(MyClass(foo, bar)); //calling ctor function-style
MyClass inst (foo, bar); //declaring var + calling ctor
MyClass func(Foo, Bar); //declaring function returning MyClass 

At a glance, I can tell if a statement was intended to construct a variable and pass arguments to the constructor, or declare a function and not specify the names of the parameters. From there, I can tell if it did what was intended or not. (ofc in C++11 you would use the curly braces instead, but not in all cases)

[hamsterman]

Oh, right... But then this is a notation of your own, isn't it? The relevance of your example is then lessened (as I could assign any meaning in any sequence of symbols). Maybe my question was wrong to begin with...