Just about every programming book or OOP example I look at has the annoying habit of prefixing interface names with an I. Yes, IInterface, ICar, IWallet, IMoney, IIAmStupid. It’s one of my pet peeves, I admit, but every time I come across code like this I find myself suppressing murderous tendencies.
Why oh why would you do this? “To clearly indicate that it’s an interface”. Why the hell do I need to know that it’s an interface in the first place? If I want to use your library, I really don’t give a toss whether I’m talking to an interface or a concrete class. If I do want to know (because I’m extending or initialising it) then I’m quite capable of figuring out for myself whether I’m dealing with an interface, abstract class or concrete class. The only thing this random I does is make it harder to look for suitable classes. I want to search for Car, or Wallet, or Money. Not to mention that I don’t want to type that extra letter every single time I’m assigning an instance to a variable.
Seriously, how ugly is this
IFoofoo=IFooFactory.createIFoo();
The irony here is that I used “I” 32 times in this post. But for crying out loud, pick a meaningful name, not some silly prefixed monstrosity.
It’s essentially a high level overview of agile practices, with a focus on the why and the how. Unlike some other books on Agile, this one tries to remain pretty neutral when it comes to methodologies. XP, Scrum, Kanban are all briefly mentioned, but the author managed to boil Agile down to its essentials: common sense, being goal oriented and having a willingness to improve.
During a recent job interview, I was asked to write some code – I know, shocking! The idea was that several test cases had been defined, and that I was to implement a relative simple class that would make the tests pass. The problem was pretty simple, so I won’t bore you with it.
What was shocking, however, was how poorly designed the tests were. Boundary cases were largely untested, and it seemed like someone spent an inordinate amount of time writing useless tests. When I brought this up during the interview, the person who wrote the tests seemed surprised that they weren’t very good, because he got nearly 100% code coverage on the implementation he created.
