O'Reilly Gives Away Free Programming Ebooks

http://www.oreilly.com/programming/free/

by Jerry2 • 10 years ago

30 5 10 years ago

These are more like eReports than eBooks and are just a marketing push on O'Reilly's part. (I'm not saying that's necessarily bad, I'm just calling it out for what it is.)

yhylord• 10 years ago

Though off topic, their covers are really interesting.

morbidhawk2• 10 years ago

I started reading the "Real-World Maintainable Software" book and found questionable advice given in the very first section of the book:

The first guideline indicates that our methods should be short, usually no more than 15 lines of code

Why would that be a good reason to break apart code into different methods? 15 lines isn't even that big

We can reduce the number of branching points per unit by moving the validation logic to its own method

Before I follow this advice I'd like to know why branching points per method unit is worse than total number of method branches. This wasn't explained to me and I don't see any reason why it should be a guideline worth following

turtle4• 10 years ago

It's about eliminating cognitive load when reading and/or modifying source later. The more code you can eliminate from what is being looked at, the easier it is for the reader to understand the purpose of the function and what it is accomplishing.

At some point, someone is going to need to change your code. When that happens, it is easier to 'surgically' modify a single method that does one simple thing, than adjust one tiny piece of a much larger function. Even though the change might be exactly the same, it will be easier to understand which callers are affected by the change so you can detect the impact of your modification.

It is a guideline, not a rule. You'll (probably frequently) have methods that logically make sense to keep longer, but if you're writing and find yourself creeping past that, it is a good indicator you might want to review the function and make sure you're not inlining something that might make sense as its own function.

morbidhawk2• 10 years ago

it is easier to 'surgically' modify a single method that does one simple thing, than adjust one tiny piece of a much larger function

I would agree for the most part but modifying one small function might cause unwanted side-effects when that function is reused elsewhere (tooling that reports references can help this). A good descriptive function name could help as well. When a function is not meant to be used in multiple places another option is writing a nested function, there might be arguments against that but that helps keep the number of possible method branchings to a better minimum

O'Reilly Gives Away Free Programming Ebooks

Related Stories