Are functions a loophole in compliance score system?
The compliance score was introduced to promote best practices in development. Improving the compliance score becomes often the goal of the whole sprints, during which the code is reviewed and refactored.
However, improving your compliance score does not always mean improving your code quality. I am pretty sure everyone has seen activities on @baseclass being wrappers for commits and obj-saves which are introduced only to reduce the number of warnings in the system. Good if they are system-wide solutions with the correct error handling. Worse if each development team creates their own activity for wrapping Obj-Save and each deals with error handling in a different way or not at all. Another method of reducing the number of warnings in the system gaining popularity recently are functions.
Build-in functions allow you to reduce the number of warnings in the system in a number of ways. You can call an existing activity by a datatransform, avoiding warning for activity use. You can log messages from an activity without security warning. Do those really improve our code?
Or are they rather tricks to improve compliance score?
Have the functions become loophole in the compliance score system?
***Edited by Moderator Marije to add Dev Studio tag to Question***
Ordina
NL
@GrzegorzK I think we can define good and bad loopholes and I would like to name a few examples:
- A good loophole is calling a generic activity PageChangeClass from a data transform instead of setting .pxObjClass directly, since it can leverage the Page-Change-Class OOTB method. It is not just any property that is being set and it should be treated as such.
- A questionable loophole is creating a custom 'Commit' activity that calls the commit method only (I believe using the commit method is giving a severe warning and using an activity a moderate warning)
- A bad loophole is removing a guardrail warning by setting an activity to type 'Utility' when it is not meant as utility, but it will work regardless of that
- In general, I try to avoid too code-y solutions and I think functions are a typical example that we don't want to overleverage just for guardrail scores. Whenever I think I'm just improving the guardrail score without providing any other benefits, it should be a red flag.