Code Formatting and Submission Criteria
If you are not using the Edge Device Builder and are seeking to create a new Device Profile or add a sub-driver, you will need to submit a pull request against the SmartThingsEdgeDrivers public repository. Before submitting your pull request, please review the following to ensure your pull request is approved in a timely manner.
important
A pull request is only necessary for devices seeking to create a new Device Profile or add a sub-driver. Devices seeking certification via the standard certification path (including using the Edge Device Builder) do not need to submit a pull request or modify code.
| Area | Rule |
|---|---|
| Indentation | Code should be indented using 2 spaces, indexed off the most recent level of indentation. |
| Line Length | Lines of code longer than 100 characters should be avoided and wrapped across multiple lines. This rule may be relaxed in some situations, but should generally be followed. If this limit is being pushed due to many levels of indentation, consider refactoring to extract methods in order to reduce indentation and complexity. Early returns may also help to reduce indentation levels. |
| Variable Names | Variables should be named using snake_case. If the variable name is short and sufficiently clear without underscores, underscores may be omitted (as is done in the Lua built-in modules). If in doubt, include underscores for ease of reading. |
| Function Names | Function names should follow the variable naming convention of snake_case. |
| Class Names | A table that acts as a class (data with associated functions) should use PascalCase. |
| Acronyms in Class Names | If a class name contains an acronym, the Rust convention of making the consecutive letters beyond the first lowercase should be followed. For example a "ZCL Command Handler" class should be named ZclCommandHandler and NOT ZCLCommandHandler. |
| Constants | Constants should be all uppercase with words being separated by underscores (e.g. MY_CONSTANT_NAME). |
| Module Names | Where possible, module names should be all lowercase. Underscores may be added for clarity between word names. |
| Semicolons | Semicolons should only be used where syntactically required and should otherwise be omitted, including at the end of statements. |
| Operator Spacing | Operators should be surrounded by one space on either side. Correct: local x = 128 Correct: if x > 57 then Incorrect: local x=128 The exception to this rule is in for-loop initializer lists, where omitting the space is required for syntactic correctness: for i=1,10 ... |
Pull requests will be denied if they contain any of the following:
- Multiple devices per certification request.
- Custom Capabilities, such as those that are not in the SmartThings namespace.
- Custom Preferences, such as those that are not in the SmartThings namespace.
- The device uses a custom Zigbee, Z-Wave, Matter cluster.
- A duplicate fingerprint already in use by another SmartThings Edge Driver
- When possible, manufacturer-specific names should not be used in naming a profile.