color lib

[Ethan Watson via Digitalmars-d]

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.