Book Review: Code Complete, 2nd Edition

Code Complete by Steve McConnell
My rating: 5 of 5 stars

This book provides a solid foundation of the things you need to “construct software”, as the author describes it, and covers a very broad topic.

The author isn't shy about referring the reader to additional reading materials; in fact, that’s a big part of the book and I love it!

The book goes over things that were barely mentioned, if at all, in my college courses. Things like: debugging, refactoring, measuring code complexity, when the right time to optimize code is and whether it even makes sense to optimize it. The author does a good job of showing different approaches to solving problems and gives many examples of “good” versus “bad” practices.

On the surface this book is similar to The Pragmatic Programmer, but goes in to a lot more depth. The book goes well with Clean Code.

View all my reviews

Create your personal brand

I love channel9.

If you've never heard of it, you should definitely check it out. It’s a site filled with interviews, keynote speeches and demos in video format. It’s one of my favorite learning resources.

I was browsing channel 9 the other day, and came across this keynote. In it, Scott Hanselman talks about social networking, something that I’ve never been really crazy about. Despite my aversion to the topic, the title interested me, so I watched the hour long video clip (and the 25 or 30 minute follow up).

Scott argues that every developer should have a blog and use twitter, I’ll leave the details to the video, but the gist of it is that you should think of it as creating your own personal brand.

I liked the idea of a personal brand so much that I extended the concept to that of a virtual business for my online “persona”, to steal a term from Alan Cooper. By thinking of my online self as a business, I can filter what I am willing to blog about by whether or not it’s good for the business. I know, it’s a bit silly, but it makes me more comfortable with the idea.

Once I changed the way I was thinking about it, I had a philosophical moment where I realized that, not only can I apply this to blogging and my career, but the concept could be applied to virtually all aspects of life. It reminded me of a podcast I listened to a while back about relationships.

I think it could be interesting, as well as, motivating to come up with a mission statement and a set of business rules. At the end of the day though, I think it will make me a better developer and that is what really matters.

Book Review: CLR via C#, Third Edition

This book was 29 chapters of awesome, and if I had to pick a favorite book this would be it.

Jeffrey Richter starts off by explaining how the CLR’s execution model works and how to package and deploy applications.  The book covers how to use and design Types, how the garbage collector manages resources as well as threading.

The author does a really great job of explaining everything, and is careful to point out what his personal preferences are and why. The material in this book lays a solid foundation for development using the CLR, C# and the .NET framework.

This book is going to be a great reference.

Book Review: Clean Code

When I read the first few chapters of this book, I wrote about my initial reaction. Now that I’ve completed the book, this is a follow up.

This book is basically split in to two things: organizing your code so that it’s easy to read and following “good” OO practices. A great deal of the information presented in Clean Code is Robert C. Martin's personal preference, he’s very upfront about that, and what he has to say throughout the book makes a lot of sense.
The first part of the book makes it seem like writing clean code is relatively simple:

• Use unambiguous names for variables and methods.
• Comments should say things that the code can't say for itself.
• Keep methods small.
• Write unit tests.

Organizing your code as the author suggests, will make it very easy to read.

The trickier part has to do with the OO principles that are covered.
Knowing when you've violated SRP, OCP or if your methods have multiple levels of abstraction can be more difficult.

Fortunately, there are some nice examples in the book that the author walks you through. This is something that is clearly going to take practice and discipline to master.

All of the examples are in Java. I use C# at work, so I converted the examples to C# and refactored them alongside him. I found this to be very helpful.

In addition to covering the importance of unit testing and the role it plays in keeping your code clean, the author has listed all of the advice at the end of the book. This makes for a handy reference to ensure that you are writing clean code and is listed under the heading “Code Smells”. The list includes advice from the author as well as Martin Fowler.

I enjoyed the book and look forward to mastering the techniques that were covered.

* Update *

I found a video clip of Robert Martin where he presents a lot of the points in this book.
It's a little under an hour long and despite the fact that he rambles a little bit for the first 8 or 10 minutes, it's worth watching.

Does function size matter?

I just finished the 3rd chapter of Clean Code by Robert C. Martin and I feel like my brain has exploded.

