Clean Code Book Recommendation

IamtheWalrus

I am a Java programmer with 5 years experience. I would like to find a good book on how to become a better programmer, how to write good, clean code. Can anyone recommend me a good book on this topic?

Is the following any good?

http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

Colonel Panic

The goto (:D) books for becoming a better programmer are Code Complete and The Pragmatic Programmer. Relevant regardless of language.

IamtheWalrus

Colonel Panic wrote: »

The goto (:D) books for becoming a better programmer are Code Complete and The Pragmatic Programmer. Relevant regardless of language.

Have you read either?

Colonel Panic

I haven't read The Pragmatic Programmer in a long time, but I've read Code Complete or parts of it many times over the course of my career.

My impression of Clean Code from the reviews and a quick Google is that it's a collection of "don't do this" style articles, not something that would help you become a better programmer.

Sparks

Haven't read Clean Code, but it raised an eyebrow reading the amazon blurb. When your title is "A Handbook of Agile Software Craftsmanship" and your content seems to be about the mechanics of the code itself (as opposed to how you do all the stuff that goes around the coding, which is what Agile is meant to be about), I start to wonder about the content. Mind you, that could be more down to Amazon than the book, and it has been recommended by a few others, and I don't care too much for the "agile" buzzword on my books so that one pushed a button or two for me :pac:

Code Complete and The Pragmatic Programmer, as said above, are deservedly well-known classics and really should be on your reference shelf and well-thumbed at that. Programming Pearls might be more in line with what you're looking for, but it's mostly in C rather than in Java.

You might also find the recommended books sticky useful btw.

IamtheWalrus

Thanks all. My The Pragmatic Programmer arrives tomorrow.

fergalr

I've read each of Code Complete and The Pragmatic Programmer, all the way through, and re-read them several years later. 5stars each.

Code Complete might be a little dated, but they are both worth it.

Was less impressed with the Practice of Programming and Programming Pearls. They are good books, but not as pragmatically useful, imo. 4 stars.

Art of Unix Programming is interesting reading too, on a similar topic (some really good stuff, but got to filter it a bit) 4stars.

Effective C++ is good too, especially for C++ :-) 4stars.

Rapid Development is worth a look too, from a project management point of view, 5stars.

I do not recommend the GoF design patterns book. 2 stars.

IamtheWalrus

fergalr wrote: »

I've read each of Code Complete and The Pragmatic Programmer, all the way through, and re-read them several years later. 5stars each.

Code Complete might be a little dated, but they are both worth it.

Was less impressed with the Practice of Programming and Programming Pearls. They are good books, but not as pragmatically useful, imo. 4 stars.

Art of Unix Programming is interesting reading too, on a similar topic (some really good stuff, but got to filter it a bit) 4stars.

Effective C++ is good too, especially for C++ :-) 4stars.

Rapid Development is worth a look too, from a project management point of view, 5stars.

I do not recommend the GoF design patterns book. 2 stars.

Great post. Thank you.

Stark

IamtheWalrus wrote: »

I am a Java programmer with 5 years experience. I would like to find a good book on how to become a better programmer, how to write good, clean code. Can anyone recommend me a good book on this topic?

Is the following any good?

http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

It is a very good book in my opinion. At least it certainly saved me doing a lot of painful stuff in my job when I introduced it to managers and tech leads there.

No more

/*
This is an integer indicating the maximum value
*/
private int maxValue

thanks be to Christ. "Why do we need these comments? Because that's what you're supposed to do. Well I have this book that says you shouldn't. Oh?"

Tbh, it is quite an opinionated book. Think "Javascript: The good parts" but for Java. Good if you want to lay down sensible coding standards for a team and want an external authority who doesn't teach stuff that's quite dumb but seldom challenged like more comments than code or checked exceptions all over the shop. But don't expect to get away with using the coding styles in any job.

It is very Java specific but you're a Java programmer so that shouldn't be too much of an issue.

I haven't read Code Complete or the Pragmatic Programmer though so can't compare with them.

fergalr

IamtheWalrus wrote: »

Great post. Thank you.

