docs/master: discussion.roff comparison

comparison discussion.roff @ 124:3d30fd938aa9

Spellchecking.

author	markus schnalke <meillo@marmaro.de>
date	Sat, 30 Jun 2012 15:05:06 +0200
parents	740f4128dea7
children	0e102cec0c73

comparison

equal deleted inserted replaced

-:740f4128dea7
+:3d30fd938aa9
 Problems became visible when
 .Cl "anno -list -number 42
 worked on the current message instead on message number 42,
 and
 .Cl "anno -list -number l:5
-did not work on the last five messages but failed with the misterious
+did not work on the last five messages but failed with the mysterious
 error message: ``anno: missing argument to -list''.
 Yet, the invocation matched the specification in the man page.
 There, the correct use of
 .Sw -number
 was defined as being
 (These numbers and the ones in the following text ignore the MH library
 as well as shell scripts and multiple names for the same program.)
 .P
 Splitting the source code of a large program into multiple files can
 increase the readability of its source code.
-Most of the mmh tools, however, are simple and staight-forward programs.
+Most of the mmh tools, however, are simple and straight-forward programs.
 With the exception of the MIME handling tools,
 .Pn pick
 is the largest tools.
 It contains 1\|037 lines of source code (measured with
 .Pn sloccount ), excluding the MH library.
 source files seldom leads to better readability.
 For such tools, splitting makes sense
 when parts of the code are reused in other programs,
 and the reused code fragment is not general enough
 for including it in the MH library,
-or, if the code has depencencies on a library that only few programs need.
+or, if the code has dependencies on a library that only few programs need.
 .Fn uip/packsbr.c ,
 for instance, provides the core program logic for the
 .Pn packf
 and
 .Pn rcvpack
 I learned about the easy and the difficult parts.
 Code is easy to understand if:
 .BU
 The influenced code area is small
 .BU
-The boundaries are stictly defined
+The boundaries are strictly defined
 .BU
 The code is written straight-forward
 .P
 .\" XXX move this paragraph somewhere else?
 Reading
 On systems where
 .Fu fork()
 and
 .Fu exec()
 are expensive, the quicker response might be noticable.
-In the old times, sacrifying readability and conceptional beauty for speed
+In the old times, sacrificing readability and conceptional beauty for
-might even have been a must to prevent MH from being unusably slow.
+speed might even have been a must to prevent MH from being unusably slow.
 Whatever the reasons had been, today they are gone.
 No longer should we sacrifice readability or conceptional beauty.
 No longer should we violate the Unix philosophy's ``one tool, one job''
 guideline.
 No longer should we keep speed improvements that became unnecessary.
 One disadvantage needs to be taken with this change:
 The compiler can no longer check the integrity of the interfaces.
 By changing the command line interfaces of tools, it is
 the developer's job to adjust the invocations of these tools as well.
 As this is a manual task and regression tests, which could detect such
-problems, are not availabe yet, it is prone to errors.
+problems, are not available yet, it is prone to errors.
 These errors will not be detected at compile time but at run time.
 Installing regression tests is a task left to do.
 In the best case, a uniform way of invoking tools from other tools
 can be developed to allow automated testing at compile time.

Mercurial > docs > master

comparison discussion.roff @ 124:3d30fd938aa9