Hi Lior,

You can use the Sonar Runner to do a “dry run” and show you the differences in metrics (new violations, etc) in your local code vs. what’s on the server. This is really nifty if you want to use it, though we didn’t use it much.

I really only used Sonar for metrics, and did not worry about style or code analysis. I rely on the IDE for code analysis and style enforcement. I feel style and code issues should always be caught at the development phase, so rely on tools for it. Your file should always be “green.” If teams aren’t achieving this, I find it requires a different approach than the more nebulous concept of ‘good code vs. bad code.’ Code analysis also happens in Sonar, but it’s not very in-depth (especially for Python), and we handle most issues upstream as described. We usually don’t put in many style checks.

Regarding introducing code analysis to a live project, I will go into this more in my next post (I’ll also add that not having nearly any style or analysis in the metrics reduces the noise). If how we used Sonar in that context is still unclear, tell me and I’ll attempt to clarify.

I personally dislike the client-server architecture it imposes. Many times i just like to have some code analysis locally to see how new code looks like. This complicates the process a bit.

Are you using Sonar only for code metrics or also for code analysis? if so, how are you handling the biggest issue of introducing code analysis to a “live” project ? (e.g; gajillion errors during the nightly build)