Updated NEP 1 : Style Guide for Nimrod Code (markdown)

NEP-1-:-Style-Guide-for-Nimrod-Code.md

@@ -13,30 +13,24 @@ sense in certain contexts. Furthermore, just as
 [Python's style guide](http://legacy.python.org/dev/peps/pep-0008/) changes
 over time, this style guide will too.
 
-<br>
+<br></br>
 Style Guidelines
 ================
-Spacing and Whitespace Conventions
-----------------------------------
+### Spacing and Whitespace Conventions ###
 - Lines should be no longer than 80 characters. Limiting the amount of
   information present on each line makes for more readable code - the reader
   has smaller chunks to process.
 
----------
-
 - 2 spaces should be used for indentation of blocks; tabstops are not allowed
   (the compiler enforces this). Using spaces means that the appearance of
   code is more consistant across editors. Unlike spaces, tabstop width varies
   across editors, and not all editors provide means of changing this width.
 
----------
-
 - Use of extra whitespace for alignment in ways other than dictated by the
   style guide is discouraged. Manual alignment and re-alignment of code is
   tedious, and not all editors have support for auto-alignment of code
   sections, plus re-alignment of code blocks causes larger, less distinct
   code diffs.
-
     ```nimrod
     # This is bad, as the next time someone comes
     # to edit this code block, they
@@ -49,8 +43,9 @@ Spacing and Whitespace Conventions
       LongLongPtr* = ptr LongLong
     ```
 
-Naming Conventions
-------------------
+<br></br>
+### Naming Conventions ###
+
 Note: While the rules outlined below are the *current* naming conventions,
 these conventions have not always been in place. Previously, the naming
 conventions for identifiers followed the Pascal tradition of prefixes
@@ -98,10 +93,9 @@ be changed in the future.
       pcFile
       pcLinkToFile
     ```
-<br>
 
-Coding Conventions
-----------------
+<br></br>
+### Coding Conventions ###
 - The 'return' statement should only be used when it's control-flow properties
   are required. Use a procedures implicit 'result' variable instead. Using the
   implicit result variables allows both the Nimrod compiler and its various
@@ -111,10 +105,9 @@ Coding Conventions
   that do not change within their scope. Using the let statement ensures that
   variables remain immutable, and gives those who read the code a better idea
   of the code's purpose.
-<br>
 
-Conventions for multi-line statements and expressions
------------------------------------------------------
+<br></br>
+### Conventions for multi-line statements and expressions ###
 - Any tuple type declarations that are longer than one line should use the
   regular object type layout instead. This enhances the readability of the
   tuple declaration by splitting its members information across multiple