Software development topics I've changed my mind on

The solution is to have computers enforce the code style. Pick a linter, pick a set of rules, and then forget about them.

Things I beleive:

- If you're picking up on code-style in PRs then your toolchain is backward.

- If you're changing linting rules every month then you're focussed on the wrong things

- It's better to have a consistent style than a perfect style

This is what we did with clang-format on our code base.

The result is occasionally ugly code and nobody is 100% happy but at least it's consistent.

Yes. I love how gofmt has no settings, basically. Is this how you envisioned? Great. Now I don't have to think about optimizing it.

Coincidentally, the choices they made are the choices I'd made, but it doesn't matter in the end.

IMO, gofmt doesn't go far enough. It should sort imports and break lines automatically, or you end up with different people with slightly different preferences for breaking up lines, leading to an inconsistent style.

Something like gofumpt + golines + goimports makes more sense to me, but I'm used to ruff in Python (previous black + isort) and rustfmt.

I'd say that if you're manually formatting stuff with line breaks and spaces, that should have been automated by tooling. And that tooling should run both as a pre-commit hook and in CI.

Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.[1]

[1] https://go-proverbs.github.io/

gofmt sorts imports within the block they are in.

I have a habit of putting stdlib imports, a line break, golang experimental (x) imports, a line break and external imports.

I just tested, gofmt orders imports within these blocks. If I won't use the line breaks, it'll consider it a single block and will globally sort.

golang also aligns variable spacing and inline comments to look them as unified blocks (or a table if you prefer the term) and handles indents. The only thing it doesn't do is breaking lines, which I think acceptable.

While Python has some great linters, I don't know of any in C that can correctly and automatically enforce some coding style. Most of them can only indent correctly, but they can't break up long lines over multiple lines, format array literals, or strings. Few or none knows how to deal with names or preprocessor macros.

clang-format and clang-tidy are both excellent for C and C++ (and protobuf, if your group uses it). Since they are based on the clang front-end, they naturally have full support for both languages and all of their complexity.

Be careful what you wish for. Sometimes leaving a line stupidly long is better for readability than awkwardly trying to break it up.

If you have five similar statements somewhere with only one exceeding the linter's line length, breaking up that one can lead to code that is harder to parse than just leaving it jutting out by way of an exception to the general rule; especially if it contains some predictable bit of code.

Agreed.

A healthy toolchain lets a developer separate the Craft from the minutiae.

*cough*clang-format off*cough*

Those would be edge cases where formatting can be turned off if needed. This would require justification during code review. Otherwise, we'd keep the automatic format, with a strong tendency towards the latter.

The general benefit of automated formatting outweighs these edge cases.

I meant that you could do this with isort in Python or rustfmt with `group_imports = StdExternalCrate` (sadly, not the default), where the imports are automatically separated into blocks, which is basically what you seem to be doing manually.

My point is that many things we end up doing manually can be automated, so I don't need to care about unsorted or unused imports at all and can rely on them to be fixed without my input, and I don't have to worry about a colleague forgetting to it either.

100%. Enforcing lint rules is very important. What those lint rules should say is generally very unimportant because the editor should be doing all the work, and most of the time "that's just like, your opinion, man".

While everyone has a favorite ES Lint ruleset but few agree on which to use.

Agreed. I don't care what the indentation is or formatting is, as long as it's consistent.

Ha, yes. I started doing that but then lost the will to continue.

Vehemently disagree. I get that go's conventions line up with your own, but when they don't, it's irritating. For example, Dart is finally coming around on the "tall" style (https://github.com/dart-lang/dart_style/issues/1253). But why should people be forced to wait for a committee (or some other lofty institution) to change a style convention that then effects everyone using the language? What's the harm in letting people write their code in the "tall" style beforehand? Why must the formatter be so insistent about it?

> Why must the formatter be so insistent about it?

Exactly to avoid conversations like this...If you want a tall format then just add a dummy comment at the end?

Except that a prescriptive formatter with zero configurability is causing this conversation.

