O'Reilly Site Lists 165 Things Every Programmer Should Know (oreilly.com)

97 Things Every Programmer Should Know was published seven years ago by O'Reilly Media, and was described as "pearls of wisdom for programmers collected from leading practitioners." Today an anonymous reader writes: All 97 are available online for free (and licensed under a Creative Commons Attribution 3), including an essay by "Uncle Bob" on taking personal responsibility and "Unix Tools Are Your Friend" by Athens-based professor Diomidis Spinellis, who writes that the Unix tool chest can be more useful than an IDE.

But the book's official site is also still accepting new submissions, and now points to 68 additional "edited contributions" (plus another seven "contributions in progress"), including "Be Stupid and Lazy" by Swiss-based Java programmer Mario Fusco, and "Decouple That UI" by tech trainer George Brooke.
"There is no overarching narrative," writes the site's editor Kevlin Henney (who also wrote the original book). "The collection is intended simply to contain multiple and varied perspectives on what it is that contributors to the project feel programmers should know...anything from code-focused advice to culture, from algorithm usage to agile thinking, from implementation know-how to professionalism, from style to substance..."

Comments

Lots of links to articles, phfft

[Snotnose]

Anyone wanna summarize the list so I don't have to read 160 articles to see if I agree/disagree with them?

That said, I trust O'Reilly to produce quality books. One fail (Make) in maybe 20 books I own from them is a good record.

/ The Gnu make manual is the best Make doc I've seen.

Re:Lots of links to articles, phfft

[geoskd]

I'm sorry, but a program that's thousands of methods and small classes is not clearer than a program with fewer, larger, structures. Yes, write code for Humans, not machines, I agree. BUT remember your other programmers want to understand your program - not any one individual method - so making each method simple only moves the complexity into the interrelationships between methods, something considerably harder to understand.

What the author was implying is that you should take relatively straightforward components of a function and break them out as their own sub-functions with a very descriptive name, especially the inner workings of nested loops. If you take the inner loop and replace it with a function call that describes what the inner loop does, then your outer loop actually gets much easier to read, as it does not have the distraction of the gritty details of how the inner loop performs its duties. With properly written sub-functions, you can simply read the name and understand what it is doing without having to actually read the function at all. I have personally done code reviews on code that has been re-factored in this fashion, and the readability of the code is night and day.

Good book for getting back into Java...

[__aaclcg7560]

This week I had to install Ant to automate some Python programming tasks. Of course, Ant requires Java. I haven't touched Java since I graduated from community college 10 years with an A.S. degree in computer programming and had to learn all flavors of Java because the CIS department couldn't afford to renew the Microsoft site license for Visual Studio, and, when the site license got renewed, none of the computers could run VS .NET. I really wanted to learn C++ instead of Java, but industry surveys showed that local employers wanted VS C++ and not GNU C++.

Anyway, Ant renewed my interest in Java. Any good O'Reilly book to get back into that language?