Clean Code - the most valuable bits

Half way through clean code by uncle bob and for those that are pretty lazy and don't want to read the book (although it is pretty damn good tbh) I just wanted to offer a quick guide on some of the more important points the book touched on.  I learnt a good bit from this book and would heartily recommend it to anyone wanting to perfect their craft...

1. Audience Perception
One of things that is touched on a number of times is the view of somebody else reading your code and how they interpret it.  A little like the consumer of a class view of when we write our unit tests, we should take the view of an outsider reading this code.  Probably one of the most important concepts in the book.

2. Think about the function names
he means, really think about your function names.  Whilst most of us think that a function name will do, the book forces us to take a little more time and effort into really conveying what the name of the function should be.  I am as guilty as anyone else regarding this one and have now adapted my thinking when ever I create a function to see if it really does describe the intent of the function.

3. Order of code
If your like me and started coding just after the dinosaurs came, then you will find you are fixed into defining functions before they were used.  Don't have to do that these days.  Basically, Bob states that a unit of code should read like a book with the detail appearing after the more abstract code at the top, you should be able to read from the top of the code and then go down the page to get extra detail if required.  good point.

4. Functions should be small !
Smaller functions are easier to understand and comprehend straight away, there is nothing worse than ploughing through 200 lines of code to try and understand what is going on.  The book insists of smaller functions with better naming.  Smaller functions are easier to refactor, understand and reuse.

One of the side effects of using smaller functions can be larger solutions and I hear the argument about large solutions with lots of projects are confusing, personally, I don't agree.  If the projects are named correctly then their intent is obvious and again, a great deal easier to reuse, swap out etc.

Ok, will update this again later but a few really valuable points to start with.  Check out here later for more.
Happy coding !

Ever wanted config transformations for all your project types in VS2010???

Hi Everyone,

in case you didn't know, when they released VS2010 and config transforms were actually built into web projects
myself for one needed a new change of underwear due to excitement... hey I'm married, have kids so I get excited about toy cars, the night garden and new VS2010 tools built into the IDE.

I then created a windows service project only to have my excitement then turn into questions of WTF??  why web projects and not others...

Well if you didnt know of a cool little project called Slow Cheetah basically a VS package that installs and then lets you trasform not only your app.config and other configs but also any Xml file in your project ! get it here :

http://visualstudiogallery.msdn.microsoft.com/69023d00-a4f9-4a34-a6cd-7e854ba318b5

I can go back to watching the night garden again hurah !