Let's start simple. You have a method that, sometimes, when called with certain arguments or at certain times it might fail. How do we tell that to the user? What about to the programmer using that method?
Here are 4 guidelines that will help your team validate data in a consistent manner without running into some trivial issues:
- Treat validation errors first
This ties in with the other article I posted:
- Do not let your methods fail silently
This is when you don't let the caller of your method know if the method failed and did absolutely nothing.
- Return a proper error
Return 0 when your method fails and it is called getIndexOf... is a really bad idea.
- Do not validate for developer errors
Validating if your constants are actually defined (in an interpreted environment) using if statements is simply a waste of time and these problems should be solved and not validated.
The caller nor the user can help you solve this issue.
These are simple rules, but they can affect your project in the long run if you don't apply them from the start. Check out this video I created explaining more in-depth about this subject:
What do you think? Was this better presented than the post before, or was it worse? Did you get something out of this?
Also, for the guys (or gals) that previously suggested to add more content on the article itself, is this good enough? I have also posted on my blog but the content is quite large and wouldn't really fit in here that well.
Top comments (0)