Coding Concerns: Do They Matter?
W. Munger, James M. Bieman, R. Alexander · 2002
In the heyday of C programming it was the requirement of many programming shops to check code for anomalies and potential bugs with a program called lint [4,6]. As the quality of compilers improved, many of the lint functions were added to compilers as ’warnings’. But many programmers soon became tired of all the compiler warnings and turned most of them off. Today compilers come with just a few warnings turned on. A programmer wishes may set the flags to have the compiler provide additional warnings. As a result, many programs are compiled with the flags set to only a few of the warnings that the original lint programs provided. This leads to the question: does the common programmer practice of turning off most compiler warnings indicate that these warning are no longer useful? The programming environment has changed greatly since the lint program was first introduced. Modern OO languages such as Java, through the use of inheritance, polymorphism, overriding, and overloading [1,5] have increased the number of places where possible errors can hide, thus increasing the complexity of the needed lint-like program. As these are places where problems can hide and are not actually errors, we prefer to call them concerns. We define a concern as an anomaly in the code that should be checked to confirm that it is not an error. A few OO lint-like programs exist, but the tendency today is to add lint-like features to software design tools. For our research we chose two such commercial tools: Together and JStyle. Both provide a way to load code into a