On Saturday, 8 October 2016 at 13:06:42 UTC, Manu wrote:
Oh no, you too? >_<
Yeah, I've been going on a readability bender lately, especially
in public facing code.
My thinking there is that statements in code that don't
immediately give context are essentially a cipher. Because that's
exactly what you need to do to understand the code - look
something up to see what it means. Named parameters and variable
names that provide the context avoid that to a large degree.
I'm especially trying to make Binderoo readable as there's so
many programmers that are scared by metaprogramming. My GDCE talk
spent a lot of time attempting to make it all understandable.
Making the code descriptive seals the deal. If I can make my code
more descriptive, and it compiles out just the same but makes the
compiler do a bit more work... Make the compiler do more work and
optimise the compiler.
I'm far more lax on not-publicly-facing code (so basically API
implementations and supporting code that isn't part of a public
interface). Anything I expect someone other than myself to
interact with gets the readability treatment. Which, as you know,
is important because readable code generally isn't efficient code
- as is evidenced by the vectorisation/buffer processing thread
going on in here.
It's also interesting how many programmers get vehemently
defensive when you call out non-descriptive programming practices
as programming for your own convenience and no one else. I have
this argument with using i/j/k/foo/bar/etc in loops as well.
Incidentally, have you had a geez over the core API? An
efficient API
will emerge when we work out how to work batched operations into
ranges...
Been slowly making my way through it. Seems solid enough, but I
haven't looked through it all thoroughly yet.
