Yes, everyone has personal opinions about code vanity. When this becomes a holy war I really start to question the maturity of people on the project. I find that people worry about trivial nonsense to mask their inability to address more valid concerns.

All that really matters is consistency. Let a team make some decisions and then just move forward.

▲ 2muchcoffeeman 4 days ago | parent | next [-]

Don’t bother making decisions. Steal a standard. Vote on it once if you want to be democratic. Done forever.

▲

gorgoiler 3 days ago | parent [-]

Democracy, strictly speaking, would be to periodically elect the most popular formatting policy once every sensible-time-period.

I’ve seen companies with such a large amount of developer churn that literally one person was left defending the status quo saying “we do X here, we voted on it once in 2019 and we’re not changing it just for new people”. 90% of the team were newcomers.

(The better teams I’ve worked on maintain a core set of leaders who are capable of building consensus through being very agreeable and smart. Gregarious Technocracy >> Popular Democracy!)

	▲	plusplusungood 3 days ago \| parent [-]
		Ah, the infamous, but fictional, Monkey Ladder Experiment.

▲ socalgal2 3 days ago | parent | prev | next [-]

> All that really matters is consistency

And this is my problem. My last example, the 2 styles are inconsistent. So when the guideline is "all that matters in consistency" then I take that at face value. You though apparently pull back and believe something more messy. Effectively "All that really matters is a consistently applied style even if that style itself is full of inconsistency"

The same applies to the trailing commas. With them, every line is consistent. Without, the last line is inconsistent with the other lines. So are we applying this rule "All that really matters is consistency" or only applying it sometimes? I would argue whatever heuristic made you say "All that really matters is consistency" should apply to both cases. Consistently apply a style guide and, the style guide itself should be consistent.

	▲	godshatter 2 days ago \| parent [-]
		> Without, the last line is inconsistent with the other lines. The last line without a comma imparts the information that this line is expected to be the last line in the list which is something you don't get from it with that trailing comma. It's a small thing, but I don't like putting in that last comma because I'm effectively misrepresenting things for "syntactic sugar".

▲ ParetoOptimal 3 days ago | parent | prev | next [-]

> All that really matters is consistency. Let a team make some decisions and then just move forward.

Not so! Amount of tokens correlates to perceived code complexity to some. One example is how some people can't unsee or look past lisps parenthesis.

Another example is how some people get used to longDescriptiveVariableNames but others find that overwhelming (me for instance) when you have something like:

    userSignup = do
        let fullName = userFirstNameInput + userLastNameInput
            userName = take 1 userFirstNameInput + take 10 userLastNameInput
        saveToDB userName

Above isn't bad, but imagine variables named that verbosely used over and over, esp in same line.

Compare it to:

    userSignup = do
        let fullName = firstName + lastName
            userName = take 1 firstName + take 10 lastName
        saveToDB userName

The second example loses some information, but I'd argue it doesn't matter too much given the context one would typically have in a function named `userSignup`.

I've had codebases where consistency required naming all variables like `firstNameInputField` rather than just `firstName` and it made functions unreadable because it made the unimportant parts seem more important than they were simply by taking up more space.

▲ parthdesai 3 days ago | parent | prev [-]

It's one of my pet peeves when some senior engineers are bothered more by these coding semantics in a PR when there are bigger data model/code architectural issues, and don't call that out.