[why-oh-why]

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.

[austincheney]

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.

[why-oh-why]

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

[austincheney]

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?

[why-oh-why]

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