Welcome to a description of my new programming paradigm: zero-time programming. Being a busy family dad, I've got no time for programming. I've got no time for even reading blogs, never mind actually writing one. Or that's what I thought until I developed zero-time-programming, for people who have zero spare time but still want to create and release something.
The principle behind zero-time programming is to write code, run it yourself (if you've got time) and then release it. The main requirement is that you have the facility in your released software to inform you immediately if there's a problem; my usual choice is by email, so I get an email every time there is an error.
"But this is crazy" I hear you say. Sorry, I've got no time to discuss it. I will concede that this is not the best method for writing mission-critical code for NASA, but if you're a hobby programmer like me who just wants to get games out there while also having family life and full-time job, there's no better choice.
Here's the main bullet points to help you out though:-
* Wrap all your new code in a try/catch, and in the catch, send yourself the error. That way, the whole program won't grind to a halt.
* Throw exceptions wherever something happens that shouldn't, i.e. at the end of switch statements.
* Make a note of any thoughts you have about what to code, immediately. Whether in the shower, on the toilet etc.., your subconscious will do a lot of the thinking for you, so don't ignore it or forget what it's telling you. I've "found" plenty of bugs whilst sitting on the toilet.
* Use your own code, and make other code your own. Avoid moving ground. Who's got time to refactor code when your favourite library decides to change their method signatures?
* Send yourself a message from your software when something you need to check for happens, so you know it is happening (or not).
* Sanity checks - for example check variables aren't null.
* Ensure your error messages state which version has the error, so you can ignore old errors that have already been fixed.
* As you code, if you think of an extra bit of code that needs to be written in addition to the bit you're currently writing, e.g. a null-check that needs to be made, quickly write a todo, e.g. "// todo - nullcheck socket". Otherwise it will fall out of your head and bite you later. Once you've written the bit you're writing, do a search for all the "todo's" in your code and addess them.
* Never start a new project from scratch. If you can, copy an existing project and refactor it towards your new ideas.
All this will save you loads of time. How long does it take to go through a testing plan? Too long. Of course, this method of programming may mean you get a stream of messages informing you of bugs, but that just means you can fix them as soon as you have a spare couple of minutes, and then upload the next version.
