Bugs; What Even Are They?

Bugs in computing are broadly defined as a computer program that doesn't perform as the maker expected. I think this could be expanded further to the function not being appropriate for the programs greater goal; the coder hasn't got the purpose right. Code is a very precise thing, a missing comma is the difference between Mashoom doing what it does and literally showing a blank page. For that matter, one if statement fundamentally secures Mashoom:

if (!password_verify($Password, $UserRow['password'])){

So, for a program to be "bug free", every line has to be perfect, down to the last character. Mashoom is broadly 40,000 lines of code, but based on who knows how many lines of other libraries etc. Bug are inevitable when you think of it this way.

Broadly, I think you can characterise bugs into the following, from most obvious and common when your coding to the most difficult to find and fix. After writing some code from afresh I find this is normally the order I find bugs in.

Syntax Errors

These are the "DOH!" moments of coding and its just inevitable. These are very simple to find and fix; the compiler of your chosen language will just reject them. There is one simple and easy trick to avoid these errors though; copy and paste. It is far better (in my opinion) to copy in code you know is correct and modify it, than try and write something from scratch.

Won't Run Errors

So now your program compiles, and you try out whatever function you just wrote. Unless your having a good day the program won't get to the end of whatever it will need to do, the program will fatal error in some way. These errors are again not normally too bad to find, but this is also when you can corrupt your development database and hang your program in a while loop... amongst other things!

Functionality Errors

Or "O that hasn't gone to plan at all" errors. The program now performs the function, but under closer inspection it hasn't done what you want it to, or its done some but not all of it. This also comes links in with the fact you are unlikely changing one solitary feature when you are coding, you may have disturbed something else.

This is where most of the focus is in bug checking, its a difficult process and one that takes a lot of time. There is also no clear end; when do you know that you won't find another bug? The most common error I make is seeing the success message and assuming it must have gone OK, especially when this is a small cycle of writing and testing a large section.

Some code is very difficult to bug check; recursive functions, dealing with large data sets or doing a suitably deep level function of the program can all present the problem of "how on earth do I know that is working". The only real way of overcoming this is to put more effort into writing checking programs, sometimes echo $var; is going to cut it for finding bugs. The nice thing is that these checking functions can easily be converted into actual errors in your program.

Rogue Errors

These are the ones that got away. Likely they come out of either a change unexpectedly affecting another bit of code/functionality, a deployment change, a bad assumption about the deployment. Both of these are tricky to find, diagnose and fix. These are where security errors creep in and weird things happen every now and again in even the biggest programs. Windows.

I spent a lot of time and effort getting Mashoom's deployment automated and its configuration into version control with the rest of the code base. I have to say hats off to AWS's Elastic Beanstalk for providing the tools to make this possible. This has minimised these problems massively though, and they can plague a web based program as they rely on a very wide range of other programs to run. The other big mention is repository controls like composer or bower, they nail down and control the libraries your program relies upon; invaluable for reliability.

As to not affecting other peoples code? You want to aim to have code where the chances of this are minimised in my opinion. Properly naming function and commenting hopefully reminds you or signposts the next person as to what you meant that bit of code to do and its limitations, so hopefully it isn't used in a way that wasn't expected.

Security Errors

These are errors found by a motivated party. Most programs get used as the coder intended, this is after all the aim. However, as we are all finding out, programs can be run/used in many different ways and manipulated into doing something that the coder didn't expect to happen. This goes from not properly checking user inputs all the way to defending a timing attack on your login screen. This is a very new section of bugs in the grand scheme of things, which is why so many are being found in well established software, it simply wasn't built to be used incorrectly!

Some programs don't require "security" as such, but as soon as you start storing data persistently you should be thinking about how someone else could access that data. There is no simple answer and it feels a lot like playing chess against yourself. The other obvious piece of advise is to Google what you are coding, possibly with the word "security", and get reading. Lots of computer security is reliant upon some very talented people writing a certain process or set of functions that secure a process. Don't think about it, if its from a  good source, copy, paste and use it.

Purpose Errors

I have embarrassingly on many occasions written a wonderful bit of code, bug checked it, then realised it doesn't actually do what I need it to. This is an extreme case of these types of errors (as I said earlier, grey area between these and bugs). These bugs normally only come to light when you show what you have done to someone else, hopefully someone who is going to use the software. Every bit of code you write fits into a larger purpose of the thing you are writing, this is where that gets taken into account. This error does therefore stretch into customer feedback, but could be as simple as a misnamed button.