From mboxrd@z Thu Jan 1 00:00:00 1970 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Tue, 24 Dec 2019 17:50:35 +0000 Subject: [COFF] What languges would you like to learn? In-Reply-To: <20191224163551.GA3839@mcvoy.com> References: <129b28e1-5629-2742-bb04-dfe6161ea3f0@telegraphics.com.au> <20191224163551.GA3839@mcvoy.com> Message-ID: On 24 Dec 2019 08:35 -0800, from lm at mcvoy.com (Larry McVoy): > There is a lot to be said for programming in the most simple way possible, > we had a saying at my company "Write code so it is the most readable. > Because 6 months from now you'll not remember it, it will be like reading > someone else's code". > > Code is write once, read many. Optimize for that. That's also why I dislike it when people remove things like explicit null checks and the likes, only because technically the value is guaranteed to be not-null at that point (either based on the type, or the code leading up to that point). Unless it's obvious that something won't be null, then let the compiler optimize that out if it can be safely optimized out, I say; there's value to being explicit in non-obvious cases, in part because over the lifetime of the code base, as you say, you are going to spend more time _anyway_ reading that code than you spent writing that one line or that one expression. Same reason why I'll sometimes add "unnecessary" parenthesis to expressions. If you parse the expression and know all precedence rules by heart (sometimes including the more esoteric ones; quick now, imagining you don't do a lot of bit-banging, does `^` have precedence over `&`? the existence of the joke "goes to" `-->` operator is just icing on the cake here), those can technically be unnecessary; but having them often adds _clarity_ that helps convey intent (yes, I really meant to do this) and meaning (this is how to parse the expression), at the cost of a totally insignificant increase in build times. To me, that's an appropriate trade-off. That said, I'd rather read code that makes good use of language features such as, say, the conditional operator (`?:` in C-derived languages), than code that does the same thing using a bunch of if/else constructs and temporary variables, just because someone might not know what `x?y:z` in the middle of a statement means. That latter is something that can be solved by a five-minute explanation when they encounter it, instead of burdening everyone who reads the code with extra crud just in the event that someone doesn't know about the conditional operator. Now, that might not be (hopefully was not) what you meant, but to me, "write readable code" should not be taken to mean "write code that does not require knowledge of the programming language to read", as sometimes happens at the other extreme end of the scale. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”