I couldn't resist writing a post about what I've read so far, to see what others thought about it. Even though I'm only at the very beginning of this book, I can tell I'm going to like it.

• The first chapter talks about what makes code "clean" (according to the author and a number of developers that are considered industry leaders).
• The second chapter talks about meaningful names, what makes them important, along with some examples. Interesting, but nothing super exciting.
• The third chapter is all about functions. This is where I had a mini freak out in my head.

The author believes functions should:

• use descriptive names
• be small - about 2 or 3 lines each
• do one thing and do it well
• only have 1 or 2 arguments passed to them, preferably none
• have one level of abstraction

This ends up resulting in a LOT of functions. The author argues that if you do this, your code becomes very easy to understand and reads from top to bottom, like a story.

I've never given much thought to the size of my functions before, but 2 or 3 lines seems exceedingly small. I tend to write functions that are 6 - 10 lines.

I've never given ANY thought to the levels of abstraction in my code, in fact, I didn't even know what that was before I read about it. In case anybody else has never heard of this term, the idea behind it is that everything in the function should be at the same level of granularity. Here is a nice definition from Wikipedia and a post on stackoverflow with a good example.

The author argues that it can be confusing if you don't follow this principle because you aren't able to tell whether an expression is an important concept or a detail. Mixing the two in a function is just as bad as falling to be weary of the broken window theory.

If having code that is easy to read and maintain isn't compelling enough for you, and you are programming against the .Net framework, you might be interested to know that Jeffrey Richter, in CLR via C#, points out that code converted to IL is evaluated on a method by method basis. This means that a method isn't evaluated until it is actually needed - this makes your code run faster. Additionally the CLR optimizes the code by "enregistering " variables in the method, but only if it is small enough. Unfortunately Jeffrey doesn't specify what a "small" method actually is.

Book Review: Pragmatic Unit Testing

I didn't even know what unit testing was before I picked up this book.

At not much more than 150 pages, this book is small. It's part of a series called "The Pragmatic Starter Kit". That series is part of a larger series of books that started coming out after "The Pragmatic Programmer" was published.

I LOVE what unit testing promises. To be able to incrementally build code that is known to work AND be instantly alerted when you break it is very, very cool.

The book goes over the NUnit framework, walks you through the initial setup, and shows some unit tests in an example project.

After reading this book, I have no idea how to write a useful unit test.

My guess is that it must take a lot of experience to do it well and might even be a bit of an artform.

The book talks about testing principles, fence post errors, mock objects and edge case scenarios. Things like: testing for null or handing a pre-sorted algorithm to a sort algorithm.

None of that really helps me.

Because of this book, I understand why it's a good idea to write unit tests and what the common reasons are that developers give for not writing them.

Even though I scratch my head a lot when I try to write a unit test, I've started using them. I open the book up, look through the examples, and skim the chapters looking for an appropriate example. Most of the time I feel like I'm missing something.

I'm wondering if I need to read a different book, one that has more concrete examples or find an open source project that uses unit tests.

Book Review: C# 2010 for Programmers, 4th edition

This book isn't for everybody. I found it to be perfect.

My first programming course in college was taught with the "C: How to Program" book by Paul and Harvey Deitel. I think that made this book feel very familiar to me. The difference between the "How to Program" and "For Progammers" series, is that the former includes practice exercises, the latter does not.

I really enjoy the Deitel books, and don't mean to make this sound like a negative review; however, I think the title of this book is a little misleading. The book's title should have been something more like: Intro to .Net development using C#.

In my opinion if you are an experienced developer that needs to pick up C# and .Net, you will probably be disappointed with this book. I think you can probably get what you need from google and some trial and error. On the other hand, if like me, you are a newbie and haven't done much programming and haven't had a chance to become familiar with OOP, XML, UML, etc, then I highly recommend this book. Reading this book will introduce you to the basics I just mentioned as well as C# 4 and .Net, Silverlight, WPF, XAML WCF, Windows Forms, Visual Studio and SQL server express.

The book is well written and offers the classic Deitel "tips" (common programming errors, software engineering tips, etc), that said, it feels like an introductory programming book that you can save a few bucks on because it doesn't have the exercises that you would find in a classroom textbook.