61–70 of 157 posts
Naming things - one of the four hardest problems in computing (the others are sorting and off-by-one errors) :)
Perhaps there is an answer lurking out there in the universe, but it feels more likely it'll only be invalid pointer Aborted (core dumped)
I thought you just added "ly" and called it a day?
But don't know what anything does.
How do you name things so they're obvious to the eye?
Descriptively,
descriptively,
descriptive... L-Y!
I've seen way too many times how much confusion is created and time wasted when a developer not too familiar with the project comes up with a brand new verb for a common action, and couples it with a new synonym for an existing business domain entity – or worse still, uses the same name previously meant for a completely different domain entity.
The unfortunate burden with this is that a new developer might be right that their name is better for their use case, which then leads to laboursome debates about which is more important: consistency or slightly crisper name for the one use case.
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)
Also when you are reading the reverse, it’s not clear on what on what updates date. The worst scenario is when two listeners share a handler.
> getInstances(); // ok, returns an array of instances
> getInstanceId(); // ok, returns an id
> getInstancesId(); // ??, returns an array of id
> get InstancesIds(); // ?? returns an array of id
> getIdsOfInstances(); // ?? returns an array of id
> getAllInstancesId(); // ?? returns an array of id
> getAllInstancesIds(); // ?? returns an array of id
How do I conjugate that ? And what about the possessive `s` ?
As a non native english speaker I have a recurring problem with this: > getInstances(); // ok, returns an array of instances > getInstanceId(); // ok, returns an id > getInstancesId(); // ??, returns an array of id > get InstancesIds(); // ?? returns an array of id > getIdsOfInstances(); // ?? returns an array of id > getAllInstancesId(); // ?? returns an array of id > getAllInstancesIds(); // ?? returns an array 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)
updateDateCallback()
updateDateFromClick()
These show how it's used and what it's doing.
(actually, "up-date date" kind of irks me,)
handleDateChangeClick()
dateChangeModalClickEvent()
And what does this thing actually do? Is it updating data, or making the update UI visible? It's kind of unclear.
If you're showing/hiding UI rather than performing the model update,
showChangeDate[Field/Modal/...]()
beginChangeDateFlow()
...
Code should read kind of like a book.
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 completely disagree with this example. Only in first order implementations does that click just change the date. As you refine UX you may add some debounce, error handling, alternative behavior, etc. DOM events rarely end up corresponding to such simply expressed handlers. Also when you are reading the reverse, it’s not clear on what on what updates date. The worst scenario is when two listeners share a handler.