3b0f55f7f427d1c004c4219f9b2ab7272ced9f0d
kent
  Tue Apr 3 14:31:10 2012 -0700
More wordsmithing
diff --git src/README src/README
index 9ff4b07..6f18bfa 100644
--- src/README
+++ src/README
@@ -165,45 +165,45 @@
 	doSomethingElse();
 	}
 Each block of code is indented by 4 from the previous block.
 As per Unix standard practice, tab stops are set to 8, not 4
 as is the common practice in Windows, so some care must be
 taken when using tabs for indenting.  Since tabs are especially
 problematic for Python code, and we are starting to use
 Python a fair bit as well, tabs are best avoided altogether.
 The proper settings for the vi editor to interpret tabs correctly
 in existing code, and avoid tabs in new code are:
      set ts=8 set sw=4 set expandtab
 
 Lines should be no more than 100 characters wide.  Lines that are 
 longer than this are broken and indented at least 8 spaces
 more than the original line to indicate the line continuation.
-Line continuations may be unavoidable when calling functions with long
-parameter lists and in a few other situations.  Where possible though
-simplifying techniques should be applied to the code in preference
-to the line continuations.  Complex expressions can be broken into
-parts that are assigned to intermediate variables.  Long variable names
-can be revisited and sometimes shortened. Deep indenting can be
-avoided by simplifying logic and moving blocks into their own functions.
-These are just some ways you can productively shorten long lines without
-resorting to continuations, which no matter how they are done will tend
-to obscure the logic apparent in the indentation.
+Where possible simplifying techniques should be applied to the code 
+in preference to using line continuations, since line continuations
+obscure the logic conveyed in the indentation of the program.
 
+Line continuations may be unavoidable when calling functions with long
+parameter lists.  In most other situations lines can be shortened 
+in better ways than line continuations.  Complex expressions can be 
+broken into parts that are assigned to intermediate variables.  Long 
+variable names can be revisited and sometimes shortened. Deep indenting 
+can be avoided by simplifying logic and by moving blocks into their own 
+functions. These are just some ways of avoiding long lines.
 
 NAMES
 
-Symbol names begin with a lower-case letter.  The second 
+Symbol names generally begin with a lower-case letter.  The second 
 and subsequent words in a name begin with a capital letter 
 to help visually separate the words.  Abbreviation of words 
 is strongly discouraged.  Words of five letters and less should
 generally not be abbreviated. If a word is abbreviated in 
 general it is abbreviated to the first three letters:
    tabSeparatedFile -> tabSepFile
 In some cases, for local variables abbreviating
 to a single letter for each word is ok:
    tabSeparatedFile -> tsf
 In rare, complex, cases you may treat the
 abbreviation itself as a word, and only the
 first letter is capitalized.
    genscanTabSeparatedFile -> genscanTsf
 Numbers are considered words.  You would
 represent "chromosome 22 annotations"