Code review rules: Problem list
In dead code detection, Project Analyzer searches your code for unused or partially unused elements. By eliminating dead code you can make your program smaller and easier to understand. In addition, you can find logical flaws and prevent new errors from being introduced in the future.
Dead code means unnecessary, inoperative code that can be removed. Dead code means excessive memory use and slower execution. It also means more source code to read and maintain. This leads to higher costs, especially during maintenance. If the code is in there, programmers must spend time trying to understand it.
Leaving dead code in a completed project often means carrying untested code around. Dead code may inadvertently become operative later, leading to a possible source for errors. Dead code exaggerates system size measures such as line counts, and may even lead to purchases of unnecessary code at a high price. Thus, one of the first things to do when taking on new projects is to reduce their size.
Dead procedure/declaration/event. A procedure, a DLL declaration or an Event declaration is not used by the project. It is not called by the code nor executed by any other means. You may remove it if you are sure you won't need it later. The removal doesn't affect the functionality of your program. Event declarations are reported dead only if they are not raised nor handled. See the problem Event not raised for events that would be handled but that aren't fired. DEAD_PROC, DEAD
Dead procedure/declaration/event (called by dead only). A procedure is not executed and it is effectively dead. Calls to the procedure exist, but the callers don't execute. You should remove this procedure along with its callers, provided that you are sure you won't need any of the callers later. DEAD, DEAD_PROC
Event not raised. An event does not fire. The class does not call RaiseEvent to raise the event. All existing event handlers are not executed. NOT_RAISED, DEAD
Dead variable. A variable is not used. You may remove it if you are sure you won't need it later. The removal doesn't affect the functionality of your program. Before removal, you might want to determine why the variable actually is superfluous and whether it represents missing functionality or the remains of some deleted functionality. — A dead variable consumes memory and makes the program harder to understand. That is why dead variables should be removed even though they don't affect the functionality of the program. DEAD, DEAD_VAR
Variable written, not read. A variable is given a value but the value is never read by the program. The variable is either useless or there is a flaw in the program. Review the write locations. Check the code to determine if it's a flaw or if the variable is simply a leftover from an earlier version. Remove the variable and the write statements if you are sure the variable is useless. Before removal, determine if the write statements contain any procedure calls that must execute. Removing these calls could make the program behave erroneously. DEAD, NOT_READ, VAR_NOT_READ
Variable read, not written. A variable is never written to, even though its value is read by the program. The value is always zero, empty or Nothing, depending on the data type. Review the code to see if the missing write is a flaw in the program or if it is intentional. The write statement(s) may have been deleted by accident or the developer forgot to add them in the first place. In this case one or more writes should be added. On the other hand, the write(s) may have been removed on purpose, in which case the variable now works as a constant. Consider removing the variable altogether or declaring it as a constant. The use of a constant prevents unexpected changes later in the life-cycle of the program. You can also save a little memory as constants don't require run-time data storage. — This review rule is especially important for object variables, because the variable will always contain the value Nothing. This can cause an 'Object variable not set' error at the location the object is referenced. A special case is denoted as 'No real value given, cleared/allocated only'. For an object variable this means the variable is set to Nothing but it never contains a live object. Alternatively, an array is allocated but nothing is stored in it. The array is consuming memory for no purpose. DEAD, NOT_WRITTEN, VAR_NOT_WRITTEN
Dead Structure/Type. A user-defined data type is not used. You may remove this if you are sure you won't need it later. The removal will not change the functionality of your code. This problem rule applies to VB Classic Types and VB.NET Structures. DEAD, DEAD_STRUCTURE
Dead type field. A field in a user-defined type is not used by your code. You may have forgotten to use the field. It may also be useless or unused on purpose. Carefully consider the reason before removing the field. You need to review the use of the entire user-defined type. If it is being used in random file access or external DLL calls, changing the type may break the file structure or the calls. - This problem rule applies to VB 3-6 only. Fields of VB.NET Structures are handled via the rule Dead variable. DEAD, DEAD_FIELD
Type field written, not read. A field in a user-defined type is written but not read by your code. This may indicate a useless field or incomplete functionality. Carefully consider removing the field. Before removal you need to review how the type is being used. If it is being used in random file access or external DLL calls, changing the type may break the file structure or the calls. - This problem rule applies to VB 3-6 only. Fields of VB.NET Structures are handled via the rule Variable written, not read. DEAD, NOT_READ, FIELD_NOT_READ.
Type field read, not written. A field in a user-defined type is never written to, even though its value is read by the program. The value is always zero, empty or Nothing, depending on the data type. Review the code to see if the missing write is a flaw in the program or if it is intentional. The field may also be useless or unused on purpose. Carefully consider the reason before removing the field. You need to review the use of the entire user-defined type. If it is being used in random file access or external DLL calls, changing the type may break the file structure or the calls. — This problem rule applies to VB 3-6 only. Fields of VB.NET Structures are handled via the rule Dead variable. DEAD, NOT_WRITTEN, FIELD_NOT_WRITTEN
Dead constant. The value of a constant is not used. You may have forgotten to use it, or it is useless in this application. You should verify which case it is. If it's useless, you may remove it if you are sure you won't need it later. The removal doesn't affect the functionality of your program. You may consider preserving the constant for the sake of completeness or later use, though. The best way to achieve this is to comment it out. The commented constant is clearly reserved for future purposes and not being used at the moment. — An extra string constant bloats the executable size while an extra numeric constant simply bloats the source code and makes it harder to understand. A dead constant may also have an obsolete value, which is not apparent before the constant is brought back to use again. These are the reasons why dead constants should be cleaned out even though they don't affect the functionality of the program. DEAD, DEAD_CONST
Dead enum constant. An enumeration constant is not used. You may have forgotten to use it, or it is useless in this application. You should verify which case it is. If it is useless, you may remove it if you are sure you won't need it later. The removal doesn't affect the functionality of your program. You may consider keeping this constant available for the sake of completeness or later use, though. Note that removing a constant from an Enum may change the values of the constants that come after it, causing side effects. When removing an Enum constant it is safest to explicitly define a value for the next constant to prevent breaking existing code. The code may rely on the specific numeric values of the enum constants. DEAD, DEAD_ENUM_CONST
Dead Enum. An Enum is not used as a data type. The constants defined by the Enum are not used either. You may remove this Enum if you are sure you won't need it later. — Even though a dead Enum does not affect the functionality of the program, its member constants may become obsolete or incomplete in time. These problems are not apparent before the Enum is brought back to use again. It is better to comment the Enum out or delete it to avoid these problems. DEAD, DEAD_ENUM
Dead return value. A function's return value is not used by any its callers. This indicates a possible bug in the callers or a useless return value. Review the function and the callers to determine whether the return value should be used or whether the function should be rewritten as a Sub. This problem does not apply to VB3 where return values must be used at all times. See also the style issue Return value discarded. RETVAL
Return value not set. A function does not set its return value, which can be an error. The function always returns zero, empty or Nothing, depending on the data type. Based on the documentation or purpose of the function, determine which value it should return. You can also visit the callers of the function to see which value(s) they expect to get. If there is no meaningful value to return, rewrite the function as a Sub. RETVAL, RETVAL_NOT_SET
Dead class. A class is not used. You may remove this class in its entirety provided that you are sure you won't need it later. DEAD
Class not inherited. A class is defined MustInherit but it is not inherited by any child class. Because it is an abstract class, you cannot instantiate it and it is thus of no use at run-time. However, the class is in compile-time use as a data type, so you cannot just remove it. Verify how it is being used to decide whether you should add a child class, remove the MustInherit keyword or remove the class together with the users. DEAD
Class not instantiated. A class is not instantiated even if it should be. Because no instances exist, you cannot access the instance procedures and variables. Thus, the class is not in use at run-time. However, the class is in compile-time use as a data type, or definitions such as Enums declared within the class are in use, so you cannot just remove it. Verify how it is being used to decide whether you should instantiate it via the New operator or remove it together with the users. This problem does not apply to abstract classes, classes with Shared members, classes that prevent instantiation or classic VB interface .cls files. DEAD
Dead interface. An Interface definition is not implemented or not used. You can remove it if you are sure you won't need it later. DEAD
Implemented interface not used. An interface is implemented by one or more classes or structures. However, the interface is not used anywhere outside of the implementors. The interface is possibly unnecessary. This problem type is available for VB.NET Interfaces. It is also available for VB Classic classes that are used as interface definitions. DEAD
Interface not implemented. An Interface is defined and used but it is not implemented by any class or structure. The Interface has no effect at run-time. You should either remove it or add one or more implementations. This problem type is available for VB.NET Interfaces. It is also available for VB Classic classes that have no code in them except for a public interface definition. These classes are candidates for either implementation or removal. You can implement a class by either adding code in its procedures or by implementing it via the Implements statement. DEAD
Dead module. A .NET Module is not used. You can remove the module in its entirety if you are sure you won't need it later. For VB Classic modules, see the problem Unused file for a similar rule. DEAD
Unused file. A file is not used. Drop the file from the project. You can always add it back later. DEAD
Code may be dead in the current analysis, but another project might use it. This happens with projects that expose interfaces to other projects (as with ActiveX, OLE Server or library project types). In a VBA project, a procedure may be exposed to be called by the host application or from another document. Unless you do a multi-project analysis and analyze all the possible callers, you may not safely remove exposed dead code. Because of this, Project Analyzer ignores dead code problems for exposed code by default. You can enable it in Problem options. When you do this, you may see dead code problems with the word Exposed in them. Remove this kind of dead code only when you are sure that other, unanalyzed projects don't use it.
Control not visible. A control's Visible property is set to False and it is not set to True by code. Most user interface controls are not very useful if they are not visible. The control was possibly set invisible by a developer who thought it was not required any more but was uncertain about removing it. You should consider removing invisible controls as they may unnecessarily consume some resources. Events related to the control are possibly not executed. Code that reads or sets the control's properties and calls its methods is potentially unnecessary for the operation of the program. There are some cases where an invisible control can be useful, so you have to be careful about removing the control and related code. This rule does not work with control arrays. It does not detect all kinds of invisibility, as controls may be hidden behind other controls or set invisible by code. This problem is available for VB 3-6. CTRLINV
Control outside of visible area. A control is located outside of the visible area of the form it is on. The control is not moved by code and the form does not seem to resize to reveal the control. Most user interface controls are not very useful if they are not visible. The control was possibly moved outside the form borders by a developer who thought it was not required any more but was uncertain about removing it. You should consider removing invisible controls as they may unnecessarily consume some resources. Events related to the control are possibly not executed. Code that reads or sets the control's properties and calls its methods is potentially unnecessary for the operation of the program. There are some cases where an invisible control can be useful, so you have to be careful about removing the control and related code. This rule does not work with control arrays or controls that are placed within other controls. This problem is available for VB 3-6. CTRLOUT
Control not enabled. A control's Enabled property is set to False and it is not set to True by code. Most user interface controls are not very useful if they are never enabled. You should consider removing disabled controls as they may unnecessarily consume some resources. Events related to the control are possibly not executed. Code that reads or sets the control's properties and calls its methods is potentially unnecessary for the operation of the program. There are some cases where a disabled control can be useful, so you have to be careful about removing the control and related code. This rule does not work with control arrays. It is available for VB 3-6. CTRLDIS
The comment directive parameter for the rules on this page is DEAD. Also the OPT directive applies to all these rules.
Problem detection
Code review rules: Problem list
©Aivosto Oy - Project Analyzer Help Contents