The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: michael@kjorling.se (Michael Kjörling)
Subject: [TUHS] Discuss of style and design of computer programs from a user stand point
Date: Sat, 6 May 2017 09:18:57 +0000	[thread overview]
Message-ID: <20170506091857.GE12539@yeono.kjorling.se> (raw)
In-Reply-To: <5a2d6cc957c2efcd968f35aa5557c7a0e309dd27@webmail.yaccman.com>

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

On 5 May 2017 22:33 -0700, from scj at yaccman.com (Steve Johnson):
> For me, a lot of what
> I learned was from Stan Brown at the Labs, who read piles of my
> (atrocious) FORTRAN code and repeatedly pointed out that when you
> wrote a program, you were not just communicating with the computer,
> but also other humans (including yourself) who would read (and perhaps
> modify) the code in the future...

I would actually take that one step further: When you are writing
code, you are _first and foremost_ communicating with whatever human
will need to read or modify the code later. That human might be you, a
colleague, or the violent psychopath who knows both where you live and
where your little kids go to school (might as well be you). You should
strive to write the code accordingly, _even if_ the odds of the threat
ever materializing are slim at most. Style matters a lot, there.

Sure, some code really needs to be heavily optimized, and might end up
obscure for it. In operating systems, interrupt routines are probably
one of the major candidates, but first stage bootloaders need their
fair share of it too for other reasons. Tight loops or code that needs
to be able to operate on lots of data quickly are other examples. But
_most code isn't like that_ and can allow for some extra verbosity and
some performance penalty if that means making it significantly easier
to read and modify. That's not to say code should be verbose _just
because_, but if you don't need ultimate performance, I say aim for
readability and modifyability first; processing and memory usage
second. You can always go back and optimize bits that turn out to need
it.

And of course, I find Doug McIlroy's shell snippet mentioned by Noel
interesting, _because I did something very similar not all that long
ago_; in my case, stringing together a bunch of shell tools to get a
list of all URLs from an e-mail message for further processing.
(Something like a composable _urlview_; if urlview had even had a
"dump to stdout" option, that would have done all I needed it for.)
Works like a charm, and isn't even terribly complicated. It could
probably be done in a single line of perl or awk instead of piping
through a grand total of six commands, but that's okay. And of course,
stringing together a bunch of commands was the first approach that
occured to me...

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)


  reply	other threads:[~2017-05-06  9:18 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-05 15:20 [TUHS] Discuss of style and design of computer programs from a user stand point [was dmr note on BSD's sins] Clem Cole
2017-05-05 15:37 ` Bakul Shah
2017-05-06  2:16   ` Noel Hunt
2017-05-06  2:40     ` Toby Thain
2017-05-06  6:07     ` Bakul Shah
2017-05-06 22:11       ` Steve Johnson
2017-05-06 23:35         ` Larry McVoy
2017-05-07  4:06       ` Dan Cross
2017-05-07 13:49         ` [TUHS] Discuss of style and design of computer programs from a user stand point Michael Kjörling
2017-05-06  2:02 ` [TUHS] Discuss of style and design of computer programs from a user stand point [was dmr note on BSD's sins] Doug McIlroy
2017-05-06  5:33   ` Steve Johnson
2017-05-06  9:18     ` Michael Kjörling [this message]
2017-05-06 13:09       ` [TUHS] Discuss of style and design of computer programs from a user stand point Nemo
2017-05-06 13:44         ` Michael Kjörling
2017-05-06 14:40       ` Larry McVoy
2017-05-06 15:09         ` [TUHS] Discuss of style and design of computer programs from a Corey Lindsly
2017-05-06 15:20           ` Michael Kjörling
2017-05-06 15:24             ` Larry McVoy
2017-05-06 15:51               ` Michael Kjörling
2017-05-06 15:53                 ` Larry McVoy
2017-05-06 20:00             ` Steve Nickolas
2017-05-06 21:45               ` Michael Kjörling
2017-05-07  7:42                 ` Stephen Kitt
2017-05-06 15:23           ` ron minnich
2017-05-06 15:44             ` Michael Kjörling
2017-05-06 18:43         ` [TUHS] Discuss of style and design of computer programs from a user stand point Dave Horsfall
2017-05-06 19:50           ` Bakul Shah
2017-05-07  1:15             ` Warner Losh
2017-05-07  1:42               ` Noel Hunt
2017-05-07 13:54                 ` Michael Kjörling
2017-05-07 14:58                   ` arnold
2017-05-07 16:33                     ` Michael Kjörling
2017-05-07 15:13                 ` Warner Losh
2017-05-06 16:40       ` Kurt H Maier
2017-05-06 14:16     ` [TUHS] The Elements of Programming Style (book) - was Re: Discuss of style and design of computer programs Toby Thain
     [not found] <mailman.821.1494062349.3779.tuhs@minnie.tuhs.org>
2017-05-06 17:52 ` [TUHS] Discuss of style and design of computer programs from a user stand point David

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=20170506091857.GE12539@yeono.kjorling.se \
    --to=michael@kjorling.se \
    /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).