Welcome.


Also, its worth saying that as you've got five years experience, you are inevitably going to know most of the stuff in any book you read already.

However, you'll hopefully understand the advice given in the books at a deeper level as a result, which might be helpful.

All these concepts are layered like an onion.

It is a bit like people talking about simplicity and complexity. I still don't understand 'simplicity' as well as I should - in terms of the art of creating a simple system; every now and then I think I do, and then later I learn I haven't been looking at the whole picture. (I think this was the last talk I watched that I got insight from was this one by Rich Hickey: http://www.infoq.com/presentations/Simple-Made-Easy)


I first read Code Complete early in college, and the Pragmatic Programmer when I was maybe in fourth year. I read them both again in maybe 2008 (four years later). The second time I read them, a lot of what was in the books was fairly second nature. Partly because I read them before, but also just because I had 3/4 years of decent experience then.


The other thing is the average level of the Software Industry as a whole gets better.

AFAIR there's a bit in the Pragmatic Programmer where they talk about using version control. Pretty much everyone does that now*; when the book came out first it was slightly less mandatory; standards improve over time.
E.g. Continuous integration is starting to become a common thing now, but I don't recall being mentioned in Pragmatic Programmer (it's been a while though).

I got more out of Rapid Development, which I read around 2006/2007, as I was learning more about project management then, at a higher level than the nuts and bolts of coding.

Joel On Software is worth a quick read through as well.


*Yes, for any statement of "pretty much everyone is at that level" there'll be loads of enterprises who aren't - but you know what I mean, the bar is slowly (though non-monotonically) raising, the tools are getting better.

Sparks

fergalr wrote: »

Joel On Software is worth a quick read through as well.

Definitely not for any beginner, and for any adept, only with a metric ton of salt...

ChRoMe

While its slightly high jacking the thread, any suggestions for unit testing books in a similar vein?

fergalr

ChRoMe wrote: »

While its slightly high jacking the thread, any suggestions for unit testing books in a similar vein?

Yeah - we've been discussing them.

I'm actually sort of serious...
Seeing as you've hijacked the thread and all (!) let me wade into it:

I think testing is way over-discussed at the moment (is TDD still being hyped?).

Testability is really just a symptom of good code.

Telling people to make their code testable, and putting all the emphasis on that, is a coping strategy.

If a terrible programmer writes their code to be testable, it probably won't as horrific as it otherwise would, so I can see why people say 'make your code testable'.

But you have to be careful with coping strategies - they mislead you in the long run - they are local maxima.
I don't think we should be focusing on making code testable, so much as we should on writing good code.


If the book tells you, like the OP asked for:
"how to become a better programmer, how to write good, clean code."
then that code will be testable, or fairly testable anyway.

And for the same reason you don't write comments that say:

int i = 5; //set of the value of i to 5

there's a limit to what should be tested.

You should only test complicated stuff, stuff that might get complicated, or stuff that might break. And only after you've tried really hard to make it simple and 'see-through' first.

You know, loose coupling where possible, simple code, be very careful with state; and then just test fertile sources of bugs, test to avoid breakage during refactoring, or when adding efficiency required complexity.

Spend most of the time trying to make simple see-through code.
(I'm not saying you don't know this)

fergalr

Sparks wrote: »

Definitely not for any beginner, and for any adept, only with a metric ton of salt...

Totally agree; plenty of provocative insights too, though.

Sparks

fergalr wrote: »

Testability is really just a symptom of good code.
Telling people to make their code testable, and putting all the emphasis on that, is a coping strategy.

I'm not sure my skepticism of all things agile runs that far
If you can't test your code, you can't be sure it runs properly; whether that test is "it starts and doesn't segfault" or whether it's the hourly report from the CI server, in both extremes your code is testable.

The idea behind unit testing is to do with the granularity of the tests, not the idea of testing itself.

