3 Useful anti-patterns

This chapter covers

Known bad practices that can be put to good use
Anti-patterns that are, in fact, useful
Identifying when to use a best practice versus its evil twin

Programming literature is full of best practices and design patterns. Some of them are even seemingly indisputable and cause people to give you the side-eye if you argue about them. They eventually turn into dogmas and are rarely questioned. Once in a while, someone writes a blog post about it, and if their article gets the approval of The Hacker News^[1] community, it can be accepted as valid criticism and can open a door for new ideas. Otherwise, you can’t even argue about them. If I had to leave a single message to the world of programming, it would be to question everything that’s taught to you—their usefulness, their reason, their gain, and their cost.

Dogmas, immutable laws create blind spots for us, and their size grows as we stick to them longer. Those blind spots can cloak some useful techniques where some can even be better for certain use cases.

3.1 If it ain’t broke, break it

3.1.1 Facing code rigidity

3.1.2 Move fast, break things

3.1.3 Respecting boundaries

3.1.4 Isolating common functionality

3.1.5 Example web page

3.1.6 Leave no debt behind

3.2 Write it from scratch

3.2.1 Erase and rewrite

3.3 Fix it, even if it ain’t broke

3.3.1 Race toward the future

3.3.2 Cleanliness is next to codeliness

3.4 Do repeat yourself

3.4.1 Reuse or copy?

3.5 Invent it here

3.6 Don't use inheritance

3.7 Don't use classes

3.7.1 Enum is yum!

3.7.2 Struct rocks!

3.8 Write bad code

3.8.1 Don't use if/else

3.8.2 Use “go to”

3.9 Don't write code comments

3.9.1 Choose great names

3.9.2 Leverage functions

3.10 Summary