Editing Guide to technical writing (section)

==Derek's golden rules==
* Derek's '''golden rule #1:''' Avoid the words "could," "would," or "should" in technical writing. "Could" and "would" are very weak sounding words, and "should" is too emotionally commanding. Suggested alternatives are:
:: Should → ought to, is possibly
:: Would → will potentially, will possibly 
:: Could → may, can potentially, may possibly
* Derek's '''golden rule #2:'''  Never begin a sentence with an abbreviation, mathematical symbol, or acronym.  All sentences must begin with a real English word.
* Derek's '''golden rule #3:''' Nested brackets are forbidden.  Although we allow nested brackets in mathematics, they are not allowed in the English prose.
* Derek's '''golden rule #4:''' Try to avoid using brackets wherever possible. Only use them when you have no other choice. 
* Derek's '''golden rule #5:''' Try to avoid multiple-letter mathematical variables. Rather than inventing a multiple-letter variable, use a single letter with a descriptive subscript. This is always preferred. In cases where multiple-letter variables have become tradition in the literature, such as SNR, then it is okay to use use them. But don't be guilty of making up new ones, because they are evil.
* Derek's '''golden rule #6:''' When referring to sections, chapters, equations etc., always be specific and refer to them by their number even if it is the next one.  Don't be vague and say "In a later chapter we discuss..."  but say "In Chapter 5 we discuss..."
* Derek's '''golden rule #7:''' Do not write about past events with relative time. Talk in terms of absolute time.  For example, do not say "Last year, Smith ''et al.'' introduced a new extension to their algorithm."  Instead of saying "Last year" write the actual year.  Talking in relative time is not good practice in a thesis or a journal article. If someone reads your work in 20 years time, you still want your writing to make sense then.