The Curious Programmer

Software, Gadgets, Books, and All Things Geek

Computer Science Geeks Rejoice! — January 20, 2015

Computer Science Geeks Rejoice!


As a computer science enthusiast, it has sometimes been hard for me to find other social, out going geeks that just want to kick back and debate data structures, algorithm designs in terms of time and space complexity, sorting techniques, bit manipulation, different types of languages, history of computing systems, and other technologies that mere mortals just don’t find interesting or sometimes have no idea existed!

It also seems like even though developers and computer science majors are typically the ones developing social gaming apps, there still weren’t any out there (that I’ve run into) that really sparked my interest and challenged me to compete with other tech geeks in a battle of computer wits.

Well yesterday I just happen to find exactly what I was looking for!

The app is called QuizUp. It is a real time trivia game that allows you to compete with other people that believe they are knowledgeable on certain subject matter and destroy them :). The game allows you to “level up” based on your demonstration of mastery over other real people all around the world . It will also rank you in comparison to the rest of the people playing in the state, the country, and universe.

Now this app isn’t just for computer geeks and technology enthusiasts. The topics are immense (nearly 1000 categories at the time of this posting including Game of Thrones!). However, I find the computer science categories one of the best out there. The app actually has some stimulating questions that can be pretty tough. You can also submit your own questions if you think you have some better that the app could use. Its fun to place against other people that are also passionate about technology and see how you stack up against people all around the world.

That being said, I definitely recommend you check it out and tell me what you think in the comments. What’s your favorite category? Also if you want to get your butt whooped by me in the computer science category you can add me as a friend and challenge me! My username is “Jason Roell” (boring I know). Hope you all like the app as much as I do!

Defensive Coding Techniques — January 4, 2015

Defensive Coding Techniques

We’ve all heard of defensive driving (and if you haven’t, you’re probably the one we are all defending against). However, as developers, we should also be familiar with defensive coding. Just as defensive driving can save you lots of money and keep you safe on the road, defensive coding can keep the code you write from crashing and burning as well.

Well the first thing you might ask yourself is “What exactly is defensive coding?”. Wikipedia defines it as:

A form of defensive design intended to ensure the continuing function of a piece of software in spite of unforeseeable usage of said software. The idea can be viewed as reducing or eliminating the prospect of Murphy’s Law having effect. Defensive programming techniques are used especially when a piece of software could be misused mischievously or inadvertently to catastrophic effect.

This is a good definition, but a better or maybe simpler definition might just be “developing a system that behaves in a predictable manner despite unexpected conditions or inputs.”

Defensive coding can generally be broken down into three main areas. These areas are:

  1. Clean Code
  2. Testable Code
  3. Validation

Let’s start off by talking about number 1.

Clean Code

Clean code is very important for a few reasons. Mainly because it will improve comprehension, simplify maintenance, and reduce bugs.

Comprehension is a very important part of defensive coding. If it is clear what your code is doing or what its responsibilities are, then there is a much lower chance of it being used in the incorrect way by client code or applications. One of the best ways to make you code comprehensible is coding in a way that is very readable. This starts off by naming methods and arguments appropriately. Of course, this is easier said than done. The famous quote by Phil Karlton points out that:

There are only two hard things in Computer Science: cache invalidation and naming things.

Keeping your methods focused and specific will help you in naming them. Spend time in developing a good name for you methods and arguments that clearly defines its purpose so that the client of the API will understand how to call the code in question rather than abusing it.

Keeping your code clean and readable also helps code maintenance. I know there have been many times when I have developed a complex method and would come back to it week later and have to re-learn the whole process of what I was actually doing.

Some people might say “Comment your code better!”, but I typically view comments that tell what the code is doing as a “code smell” and see it as an opportunity to refactor the code into a more readable solution instead (don’t get me wrong, comments aren’t always a code smell. If a comment explains why a particular action was done, especially an unexpected one, I believe it to be a good use for code comments). Having a clear understanding of your code will simplify maintenance and prevent unexpected bugs from popping up from someone that didn’t fully comprehend what the code was actually doing.

Testable Code

Well I don’t think it would be possible to talk about defensive coding and not mention unit testing. Unit testing is a automated way to test small “units” of your code that will provide your code with improved overall quality and confirm that code maintenance and changes did not break previous functionality.

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect. Each unit is tested separately before integrating them into modules to test the interfaces between modules. Unit testing has proven its value in that a large percentage of defects are identified during its use.

One great way to make sure you are developing testable code is to follow the SOLID principles of software development. Now the SOLID principles are a topic of their own and if you aren’t familiar with them I highly suggest your read this article by Shivprasad Koirala. However, I do want to cover what I perceive as the two most important SOLID principles in regards to testability. These are the ‘S’ and the ‘D’ in SOLID. The ‘S’ stands for Single Responsibility and ‘D’ stands for Dependency Inversion.

Single Responsibility: Your classes should really only be doing one thing, and one thing only. A class that creates a file, parses some input, and writes it to the file is already doing three things. If your class only does one thing, you know exactly what to expect of it, and designing the test cases for that should be fairly easy.

Dependency Inversion/Injection (DI): This gives you control of the testing environment. Instead of creating foreign objects inside your code, you inject it through the class constructor or the method call. When unit testing, you simply replace real classes by stubs or mocks, that you control entirely.


Validating (or sanitizing) user input is to ensure that input is safe prior to use.

The most secure way to do this is to Terminate on incorrect input and use a Whitelist/Blacklist strategy to determine if execution should continue or not.

In terms of method arguments, there are often known good inputs — input the developer is completely certain is safe. There are also known bad characters; input the developer is certain is unsafe (can cause Code injection etc.). Based on this, two different approaches to how input should be managed exists:

  • Whitelist (known goods). A Whitelist is a list of “known good inputs”. A Whitelist is basically a list which says “A, B and C is good (and everything else is bad)”.
  • Blacklist (known bads). A Blacklist is a list of “known bad inputs”. A Blacklist is basically a list which says “A, B and C is bad (and everything else is good)”.

Security professionals tend to prefer Whitelists, because Blacklists may accidentally treat bad input as safe. However, in some cases a whitelist solution may not be easily implemented.

Handling bad input in a predictable manner can better allow client applications to understand what exactly is bad input and what is good input and how to satisfy the conditions to achieve the desired result. This is typically done through an exception handling and propagation strategy, of which I will not go into detail here.


Following these three techniques can greatly reduce the amount of bugs in your code and will especially help with the overall quality of your code. Remember, just as defensive driving can’t prevent you from all accidents, defensive coding won’t protect you from all bugs. It will, however, certainly help you avoid being the cause or reason for many of them and I know your fellow developers will most definitely appreciate that :).