Now, the last rule is more prevalent to interpreted languages than compiled ones but here it is:

3) Do not validate for developer errors

This rule is simple. If the user has absolutely nothing to do with the current data then don't validate for it. Here is a very simple example:

function getIdeas() { let url = constants.getAllIdeasUrl; if (!url) { console.error('Url for getting all ideas is missing'); return; } return fetch(url, { method: 'GET' }).then((res) => res.json()); }

Let's assume constants is a variable created by us for the sole reason to keep constant values in it. So then, why would getting a constant fail?

The answer: the programmer failed to declare it.

But what happens if we don't declare the variable and don't check if it exists? We get an error of the sorts:

The last line is key here. It gives us the exact file and line of code we have to check to fix the issue and it is one of the best ways an application could fail. Furthermore, once the issue is resolved, the if statement has no meaning and does absolutely nothing.

In a compiled language this would simply be a compiler error but, in some cases (like when using Reflection) this could also happen and we shouldn't normally validate it.

The core conclusion of this series is: You should always think of the ones using your code Everything we talked will influence your team as a whole so treat your team well using good code practices and, who knows, maybe next time you are trying to use methods they have nicely organized validations that you can check for.

We hope this was helpful! Let us know in the comments down below!