Writing software can be hard, but it doesn’t have to be complex and hard to understand. On this weeks episode, Robert and I will discuss what cyclomatic complexity is, and how to refactor code to be less complex
The opinions expressed by guests do not always follow Salesforce Best Practices; and that’s OK. Receiving feedback on code from trusted members of the community is a gift for everyone – but not all feedback is in line with the goals of the Apex-Recipes project, or Salesforce best practices. We encourage viewers to be open to learning new ideas, while critically thinking about that feedback in relation to published best practices.
Salesforce Prettier default settings in apex is really frustrating, specially when you need to debug a specific line.
I agree with Kevin, the third parameter on assert can also save a comment
I do not agree with Robert telling his devs not to listen to Salesforce recommendations. This is not Java custom development, and it’s best to follow the platform’s recommendations.
Robert has some great tips, but his code will be unmaintainable to devs outside of his team. I found myself agreeing with Kevin a lot more.
In terms of writing solid OO code, I think Robert's points are spot on. Points like static being the enemy of OO are 100% legit.
In terms of writing readable code, again I think Robert is spot on in some of the classical knowledge he espouses. He correctly identifies things such as the association between a variable's scope and the length/explanatory value of its name, which anyone reading the coding classics such as Code Complete would be well aware of. The other point that comments should only explain things not obvious from the code (such as why conventions are being broken) is also common knowledge among well-studied developers.
As can be seen from other comments here, his point on omitting the last parameter to System.assert is a bit more controversial and I don't really have an opinion either way on it.
The problem I see is that it all boils down to your definition of good, or clean code. Self-evidently one of the criteria would be how understandable the code is. But how understandable to who? If by good Salesforce code we mean code which is understandable to most Salesforce developers, then let's face it – most orgs I've seen do not contain solid OO code. Instead, we see lots of procedural if/else code, static methods everywhere, 0 real application of the GOF design patterns, classes with more than one actual responsibility etc. Just to highlight that by 'procedural' here I don't mean messy or necessarily bad code, I just mean the procedural and not object-oriented paradigm.
I don't mean to indict those who write such code. Imo Salesforce as a platform does lend itself toward more procedural code, for several reasons. For one there are several native classes given to you for free, most important imo being the auto-generated sObject classes and the Schema class. For two Salesforce code has to take into consideration its interaction with declarative processes as well. But all in all it does mean that introducing OO concepts or design patterns brings with it a greater level of overhead, and it is imo again the reason why we don't see libraries like FFLib being used everywhere. In turn that generates even more unfamiliarity with OO among SF developers. So when someone really wants to do some cool OO stuff, that's when everyone scratches their head and asks: How pragmatic is this?
good video buddy
Hi Kevin
Can you take this to Salesforce,
We would like to have custom pmd rules open source for salesforce apex.
Request salesforce to invest in development on code analyser.
Similar to what you did for ESLint…
Can you refer any link where we have solution guidance for the different cyclometic and cognitive complexity
Comments are closed.