|
I have a lot of code lying around that doesn't live up to my own standards.
I try to do the following, but my success is definitely incomplete. I
hope this can serve as a "test checklist" for your projects (so you may avoid
any possible deductions from the graders on these matters):
- In theory, I try to place all code within try...catch blocks--even if
I think it will never fail. Despite what many people say, the catch need not catch
specific exceptions--but having it there causes me to think about taking any action that is appropriate to handle an
error. I try to add a finally clause if there
are resources such as files or database connections that really
need to be cleaned up even if an
exception occurs.
- I try to ask someone else to use my code--they
nearly always find issues immediately. I think most people
underestimate the importance of testing; I can never
foresee all
the circumstances in which my code is going to be used.
- I like to avoid the use of tabs, because
their display in someone else's environment is quite unpredictable.
One can change tabs to spaces with Find & Replace...
And I can coerce Visual Studio to interpret tabs as spaces by doing
this: Tools...Options...Text Editor...All Languages...General...Tabs...select
Insert Spaces.
- I try to use method and field names that are descriptive
enough that my code is mostly "self-documenting".
- I generally avoid having multiple exit points
to a program--maybe just one way out for good exits, and another for
bad. That way, any special cleanup code can be consolidated in one
place. For example, from within a form, I try to leave the program using
this.Close() so the Form_Closing event will fire; only from within Main (when not displaying any form),
I try to
leave using Environment.Exit().
- I try to keep source code, including comments, under 80 chars per line, as this is the
approximate
width that editors can display, and it is difficult
to read printed code if the lines wrap.
- I try to get rid of any compile warnings.
- I try to make sure I can build, with no warnings, in both Debug and Release mode.
- I try to make sure that only constants appear in UPPER CASE.
- I try to make
Windows applications adhere to standard behavior--standard menus, standard
terminology, standard About... screens as patterned after leading Microsoft
applications such as Internet Explorer or Microsoft Word. Minimum
menus will usually include File...Exit and Help...About.
- In most cases, I try to prevent a program from running twice.
However, this depends on the kind of program--an editor might, for example,
be allowed to run multiple copies of itself.
- I try to display the application icon on the exe file. I try to
keep the program icon identical in several places: main form title, About form
title, executable file, and About form picturebox (if present).
- In menus, I try to use of the word Exit, which is the de facto
Windows standard (and yes, I know that Close is used on some other
operating systems).
- Exit should be the bottommost menu item--this is the
de facto
Windows standard.
- I try never to add code to the form or button constructor before
(or inside) the call to InitializeComponents; the Windows Form designer generates
comments warning people not to do this.
- I try always to provide an explicit public, private or
protected modifier on field and method declarations..
- I try to begin private fields and methods with a small letter, and
public fields and methods with a capital letter.
- I usually disable a timer while its handler is running.
- I try not to hardcode the information displayed by the About form--instead,
I try to make the About form pull the information from AssemblyInfo.cs.
As they say...the road to hell is paved with good intentions. |