
O'Reilly Gives Away Free Programming Ebooks - Jerry2
http://www.oreilly.com/programming/free/
======
ChristianGeek
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.)

------
morbidhawk
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
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.

~~~
morbidhawk
> 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

------
yhylord
Though off topic, their covers are really interesting.

