4 ms·
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 cas
by cletus 2y ago
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++ )
- speed_spread 2y agoThere 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.
- ReleaseCandidat 2y ago> 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.
- cletus 2y agoI 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.
- CRConrad 2y agoComplicatred: The hatred we feel for complication.
- Mawr 2y agoReturnType< SomeOther< S, TypeConstructor< Nested<S, T, U>, T, >, >, U, HmmLetsAdd<V, W>, >
- me_me_me 2y agoVery 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.
- ReleaseCandidat 2y ago> Whoever does that do not change it, they are probably a psychopath French generally adds a space before punctuation.
- fmorel 2y agoI've gone for tabs ever since I realized it helps with accessibility https://gomakethings.com/tabs-are-objectively-better-than-spaces/ https://gomakethings.com/tabs-are-objectively-better-than-sp... Every developer can control how those tabs are rendered to their preference.
- smrq 2y agoI 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.