No commented code, unless there is a comment clearly explaining under what circumstances the code should be uncommented. If there are no circumstances in which the code should be uncommented, it should be deleted.

Justification: Commented code adds no value to the source. It does not clarify or explain functionality. It is old rubbish that should be removed. Source control is for looking at old code.

Comments should be

• complete sentences,
• on their own line, at the current indent
• grammatically correct, spelt correctly and have the correct punctuation (including a capital letter at the start and a full stop at the end).

Developer names should not appear in code.

Justification: The code belongs to the company not the individual developers that wrote it. Names in code encourages an attitude of certain developers 'owning' certain parts of the code or particular parts of functionality of the system. It also discourages other developers from changing the code due to a fear of standing on someone's toes. At TallGuyProgramming Inc, all developers are free to change any part of the code and developer specialisation is strongly discouraged.

Where a comma separated list is spilt over multiple lines, the commas should be prepended to the item. The first item should be indented, then have two spaces, then the item. Subsequent items should be indented, have a comma, have a space and then the item.

  →  ••Item one
  →  ,•Item two
  →  ,•Item three

Use tabs to indent, spaces to align. Tabs should only appear at the beginning of a line No arguments, no debates, this is how things are done at TallGuyProgramming Inc.

SELECT 
  →  ··Name·········AS·CustomerName
  →  ,·CreatedDate··AS·OrginalCreatedDate
FROM
  →  Customers