31–40 of 157 posts
Earlier quoted context omitted.
I'd argue that the ability to unite people by assigning meaning onto things, places, and ideas is the single reason why humans have been so successful in advancing civilization to where it is today. Edit: eschew -> assign
Pedant note: eschew means ‘to go without’. You probably meant ‘assigning’.
One of the most cruel things evolution did to us is that we constantly seek meaning, order, correctness, where there are none to speak of.
I have a rule called “name it what it does, not how it’s used” which is a mistake I often see with junior developers and sacrifices information density Eg it’s more helpful for readability to do “onClick => updateDate()” rather than “onClick => handleClick()” (Not the best example and I’ve seen far more egregious, but those examples are escaping me now)
I’d agree in some cases, but then you get weird debouncing code in your update date function. Because, no one wanted to change the onClick function name in 38 different places when it starts to do more.
I have a rule called “name it what it does, not how it’s used” which is a mistake I often see with junior developers and sacrifices information density Eg it’s more helpful for readability to do “onClick => updateDate()” rather than “onClick => handleClick()” (Not the best example and I’ve seen far more egregious, but those examples are escaping me now)
I have a rule called “name it what it does, not how it’s used” which is a mistake I often see with junior developers and sacrifices information density Eg it’s more helpful for readability to do “onClick => updateDate()” rather than “onClick => handleClick()” (Not the best example and I’ve seen far more egregious, but those examples are escaping me now)
I’m an engineering lead and I made a rule of using the handleClick() style instead of updateDate() in our codebase. The reasoning is that the latter sounds more like an atomic, standalone function, whereas handleClick() may have some internal checks that could eventually call something like updateDate(), but the internal checks are beyond the responsibility of the updateDate() function.
I have a rule called “name it what it does, not how it’s used” which is a mistake I often see with junior developers and sacrifices information density Eg it’s more helpful for readability to do “onClick => updateDate()” rather than “onClick => handleClick()” (Not the best example and I’ve seen far more egregious, but those examples are escaping me now)
I’d agree in some cases, but then you get weird debouncing code in your update date function. Because, no one wanted to change the onClick function name in 38 different places when it starts to do more.
The downside is lots of little functions, the plus side is smaller behaviors. (Ie avoiding 5 levels of nesting in a single function.)
I would be interested if any task-performance based studies had been run with different naming schemes and enough developers to see which naming conventions worked best. Some simple job like fixing a bug or a simple refactoring, judged on time to completion and correctness.
Earlier quoted context omitted.
I'd argue that the ability to unite people by assigning meaning onto things, places, and ideas is the single reason why humans have been so successful in advancing civilization to where it is today. Edit: eschew -> assign
That's precisely the problem. It's very useful, when it's useful. Which leaves us spinning in circles when it's not.
Variable names are alright, available domain names are a different beast
Earlier quoted context omitted.
I’d agree in some cases, but then you get weird debouncing code in your update date function. Because, no one wanted to change the onClick function name in 38 different places when it starts to do more.
If you don't have refactoring that can rename functions across your code base, now you have two problems