Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
no-simple-event-func-name should have an exception of ERC20 token
See original GitHub issueERC 20 is a standard. Unfortunately, they named their Transfer event the same as their transfer function.
You’re correct in marking this as a warning if no-simple-event-func-name is being checked, but I think it’s a bad idea to do so.
A nieve programmer may change that event name to something else, only to silence the linter, but this will make the token contract non-compliant. In order to remove the warning, the programmer must create an incompatible client.
I would make an exception and not report a warning if the smart contract is an ERC20 token (which may be impossible, but in that case simply don’t warn for the Transfer(address indexed, address indexed, uint256) event.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:2
- Comments:8 (5 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
I ended up disabling this rule globally: I find that forcing events to use CamelCase and functions to use mixedCase is enough to differentiate them.
hey @mswezey23 thanks for the feedback. I really like the idea of checking if a given code is ERCXYZ compliant, looks to me that it’s worth researching into it. First thing that comes to my mind is checking that it matches proposed interface. Do you think there may be other stuff to check/validate?