Comment by austincheney | Hacker News Reader

Comment by austincheney | Hacker News Reader

Parent Full thread

For me, as a developer who maintains open source software, the best feedback has nothing to do with the code. Honestly, nobody cares. The application does what it claims or it doesn't. People who spend all their energy on code style have clearly, in my opinion, never had the experience of directly interfacing with their users. Here is my checklist of competence:

* defects - The application has certain defects or it doesn't and you can prove it with tests. If there is a defect I will prioritize it, or solve it immediately, or mark it as won't fix.

* performance - Does the application execute fast enough in all stages and interactions? This is a simple yes or no, but performance testing is often volatile so this needs to be tested and measured as well so that it can be observed over time keeping slippage in mind.

* ease of use - Does the application work out of the box? If not its broken. If it requires a bunch of manual configuration then nobody will use unless its forced on them. For this I take all my frustrations with corporate software from my past jobs and I intentionally design against that when I write software and encourage my users to complain to me.

* documentation - Does the documentation stand on its own? Is it complete, well organized, and simple enough that a high school freshman can read it? If you cannot write you aren't as great a developer as you think you are.

If your code has 20 if else in a row I don’t care if it’s performant and has no bugs, you’ll get a change request because I don’t want to maintain that pile of garbage.

There are minor code style preferences and others that affect maintainability. Just because it works now it doesn’t mean the code is done.

Yes, there are conventions that are generally harmful to code maintenance. For these things the preferred approach is screening via some sort of automated gatekeeper whether its unit tests, code beautification, better custom types, code validation, or something else. If a developer isn't willing to do the work to automate these subjective concerns then their complaints really need to be something measurable. Everything else isn't worth the energy when instead you could be productively writing the next hot feature.

Some bad code is hard to lint automatically (e.g. if there’s a single function that all it does is arg.slice(1), no linter will catch that).

I’ve found all kind of bugs just refactoring code because poor code obfuscates them.

Your way of building things will lead to debt and bug reports

How that code example a style violation? I am not even sure how it's bad code. In JavaScript that would just return a value without the first index. What code style rule would solve for that in a meaningful way that you are willing to enforce uniformly on all concerns?

It is because if a file is made of a hundred 1-line functions that’s not good code. The separation of concerns is likely not meaningful and it’s detrimental to the reading/understanding of the file.

Why create a function that shortens/clarifies nothing and is used once? If you want to explain some code, use a comment, don’t make spaghetti

> Honestly, nobody cares

Other programmers care. A one/two man workshop doesn't need order or processes to get things done. A ten man workshop cannot function without it. The same is true with coding - it becomes a tool for programmers to communicate intent, it's becomes important to be ordered, clean and understandable by every other dev.

The end users of my open source software are all developers and they never complained about the code style. Not once. My largest application lived for 10 years and was used by hundreds of thousands of people.

> it's becomes important to be ordered, clean and understandable by every other dev

Code style is the wrong tool for that job. Better are code reviews and written documentation.

Reply on news.ycombinator.com