Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
Keep this in mind when coding

Coding Maxims

  • code is debt (and bad code is a unhedged call option)

    • cant have 0-days or bugs if I dont write any code
    • our users dont care about the code
    • every line of code has costs (your time, readability, maintainability, complexity)
      • its like owning a house with lots of rooms. its nice when your friends come over once a month, but you pay rent every day
    • dont add features unless you're sure it is necessary
    • dont optimize prematurely
  • DRY DRY DRY

  • keep it simple (especially at first)

  • be consistent

  • be predictable (aka no magic)

  • no magic numbers/strings — use constants instead

  • a good repro is 90% of a bugfix

  • code is written once, but is read many times

  • ship early, ship often

  • first code, then ship, then measure, then optimize

  • remember the 80/20 rule, and the 90/90 rule

  • first you don't know the rules, then you learn the rules, then you break the rules

See also: https://en.wikipedia.org/wiki/Category:Programming_principles

@nrjohnstone

This comment has been minimized.

Show comment Hide comment
@nrjohnstone

nrjohnstone Sep 22, 2017

DRY is a dangerous mantra when applied without thinking... If your crossing architectural boundaries, and you think that it's "DRY" to share your dto from one boundary to another all the way down to your persistence layer because, if you don't, your repeating yourself, then your going to be asking for a world of pain in terms of coupling between layers ... DRY within a bounded context / specific scope is the only way to apply this principal...

The rest of your principles are well written and unfortunately I don't see enough like them in other places.

nrjohnstone commented Sep 22, 2017

DRY is a dangerous mantra when applied without thinking... If your crossing architectural boundaries, and you think that it's "DRY" to share your dto from one boundary to another all the way down to your persistence layer because, if you don't, your repeating yourself, then your going to be asking for a world of pain in terms of coupling between layers ... DRY within a bounded context / specific scope is the only way to apply this principal...

The rest of your principles are well written and unfortunately I don't see enough like them in other places.

@kauffj

This comment has been minimized.

Show comment Hide comment
@kauffj

kauffj Nov 21, 2017

  1. I propose these be numbered.
  2. I propose "no magic numbers/strings — use constants instead" be modified (or a new rule added) to cover that strings are only for messages for people (e.g. to be displayed, for log files, etc.). If you are doing a comparison against a string, especially in more than one place, that is a strong sign it should be a constant. I think magic strings/numbers specifically refers to input that triggers hidden or non-standard behavior, which is a bad idea even if you are using constants.

kauffj commented Nov 21, 2017

  1. I propose these be numbered.
  2. I propose "no magic numbers/strings — use constants instead" be modified (or a new rule added) to cover that strings are only for messages for people (e.g. to be displayed, for log files, etc.). If you are doing a comparison against a string, especially in more than one place, that is a strong sign it should be a constant. I think magic strings/numbers specifically refers to input that triggers hidden or non-standard behavior, which is a bad idea even if you are using constants.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment