Callback naming consistency
See original GitHub issueFollowing up on @vitaly-krugl’s comment, we’re going to use the on_
prefix with an action verb for all callback parameter names.
Issue Analytics
- State:
- Created 6 years ago
- Comments:6 (6 by maintainers)
Top Results From Across the Web
Handy Naming Conventions for Event Handler Functions ...
Tying it all together. Following these simple naming conventions provide your code predictability and consistency. By implementing these naming conventions, ...
Read more >Nested Callback arguments and naming conventions
I have a piece of code that has nested call backs. Each callback has a response. One is name res and one is...
Read more >Inconsistent naming convention for callback props #14406
Name things consistently when developing components. Naming should be consistent, so that it's clear to third-party developers which one is ...
Read more >Simple Naming Tips for Event Handlers | by Vlad Sabev
1. Event names should answer the question when, because they're on the left side and describe the conditions under which events trigger. 2....
Read more >Naming (in code) - The ultimate guide and reference
This article is the complete guide and reference for naming in code. ... Programming principles tell us that consistency is very important.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@lukebakken, regarding documentation comment in https://github.com/pika/pika/issues/988#issuecomment-370978795, I was hoping to get the apps away from accessing the connection’s internal ioloop, which is often an adapter on top of the native I/O loop. I would not want them to depend on any connection.ioloop API (that’s should really be just for the benefit of adapter implementations), calling it’s start method, etc. (it shouldn’t be even providing a
start()
method). Instead, apps should be interacting with the native I/O loop directly - calling the native loop’sstart()
,run_forever()
, etc.I started going on this path in my WIP PR https://github.com/pika/pika/pull/982.
Making the callback names more descriptive would help with making the API more self-documenting. But things are not bad now, so I’m not certain it’s worth the extra effort. I’m okay to keep as they are.