Reading & Obfuscated code

Not every thing is readable

Today started differently than others as there was no morning kata, so instead I ended up reading a few articles of interest I started with code golf (trying to solve a problem with the fewest characters possible) and then International Obfuscated C Code Contest which one of it’s goals is to To show the importance of programming style, in an ironic way.

Looking through some of the solutions from the code golf stack exchange and some of the winners code from International Obfuscated C Code Contest is an interesting way to understand the need for descriptive names in source code.

Readable

After that reading something that was made to understandable seemed like a good idea, one of the tasks from my back log was smoke tests, integrated tests and unit tests some of the terms where not familiar with me si read a little about each of them on http://softwaretestingfundamentals.com/. In short:

• Smoke tests checking something does not break or catch fire when you use it, an example would be can it compile?.
• Unit tests a unit is the smallest piece of testable code, like a method or function, a unit test is checking it works as intended.
• Integrated tests test for piece of code comprised of multiple units, these tests are run to check the units are interacting as expected.

Soon after I went on to use a unit test first approach to a programming exercise. At first I started with writing tests for functionality required to complete the task and found my self writing a few tests then writing a function to pass the tests then occasionally writing a test that required a dedicated function and eventually I ended up with enough “units” to implement a full solution.

Creative and defensive programming

The chapter from learn c the hard way was titled creative and defensive programming, which in short are two mindsets to use when programming. Initially start by solving the problem in a creative way then refine the result with a more defensive mindset which would include checking inputs to functions, writing safer versions of functions in the standard library, adding more meaningful assert messages and refactoring the creative solution in to a more resilient program.

I thought this was an interesting idea so I went about another advent code, writing a test first then unit inside of test so I could quickly see what works and identify other functionality that would be required.

Written by Marc McIntosh Find him on github