General rules to live by, that generally apply to most things programming, broadly speaking... generally.

General Programming Rules.md

• Master branch (master) is treated as the best, current WIP, destined to be a PRODUCTION release.

  • Used as the basis for all remote DEVELOPMENT servers.
  • Force pushes are allowed.

• Release branch (release) is treated as a final source of truth for remote PRODUCTION servers.

  • The current version of release should reflect what all PRODUCTION servers should be running (or updating to).
  • This is the branch from which all version tags are created.
  • Force pushes are NEVER ALLOWED. The history is immutable. If something must change, it must be reflected in its history, and not overwritten.

• Version tags are immutable.

  • Once created / pushed, version tags CAN NOT BE ALTERED IN ANY WAY.
  • If, for ANY REASON, there was a mistake made, or something MUST be un-done, a version can ONLY BE DELETED, NEVER RECREATED. PRODUCTION servers can roll-back to a previous version automatically.

• Spaces, not tabs. Let the IDE handle it. In the end, using spaces will help.

• NEVER EVER store credentialls / keys / passwords in git-versioned files!!!

  • NEVER EVER store credentialls / keys / passwords in git-versioned files!!!
    • NEVER EVER store credentialls / keys / passwords in git-versioned files!!!
      • NEVER EVER store credentialls / keys / passwords in git-versioned files!!!
        • NEVER EVER store credentialls / keys / passwords in git-versioned files!!!
          • NEVER EVER store credentialls / keys / passwords in git-versioned files!!!
            • NEVER EVER store credentialls / keys / passwords in git-versioned files!!!
              • NEVER EVER store credentialls / keys / passwords in git-versioned files!!!
                • NEVER EVER store credentialls / keys / passwords in git-versioned files!!!
                  • NEVER EVER store credentialls / keys / passwords in git-versioned files!!!

• Be accessible!

  • DO NOT RELY ON COLOR ALONE! Colorblind people exist! Use multiple cues in your interfaces.
  • Remember there are blind people too! Use the ARIA standards. Try using your application with a screen-reader only, it's not easy.

• Always have a backup plan for your backup plan. 1 backup is good, 2 backups is being prepared.

  • Use at least 1 remote backup.
  • A physical, non-volatiale backup is ALWAYS good, when appropriate (security keys for example). Encrypted of course.

• ALWAYS encrypt the harddrive, and ALL backups.

  • Change encryption key periodically (at-least once a year).

• Use a password manager!!!

  • NEVER use the same password twice!
    • NEVER use the same password twice!
      • NEVER use the same password twice!
        • NEVER use the same password twice!
          • NEVER use the same password twice!
            • NEVER use the same password twice!
              • NEVER use the same password twice!
                • NEVER use the same password twice!
                  • NEVER use the same password twice!