Chapter 4 of The Clean Coder starts to explain some practices when it comes to coding. Many do’s and don’t’s, some myths busted, and general good practices are told. It tries to explain that coding is hard and that it shouldn’t be done when one is tired. Not only that but it shouldn’t be done when you can’t focus at all. Not being able to focus on your coding is a route to disaster and prone for mistakes. It even claims that when you are in “the Zone”, a time where you are coding quickly and nothing is stopping you, it’s a mistake waiting to happen. Although coding quickly can yield some results, it’s never perfect. I’ve experienced this myself even. When coding quickly to try and make a due date for assignments, there are usually always errors whereas work that is done over time and at reasonable times, it’s almost always better. The book then goes on to explain about how music and other distractions can also causes errors as well. Although music might help some, the book claims is puts coders into “the Zone” which is where you don’t want to be. You want to be in complete and total control over your coding, not someone else in your head.
Chapter 5 on the other hand talks about something I’ve been told many many times before, and it’s still something I have yet to fully experience or see the point to, and that’s Test Driven Development. I understand the concepts behind it and how it can help, but I just don’t understand why you want to write the tests before you have actual code to test. I want to start with a plan of what I want to write first, figure out what I want to code, and then attempt to start it and THEN test it. Once I have something worthy of testing, I test it. Why would I want to write a test on something that I haven’t even created yet? When creating the program for the test I created, I might even change how it works, which means I have to change how the test works anyways! It just seems silly to me, but to each their own I suppose.
The only thing that I agree with with TDD is that you want to write your tests alongside your code. You wrote something that needs a test? Write a test for it now. That makes perfect and reasonable sense to me. Don’t save writing all the tests for last. By writing your tests as you go, and even testing them, you can see any problems on what small problems you are currently working on, and can fix it now before it can lead to greater errors later on.
Anyway, in regards to what was actually in the book, it just lists some practices on how to conduct TDD. It explains the three laws and how the three laws can lead someone to better structured code rather than a mess of code. However, one needs to practice at it because following the three laws won’t yield perfect results.