Yeah. That's where I thought the analysis itself became over-engineered. It's interesting, but can the concept of code smell be reduced this way? The best I

Yeah. That's where I thought the analysis itself became over-engineered. It's interesting, but can the concept of code smell be reduced this way? The best I can express "code smell" into a reductionist statement is like so: Code smell is when a given aspect of code contradicts the general purpose, overall ethos or accepted style of the whole program itself. Leaky abstractions is a good example of this. Improperly normalised tables is another (eg. a calculated totals field in Invoice table). But then again, a team could have taken the conscious strategy of breaking those rules deliberately. Anti-patterns could be a part of a "pragmatic" development strategy. Code smell detection is not an exact science. It has to be understood in the context of a given program.