Re: So You Think You Can Const?

On 10/01/2025 03:51, Julio Di Egidio wrote:

On 10/01/2025 03:14, Julio Di Egidio wrote:

On 10/01/2025 02:43, Tim Rentsch wrote:

Julio Di Egidio <julio@diegidio.name> writes:

On 10/01/2025 00:37, Julio Di Egidio wrote:

On 10/01/2025 00:23, Ben Bacarisse wrote:

Julio Di Egidio <julio@diegidio.name> writes:

On 09/01/2025 02:09, Ben Bacarisse wrote:

Julio Di Egidio <julio@diegidio.name> writes:
>

static AvlTree_t const *AvlTree_node(
  void const *pk, AvlTree_t const *pL, AvlTree_t const *pR
) {
  AvlTree_t *pT;
>
  pT = malloc(sizeof(AvlTree_t));
>
  if (!pT) {
  return NULL;
  }
>
  pT->pk = pk;
  pT->pL = pL;
  pT->pR = pR;
>
  return pT;
}

>
Just on a side issue, I prefer to make tests like this positive
so I'd write:
  static AvlTree_t const *AvlTree_node(
  void const *pk, AvlTree_t const *pL, AvlTree_t const *pR
  ) {
  AvlTree_t *pT = malloc(*pT);
  if (pT) {
  pT->pk = pk;
  pT->pL = pL;
  pT->pR = pR;
  }
  return pT;
  }
I'm not going to "make a case" for this (though I will if you
want!) -- I just think it helps to see lots of different styles.

>
That is *more* error prone,

>
I would be happy for you to expand on why you say that.
>

all the more so if it's not a 5 liner...

>
There is no such thing as expanding 40 years of professional
experience in software engineering and programming and doing it
properly since day one:  just think about that code and what I said
for what it's worth, in particular I haven't mentioned 5 liners by
chance, things are quite more complicated not in vitro.
>
And please do not hold a grudge about that:  it's not me who was
trying to say how to write code... ;)

>
BTW, I hadn't mention it, but have you noticed the second one is
misindented?  Between me and you, I can tell how long a piece of
code will take to break when in production by just looking at
it...  A lot of fun.  :)

>
The indentation was correct in Ben's original posting.
>
The misindentation first appeared in your followup to that
posting, where the quoted portion had been changed to remove a
blank line and over-indent the if().

>
But indeed the point is what happens in the long run: if you look above mine is still better indented... :)  But of course it is not indentation per se the problem: for example check the return value as soon as the function returns a possibly null pointer or an error value is certainly more widely applicable, and quite less error prone, especially if it's

 I meant: immediately check the return value and bail out if needed.  The other approach does not even simplify on the clean-up, by the way...
 

not a 5 liner...  Anyway, I also truly believe there is no point in belabouring the point: it's the overall picture that one must get to see.

A last one for the more theoretically inclined: every "if" is a code path, but not all code paths are "if"s...
Cheers,
-Julio