Comment by cletus | Hacker News Reader

Comment by cletus | Hacker News Reader

I'm firmly in the camp that doesn't care what the rule/style is, I just want an unambiguous rule. I'll just use whatever the language conventions are. Snake case in Java, for example, would be a hate crime. So would camel case in C.

My general preferences beyond that are:

- Opening braces on the same line (I see the article has examples where it's on a new line);

- Two space indent, no tabs

- No trailing white space. This should be automatically removed so it doesn't generate extraneous changes on commit;

- A reasonable line length between 80 and 120 characters, depending on the language. You need to be able to look at 3 files side by side without wrapping.

- Don't put the return type on a separate line. This is a really old school (K&R) C style

- Don't align function parameters with opening parentheses. Change the function name and you generate a bunch of changed lines for the parameters.

- No space before semi-colons eg for (i=1; i<100; i++) not for (i = i ; i < 100 ; i++ )

I've gone for tabs ever since I realized it helps with accessibility https://gomakethings.com/tabs-are-objectively-better-than-sp...

Every developer can control how those tabs are rendered to their preference.

I would love to see a space advocate's response to this, mostly so I can disregard it because they are heathens on the wrong side of a holy war, but also because this is the only argument I've ever heard one way or another which seems to boil down to anything more than opinion.

There are two classes of rules here: naming and formatting. Formatting can be completely automated and thus changed at will, even locally with git hooks. Whitespace can be made truly insignificant with the proper tools.

While you could apply the same kind of automated logic to naming, the risk of collision is non zero and moreover would likely break runtime mechanisms like reflection, etc.

> Don't put the return type on a separate line.

Generally yes, but stuff like

   ReturnType<SomeOther<S, TypeConstructor<Nested<S, T, U>, T>>, U, HmmLetsAdd<V, W>>

can be on a line of its own.

I generally agree but there are two problems:

1. You're writing C++. You've really lost half the battle laready :) and

2. Writing correct templated code is difficult and should generally be reserved for when you're writing a library; and

3. For complicatred types like this, one should strive to increase readability by using type aliases, assuming your language supports it (eg C++ and Hack do). It's not always possible.

Complicatred: The hatred we feel for complication.

    ReturnType<
        SomeOther<
            S,
            TypeConstructor<
                Nested<S, T, U>,
                T,
            >,
        >,
        U,
        HmmLetsAdd<V, W>,
    >

Very reasonable but, changing func name for sake of code style sounds like a step too far.

Also

(i = i ; i < 100 ; i++ )

Whoever does that do not change it, they are probably a psychopath. Dont risk your life correcting them.

> Whoever does that do not change it, they are probably a psychopath

French generally adds a space before punctuation.

So I was right!

Wait, what -- you were talking about the space-semicolon bit?

And here I was agreeing... But that was because of the "i = i".

Reply on news.ycombinator.com