Computer Old Farts Forum
 help / color / mirror / Atom feed
Subject: [COFF] What languges would you like to learn?
Date: Tue, 24 Dec 2019 17:50:35 +0000	[thread overview]
Message-ID: <trrkqwt9kjzbmrgzctxrvjqz@localhost> (raw)
In-Reply-To: <20191224163551.GA3839@mcvoy.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2616 bytes --]

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?”



  reply	other threads:[~2019-12-24 17:50 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-23 23:27 cym224
2019-12-24  9:54 ` thomas.paulsen
2019-12-24 16:28 ` toby
2019-12-24 16:35   ` lm
2019-12-24 17:50     `  [this message]
2019-12-24 18:04       ` lm
2019-12-25  3:34     ` dave
2019-12-25 16:02     ` cym224
2019-12-25 17:05     ` thomas.paulsen
2019-12-24 20:27 ` dave
2019-12-25 17:31 ` rtomek
2019-12-25 19:13   ` athornton
2019-12-26  0:23     ` me
2019-12-26  1:54       ` wobblygong
2019-12-26  3:44         ` dave
2019-12-26  4:00           ` lm
2019-12-26  5:43             ` wobblygong
2019-12-26 11:49               ` tih
2019-12-26 15:33                 ` lm
2019-12-26 16:34                 ` thomas.paulsen
2019-12-26 16:53                   ` lm
2019-12-27  3:00                 ` dave
2019-12-27  7:02                   ` thomas.paulsen
2019-12-26 17:57               ` bakul
2019-12-26 21:28                 ` davida
2019-12-26 21:37                   ` lm
2019-12-26 21:57                     ` sauer
2019-12-26 22:13                     ` 
2019-12-27  3:41                     ` bakul
2019-12-27  4:00                       ` lm
2019-12-27  4:28                         ` bakul
2019-12-26 22:16                   ` imp
2019-12-27  3:41                   ` bakul
2019-12-26 15:43         ` dfawcus+lists-coff
2019-12-27 17:46   ` cym224
2019-12-27 21:33     ` tih

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=trrkqwt9kjzbmrgzctxrvjqz@localhost \
    --to=coff@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).