Developer Guidelines Checklist
- General Syntax and Correctness:
- Classes and methods are properly named and cased
- Variables are properly named and cased
- Prolific and informative commenting using proper comment style
- Capital letters used for all constants, e.g.
- Capital letters used for the keywords:
- Proper comparison of return values and variables (
- No debugging code leftover unless commented out
- No whitespace before or after opening/closing PHP tags in files
- No use of deprecated core methods (check the Developer Log to make sure no deprecation warnings have surfaced from your add-on)
- All code is PHP 5.3.10+ compatible
- Proper use of
- Class and filenames are prefixed to avoid overlap when the name and purpose may be common
- Custom database tables all use
exp_prefix, followed by unique prefix, then the table name, e.g.:
- Separate files used for unrelated classes.
- Tabs for whitespacing, not spaces
- File saved with Unix line breaks
- Allman style indenting: braces placed on a line by themselves and indented at same level as the control statement
- Text output in the control panel uses Language variables to allow localization
- Private variables and methods start with an underscore:
_convert_text()is a private method,
- Not using PHP functions that require non-default libraries unless an alternative is provided, or implicitly documented as a requirement.
- Code executes error free for all users with
- Full PHP opening tags used.
- Multiple statements are not combined on a single line
- Single quoted strings used unless variables are being parsed or string needs to contain single quotes
- Variables inside double-quoted strings are braced, e.g.
- No overlap of tag parameters effecting the same thing
- Long queries broken up into multiple lines for legibility.
- Function argument defaults used when appropriate
- POSIX extended (
ereg, etc.) regular expression functions not being used
?:used at the start of a PCRE subpattern not being captured for use
preg_replace()is not being used where
str_replace()to see if the replacement is necessary
preg_match()when comparing the start of strings
- Calculations are not being made in the second expression of
Heredocstring syntax avoided whenever possible
- No variables are being set for one-time use
- Queries are not needlessly stuck in loops or being run redundantly on a single page load
- POSIX extended (
- XSS Cleaning taking place for all front-side user input before inserting into the database or output to the screen.
- PHP variables escaped in queries.
- Manually written queries using
ee()->db->insert_string()used for data
ee()->db->update_string()is used for
- Strings sent as the
ee()->db->update_string()are escaped with
- Security and required preference settings are stored in the database or
- Prefs and settings are not being used in hidden form fields
- No unnecessary preferences being used
- Tag parameters are validated before use
- Tag parameters have default values to fall back on
- User-side forms are created with
- Checks and deletions of secure form hashes taking place appropriately
- No unfiltered incoming data output to the screen.
- Methods processing forms are thorough with regards to validation, security, and processing
- File name security precautions are being taken for
require()and saving files to servers.
- Typography class used for outputting blocks of user submitted data, with proper settings as security dictates.
- Security exceptions not being made for Super Admins
- Built in EE classes and methods used for tasks when possible
- Least Privilege approach used