Writing code is an inexact science, imperfections in your code are inevitable and add up.
Having a tool that constantly nags you to strive for perfect code is a must have for flawed [see human] developers.
Compiled Code
Where code analysis tools really excel is with compiled code.
With compiled code, the clean code tools not only analyse the quality of your code but also automatically fix and style it!. With compiled code you get piece of mind when these ‘automatic’ changes are made because the compiler is there to reassure you.
Thank God for Resharper!
I use these type of productivity tools religiously; in particular, for any C# or JS code that I write, I always use/need Resharper from JetBrains.
Some people might say that it is ‘lazy’, letting a productivity tool ‘automagically’ do what you should be doing out of hard learned habit. I agree, it is lazy, and I am often sloppy with my code knowing that my ‘magic helper’ will clean up after me. But, I have found that, after a while, I start incorporating the suggestions and changes that the tools give me into my ‘unclean’ code, so that the tools have less work to do and my code becomes cleaner ‘naturally’.
Too much of a good thing?
However, you can go too far with these tools.
Not only do you start to rely heavily on these types of tool to do a lot of the basic coding for you but also some of the suggestions it make for code changes can lead to your code becoming less ‘human readable’. It is soooo tempting to accept the suggestions to lambdify or linq entire sections of your code just because Reharper tell you to do it and it compresses your code to a single line. I thoroughly recommend watching the clean code Pluralsight course or reading Robert Martin’s (uncle Bob) book on clean code, to understand why human readable code is so important.
Interpreted Code
Things get more trickier with interpreted code e.g. Javascript. With interpreted code you do not have the compiler to reassure you that any ‘automagic’ changes are ‘safe’. For this reason, most clean code tools for interpreted code will give advice, rather than make changes for you. However, the ‘linting’ tools for interpreted code (JS in particular) have come a long way and are an essential part of any coder’s utility belt. For instance, when writing Javascript code I now rely [heavily] on Douglas Crockford’s JSLint to tell me that have been a naughty boy (I would highly recommend all Javascript developers to read Douglas’s book: Javascript The good parts and watch his talk on pluralsight) about Javascript.
What lint/analysis/style/refactoring tools do you use everyday and cannot live without? Leave a comment below:
