Re: Code guidelines

On 03/09/2024 18:23, Thiago Adams wrote:

On 03/09/2024 11:53, David Brown wrote:

On 03/09/2024 16:12, Thiago Adams wrote:

A safeguards for a very low risk situation also may indicate a mental confusion about the risks involved. For instance, assert(2 + 2 == 4);
>

>
A redundant check is, by definition, a very low risk situation.
>

 I will give a sample
 

<snip>

but...maybe, is better to be a little redundant here?

 > I think I prefer to leave "obj->member1->member2 && " even if I know
 > it should not be null.
 >
 > if (obj->member1 &&
 >     obj->member1->member2 &&
 >     obj->member1->member2->member3)
 > {
 >
 > }
No.
Well, there might occasionally be times where a pattern in the code layout gives so much extra clarity or increases maintainability so much that the redundancy is worth it.
Instead of thinking that the risk of someone breaking the specifications is so high that it is worth putting in extra checks, deal with the /real/ problem - ask why there is that risk.  Is the person writing the rest of the code (you, or someone else) capable of the task or do they need help, guidance, extra training, etc.?  Are the specifications unclear or in an inconvenient place?  Are the specifications particularly onerous or illogical?
Before you put any check in code, think about the circumstances in which it could fail.  If there are no circumstances, it is redundant and counter-productive.  If it /could/ fail, think about /why/ it could fail - can you do something to ensure the failure will not occur?  Then fix the source of the problem, and the check is redundant.  Think about what you can do with the information about the failure - can you recover? Can you mitigate damage?  Can you at least report the issue in a useful way?  If there's nothing you can do, why check it?
This kind of obsessive "check each pointer for null before using it" is a bad habit.  It is arse-covering of the worst kind - it's about being able to claim "it's not /my/ fault the program doesn't work".  It is not a real check of pointer validity, or being sure the code works as it should - it's just a show to make it look like you take code quality seriously.  And in almost all cases, it is never tested - no one ever checks through all the combinations of possible failures, and the cyclomatic complexity of the code quickly makes such tests impractical.
Focus on how to avoid code failing to match the specifications - not on pointless redundant checks.  Get in the habit of checking for /real/ problems at run-time.  If you keep putting in these extra checks without thinking, you'll start believing your code is safe and has all the checks it needs - and miss out on the things that are important.