Comments

• Inaccurate comments are worse than no comments at all. e.g. code is updated and comments are no longer accurate
• comments do not make up for bad code
• code should express itself instead, e.g.
  // Check to see if the employee is eligible for full benefits
  if (employee.flags & HOURLY_FLAG && employee.age $>$ 65)
  vs.
  if (employee.isElegibleForBenefits())
• informative comments - should convey information that CANNOT be conveyed with code/naming
  e.g. a regular expression:
  // format matched: kk:mm:ss EEE, MMM dd, yyy
  

  Pattern timeMatcher = Pattern.compile("\\d*:$\\$d* $\\$w*")
  

• clarifying code that you cannot change or alter (e.g. part of a library or something) is good
• TODOs are also fine - jobs that you think should be done but can't at the moment for some reason
• Amplification - emphasizes the importance of something that at first glance may seem trivial
• a comment that requires you to look elsewhere to find its meaning is bad
• redundant comments are bad - they are just distracting noise
• don't leave commented out lines of code - delete them! that's what source control is for
• instead of marking ends of loops and such; try and make the function/section shorter
• position markers (marking related sections/functions) are generally noise
• don't add systemwide information to a local comment - if it contains information that could change elsewhere besides the current code, there's no guarantee that comment will be changed later and hence could become incorrect

Don't use a comment when you can use a function or variable