I find a lot of the contributions/articles to be applicable even for designers like:
Simplicity is beauty, DRY, Before you Refactor, Encapsulate behaviour not just state, a lot of the code smells are for the designers to take care of....lest gullible developers fall in the trap! My view is that, well atleast for prgamatic reasons (like time to deliver, lack of training, email to dev and deploy, etc.), developers are generally not good at selecting and building good OO designs or for that matter even system/db designs. They just get the job done. These 97 things have at times crossed that "basic" picture of the develper and have been optimistic about the developers abilities and knowledge and have swerved around design practices. I agree that they are useful to the developer, but weren't there other things, about correct constructs, doing more with innovative uses of constructs, right naming, declaring and ordering of everything from variables to import/includes etc. that could have found a place somewhere?
Java Pal - Your friend in technology and innovation...India.
Many of the items have broader applicability beyond the role of a programmer, but I would disagree that programmers should not be focusing on these things. The question you have to ask is "Why are programmers not good at these things?" rather than accepting that. It is not someone else's job to be good at OO design, it is a programmer's. Programming is design, and therefore good programming is by definition good design.
As for emphasis on other pieces of advice, I agree that there could have been other items that touched on other details, but that is the thing about an open-source book: the content is ultimately dependent on the content that people contribute. Had people contributed specific pieces on these topics, I would have considered them.
I hope that answers your question.
snakes are really good at eating slugs. And you wouldn't think it, but so are tiny ads:
Devious Experiments for a Truly Passive Greenhouse!