From Anope Wiki

Contents 1 QA Modules Checklist 1.1 General 1.2 Coding Standards and Comments 1.3 Error Handling 1.4 Memory 1.5 Bad Practice 1.6 Control Structures 1.7 Performance 1.8 Functions

QA Modules Checklist

The checklist below outlines the criteria the QA Team will use when deciding whether or not to give a module QA-Approved status. It was originally drawn up by Rob, and has been amended several times since it's first incarnation.

Modules with QA-Approved status show the user that the module author has taken time and care to make a high quality Anope module.

General

Is the Author clear?

• Is it clear who created the module? moduleAddAuthor() and moduleAddVersion() should both be used.

Is the module setting a type?

• Third party modules should avoid the use of moduleSetType() and allow anope to classify them as it sees fit.

Does the module require a specific version?

• If so, is this mentioned in the header of the module, and in the module description on the website?

Succesful Compile?

• No errors or warnings should occur when building the source

Does the module perform as expected?

• When used correctly, the module does what it is supposed to do. When used incorrectly, the module should cope gracefully.

Do you understand the module you are reviewing?

• As a QA Reviewer, you should understand the module you are reviewing. If you don't, the review will be inaccurate, and it may imply the module is poorly commented.

Is the modules name appropriate for what it does?

• The name of the module should ideally be service_description, e.g. hs_moo for a module to make HostServ moo.

Coding Standards and Comments

Are variables given sensible names?

• Variables should all be given sensible descriptive names, this should not be taken to literally, for example, i is a perfectly "normal" variable name for a loop index counter etc.

Is the style consistent?

• Anope core uses a defined style involving K&R style with no "tabs", while we do not force this on module coders, the module should pick one style and stick with it, as mixing styles produces hard to understand code.

Are comments used to explain complex/difficult algorithms or optimizations?

• Complex areas of code should be well commented in order to allow easy maintenance and future expandability.

Is the module Author and Version identified and set for Anope?

• Module author and version number's should be set for use with /os modinfo name.

Are there areas of commented out code?

• Commented out code should have an explanation explaining why it is commented out. In the event the code is "dead" and no longer used, it should be removed.

Are all functions documented?

• Describe each routine, in one or two sentences at the top of its definition. If this description is overly long/complex it may be a sign the function is doing too much and should be looked at again from a design point of view.

Error Handling

Are errors properly handled each time a function returns?

• The return values from functions such as malloc should always be checked, return codes from commands such as moduleAddCommand may need to be checked.

Memory

Is allocated memory freed?

• All allocated memory needs to be freed when no longer needed. Make sure memory is released in all code paths, including error paths. Memory allocated with strdup and sstrdup also needs to be freed.

Bad Practice

Is strtok() used?

• The use of strtok will often indicate a potential error as strtok is not thread safe, and is used inside of Anope's core.

Are any bad functions used?

• The use of the following functions may indicate an error is present somewhere: gets(), strcat(), strcpy(), sprintf(), vsprintf(), bcopy(), scanf(), fscanf(), sscanf(), getwd().

Are Anope variables modified?

• Anope core variables should ideally not be modified. If they are, the reason should be explained properly.

Does the module modify any module control functions?

• Ideally modules should not modify the module info list load or unload commands, if they do, care should be taken it is not for a malicious reason.

Does the module use send_cmd to change a mode?

• If the module changes a user or channel mode with send_cmd it must also update anope's internal list.

Control Structures

Are loops ending conditions accurate?

• Check all loops to ensure they iterate the right number of times. Check the condition that ends the loop; ensure it will end after the expected number of iterations.

Is the code free from endless loops?

• Check all loops to ensure there is no code path which could result in an endless loop.

Performance

Could the module take "too long"?

• Anope is single threaded, if a module is busy "working" then Anope cannot answer other users, this should be a consideration when deciding if QA will accept a module.

Functions

Are variables initialized before they are used?

• Make sure there are no code paths where variables are used prior to being initialized.

Does the code re-write functionality that could be achieved by using an existing API?

• Don't reinvent the wheel. New code should use existing functionality as much as possible. Don't rewrite source code that already exists in the project.