Hacker News Reader

Comment by tantaman | Hacker News Reader

I hate all of these rants on questions of style.

The only problem of style is when there are mixed styles within the same codebase.

But on that note, every code base should have aggressive linters and auto-formatters that force everyone to use the same style. So the question is moot.

If you're working in someone else's codebase and their style is different than your preferred style, suck it up because it just doesn't matter.

--- When moving from a company that didn't have said linters and auto-formatters to one that did, all of these questions disappeared and we could focus solely on solving problems that mattered.

View on HN

100% agreed. My company recently did this to our main codebase, and it's been a joy. I can write code now, not play with formatting! I wish it had been this way since day 1.

Style should express intent. Diffs that enforce uniformity without preserving intent are vandalism that poisons “git blame”. Auto-formatting should not be used because it doesn’t understand intent in any way. (And when it does, we will no longer need formatted source files, nor developers.)

I think there actually are bad styles. The google style guide is such a bad style guide. The combination of 2 spaces indent and not putting { and } on top of each other makes it difficult to see at a glance where a block begin and ends.

I wholeheartedly disagree. Two spaces and the One True Brace style is my preferred way of working. Blocks are easy to identify based on indentation. This is exactly why auto-formatters are the best solution. Then there's no need to have this conversation. Some of the style choices we have at work are not ones I would have chosen but I'm quite comfortable with them now thanks to auto-formatting

Many projects vendor code whose styles are not compatible. For C# this is common in Unity3D development. Often external dependencies, vendored, need custom patches, future updates and are not available in VCS. Besides Git is ill-suited for vendoring.

Next you’ll say “all code should not be vendored.”

Anyway it’s interesting to disseminate opinions on style because agreement on style beyond the boundaries of a corporate engineering hierarchy is really the best route to solving style issues.

Just create a `vendor/` folder and an exclude rule to your linters. Or for Unity include your `Assets/Scripts` folder, whichever fits better.

>Besides Git is ill-suited for vendoring.

VCS is ill suited for vendoring, but is there a better option? Vendoring is usually a "hack" in some ways as you're keeping dependancies local when you don't "have to", but if your goal is to keep 'em local then git does a fine job.

I'm surprised to see push-back for this idea because I've never come across this stumbling block. Please feel free to disagree, as I feel like there might be a perspective I'm not considering or something I can learn.

This is one of the reasons I like the Nix package manager—I can use Nix to de facto vendor dependencies (at least in the sense of having a local copy where I fully control the version we're on) without the attendant Git/build tool/etc hassle.

If anything, a Nix derivation with a hash is going to be more reliable than a git commit hash even when you control the repo because it forces the build of your vendored dependency (including any transitive dependencies) to be deterministic. The downside, of course, is that it can be a lot of effort to retrofit deterministic builds on top of external codebases not built with that in mind...

I think we should encourage junior developers to be dogmatic about styling because they will want to make positive changes.

Once you get to a certain level of experience though, it should be a foregone conclusion that all code looks the same automagically.

Reply on news.ycombinator.com