From: Jason Duerstock <jason.duerstock@gmail.com>
To: Alejandro Colomar <alx.manpages@gmail.com>
Cc: A <amit234234234234@gmail.com>,
GNU C Library <libc-alpha@sourceware.org>
Subject: Re: size_t vs long.
Date: Thu, 17 Nov 2022 14:40:51 -0500 [thread overview]
Message-ID: <CAP5F8cKtbO7W67eLcikcBDa4yC=y7ORVxFF5FmFGNST+v=kXeA@mail.gmail.com> (raw)
In-Reply-To: <7729eea1-d160-9148-f556-a0128d4a2e0e@gmail.com>
On Thu, Nov 17, 2022 at 6:01 AM Alejandro Colomar via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> Not really. I was trying to be explicative, while being a bit funny, to make it
> more entertaining to read. But as Brian Kernighan said, noone is smart enough
> to debug its own code:
>
> [
> Debugging is twice as hard as writing the code in the first place. Therefore, if
> you write the code as cleverly as possible, you are, by definition, not smart
> enough to debug it.
> ]
> — Brian W. Kernighan and P. J. Plauger in The Elements of Programming
> Style.
Not to get too far off topic, but I took this to mean that one should
endeavor to be boring and straightforward when coding unless it was
absolutely necessary to be clever, as the boring and straightforward
code would be easier to debug.
Or at the very least, one should never be more than 50% clever about it.
Jason
next prev parent reply other threads:[~2022-11-17 19:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-17 7:02 A
2022-11-17 9:21 ` Alejandro Colomar
2022-11-17 9:48 ` A
2022-11-17 11:00 ` Alejandro Colomar
2022-11-17 19:40 ` Jason Duerstock [this message]
2022-11-17 20:01 ` Alejandro Colomar
2022-11-17 19:17 ` Paul Eggert
2022-11-17 20:27 ` Alejandro Colomar
2022-11-17 21:39 ` Paul Eggert
2022-11-17 23:04 ` Alejandro Colomar
2022-11-23 20:08 ` Using size_t to crash on off-by-one errors (was: size_t vs long.) Alejandro Colomar
2022-11-18 2:11 ` size_t vs long Maciej W. Rozycki
2022-11-18 2:47 ` Paul Eggert
2022-11-23 20:01 ` Alejandro Colomar
2022-11-17 21:58 ` DJ Delorie
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='CAP5F8cKtbO7W67eLcikcBDa4yC=y7ORVxFF5FmFGNST+v=kXeA@mail.gmail.com' \
--to=jason.duerstock@gmail.com \
--cc=alx.manpages@gmail.com \
--cc=amit234234234234@gmail.com \
--cc=libc-alpha@sourceware.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 read-only IMAP folder(s) and NNTP newsgroup(s).