| IT |
unused code; dead code (Dead code is code that is present in the system but is not supposed or expected to be used anymore. Dead code needs to be found and removed; leaving dead code in is an obstacle to programmer understanding and action, and there’s the risk that the code is awakened which can cause significant problems. Dead code is not truly dead until it’s buried. Deleting dead code is not a technical problem; it is a problem of mindset and culture. Finding dead code is the hard part. Sometimes dead code is genuinely unreachable, and static analysis can tell you this. The effectiveness of static analysis, however, depends on tools, language and architecture, but it’s a good start. When software features are withdrawn or superseded at the requirements level, code associated with those features must also be due for retirement. Another clue that can be used is code stability. Your version control system is a knowledgebase of change. Which parts of the codebase never change? There are many reasons code may be stable – it’s just right, it’s just dead, it’s just too scary – but unless you investigate you’ll never know. Of course, dead code may still end up being changed as a consequence of an automated refactoring, but such changes also have a signature: their changes correlate with other refactoring changes, but they are not changed to fix bugs or add features. Runtime monitoring of the system cannot definitively tell you which parts are dead, but they can tell you which parts are definitely alive.); dead code (Dead code is code that is present in the system but is not supposed or expected to be used anymore. Dead code needs to be found and removed; leaving dead code in is an obstacle to programmer understanding and action, and there’s the risk that the code is awakened which can cause significant problems. Dead code is not truly dead until it’s buried. Deleting dead code is not a technical problem; it is a problem of mindset and culture. Finding dead code is the hard part. Sometimes dead code is genuinely unreachable, and static analysis can tell you this. The effectiveness of static analysis, however, depends on tools, language and architecture, but it’s a good start. When software features are withdrawn or superseded at the requirements level, code associated with those features must also be due for retirement. Another clue is code stability. Your version control system is a knowledgebase of change. Which parts of the codebase never change? There are many reasons code may be stable – it’s just right, it’s just dead, it’s just too scary. Dead code may end up being changed as a consequence of an automated refactoring, but such changes also have a signature: their changes correlate with other refactoring changes, but they are not changed to fix bugs or add features. Runtime monitoring of the system cannot definitively tell you which parts are dead and which parts are definitely alive.) |
