Submitting Bug Reports and Feature Requests Guidelines

The following guidelines are set for this project (for users whom know some development or qa):

-> Name the bug or feature in a manner which is consistent and memorable for the content of the bug or feature request
-> Prioritize bugs correctly. Otherwise, you are crying wolf. Priority of bugs and feature requests are essential to the organization of the project and project timelines.
-> Code must be readable. Something which may take up more space than something else in Delphi does not mean it compiles any differently. The shorter code in Delphi may mean it is less readable, though, and this is cardinal against the project guidelines.
-> Use comments. I only wish I had more in there. There should be comments for every other line of code, though sometimes too many comments can make the code unreadable.
-> only use variable names which are common sense. Some things in the code still use the original name of the component, make the code a bit less common sense to read. For instance, Edit1 should be PasswordEdit. i can be used for a for i:=, and at times "f" can be used for files, or "s" for strings.
-> There are many old wives tales about what is better compiled code or not. If you don't know assembly and can not produce a recommendation from Borland, don't submit code optimizations which make the code less readable or make no difference to performance.
-> All potential errors should be trapped correctly. Everything does not need a try -> catch block, but errors put out to end users should be readable and pertinant for debugging. Otherwise, error conditions which are not caught and may reduce the security or reliability of the code is dangerous.
-> size is of utmost importance, this is why some of the earliest, highest ranking bugs are about size - size compiled, not size uncompiled. Primarily new includes and windows cause larger size.
-> Nothing should be written to disk, except the history registry lock and unlock.
-> the interface must be user friendly. This also means I will not have a wizard, for instance, for gif creation... because gif creation requires higher skilled people and using a wizard every time is laborious.
-> Look through the bug reports and feature requests to get a grasp of current project guidelines and goals

Posted by thePull 2002-07-24

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks