Naming Convention for Rules
This page is under progress, lines marked with red is considered material for discussion by the rules group. When we come to a conclusion we will either remove it or remove the red marker.
Rule filename and class name
The rule filename and the class name should be consistent with each other. When writing a new rule it should be named using UpperCamelCase, no underscores in the class name.
The name should always end with Rule.
Example:
case class CrossVendorArpFailureRule(context: RuleContext)
Filename in this case would then be "CrossVendorArpFailureRule.scala"
The class name should always start with the vendor if possible or "CrossVendor" if the rule applies to multiple vendors. Example of vendors:
- CrossVendor
- CheckPoint
- Cisco
- F5
- Panos
- Juniper
- BlueCoat
- Fortinet
Rule parameters
We use named parameters since it gives a better view of what we are trying to accomplish. The parameter order should be consistent with the original parameter order, for reference, see this page: Rules
- ruleName
- A special mention here. The rule name should be consistent with the class name and the filename. In previous example this would be "CrossVendorArpFailureRule"
Continuous changes
Some things to keep in mind both while writing a new rules or modifying old ones.
- Trailing whitespaces
- We don't want them, remove them
- indeni in strings
- Capitalize them if they are not
Should we change class names, filenames and ruleName while working on an existing rule? This is subject for discussion at this point and not yet implemented. For the time being, leave the class and filenames as they are.
This change would NOT be for the non-template rules, don't touch these names.