![]() ![]() A missing Default button means the user cannot use this interface standard. Each dialog box should have a Default button (titled OK, Save, etc.) so that the user can press the Enter key to accept the dialog. Setting the context ID numbers is an easy way to reduce the number of help calls from users (assuming the help file itself is well-written, of course). When HelpContextID is missing (it is set to 0), the correct help page will not be shown when the user presses F1. ![]() A program with a context-sensitive help file is supposed to set a HelpContextID for each form. This is an easy way to give a program an unfinished look. When there is no icon for a form, the program will display a default icon. Giving the UI a final polish might not be intellectually challenging for the developers, but forgetting to do it will be challenging for the users! If the UI is not performing the way they expect, that will affect the entire user experience. This is also an important part as it affects what the users think about your application. Now we move on to polishing the windows and dialogs. Check your code against the DLL versions your users might have, not just the version you have on your own disk. Your version of the DLL might be different from that of the original developer. This check is especially important when you plan to release code that you received from someone else. A function your program uses might not exist in an old DLL version. There may be different versions of the same DLL. ![]() When you declare and use functions from external DLLs, make sure the functions actually exist there. Alternatively, remove the WithEvents keyword to make your program run faster. Some important feature may be missing from the program. The events of an object variable are not handled, even if the variable was marked WithEvents. Events not handled for WithEvents variable.A premature end can lose or corrupt data and cause severe user aggravation. Verify that each end is intended and not just a leftover from debugging sessions. Program ends: Stop and End statements.You kept the procedure (or module), because you didn't feel like removing it completely. You forgot to write the code! Write it now.Sometimes you find an empty procedure or an empty module. Again, you get a chance to delete the code that manages this useless control. You should remove it as it distracts the users. It shows up in the user interface but it's never enabled, so it serves no purpose. A control may have been disabled for some reason (by setting Enabled=False). When you delete the control, you get a chance to delete that code too. The code that sets the properties of the control and handles its events is unnecessary as well. It may belong to an unimplemented feature or a feature that should have been removed. In either case, the control is a potential source of errors. A control may be invisible because someone flagged it so (Visibility=False), or because someone dragged it off the form borders. The event will cause headache later in maintenance when someone expects it to fire. An event that does not fire must be a bug or a leftover from a removed feature. Bringing it back to life without testing it is likely to cause trouble later during maintenance. The implementation was probably not properly tested anyway. An unused implementation adds weight to the executable but no benefit. Implemented interfaces that are not used.If someone calls the interface later on, the code will fail as there is no object to respond to the calls. Defining extra interfaces just adds baggage to the program. Determine whether you should instantiate these classes or remove them altogether. When the code calls such a class via an object variable or a pointer, the program can crash due to Object variable not set or NULL pointer. This case consists of classes which are used as data types (in As clauses), but which are not instantiated at run-time (with As New clauses). These classes are a source of nasty crashes. Mark them untested if you intend to use them later in order to prevent accidental reuse of possibly erroneous code. They contain untested code and hidden bugs that can accidentally come back to life during maintenance. Unused files, such as dead classes and dead modules.You can remove the more problematic parts and decide to keep an acceptable level of dead code.Īt a minimum, remove the following types of dead code: Fortunately, not all dead code is equally bad. Ideally, it should be done at regular intervals. Complete dead code removal is a demanding task. The amount of dead code in a "dirty" program can well be something like 30-40%. Many programs contain parts that are not in use. It supports all the review rules mentioned in this article. Project Analyzer is a VB code review tool that can be used as an automated checklist verification tool. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |