d3036c5af348ca18906cdad412ae3cd56cadfd59
kent
  Tue Apr 3 14:08:22 2012 -0700
Minor edits.
diff --git src/README src/README
index 95c37ba..9ff4b07 100644
--- src/README
+++ src/README
@@ -155,31 +155,31 @@
 
 INDENTATION AND SPACING:
 
 The code follows an indentation convention that is a bit
 unusual for C.  Opening and closing braces are on
 a line by themselves and are indented at the same
 level as the block they enclose:
     if (someTest)
 	{
 	doSomething();
 	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 to use tabs for indenting.  Since tabs are especially
+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
@@ -210,32 +210,32 @@
 as "chromosome22Annotations" or "chr22Ann."
 Note the capitalized 'A" after the 22.  Since both numbers and
 single letter words (or abbreviations) disrupt the visual flow
 of the word separation by capitalization, it is better to avoid
 these except at the end of the name.
 
 These naming rules apply to variables, constants, functions, fields,
 and structures.  They generally are used for file names, database tables,
 database columns, and C macros as well, though there is a bit less
 consistency there in the existing code base.
 
 ERROR HANDLING AND MEMORY ALLOCATION
 
 Another convention is that errors are reported
 at a fairly low level, and the programs simply
-print an error message and abort.  If you
-need to catch errors underneath you see the
+print an error message and abort using errAbort.  If 
+you need to catch errors underneath you see the
 file errAbort.h and install an "abort handler".
 
 Memory is generally allocated through "needMem"
 (which aborts on failure to allocate) and the
 macros "AllocVar" and "AllocArray".  This 
 memory is initially set to zero, and the programs
 very much depend on this fact.
 
 COMMENTING 
 
 Every module should have a comment at the start of
 a file that explains concisely what the module
 does.  Explanations of algorithms also belong
 at the top of the file in most cases. Comments can
 be of the /*  */ or the // form.  Structures should be 
@@ -332,19 +332,19 @@
     twoBit->maskBlockCount = countBlocksOfLower(dna, seq->size);
     if (twoBit->maskBlockCount > 0)
         {
         AllocArray(twoBit->maskStarts, twoBit->maskBlockCount);
         AllocArray(twoBit->maskSizes, twoBit->maskBlockCount);
         storeBlocksOfLower(dna, seq->size,
                 twoBit->maskStarts, twoBit->maskSizes);
         }
     }
 return twoBit;
 }
 
 Though code paragraphs help make long functions readable, in general
 smaller functions are preferred. It is rare that a longer function
 couldn't be improved by moving some blocks of code into new functions
-or simplifying.
+or simplifying what the function is trying to do.
 
 ====================================================================
 This file last updated: $Date: 2010/06/03 16:48:53 $