Messages

1

Programming / Re: When to use scripting languages?

« on: January 10, 2013, 06:06:57 PM »

Well an important question in coding, one of if not the most important, is 'where does this functionality belong?'. When a piece of code (be it function or class or even application) starts developing an awareness of the world beyond it's very discrete purpose, that is a flashing neon sign that it is time to refactor.

So similar to how you refactor to introduce a configuration when it becomes clear a piece of information doesn't belong in the code, you will introduce scripting when it becomes clear that behaviour has no place in the code.

Where that line lies will depend on a lot of factors so is mostly a judgement call. Experience or requirements for a project can allow or force you to make that call early on. But in the absence of those, it simply becomes a matter of 'when it becomes appropriate'.

2

Programming / Re: Debugging and other helpful things

« on: December 12, 2012, 10:08:12 PM »

I tried Google Test, but I like to do a "Given X When Y Then Z" structure with Test Fixtures, where most logic is in the SetUp ("Given X When Y") and the Tests themselves only contain the Assertions ("Then Z"). Well, sometimes the Given is alone and the When and Then get combined, but not often. Not strict BDD, but more inspired by BDD but without the strict requirements.

Google Tests' lack of Suite support made organising that layout tricky and kept me with UnitTest++. I did use Google Mock, but I like to have "Weak" setups of functions with strong verifications after the calls are made and Google Mock didn't support that.

I use C# at work, where we do TDD in this manner using Nunit and Moq which work very well. But C++ doesn't have the kind of reflection that lets Moq work.

3

Programming / Re: Debugging and other helpful things

« on: December 12, 2012, 05:27:37 PM »

Tests glorious tests. The tricky part is figuring out where the problem is so I can put a unit test around it and fix. If it isn't obvious, Integration tests, debug logging and if all else fails step through. Then it's isolate the parameters that cause the erroneous behaviour with failing unit tests, then fix.

Though none of the existing unit testing or mocking libraries I found in C++ ever felt right or fit my needs and preferred testing style quite right. But I'm growing my own in my latest projects, taking advantage of C++11.

4

Programming / Re: Easy way to store source code?

« on: November 05, 2012, 06:15:24 PM »

I recommend version control. You pick up the basics of git pretty quickly, and it's another tool in your belt.

Plus it allows you to safely experiment and spike out new ideas with a safe roll-back point. Then when the ideas are more fleshed out you can roll back and integrate the features properly.

Most of my code tends to be bug free due to being very loosely coupled with heavy test coverage (so I get near instant feedback if things are not as expected, and can track down issues quickly), though things will still occasionally slip past.

Plus, I like the peace of mind of knowing if things blow up I have a relatively painless way to roll back.

Also issue trackers are a good way to map out features to be implemented, though admittedly not intended for this and github's issue tracker is no JIRA...

5

Programming / Re: Programming habits, standards, and learning.

« on: October 31, 2012, 06:21:07 PM »

Hmm, good habits?

Nowadays I advocate test-driven design. Testable, loosely coupled code that can easily be debugged and refactored? Yes please.

Also red green refactor. Always refactor. Keep the code as clean as possible, you'll regain that technical debt ten-fold when the time comes to optimise, change functionality or extend code. Refactoring is very good. And since your TDD has given you good test coverage, you get instant feedback if you accidentally broke something.