And whatever about TDD (which I think is an interesting tool but not one you can use in every situation), unit testing as an tool in and of itself is pretty damn snazzy and I've missed it terribly in projects where it wasn't available (and no, it's not always simple to add it in, large legacy projects can mean that adding in unit testing requires investing man-years of work into an effort that produces no features for Sales and Marketing to tout to customers).

I mean, if you can test a specific method/function/object/module independently of the entire system, that makes your life so much easier. I've worked on code where a sanity test required four machines all running test code for upwards of twelve hours; any glitch on any machine in any of the test code and that rendered the test invalid most of the time (and that's the sanity test, not the full-blown all-up test). That's a deeply frustrating way to work. Compared to that, unit testing is just the bee's knees.

But in terms of specific references for unit testing, I just have the O'Reilly book on Unit Test Frameworks; I don't think I've come across a generic UT book that I'd recommend as the Pragmatic Programmer of unit testing, not yet at least. And I'm not even sure I'd recommend Unit Test Frameworks over online sources at that.

counterpointaud

I have Robert Martin's book, Clean Code, mentioned in the OP. It's a very good read with some great real-world techniques IMO. His series of videos of the same name are also worth checking out, even if only for his eccentric delivery.

I'm definitely a fan.

With regards to testing, I've heard good things about 'Working Effectively with Legacy Code'

Sparks

counterpointaud wrote: »

With regards to testing, I've heard good things about 'Working Effectively with Legacy Code'

It's not bad, but it's rather based on the idea that you can add unit testing to the legacy project. If you can, sweet; if you can't, it's not as useful (still definitely worth the read though).

IamtheWalrus

In terms of making myself more valuable to an employer as a developer, do you think it's best to be a jack of all trades or a master of one? Should I concentrate on being a standard Java stack whiz (Hibernate, Spring, etc) or should I pick up new tech in my free time?

If I am going for a Java dev job, won't it be beneficial for me to really nail the Java side instead of trying, say, .Net at home? If I have no commercial experience of a particular tech, isn't home-learned tech useless to an employer?

edit: Think my new book has answered my question.

"It doesn't matter whether you ever use any of these technologies on a project, or even whether you put them on your
resume. The process of learning will expand your thinking, opening you to new possibilities and new ways of doing
things. The cross-pollination of ideas is important; try to apply the lessons you've learned to your current project.
Even if your project doesn't use that technology, perhaps you can borrow some ideas".

moycullen14

IamtheWalrus wrote: »

In terms of making myself more valuable to an employer as a developer, do you think it's best to be a jack of all trades or a master of one? Should I concentrate on being a standard Java stack whiz (Hibernate, Spring, etc) or should I pick up new tech in my free time?

If I am going for a Java dev job, won't it be beneficial for me to really nail the Java side instead of trying, say, .Net at home? If I have no commercial experience of a particular tech, isn't home-learned tech useless to an employer?

edit: Think my new book has answered my question.

"It doesn't matter whether you ever use any of these technologies on a project, or even whether you put them on your
resume. The process of learning will expand your thinking, opening you to new possibilities and new ways of doing
things. The cross-pollination of ideas is important; try to apply the lessons you've learned to your current project.
Even if your project doesn't use that technology, perhaps you can borrow some ideas".

That's always a tricky one. There are a number of distinct areas that you need to consider:

1) How to get past the agent/HR doorkeeper
2) How to 'pass' the technical interview
3) Can you actually do the job.

With 1), you're generally dealing with non-techies and it is a question of 'matching'. If the agent/HR wants J2EE/Spring, he needs to see that on a CV.

2) really depends on the company. The better ones will be able to separate out knowledge from experience, others - alas - won't. If you have Java as a skill, they would expect you to know the ins and outs of Collections, say.

3) The one that reall matters. If you are smart, diligent, willing to learn
and can get on with people, chances are you'll make a good developer. Specific skills can be learnt.

I'm assuming in the above that you are coming to an environment that is reasonably mature. The skills required to introduce a technology ecosystem are very different and really require someone quite 'senior'

goalscoringhero

I've read Clean Code and it's relative, The Clean Coder.

