Oh, naming. Naming is difficult. (There's for sure some xkcd strip for this, too lazy to find it)
I'm in no position to say what's good practice.
Coming from Python and recently heavily influenced by Ruby, I try to ask what reads well - what makes understanding what's happening easiest (with minimum cognition) a fastest.
But that depends on how I think vs how others think, on rest of code (consistency can be make good name not that good), and code context.
In case you show here, I would heavily incline to Element event.
On Example 2, I read onProductCreated as there was created product in database/somewhere, which may be misleading. onProductCreateButtonClick describes what really happened.
Same in first example - submitting form doesn't mean user was registered - backend form verification could stop registration, there could be some reason user wasn't really created in database. But we know that form was submitted.
That's what exact I mean. UI event handler name should NOT be equal with the method name of the service layer. Event handlers should clearly represent elements and their events. Consider that there are multiple forms on the page, they all have submit event handlers. onFormASubmit and onFormBSubmit are clear. We should distinguish UI events and service method names. If this file has a 1000-line code, we don't have to scroll or copy the search, you can know which form of this is the submission event.
Oh, naming. Naming is difficult. (There's for sure some xkcd strip for this, too lazy to find it)
I'm in no position to say what's good practice.
Coming from Python and recently heavily influenced by Ruby, I try to ask
what reads well
- what makes understanding what's happening easiest (with minimum cognition) a fastest.But that depends on how I think vs how others think, on rest of code (consistency can be make good name not that good), and code context.
In case you show here, I would heavily incline to
Element event
.On Example 2, I read
onProductCreated
asthere was created product in database/somewhere
, which may be misleading.onProductCreateButtonClick
describes what really happened.Same in first example - submitting form doesn't mean user was registered - backend form verification could stop registration, there could be some reason user wasn't really created in database. But we know that form was submitted.
Hope this helps.
That's what exact I mean. UI event handler name should NOT be equal with the method name of the service layer. Event handlers should clearly represent elements and their events. Consider that there are multiple forms on the page, they all have submit event handlers.
onFormASubmit
andonFormBSubmit
are clear. We should distinguish UI events and service method names. If this file has a 1000-line code, we don't have to scroll or copy the search, you can know which form of this is the submission event.If this file has 1000 lines, we should split the file :D