Changes between Version 14 and Version 15 of Commentary/CodingStyle


Ignore:
Timestamp:
Sep 4, 2007 7:57:32 AM (7 years ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/CodingStyle

    v14 v15  
    2121}}} 
    2222pragma; you are encouraged to remove this pragma and fix any warnings when working on a module. 
    23  
    24 == General Style == 
    25  
    26 It's much better to write code that is transparent, than to write code that is short. 
    27  
    28 Often it's better to write out the code longhand than to reuse a generic abstraction (not always, of course).  Sometimes it's better to duplicate some similar code than to try to construct an elaborate generalisation with only two instances.  Remember: other people have to be able to quickly understand what you've done, and overuse of abstractions just serves to obscure the ''really'' tricky stuff, and there's no shortage of that in GHC. 
    29  
    3023 
    3124== To literate or not to literate? == 
     
    149142If the module can be compiled multiple ways (eg. GHCI vs. non-GHCI), make sure the imports are properly `#ifdefed` too, so as to avoid spurious unused import warnings.  
    150143 
     144=== General Style === 
     145 
     146It's much better to write code that is transparent, than to write code that is short. 
     147 
     148Often it's better to write out the code longhand than to reuse a generic abstraction (not always, of course).  Sometimes it's better to duplicate some similar code than to try to construct an elaborate generalisation with only two instances.  Remember: other people have to be able to quickly understand what you've done, and overuse of abstractions just serves to obscure the ''really'' tricky stuff, and there's no shortage of that in GHC. 
     149