I am a huge fan of this book. The Pragmatic Programmer and this book are the two that I recommend most.
When I first read Refactoring, IntelliJ wasn't released yet and refactorings still needed to be done by hand. Automated refactorings are so incredibly useful when it comes to improving code quality over time that I don't know what it was we did without them.
I would highly recommend Refactoring by Martin Fowler. Out of all the books I've read and been exposed to, that one stuck with me the most over the years.
The Pragmatic Programmer, Refactoring (I'm rereading it after many years with the 2018 edition, opinion not totally formed on this one), Working Effectively With Legacy Code, A Philosophy of Software Design. It's been a long time since I've read Clean Code, I don't quite get the hate from the other thread here today so I'm rereading it now. I figure it'll take me a couple days and worst case I'll agree with the criticism and stop recommending it.
The Pragmatic Programmer is one of my favorite books ever. I recommend it to every programmer. At whatever point I'll have employees of my own, it will be required reading.
The Pragmatic Programmer might be useful from an angle of what not to do, and has a good amount of wisdom with regards to refactoring. It's also quite pleasant to read, less technical, more on general patterns to learn from.
It's one of the classics of our trade; Even if you know everything there is to know about refactoring you should really read it just to have read it. So consider that my recommendation :)
Clean Code (2008) is at the top of my Books I wish I'd read 10 or 20 years earlier list, along with Refactoring (1999). They totally transformed the quality of my finished programs, in many ways. Some what I learnt may fit into "That's so obvious, why didn't I think of that", or making conscious the things you already do... Refactoring, just by naming and defining the activity, was useful. They're both talking about the programming equivalent of editing for writers. And how to do that, how to get from the 'dirty code' first draft to the 50th draft with everything as good as it can get. Do your future self (and other people) a favour - they're the ones who will have to read and understand your programs.
A couple of years later I came across Allen Holub's Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ Programming (1995). I didn't learn anything from it, but it contains almost all of what's in those 2 books, and was written years earlier, (so could have been read earlier), and I think he deserves more credit.
When I first read Refactoring, IntelliJ wasn't released yet and refactorings still needed to be done by hand. Automated refactorings are so incredibly useful when it comes to improving code quality over time that I don't know what it was we did without them.
reply