Clean Code definitely makes my list of reference material that you'll find yourself coming back to in years to come. Not everyone may agree exactly with what is laid out there (which coding standards to use, how high the ratio of unit test coverage), but that doesn't matter. Important is that these concepts are talked about in your development environment, and that agreement is reached there (and that will be different for each environment). I can definitely recommend it.

The Clean Coder is more a collection of examples of situations you as a developer will find yourself in at times - in relation to your peers, your managers, etc . It suggests good attitudes developers should get accustomed to in order to manage expectations, be seen as reliable and crush stereotypes. I didn't find it as good as Clean Code but it was still a valuable time spent reading.

fergalr

Having looked at the table of contents, and looked at a few random pages, I'm going to add 'Clean Code' to my reading list.

It looks like its written in a bit of a silly style (?) but the topics seem sensible, and the attitude seems good:

From the book:

Readers shouldn’t have to mentally translate your names into other names they already know. This problem generally arises from a choice to use neither problem domain terms nor solution domain terms.

I wish mathematicians knew this, actually.

Sparks

fergalr wrote: »

I wish mathematicians knew this, actually.

+oh, let's say infinity...

IamtheWalrus

I'm on the last chapter of The Pragmatic Programmer. Although I've enjoyed the read, I've found it very high level and maybe geared towards a complete novice. Glad I've read it all the same.

Can anyone recommend me more books that are 'must reads' for developers? My contract comes to an end in a few months so I'm trying to prepare myself for interviews/new role, and become an all round better developer.

Some have recommended Code Complete. Will I benefit much from also reading that book as well as The Pragmatic Programmer or would my limited time be best spent elsewhere?

There are 900+ pages in Code Complete. I've read that it was useful because of its time, and is a bit verbose. It's been suggested that Clean Code does the same job but more concise and is more practical. I'm leaning towards Clean Code.

Merrion

In terms of must reads for getting a new role I'd recommend an architecture patterns type book - for example Martin Fowler's rather cumbersomely titled Patterns of Enterprise Application Architecture.

In my experience, it is becoming quite popular to ask candidates about patterns they have used and to then ask to explain the what and why of these patterns.

mewso

Clean Code is an excellent book imo. I'm surprised more people haven't heard of Robert (Uncle Bob) Martin actually. The only minor negative is not all of it will be relevant but the bones of it will be to most programmers.

Mind you if you like naming variables/methods so that anyone can understand them, know what loosely coupled means (and write loosely coupled objects/unit tests) and have a strong suspicion of the "always comment your code" rule then you may not benefit as much as someone with less experience.

IamtheWalrus

I'm half way through Clean Code and am enjoying it. It's pointing out a lot of bad habits I have. I just hope I don't forget them when I've finished the book. Does any one think, to really get the concepts to sink in, that I should read a similar book on good coding or move to a new area? If a new area, which one?

I've been thinking about 2 potentials: TDD or design patterns. What do people think of those?

Merrion: have you read Patterns of Enterprise Application Architecture?

Merrion

IamtheWalrus wrote: »

Merrion: have you read Patterns of Enterprise Application Architecture?

I have indeed - but it's more like Petzold (I.e. a book to have on your desk to dip into as needed) than Code Complete etc.

It's worth reading Martin Fowler's articles on this kind of thing as well.

Giblet

Eric Evans, Domain Driven Design. Getting a little old now, but solid. Or is that SOLID?

GreeBo

For java, Joshua Bloch's effective java is pretty darn good.

http://www.amazon.com/gp/aw/d/0321356683&cd=10&ved=0CHgQFjAJ&usg=AFQjCNEyRshCN8jsHMq8r31I6IEU6hmckg&sig2=1nvQiKz9oiogRlmEaRIf7w

IamtheWalrus

I've decided to tackle TDD next. Can anyone recommend me a good book to teach me this?

Has anyone read this?

Test Driven Development - Kent Beck

This one seems to be getting better reviews: Growing Object-Oriented Software, Guided by Tests

Talisman

IamtheWalrus wrote: »

This one seems to be getting better reviews: Growing Object-Oriented Software, Guided by Tests

Have a listen to this podcast with the authors.

068 RR Book Club: Growing Object Oriented Software Guided by Tests