Hacker News Reader

Comment by theshrike79 | Hacker News Reader

And there is the problem. Then you start arguing about brace positions and function names and whether simple data classes should have docstrings on properties or not.

All that time it's people arguing with people and wasting time on pure feels. People will get offended and angry and defensive, nothing good ever comes from it.

But when you pick a style and enforce it with a tool like gofmt or black both locally and in the CI, the arguments go away. That's the style all code merged to the codebase must look like and you will deal with it like a professional.

Go proverb: "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite."

View on HN

"Style" is such a small part about what people generally care about when they talk about code quality though, useful/intuitive abstractions, the general design and more tends to be a lot more important and core to the whole code quality debate.

Linters can be set check for cyclomatic complexity, using old/inefficient styles of programming (go fix ftw) etc. Formatting is just an easy and clear example that everyone should understand.

Right, but all of those are easy, left is the actually hard stuff...

Amateurs are the one who argue about syntax.

Code quality is about how well a piece of code expresses what it intends to do. It’s like quality writing.

Syntax and style can be very important, when transferring code.

I’m generally of the opinion that LLM-supplied code is “prolix,” but works well. I don’t intend to be personally maintaining the code, and plan to have an LLM do that, so I ask the LLM to document the code, with the constraint being, that an LLM will be reading the code.

It tends to write somewhat wordy documentation, but quite human-understandable.

In fact, it does such a good job, that I plan on having an LLM rewrite a lot of my docs (and I have a lot of code documentation. My cloc says that it’s about 50/50, between code and documentation).

Personally, I wish Apple would turn an LLM loose on the header docs for their SwiftUI codebase. It would drastically improve their docs (which are clearly DocC).

[EDITED TO ADD] By the way, it warms my heart to see actual discussion threads on code Quality, on HN.

You start to care about standard syntactic rules and enforced naming conventions when you're the one waking up 4 in the morning on a Saturday to an urgent production issue and you need to fix someone else's code that's written in a completely incoherent style.

It "expresses what it intends to do" prefectly well - for the original author. Nobody else can decipher it without spending significant amounts of memory cycles.

Jack Kerouac is "quality writing" as is the Finnish national epic Kalevala.

But neither are the kind you want to read in a hurry when you need to understand something.

I want the code at work to be boring, standard and easy to understand. I can get excited by fancy expressive tricks on my own time.

What do you mean exactly? Are you the type that hates seeing comprehensions and high order functions and would rather just see long for loops and nested ifs?

> And there is the problem. Then you start arguing about brace positions and function names and whether simple data classes should have docstrings on properties or not.

In my 15 years of experience I have not worked at a place like this. Those are distractions. Anytime something about style has been brought up, the solution was to just enforce a linter/pre-commit process/blacklist for certain functions, etc. It can easily be automated. When those tools don't exist for particular ecosystems we made our own.

> And there is the problem. Then you start arguing about brace positions and function names and whether simple data classes should have docstrings on properties or not.

Holy strawman Batman!

Have you ever given a code review? These are the lowest items on the totem pole of things usually considered critical for a code review.

Here’s an example code review from this week from me to a colleague, paraphrased:

“We should consider using fewer log statements and raising more exceptions in functions like this. This condition shouldn’t happen very often, and a failure of this service is more desirable than it silently chugging along but filling STDOUT with error messages.”

So you're fine with people using, for example, different brace styles at random? Or one person uses var everywhere, other uses definite types. One adds standard docstrings on every function and property, one never comments a single line of code.

Don't you have "format on save" enabled in your editor? When you open a file, change two lines and save -> boom 500 changed lines because the previous programmer had different formatting rules than you. Whoops.

This is why the low totem pole stuff needs to be enforced automatically so that actual humans can focus on the higher stuff that's about feels and intuition - things that are highly context dependent and can't be codified into rules.

You're bikeshedding in a conversation about real issues.

After a certain point in your career you don't care what brace style the new dev used, even if the project has lint rules. You do care if critical errors are ignored and possibly incorrect data is returned. These two situations are in no way equivalent, no need to bikeshed the former when discussing the latter.

> Code quality can also be codified. If you can't express "code quality" deterministically, then it's all just feels. And if you can define "quality" in a way the agent can check against it, it will follow the instructions.

…

> This is why the low totem pole stuff needs to be enforced automatically so that actual humans can focus on the higher stuff that's about feels and intuition - things that are highly context dependent and can't be codified into rules.

I’m confused, have you switched your position on this topic over the course of this thread? Maybe I’ve misinterpreted your position entirely. If so, my bad.

Reply on news.ycombinator.com