Refactoring Thumbnails

It is a cool way to view refactorings.
http://refactoring.be/thumbnails/ec-proxy.html

How OO are you?

I once introduced a very smart C coder to C++. I had the pleasure of working with the guy, and what impressed me most was how he followed a coding standard of his own invention.

Namely:
* All methods take as their first parameter a structure.
* Only methods related to a structure lived in the same .h and cpp files.

Basically the guy was doing OO and didn't know it.

So... What is the opposite of OO?

I recently had to interview a guy that claimed to know C++, Java, C# and more. In the interview it turned out that he didn't like objects and preferred to just use functions and global variables. In Java, for example, his code would consist of a single class containing all methods and variables.

It seems that Procedural and OO are different ends of some spectrum. Which makes me think 'Where about on this spectrum does my code live?' I hope its up the OO end. That's my aim. I have found that TDD has help me move much closer to the OO end than I thought possible. I am going to make a conscious effort to see if I can get any further away from procedural code.

Basically I am going to try to make all method bodies as small as possible (try to get to one line) and use objects not basic types (try to pass at most one parameter to each method). Also I'll make sure no methods have any side effects. :)

We'll see how I get on.

Hungarian Notation is good? Since when?!?

Wow! It seems that the completely pointless naming standard I was taught years ago called 'Hungarian Notation' was a misinterpretation of a slightly more useful coding standard.

Check out JoelOnSoftware for the details : Making Wrong Code Look Wrong
http://www.joelonsoftware.com/articles/Wrong.html

Refactoring is optimization

Refactoring is a form of Optimization. You are optimizing the code for maintainability and clarity.

The rule of premature optimization is that you don't do it till you need it. This prevents you spending time optimizing code that doesn't need it. You measure where you need to optimize before optimizing. In reality the optimizations needed are never where you would have guessed. So the question is... In the case of refactoring, what is premature optimization?

In my opinion, premature optimization is when you design the code before you write it. You are guessing at what concepts you are going to need to hold in the code, and not being driven by the actual need of the system. You end up over-designing system that a simple solution would work just a well for. (see YAGNI).

Hence the order of Red, Green, Refactor.
* Red - Add an idea to the requirements.
* Green - Add the concept to the code.
* Refactor - Distill the new concepts for clarity.

Note that refactor is after the idea is in the system, not before!

These thoughts came out of a chat with Simon Harris the other week.

What the hell was MSWord thinking?

Right
Resharper makes an icon appear to say 'I know how to do some stuff with the thing you have highlighted'. The user is not interrupted. The code doesn't change without being asked (well except in Visual studio's VB editor, but that doesn't count).

Wrong
MSWord changes stuff while you type without asking. It then highlights the changes to give you the chance to undo them. I spend more time undoing the mistakes it makes with its guesses than any possible benefit I get from its changes.

Editors should be intelligent, but they should offer assistance when asked, NOT when they feel like it.