1. I believe its referring to unit testing. The more of your codebase that is covered by unit tests, the more code coverage you achieve. In a perfect world, you write unit tests that cover 100% of your codebase.

  1. Regarding Number 4, I believe it’s more appropriate to learn more patterns and understand how technologies work. But then, I have issues (http://www.codeflux.org.uk/2013/08/why-i-dont-like-frameworks-and-xml.html) with third-party components which black-box something that should be very simple while adding heaps of overcomplexity to satisfy all plausible (and consequently many implausble) use cases. DI and IOC, for example, are incredibly simple. I have the implementation of such a pattern in fewer than 160 lines of code, and it throws meaningful exceptions. And that’s not because I write twiddly, complex code. It’s because of Points 11 and 12 which are missing from the list:

    11. Write simple code (Don’t overcomplicate it.)
    12. Reuse reusable code (If you find yourself doing the same thing twice, put the code into a separate assembly and share it between the projects – or solutions.)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: