Difference between revisions of "2009 Winter Project Week Compiler Warnings:Slicer3 Graffiti"
(New page: {| |thumb|320px|Return to [[2009_Winter_Project_Week|Project Week Main Page ]] |} __NOTOC__ ===Key Investigators=== * Bill Lorensen (His Basement) <div style="...) |
|||
| Line 19: | Line 19: | ||
In the ''Tipping Point'', a chapter on increasing crime in New York City in the 1990's describes how the trend was reversed. The city concentrated areas like cleaning graffiti from subway cars. The author claims that this and other seemingly trivial goals may have led to a reversal of the crime trend. | In the ''Tipping Point'', a chapter on increasing crime in New York City in the 1990's describes how the trend was reversed. The city concentrated areas like cleaning graffiti from subway cars. The author claims that this and other seemingly trivial goals may have led to a reversal of the crime trend. | ||
| − | This project hypothesizes that compilation warnings are the graffiti of software quality. A lack of attention to this seemingly trivial goal shows a lack of attention to the quality of software. This project will | + | This project hypothesizes that compilation warnings are the graffiti of software quality. A lack of attention to this seemingly trivial goal shows a lack of attention to the overall quality of software. This project will reduce warnings to zero for a popular c++ compiler, GCC 4.3. |
| + | |||
| + | |||
</div> | </div> | ||
| Line 26: | Line 28: | ||
<h1>Approach, Plan</h1> | <h1>Approach, Plan</h1> | ||
| − | This project will use the [http://en.wikipedia.org/wiki/DMAIC#DMAIC '''DMAIC'''] methodology of the [http://en.wikipedia.org/wiki/Six_Sigma ''Six Sigma management process''] to "Define", "Measure", "Analyze", "Improve" and "Control" compiler warnings in Slicer3. | + | This project will use the [http://en.wikipedia.org/wiki/DMAIC#DMAIC '''DMAIC'''] methodology of the [http://en.wikipedia.org/wiki/Six_Sigma ''Six Sigma management process''] to ''"Define"'', ''"Measure"'', ''"Analyze"'', ''"Improve"'' and ''"Control"'' compiler warnings in Slicer3. This project will concentrate on warnings produced by the GNU gcc 4.3 compiler. Similar approaches can be applied to other Slicer3 compilers. |
| + | |||
| + | The basic methodology (from Wikipedia) consists of the following five steps: | ||
| + | *'''''D'''efine'' process goals that are consistent with customer demands and the NA-MIC's strategy. | ||
| + | *'''''M'''easure'' key aspects of the current process and collect relevant data. | ||
| + | *'''''A'''nalyze'' the data to verify cause-and-effect relationships. Determine what the relationships are, and attempt to ensure that all factors have been considered. | ||
| + | *'''''I'''mprove'' or optimize the process. | ||
| + | *'''''C'''ontrol'' to ensure that any deviations from target are corrected before they result in defects. Set up pilot runs to establish software quality, move on to production, set up control mechanisms and continuously monitor the process. | ||
| + | |||
</div> | </div> | ||
| Line 32: | Line 42: | ||
<h1>Progress</h1> | <h1>Progress</h1> | ||
| + | *'''''D'''efine'' | ||
| + | The goal is to eliminate all compiler warnings produced by the GCC 4.3 c++ compiler and to implement measures to prevent warnings from entering the software. | ||
| + | *'''''M'''easure'' | ||
| + | On December 1, 2008, a clean Slicer3 build using the gcc 4.3 compiler produced 523 warnings in 173 source files. | ||
| + | ** 278: shadowed variables | ||
| + | ** 131: unused variable | ||
| + | ** 29: suggest parentheses around && within || | ||
| + | ** 26: comparison between signed and unsigned integer expressions | ||
| + | ** 17: deprecated conversion from string constant to ‘char*’ | ||
| + | ** 14: defined but not used | ||
| + | ** 13: cast from type ‘const char*’ to type ‘char*’ casts away constness | ||
| + | ** 7: format ‘%X’ expects type ‘unsigned int’, but argument 5 has type ‘double’ | ||
| + | ** 2: zero-length printf format string | ||
| + | *'''''A'''nalyze'' | ||
| + | A description of each warning, why it is important and how to eliminate it will be provided. | ||
| + | *'''''I'''mprove'' | ||
| + | All Slicer3 source files with GCC warning defects will be repaired. | ||
| + | *'''''C'''ontrol'' | ||
| + | The Slicer3 dashboard will report the warnings each day. Individuals will receive e-mails when they introduce warnings. Other more drastic measures will be investigated. For example, the GCC compiler flag ''-Werror'' will treat warnings as errors, thus blocking compilation of any files that have defects. | ||
</div> | </div> | ||
Revision as of 19:55, 9 December 2008
Home < 2009 Winter Project Week Compiler Warnings:Slicer3 Graffiti Return to Project Week Main Page |
Key Investigators
- Bill Lorensen (His Basement)
Objective
The book, The Tipping Point, analyses trends and how they take hold. As Slicer3 grows and the number of contributors increases, there needs to be tighter controls on the quality of the system. The larger the code base, number of platforms and developers, the more need there is for attention to quality.
In the Tipping Point, a chapter on increasing crime in New York City in the 1990's describes how the trend was reversed. The city concentrated areas like cleaning graffiti from subway cars. The author claims that this and other seemingly trivial goals may have led to a reversal of the crime trend.
This project hypothesizes that compilation warnings are the graffiti of software quality. A lack of attention to this seemingly trivial goal shows a lack of attention to the overall quality of software. This project will reduce warnings to zero for a popular c++ compiler, GCC 4.3.
Approach, Plan
This project will use the DMAIC methodology of the Six Sigma management process to "Define", "Measure", "Analyze", "Improve" and "Control" compiler warnings in Slicer3. This project will concentrate on warnings produced by the GNU gcc 4.3 compiler. Similar approaches can be applied to other Slicer3 compilers.
The basic methodology (from Wikipedia) consists of the following five steps:
- Define process goals that are consistent with customer demands and the NA-MIC's strategy.
- Measure key aspects of the current process and collect relevant data.
- Analyze the data to verify cause-and-effect relationships. Determine what the relationships are, and attempt to ensure that all factors have been considered.
- Improve or optimize the process.
- Control to ensure that any deviations from target are corrected before they result in defects. Set up pilot runs to establish software quality, move on to production, set up control mechanisms and continuously monitor the process.
Progress
- Define
The goal is to eliminate all compiler warnings produced by the GCC 4.3 c++ compiler and to implement measures to prevent warnings from entering the software.
- Measure
On December 1, 2008, a clean Slicer3 build using the gcc 4.3 compiler produced 523 warnings in 173 source files.
- 278: shadowed variables
- 131: unused variable
- 29: suggest parentheses around && within ||
- 26: comparison between signed and unsigned integer expressions
- 17: deprecated conversion from string constant to ‘char*’
- 14: defined but not used
- 13: cast from type ‘const char*’ to type ‘char*’ casts away constness
- 7: format ‘%X’ expects type ‘unsigned int’, but argument 5 has type ‘double’
- 2: zero-length printf format string
- Analyze
A description of each warning, why it is important and how to eliminate it will be provided.
- Improve
All Slicer3 source files with GCC warning defects will be repaired.
- Control
The Slicer3 dashboard will report the warnings each day. Individuals will receive e-mails when they introduce warnings. Other more drastic measures will be investigated. For example, the GCC compiler flag -Werror will treat warnings as errors, thus blocking compilation of any files that have defects.
