Index

Cleaning up the toybox code.

Toybox hasn't always
taken proper advantage of external contributions.
Lots of people want to help, but their contributions languish out of tree
or in the "pending" directory, awaiting cleanup.

Toybox's design goals require simpler, tighter, and more explicit code
than most other implementations, among other reasons to allow better security
auditing. Writing "another" implementation of standard command line tools
isn't very interesting, they should be _better_ implementations.
Unfortunately, this means existing, working commands often take more effort to
clean up to Toybox's standards than writing a new one from scratch, not
because they don't work, but because we aim for an unusual level of polish.

In hopes of teaching more people how to do this
cleanup work, I've started breaking cleanup changes into smaller chunks and
posting explanations of each change to the mailing list.
Below are indexes of such cleanup series. Each commit and post are meant to
be read together: each description explains what the corresponding patch
was trying to accomplish.

Line/byte totals of completed series are given for scale, but the point
of this work is simplicity and compactness, not size per se.

(Note: mercurial's web viewer doesn't follow renames, so although each
command name links to a commit list with the bulk of the changes, it may
not include the final version of each file moved from the "pending"
directory to its final location. The summaries link the initial and cleaned
versions of each file when giving line counts.)

General advice and/or policy.

The design of toybox page and the coding
style section at the start of the source code walkthrough
don't cover everything. Here are some
links to mailing list messages that cover various programming topics
not directly related to a specific cleanup series:

"Hiding numbers that are used just once into defines to put them out of
sight does not really help readability." -
Pavel
Machek

"Infrastructure in search of a user" is a bad thing, so don't put code
in lib/ that doesn't already have at least two users. Don't preemptively
factor stuff out, it's easy enough to rewrite it uin future if it needs
to change. The "extreme programming" fad called this "You Ain't Gonna
Need It" (while inexplicably screaming at cans of Mountain Dew, back in the
90's). Here's Linus Torvalds' take.

This is an example of cleaning up something most projects would be quite
happy with. The initial submission of uuencode and uudecode was high
quality code, written by a seasoned developer who did an excellent
job, but it was still possible to shrink the result almost by half:

When ifconfig was submitted, it touched a half-dozen files. I glued it
together into a single self-contained file, which needed a lot of
cleanup. The final version is about 1/3 the size of the original.

This was the first command I started cleaning up with the intent of
describing the process, and especially the first few entries in this
series describe many of the low hanging fruit techniques used to clean
up a codebase.