Point 2 is somewhat of a difficult area on my opinion. When looking at programming books, I usually have the following process in mind: * How in depth are the

Point 2 is somewhat of a difficult area on my opinion. When looking at programming books, I usually have the following process in mind: * How in depth are the official docs? If you're going to read a book on a language, you need a way to validate the book's contents. How else will you be able to tell the book is not leading you down the wrong learning path? This also gives you a chance to check on if the language is right for you. * How old is the book? If the book is talking about the language 5 years ago, chances are syntax and ways structuring your program (object oriented features may have gotten better for example) have changed. Make sure you have the most up to date edition, and complement it with checking the API docs. Well written API docs will generally indicate if a way of doing something has changed, or will no longer be supported. * Look at the author of the book, and see how close they are to the community of the programming language in question. Are they the creator? Contributor? Someone else? * What is the book trying to achieve? Some great books expect you to have basic knowledge of the language, or some other specific concept (MVC for example). Make sure you know what you're getting into. Some books also act as "desk references" that could be potentially replaced by more up to date API docs on the language's website. There's probably much more that can be added to the list, but I think these provide a basic sanity check.