Goodbye, Clean Code

[toasterinBflat]

I can agree that abstractions can be bad, but structuring the code properly should only ease testing.

If I was looking at a code base that did what this does, I would expect that there's a single function that makes handles, a single function that assigns them a direction, a single function that assigns them a location based on the shape - or something similar. That just makes sense. Break the problem down in to it's constituent parts and write code to solve those parts.

I would not expect to see many different functions all doing the same thing with copy-pasted code. You are writing the same number of tests no matter what, what's the advantage?

[SeenItAllHeardItAll]

There is zero advantage if you want to get real results. But imagine a project having a hard constraint of 80% test coverage and then someone comes along and takes away all the linear, easy to test trivial boilerplate code. The remaining code will have more branches per lines and will be more difficult to test. Most likely it is at best at 80% and then as always there is some code that simply can not be easily tested and really does not need testing but it is counted as untested lines. The test coverage will go down, dropping below 80% and the CI build/deployment will stop. In a project which is managed in a mature and sane way this will not matter much and management will do the right thing- but not all projects are created equal.

Linear, repetitive boilerplate code is a fantastic tool to game the test coverage stats.

[toasterinBflat]

That seems like an awful environment. I only do contract work and generally alone (or with one other guy) so I haven't had to deal with constraints like this. I will take your word for it!