Fixing function-name rule functionality added by PR #501. These options should be reworked in the future, but the intent of this change is that the existing intended functionality is met.
PR checklist
[x] Addresses an existing issue: fixes #661
[x] New feature, bugfix, or enhancement
[x] Includes tests
[x] Documentation update
Overview of change:
The function-name rule supports options for handling private/protected static methods. The default option is "validate-private-statics-as-private", which means that private/protected static methods will only validate against the private-method regex.
When changing to the either the "validate-private-statics-as-either" or "validate-private-statics-as-static" option, it would not perform and validation on private/protected static methods.
After the change, "validate-private-statics-as-static" will only validate against the static-method regex, and "validate-private-statics-as-either" will validate against both, but only add a failure if both fail to match.
Fixing function-name rule functionality added by PR #501. These options should be reworked in the future, but the intent of this change is that the existing intended functionality is met.
PR checklist
Overview of change:
The function-name rule supports options for handling private/protected static methods. The default option is "validate-private-statics-as-private", which means that private/protected static methods will only validate against the private-method regex.
When changing to the either the "validate-private-statics-as-either" or "validate-private-statics-as-static" option, it would not perform and validation on private/protected static methods.
After the change, "validate-private-statics-as-static" will only validate against the static-method regex, and "validate-private-statics-as-either" will validate against both, but only add a failure if both fail to match.