3 ms·
> There’s a lint rule about naming the error parameter in catch “error”, not “err” or “e”. Who cares about this shit??? That is certainly in the less important
by s4i 4y ago
> There’s a lint rule about naming the error parameter in catch “error”, not “err” or “e”. Who cares about this shit???
That is certainly in the less important end of the linting rules spectrum. Nonetheless, conventions like these add up in larger codebases in my experience. The more consistency you have with things that repeat a lot across the code improve readability quite much because the brain is able to do more chunking over time.
Of course this doesn't matter that much when you are learning a language or a framework and only have a couple of files.
- hardwaregeek 4y agoI’ve cited the same concept of consistency, and I still believe it to an extent. But I do feel like it’s folk wisdom to an extent and not necessarily backed up by evidence. Like is e vs err vs error so egregious that it really adds to mental overhead? And sometimes there are explicit reasons to not do certain “best practices”. There was that whole era of making functions as small as possible, which of course meant you needed to jump to five function definitions to get even the slightest idea of what was happening. Or when everybody insisted on const and arrow functions for everything. As well intentioned as these ideas are, they fall victim to trends and overzealous application. Any piece of advice has a trade-off and a situation where it does not apply. Therefore it’s important to remember that these ideas are fundamentally subjective guesses at how to write good code. Not gospel truth. Of course that isn’t to say linters are bad. Just that lint rule authors should be very careful to check that they are actually writing rules of value and not just nit picky folk wisdom.