From the D Blog: Crafting Self-Evident Code in D

[claptrap]

On Thursday, 5 October 2023 at 08:46:50 UTC, Dom DiSc wrote:
> On Thursday, 5 October 2023 at 00:53:45 UTC, claptrap wrote:
>> [...] he is has more interesting things to talk about than 
>> whether "enum { yes, no }" is a good idea or not.
>
> His point here was not that having an enum with values for yes 
> and no is a bad idea. The bad idea is assigning yes the value 0.
> That's a much more subtle point, as here nowhere 0 is written.

His point was that both are bad, but one in worse.

And lets be honest, the problem is implicit casting of enums to 
int, and then to bool. Or the conflation of enums and manifest 
constants. If he wants to argue for self evident code then maybe 
that kind of thing needs looking at. Even the UFCS chain example 
is bad. Is...

a.b.c()

actually... "c(b(a))"

or is it member function b() on object 'a' that returns an object 
with member function c().

It's not self evident is it? So yes UFCS makes the "pipeline" 
easier to read, but it actually makes the code more ambiguous if 
you dont know what each of the things is. So you need more 
context to understand it.


> That's what make this kind of mistakes so easy and I think it's 
> well worth to explain it to less experienced programmers.

If he was doing a talk to a bunch of inexperienced programmers 
then yes that stuff might be interesting, but he wasnt. You need 
to understand who your audience is, otherwise you risk wasting 
your and everyone elses time.


> It's not easy to make simple looking code. That has nothing to 
> do with (coding-)style, it is all about not defining things a 
> different way than it is usually done, so nobody mix it up.
> Sometimes it's very hard to find the correct order of things - 
> often even experiments are necessary to determine what 
> "usually" means.
> What he says is: Invest your time to find out what "usually" 
> means, and that is not trivial, even if it sounds like it is. 
> It requires a lot of experience to come to this conclusion. 
> Investing time to make things look easy and obvious is well 
> worth it, despite you're likely not payed (or in your case: 
> honored) for it.

While I agree with the overall gist I didn't find his examples 
very interesting or convincing. They were pretty much all made up 
to illustrate, outdated, or disingenuous (the first one with the 
intentionally obfuscated code).

It would have been far better if he had actual real code examples 
he'd cleaned up.