Two of the meanings of the word “cultivation” that are rather unrelated show a strong dependency, when applied to the domain of code quality:
The existing code in an evolving software system could be seen as the soil in which new code and new functionality is growing. While working this “soil” developers benefit from unobtrusively presented automatic feedback about the quality of their code. There are tools that verify the correct usage of good code structures (“design pattern”) and other tools that highlight improvement opportunities (“bad smells”).
As design patterns and bad smells are usually presented and discussed separately it has not been observed, that they partially contradict with each other. We will show that even well chosen design patterns can lead to bad smells. Thus, design quality is relative, which does not mean that it is arbitrary. Design quality knowledge has to be rendered more precisely. We suggest to co-evolve the quality knowledge specifications together with the code in a process of cultivation. Bad smell definitions can then easily be extended by taking existing design patterns into account.
When the design knowledge is cultivated together with the code, specific knowledge like typical method names can be incorporated. A case study explored unjustified “intensive coupling”-smells in ArgoUML: While a previously suggested generic structural criterion identified 13% unjustified warnings, taking the specific names into account, identified 90%.