Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #388115

Re: Code guidelines

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.lang.c
Subject Re: Code guidelines
Date 2024-09-03 16:53 +0200
Organization A noiseless patient Spider
Message-ID <vb77tn$3bu07$3@dont-email.me> (permalink)
References <vb6v1t$3b5mb$1@dont-email.me> <vb726n$3b4rq$1@dont-email.me> <vb736j$3b5mb$2@dont-email.me> <vb75g9$3bntp$1@dont-email.me>

Show all headers | View raw


On 03/09/2024 16:12, Thiago Adams wrote:
> On 03/09/2024 10:33, Thiago Adams wrote:
> ...
>> For instance:
>>
>> The first sample my create confusion (is name optional?)
>>
>> void f(struct user* user)
>> {
>>       if (user->name && strcmp(user->name, "john") == 0)
>>       {
>>          //...
>>       }
>>   }
>>
>> But :
>> void f(struct user* user)
>> {
>>       assert(user->name);
>>       if (user->name && strcmp(user->name, "john") == 0)
>>       {
>>          //...
>>       }
>>   }
>>
>> would show redundancy but making clear the contract still "name should 
>> not be null"
> 
> Redundant code can either indicate a programmer's mental confusion 

Yes.

> or 
> serve as a way to address potential contract violations.

No.

If specification violations are realistic (from untrusted code, or code 
under development), then a /single/ check looks for violations. 
/Redundant/ checks are pointless at best, and (as I have explained) 
often worse than useless.

Computers are not humans that might miss something on the first glance, 
then see it on the second time.  Do the same check twice in the code and 
you will get the same answer each time - the second check gives no benefits.

> 
> I believe the objective is to ensure that runtime checks are not 
> questioning the contract but rather functioning as redundant safeguards.
> 
> In other words, the programmer must demonstrate that they understand the 
> contract and are not messing it.
> 
> 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.

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Code guidelines Thiago Adams <thiago.adams@gmail.com> - 2024-09-03 09:22 -0300
  Re: Code guidelines David Brown <david.brown@hesbynett.no> - 2024-09-03 15:16 +0200
    Re: Code guidelines Thiago Adams <thiago.adams@gmail.com> - 2024-09-03 10:33 -0300
      Re: Code guidelines David Brown <david.brown@hesbynett.no> - 2024-09-03 16:10 +0200
        Re: Code guidelines Thiago Adams <thiago.adams@gmail.com> - 2024-09-03 11:37 -0300
          Re: Code guidelines David Brown <david.brown@hesbynett.no> - 2024-09-03 16:49 +0200
          Re: Code guidelines "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-03 14:39 -0700
          Re: Code guidelines Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-09-22 02:08 +0000
      Re: Code guidelines Thiago Adams <thiago.adams@gmail.com> - 2024-09-03 11:12 -0300
        Re: Code guidelines David Brown <david.brown@hesbynett.no> - 2024-09-03 16:53 +0200
          Re: Code guidelines Thiago Adams <thiago.adams@gmail.com> - 2024-09-03 13:23 -0300
            Re: Code guidelines Thiago Adams <thiago.adams@gmail.com> - 2024-09-03 13:37 -0300
              Re: Code guidelines David Brown <david.brown@hesbynett.no> - 2024-09-04 08:45 +0200
                Re: Code guidelines Thiago Adams <thiago.adams@gmail.com> - 2024-09-04 08:52 -0300
                Re: Code guidelines Thiago Adams <thiago.adams@gmail.com> - 2024-09-04 09:06 -0300
                Re: Code guidelines David Brown <david.brown@hesbynett.no> - 2024-09-04 20:14 +0200
            Re: Code guidelines David Brown <david.brown@hesbynett.no> - 2024-09-04 08:40 +0200
              Re: Code guidelines Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-04 00:22 -0700
                Re: Code guidelines David Brown <david.brown@hesbynett.no> - 2024-09-04 12:47 +0200
            Re: Code guidelines Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-04 14:02 +0000
              Re: Code guidelines David Brown <david.brown@hesbynett.no> - 2024-09-04 20:20 +0200
            Re: Code guidelines Vir Campestris <vir.campestris@invalid.invalid> - 2024-10-01 11:41 +0100
              Re: Code guidelines Kaz Kylheku <643-408-1753@kylheku.com> - 2024-10-01 21:39 +0000
  Re: Code guidelines Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-03 15:10 +0000
  Re: Code guidelines Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-09-03 21:01 +0000

csiph-web