Programming is like sex. One mistake and you have to support it for the rest of your life. Michael Sinz
The battle against bad code is a never-ending one and it’s important CRM developers keep code quality high.
These blogs talk about the effects of bad code
- Bad code is like a virus, don’t get infected
- The problems with complex code and complex CRM Customizations
One of the causes of bad code is rushed projects and tight deadlines, developers need to have integrity and not let leave a CRM developers stranded. You can stop bad code by writing code like a boy scout and having passion for CRM development
- Write unit tests
- Use static analysis tools
- Code reviews
- Get into good habits
- Junior developers learn correct formatting
- Create quality code
- You will thank yourself in the future
- It reminds all developers to tidy up their code
Re-Sharper is a great tool and once you have tried it, it’s difficult to go back – CRM Developers tools of the trade – Resharper
Writing unit tests and checking and correctly your code using code analysis tools seem like extra work which one reason developers don’t like using them but it allows you test the logic of your code and for all developers to refactor the code and test if it’s still working.
- Experiences of Unit testing with Microsoft Dynamics CRM Projects
- Why CRM Developers should unit test their code
- Information to Get started with Unit Testing with Microsoft Fakes and Microsoft Dynamics CRM 2013
- Unit tests are a vital part of emerging code design
Writing unit tests and analyzing and fixing code seems like you are not progressing because you are not writing new code but you are creating quality code and quality code will take less time to interact with in the future.
Bug fixing, understanding, extending and modifying is easier and quicker with quality code than it is in legacy code. If the code is consistent between different programmers it’s easier to read and maintain – Why your CRM code and customizations should be simple. Static code analysis helps to make sure all code written but different developers conforms to the same standards and is similar.
A good example is bug fixing legacy code with huge methods, it’s difficult to understand and tricky to fix, Are your CRM plugins creating technical debt?
When you first analyse your code
When you first analyse you code you will get a lot of warnings and I mean lots. If you run the analyser on a legacy project or project with a lot of code (and hasn’t been analysed before) you will get a lot of warnings.
My advice is to start small and just use this on the code you have been recently creating/changing.
Don’t take the warnings personally, view the warnings like someone code reviewing your code and giving your tips on how to create better code.
Remember they are warnings, you should see them as recommendations, in some situations is OK to ignore a warning if you have a good reason for it, this is better than not knowing there was a potential problem.
I am a continuous learner, I like learning, I like improving and getting feedback on your code is a good way to learn, I believe in continuous learning and improvement.
Finish work a litter wiser about CRM than you when you started work. – Hosk
When I analysed the code I got lots of warnings but I found these interesting. I wanted to know the logic behind the warning.
It’s easy to be initially overwhelmed and condemn the analysis as being too pedantic. In some recommendations it can be but if you can prove your reason for ignoring the warning (with something more than I can’t be bothered to change it).
Over time I found myself writing code which I knew would not generate complaints from the static analysis tool because I didn’t want to have to go through the code and correcting it. This shows me static analysis is an effective tool in changing my the syntax of the code I was writing.
The goal of static analysis
Creating standard code syntax and get the team to deliver a minimum standard of code. Developers can get lazy and like to quickly check in code, running static analysis is a good tool to nudge developers to tidy up their code. Static analysis is like running a spell and grammar check on your code, it finds areas you can polish your first draft.
Static code analysis also finds common bad coding practices and highlights poor code design.
Look at the default areas the default rule set checks
I had some errors telling me to hide public variables.
CA1002 – Do Not expose generic List
CA1822 – Mark members as static
Members that do not access instance data or call instance methods can be marked as static (Shared in Visual Basic). After you mark the methods as static, the compiler will emit nonvirtual call sites to these members. Emitting nonvirtual call sites will prevent a check at runtime for each call that makes sure that the current object pointer is non-null. This can achieve a measurable performance gain for performance-sensitive code. In some cases, the failure to access the current object instance represents a correctness issue.
Why was I getting this error, this articles help to explain
It’s ok to ignore some errors
I was getting an error CA1011 – Consider passing base types as parameters
I was passing in an early bound type e.g. contact and it was saying I could pass in entity. I’m happy to ignore this warning for CRM early bound classes because I the method needs a contact record and isn’t going to work with a different one. I want this type checking on the method.
What did I make of it
I found the process interesting. As I went through the warnings I would think about the design of the code and the merits the warning and suggested action.
The key to making this productive is to understand why it’s warning you. To do this I had to paste the warning into the internet and search for blog posts or usually forum posts discussing the warning.
Most of the warnings made me change the code for the better, it made me think about what the code was doing. Its tedious to begin with because there are lots of errors but over time the number of errors reduces and you code becomes more standard and following best practices.
Given time I would recommend a CRM development team keep updating the rules and turning off the ones which aren’t relevant. This would generate a set of standard rules your code should follow.
I think all CRM developers should have static code analysis running on their code, it will help you keep your code tidy and uniform.
CRM development teams should spend time updating the rules run for CRM code and turning off the rules which are not relevant. If you had time it’s possible to create new rules.
Developers should run static analysis on their code and I would recommend all code goes through a code review, the threat of a code review will help ensure code is kept at a high level.
Code reviews are a great way for junior developers to learn from senior developers.