I didn't know that so many people did that so formatters have an option for this. On the other hand, I'm doing this for so long across so many languages, I never thought about it. It consumes no effort on my part.

Also, gofmt not removing the breaking lines and handling groups inside themselves tell me that gofmt is aware of these choices already and accommodates this without being fussy or needing configuration about it, and it's an elegant approach.

When you are a solo dev, everything is acceptable. When you're in a group, this can cause friction and cause real problems if people are "so insistent" about their style.

Go is a programming language developed for teams. From its syntax to core library to language server to tooling, Go is made for teams, and to minimize thinking. It's opposite of Rust. It's devilishly simple, so you can't make mistakes most of the time.

Even the logo's expression is an homage to this.

So yes, Go's formatter should be this prescriptive. The other thing is, you can continue this conversation till the end of time, but you can't argue with the formatter. It'll always do its thing.

In other words, "computer says no".

You are misunderstanding the argument: I am not against prescriptive formatters. By all means, enforce a style convention for your project, I have nothing against that, nor do I understand how you interpreted that from my comment. I am against prescriptive formatters that cannot be configured. This creates the absurd situation, as previously described, where one must appeal to 'The Committee' who decides the style convention for the entire world. This should not be necessary. Nor should you have to surround your code with formatter-disabling comments (assuming the language even supports that) to, for example, use the "tall" style, as previously mentioned. Nor should you have to literally fork the language or its tools to disable the formatter.

I sometimes care when I want to introduce empty space to visually make parts of code stand out, eg multiple blank lines between functions or classes etc. I think whitespace can be effectively used like paragraphs in a book, basically make different blocks more obvious. Most formatters just squash everything to be one empty line apart, for me it can be annoying.

in my experience half the people don't bother installing the tools. They just don't care about formatting/linting, at all.

Just don’t make it optional.

Completely agree on all points. I used to have a style that I preferred and really wanted to use everywhere but nowadays I just throw prettier at it and take the defaults for the most part. I’ll take consistent code over mixed styles every day.

I know this sounds insane, but I used to work on some big svn codebase with many developers, without any fancy formating tools AND no one cared about consistent style.

One interesting thing that happened was the ability to guess who wrote what code purely based on coding style.

This happens to some degree in linted code bases since there’s more than one way to write the same code, and people reach for what they like

If something can be configured, this opens up infinite possibilities for discussions on how it should be configured. The fact that you even ASK if you should use the tall style means that you are considering the POSSIBILITY of using it that way.

Put it this way, if it is technically impossible to develop a car that have the color red, we would not be discussing or entertaining what color the next car should have. It would be red, end of story. It doesn't matter if we like red or not, it just has to be. end of story.

Yes, the code looks awful. end of story.

Hot take: stop being authoritarian with code styles, perchance? You are not so wise as to determine what is clean code for the entire world, and the ego required to believe that you are is beyond astounding. And we're still having these discussions despite unconfigurably prescriptive formatters. This idea that such formatters end these discussions is just demonstrably false... you are literally taking part in one of these discussions.

The point is, that the way it's formatted doesn't matter. It just matters that it's consistent. Consistency is better than being right.

As I've said, it's fine for people, projects, and organisations to require and enforce a particular style for their code, to demand consistency for their code. The problem comes when people with inflated egos believe they have the right to dictate how the entire world writes their code. I feel like I need to stress that this is the issue here.

The fact that Dart's formatter FAQ tells developers who are unhappy with the output to change their code to satisfy the formatter (https://github.com/dart-lang/dart_style/wiki/FAQ#i-dont-like...), rather than allowing developers to tweak the formatter to satisfy their code, is such a huge tell about their mindset. And again, these global styles do not "end the discussion" as people in this thread have asserted. The "tall style" PR (https://github.com/dart-lang/dart_style/issues/1253) refutes that. And that PR has since devolved into bickering and heated demands since its adoption into SDK 3.7.0, since it transforms people's code in ways they dislike and/or find less readable.

Just let people, projects, and organisations enforce their own styles conventions. It's not hard and it shouldn't be controversial.