So you think you are almost there. You think one or two more hacking sessions could “do it” and you start the weekend thrash.
What is the difference between a clever hack and an unmaintainable pit of tar?
If you are in the Zone, then you of course nothing can stop you. But I say stop and rethink your life. You probably are building the wrong thing anyway.
I don’t roll on Shabbos!
My favorite super-pattern in developing and supporting software. Always assume the user is wrong. Remember, you are User Number Zero, so… blame yourself.
Defensive Programming is a technique similar to Defensive Driving. Always assume the user will break your program. Defensive programming will save you time in the long run by reducing support and increasing user satisfaction.
Its aim is to reduce the risk of collision by anticipating dangerous situations, despite adverse conditions or the mistakes of others – Defensive Driving – Wikipedia 2018
We must have a balance of making programs flexible enough to allow the user to use it for intentions unforeseen by the tool-makers themselves, and to ensure they don’t fall off the rails and lose data because they entered a word instead of a number.
- Never trust Input Text Boxes
- Always convert numerical values using ParseFloat or equivalent
- Never Eval() or Shell() with input string
- Never use string to build SQL Query without proper escaping. see SQL Injection
- Always trim whitespace at beginning and end of string
- Give clear and actionable error messages when providing feedback to user on their incorrect inputs
- … This post could go on for a while, TBF