Don't buy shitty tech books

Don't buy this shitty book even though it's old and has some stars in review (better read reviews with fewer stars). I'm telling you: don't buy "The Pragmatic Programmer: From Journeyman to Master". It has nothing to do with pragmatic. It simply looks like a book written while travelling, in a break, when tired, while taking a dump etc (you get the idea).

This book can only be good for people that want to chat about programming and have only written short "hello world"-like programs while alive.

---

"Use Saboteurs to Test Your Testing

If you are really serious about testing, you might want to appoint a project saboteur. The saboteur's role is to take a separate copy of the source tree, introduce bugs on purpose, and verify that the tests will catch them.

When writing tests, make sure that alarms sound when they should."
---

So this means that we should test our tests? What the hell is that?

Now really, who in the world allocates budget for testing the tests? It is clearly that who wrote this never understood what developing software means. How much time do you think you need to test your tests when most of the projects don't have enough tests?

Simply idiotic!
---
"Testing Thoroughly

Once you are confident that your tests are correct, and are finding bugs you create, how do you know if you have tested the code base thoroughly enough?

The short answer is "you don't," and you never will. But there are products on the market that can help. These coverage analysis tools watch your code during testing and keep track of which lines of code have been executed and which haven't. These tools help give you a general feel for how comprehensive your testing is, but don't expect to see 100% coverage."
---
Again, it is clearly that this guy (the book was written by two guys) wrote some unit tests for getters and setters and then saw that writing complete unit tests for functions with at least a loop and an "if" is difficult.

As I've written unit test for a safety critical project I had to achieve 100% coverage. Coverage that was not possible was detailed in a report.

Example of code that is not normally coverable (we don't discuss stubs):

~~~
....
handle = OpenFile(...);
if (!handle)
    return;
size = GetFileSize(handle);
if (size != 100)
   return;
if ( !Read(handle, buff, 100) ) // this will most likely succeed
   return; // this won't execute - must explain why
....
~~~

So when I see that sentence with "don't expect 100% coverage" I feel like  I need to shout to the author and tell him to stop writing books. Do whatever you do, I'm sure you're good at what you do, but STOP WRITING SHITTY ADVICES!

100% is totally achievable for most of the algorithms written. Special cases like the one above should be documented and documenting it means that the code is reviewed and expected to work ok even in weird cases (for example when drive is unmounted/disconnected exactly after the GetFileSize function).

So, stop writing shitty advices in books, 100% coverage can be achieved even if it means documenting what's not covered.

Oh, and when I mean 100% I mean 100% for most types of coverage (dc,path, mcdc usually):

http://www.bullseye.com/coverage.html

The only reason you can't achieve 100% coverage is laziness from my point of view.
---
"Even if you do happen to hit every line of code, that's not the whole picture. What is important is the number of states that your program may have. States are not equivalent to lines of code. For instance, suppose you have a function that takes two integers, each of which can be a number from 0 to 999.

int test(int a, int b) {

return a / (a + b);

}"
---
If you write code like that monkey above you surely treat all cases the same when in fact you should be treating special cases separately. A sane person knowing what the 0,999 interval means would write code like this:
int test (int a, int b)
{

if (a > 999 || b > 999 || a < 0 ||  b < 0)
  return -1; // invalid

if (a  ==  0)
  return 0;



// right now a > 0 so we don’t get division by zero since b >= 0
return a / (a +b);

}

Any programmer knows about division by 0. The code from the book is simply ... not relevant.

---
"In theory, this three-line function has 1,000,000 logical states, 999,999 of which will work correctly and one that will
not (when a + b equals zero)."
---

In theory, code like that should never be found on a decent file system. It should be found on some whiteboard, paper or other non-it related communication method. Simply putting such code on a file system is an insult to the IT industry. (I apologize to the industry for publishing it)

And what does he mean by "states"? Because I'm thinking of a state machine but he clearly means something else which is ... only he may know.

---
"Simply knowing that you executed this line of code doesn't tell you that—you would need to identify all possible states of the program. Unfortunately, in general this is a really hard problem. Hard as in, "The sun will be a cold hard lump before you can solve it."

Tip 65
Test State Coverage, Not Code Coverage"
---
Showing such arguments only goes to say that some people don’t deserve to use a computer keyboard, not to mention coding. If special cases are correctly identified then coverage is most likely enough. Writing code like a unevolved monkey is no excuse to create a new “pseudo-science” where state means ... whatever the hell the author wants.

So my advice to you is not to buy this book. It is a book full of crap and stupid advices.

What this book does is like recommending people to put a mattress on front of the car to avoid injuring pedestrians. Looks like a new idea, but it is not applicable and in the end it only proves stupid.

I also have some insights on how these types of books are written but that may be for later. I offer just a hint: don't expect the authors to always be the ones actually writing books.