[Cryptography] Ada vs Rust vs safer C

[Ray Dillinger]

On 09/20/2016 12:08 AM, John Gilmore wrote:

> There is usually a reason that long, complicated functions are long
> and complicated!  And it's not stupidity.  It's the complicated nature
> of the job that that function is trying to do.
> 
> Inserting pragmas that are basically comments is unlikely to produce
> any NEW bugs in the code.
> 
> Refactoring a long, complex function is very likely to introduce new
> bugs.


I have gradually gotten into a habit that seems to help me (especially
when dealing with large-ish functions), although most people find it
peculiar and react badly to it on first sight.  I would have reacted
badly to it myself ten years ago.  But having gotten used to it it just
seems much clearer. I still restrain myself from doing it while working
with people who don't like it, but in a pinch I just pipe my  code
through a sed script to astyle to massage it into a format more familiar
to them before checking it in.

I find that I can more easily understand functions, even functions of
just as many statements, if they're on fewer lines.  This brings out
control structure on the left side without stringing code off the top
and bottom of the page.  And I can more easily see relationships between
functions if they're vertically compact enough to see both (or all) of
those functions at once.  The habits that made for readable code when we
were writing on 20x80 character monitors have, at least for me, become
obviously wrong in an era of 10-Megapixel displays.

My pages are now ~100 lines or so rather than 20 lines, and my editor
can be as wide as the whole screen. So, gradually, I've taken to writing
code in a 250-column format where I can read it on about 3/4 the width
of my monitor.  That way I can still keep on the right side a terminal
window where I can see it and use the command line (and see compilation
errors) while the code is still visible.  Most functions fit on <6
lines, and I *VERY* seldom have to write one that runs off a 250x100
screen.

So if-statements and loops that fit on one line, or even short function
definitions that fit on one line, go on one line.  Conceptually related
short statements and multi-statement idioms like the classic 'shuffle'
that exchanges two values, also go together on one line.  Statements
that are related in two different ways (like expressions that initialize
or manipulate elements of a 2d array, or doing 5-or-so related but
non-identical things with x and y coordinates while navigating a
structure) go into a grid that matches the structure of the operations.
That way I can see the differences in handling different elements by
contrasting statements that are vertically adjacent, and see the
"general" nature of the analogous operations involved by contrasting
statements that are horizontally adjacent. I can find relevant
statements more easily that way than when the code is vertically strung
out, and see more easily how it relates to other operations.

This flies in the face of what used to be the accepted advice for
writing readable code, and violates some assumptions that some of the
tools make (like GDB wanting to execute a whole line at a time rather
than a statement at a time).  Nevertheless I find it more readable and
easier to work with, and for GDB and similar, debug builds pipe the code
through my sed script to an intermediate file (to one-statement-per-line
form) and that works fine even though it screws up the relationship
between GDB's line-numbering and the code's line-numbering.

				Bear

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160920/da13dfb5/attachment.sig>