13 Make bad code look bad

At the end of the last chapter, we discussed the advantage of clarifying the quality expectation for code at a glance. In the context of optimization, we did so by putting the code in an isolated namespace or package. In this chapter, we study how to make the quality level clear by making bad code look bad at a glance, a process we will call anti-refactoring.

We begin by discussing why anti-refactoring is useful, first from a process perspective and then from a maintenance perspective. Having established the motivation, we look for bad code traits through a brief introduction to some of the most common quality metrics. The last preliminary before beginning to anti-refactor is to establish ground rules that ensure we are not permanently damaging the code’s structure but only modifying how it presents itself. Rules in hand, we conclude this chapter with a string of safe, practical methods to make code stand out. This practical section also demonstrates how to use the rules to develop techniques suited to your team.

13.1 Signaling process issues with bad code

13.2 Segregating into pristine and legacy code

13.2.1 The broken window theory

13.3 Approaches to defining bad code

13.3.1 The rules in this book: Simple and concrete

13.3.2 Code smells: Complete and abstract

13.3.3 Cyclomatic complexity: Algorithmic (objective)

13.3.4 Cognitive complexity: Algorithmic (subjective)

13.4 Rules for safely vandalizing code

13.5 Methods for safely vandalizing code

13.5.1 Using enums

13.5.2 Using ints and strings as type codes

13.5.3 Putting magic numbers in the code

13.5.4 Adding comments to the code

13.5.5 Putting whitespace in the code

13.5.6 Grouping things based on naming

13.5.7 Adding context to names

13.5.8 Creating long methods

13.5.9 Giving methods many parameters

13.5.10 Using getters and setters