5 ms·

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

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.

granshaw 6y ago
Yes my example was if updateDate literally just updates the date - I take this a step further too, Eg if the function has some extra checks, I’ll name it maybeDoX(), which is a somewhat uncommon practice in common programming languages
- deleted 6y ago
  [deleted]
hanniabu 6y ago
Personally I would have both and within the handleClick() function do whatever it needs to do and call an atomic updateDate() function (assuming it's updating the date globally). Although for anything generalized standalone function I like to put that in its own namespace, such as helper.updateDate().
- dapids 6y ago
  Or be explicit. Call it AtomicUpdateDate if such functionality is really desired. Nobody should assume any operation is atomic ... Unless it is explicitly stated to be so. EDIT: sorry meant to reply to the parent comment.
jbluepolarbear 6y ago
I take this approach as well; especially, when the handle takes an event param and can then let the object react with the correct behaviour.
city41 6y ago
I agree. It's also nice to know when you see a `handle` function, it is getting slotted into an `on` somewhere. Within the handle I prefer to call functions such as updateDate(). But this whole thread brings up something about coding that has always irked me, it's very opinion based. When two people strongly hold the opposite opinions on the same team, it can be a massive hassle for absolutely zero benefit.
- hinkley 6y ago
  It also quickly explains to you that no, you can’t refactor this method to change the arguments.
- DrSiemer 6y ago
  In training interns I had to figure out what part of my coding advice to them is best practice and what part is just the way I like to do things. It's good to know the difference and it gave them the space to challenge me on some of those methods, which in turn helped me write better code.
- nitrogen 6y ago
  When two people strongly hold the opposite opinions on the same team, it can be a massive hassle for absolutely zero benefit. On teams, or in life in general, IMO when there is no consensus, or even an anti-consensus, the only rational global decision is not to make a global decision.
  - kuang_eleven 6y ago
    I cannot disagree strongly enough, this is how you end up working on teams that are just disconnected, hostile fiefdoms. Solving an issue that is intractable via discussion is when you escalate. Probably to a tech lead, or even to a manager.
    - nitrogen 6y ago
      Maybe we're talking about different kinds of issues. In the context of opinion-based disagreements (rather than matters of fact or evidence), an anti-consensus seems to indicate that there isn't (and can't be) one right answer. If one group imposes its will on another group, or appeals to the powers that be to do so on their behalf, the second group will definitely become hostile to the first. Thus, anything other than "agreeing to disagree" and moving on to areas where you do agree would just build more resentful, disconnected hostility.
TechBro8615 6y ago
> may have some internal checks that could eventually call something like updateDate This sounds like exactly the kind of pre-mature optimization that leads to overly-abstract function names throughout the codebase. Your point is a good one, once the function does something more than `updateDate()`. But until then, just call it `updateDate()`. As a bonus, this way any time you do choose to use `handleClick()`, the name is conspicuous enough that you pause to see what side effects it might have.
- 3grdlurker 6y ago
  It’s not premature optimization, it’s just boilerplate because it’s a pattern that happens so often. Besides, there’ll be less work if the requirements do in fact change, and there’s nothing wrong with accounting for the possibility of change when you’re writing code because what you write now constrains what you can write in the future.
throwawayboise 6y ago
validateAndUpdateDate()

granshaw 6y ago

Yes my example was if updateDate literally just updates the date - I take this a step further too, Eg if the function has some extra checks, I’ll name it maybeDoX(), which is a somewhat uncommon practice in common programming languages

deleted 6y ago
[deleted]

hanniabu 6y ago

Personally I would have both and within the handleClick() function do whatever it needs to do and call an atomic updateDate() function (assuming it's updating the date globally). Although for anything generalized standalone function I like to put that in its own namespace, such as helper.updateDate().

dapids 6y ago
Or be explicit. Call it AtomicUpdateDate if such functionality is really desired. Nobody should assume any operation is atomic ... Unless it is explicitly stated to be so. EDIT: sorry meant to reply to the parent comment.

jbluepolarbear 6y ago

I take this approach as well; especially, when the handle takes an event param and can then let the object react with the correct behaviour.

city41 6y ago

I agree. It's also nice to know when you see a `handle` function, it is getting slotted into an `on` somewhere. Within the handle I prefer to call functions such as updateDate(). But this whole thread brings up something about coding that has always irked me, it's very opinion based. When two people strongly hold the opposite opinions on the same team, it can be a massive hassle for absolutely zero benefit.

hinkley 6y ago
It also quickly explains to you that no, you can’t refactor this method to change the arguments.
DrSiemer 6y ago
In training interns I had to figure out what part of my coding advice to them is best practice and what part is just the way I like to do things. It's good to know the difference and it gave them the space to challenge me on some of those methods, which in turn helped me write better code.
nitrogen 6y ago
When two people strongly hold the opposite opinions on the same team, it can be a massive hassle for absolutely zero benefit. On teams, or in life in general, IMO when there is no consensus, or even an anti-consensus, the only rational global decision is not to make a global decision.
- kuang_eleven 6y ago
  I cannot disagree strongly enough, this is how you end up working on teams that are just disconnected, hostile fiefdoms. Solving an issue that is intractable via discussion is when you escalate. Probably to a tech lead, or even to a manager.
  - nitrogen 6y ago
    Maybe we're talking about different kinds of issues. In the context of opinion-based disagreements (rather than matters of fact or evidence), an anti-consensus seems to indicate that there isn't (and can't be) one right answer. If one group imposes its will on another group, or appeals to the powers that be to do so on their behalf, the second group will definitely become hostile to the first. Thus, anything other than "agreeing to disagree" and moving on to areas where you do agree would just build more resentful, disconnected hostility.

TechBro8615 6y ago

> may have some internal checks that could eventually call something like updateDate This sounds like exactly the kind of pre-mature optimization that leads to overly-abstract function names throughout the codebase. Your point is a good one, once the function does something more than `updateDate()`. But until then, just call it `updateDate()`. As a bonus, this way any time you do choose to use `handleClick()`, the name is conspicuous enough that you pause to see what side effects it might have.

3grdlurker 6y ago
It’s not premature optimization, it’s just boilerplate because it’s a pattern that happens so often. Besides, there’ll be less work if the requirements do in fact change, and there’s nothing wrong with accounting for the possibility of change when you’re writing code because what you write now constrains what you can write in the future.

throwawayboise 6y ago

validateAndUpdateDate()