{"id":12096,"date":"2014-04-23T12:16:42","date_gmt":"2014-04-23T09:16:42","guid":{"rendered":"https:\/\/mozaicworks.com\/?p=6924"},"modified":"2022-02-01T17:59:33","modified_gmt":"2022-02-01T15:59:33","slug":"measuring-code-quality","status":"publish","type":"post","link":"https:\/\/mozaicworks.com\/blog\/measuring-code-quality","title":{"rendered":"Measuring code quality"},"content":{"rendered":"<p>In about six weeks I&#8217;ll attend the second edition of <a title=\"I T.A.K.E. Unconference\" href=\"http:\/\/2014.itakeunconf.com\">I T.A.K.E. Unconference<\/a>. &#8220;Preparing&#8221; for it, I decided to take a look at the videos for some of the talks that I missed last year. Today, I watched <a title=\"The good, the bad and the ugly of dealing with smelly code | YouTube\" href=\"https:\/\/www.youtube.com\/watch?v=tIM96lYPX5M\">The Good, the Bad and the Ugly of Dealing with Smelly Code<\/a> by <a title=\"Radu Marinescu homepage\" href=\"http:\/\/bigfoot.cs.upt.ro\/~radum\/\" class=\"broken_link\">Radu Marinescu<\/a>.<\/p>\n<p>Watching it has reinforced my belief that we can (and should) try to be more specific about <strong>measuring the code quality<\/strong>. I meet quite often teams that only track the number of reported production bugs. This is a good metric, and one I recommend, but it shouldn&#8217;t be the only thing you measure. Why? For at least a few reasons:<\/p>\n<ul>\n<li>It&#8217;s a <strong>lagging indicator<\/strong>. That means you can&#8217;t take action until after an unfortunate event has happened.<\/li>\n<li>It doesn&#8217;t give much indication on <strong>where to focus your efforts<\/strong>. Sometimes it&#8217;s difficult to reason about the module(s) with low quality from the bugs alone, because there&#8217;s a chain of errors that led to the bug.<\/li>\n<li>It tends to lead to <strong>arguments<\/strong> between coders and testers about whose fault it is that the bugs weren&#8217;t caught.<\/li>\n<\/ul>\n<p>So, what is Radu suggesting that we do? Well, he argues that we should augment our toolset by adding applications which measure and visualize quality at the class and module level. This way, we can control quality.<\/p>\n<p>A popular tool for code analysis is <a title=\"SonarQube\" href=\"http:\/\/www.sonarqube.org\/\">SonarQube<\/a>, which supports 20 languages, but there&#8217;s a <a title=\"List of tools for static code analysis | Wikipedia\" href=\"http:\/\/en.wikipedia.org\/wiki\/List_of_tools_for_static_code_analysis\">Wikipedia page<\/a> that lists tens of others.\u00a0Radu himself has been part of a team which develops two products for the same purpose: <a title=\"inFusion\" href=\"https:\/\/web.archive.org\/web\/20160419042239\/http:\/\/www.intooitus.com\/products\/infusion\">inFusion<\/a> and <a title=\"inCode\" href=\"https:\/\/web.archive.org\/web\/20160327100843\/http:\/\/www.intooitus.com\/products\/incode\">inCode<\/a>. You should check them out. They not only provide standards metrics like lines of code per class or cyclomatic complexity, but they have heuristic engines which can detect code smells like <a title=\"God class | c2 wiki\" href=\"http:\/\/c2.com\/cgi\/wiki?GodClass\">God Class<\/a> or <a title=\"Feature Envy | c2 wiki\" href=\"http:\/\/c2.com\/cgi\/wiki?FeatureEnvySmell\">Feature Envy<\/a>. If you use inFusion or inCode, you can also take advantage of another tool called <a title=\"CodeCity\" href=\"http:\/\/www.inf.usi.ch\/phd\/wettel\/codecity.html\">CodeCity<\/a>, which represents your code graphically, just like a city with buildings. The image above is actually generated using this tool.<\/p>\n<p>Some more advice I took from Radu&#8217;s talk:<\/p>\n<ul>\n<li>Often time the code is the <strong>only documentation<\/strong> we have. Technical specs don&#8217;t get written or they are written upfront, so by the time we finish the project they are out of date. As such, to ensure maintainability it makes a lot of sense to invest time in cleaning up our code.<\/li>\n<li>Use <strong>multiple metrics<\/strong> to make decisions. A doctor correlates the various results from your blood analysis to understand if you&#8217;re healthy. Likewise, we shouldn&#8217;t focus on a single metric, like cyclomatic complexity or fan out when trying to decide where to intervene.<\/li>\n<li>Metrics will only point you in the right direction. They are like a rough map. To really understand what&#8217;s going on, you&#8217;ll need to dig deeper. <strong>Gather context<\/strong> by going at the code level.<\/li>\n<li>Whenever possible, use tools that have <strong>visualization<\/strong> features. &#8220;A picture is worth a thousand words&#8221;, they say. Our brains have evolved for pattern matching, that&#8217;s why we can instantly understand what a chart like the one above is telling us.<\/li>\n<\/ul>\n<p>What about you? How do you ensure a high code quality? What tools are you using for code analysis? Let me know in the comments.<\/p>\n<p>Also, if you&#8217;d like to learn more about the quality of your code or playing with data, don&#8217;t miss this year&#8217;s edition of <a title=\"I TAKE Unconference 2014\" href=\"http:\/\/2014.itakeunconf.com\/\">I T.A.K.E. Unconference<\/a>. A couple of sessions that I find interesting:\u00a0<a href=\"http:\/\/2014.itakeunconf.com\/aki-salmi-refactoring-legacy-code-a-true-story\/\">Aki Salmi \u2013 Refactoring Legacy Code \u2013 a true Story<\/a>\u00a0and\u00a0<a href=\"http:\/\/2014.itakeunconf.com\/martin-naumann-open-data-wizardry-101\/\">Martin Naumann \u2013 Open Data Wizardry 101<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In about six weeks I&#8217;ll attend the second edition of I T.A.K.E. Unconference. &#8220;Preparing&#8221; for it, I decided to take a look at the videos for some of the talks that I missed last year. Today, I watched The Good, the Bad and the Ugly of Dealing with Smelly Code by Radu Marinescu. Watching it [&hellip;]<\/p>\n","protected":false},"author":4,"featured_media":6927,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""}},"footnotes":""},"categories":[1103,1126],"tags":[],"acf":[],"_links":{"self":[{"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/posts\/12096"}],"collection":[{"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/comments?post=12096"}],"version-history":[{"count":2,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/posts\/12096\/revisions"}],"predecessor-version":[{"id":14308,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/posts\/12096\/revisions\/14308"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/media\/6927"}],"wp:attachment":[{"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/media?parent=12096"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/categories?post=12096"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/tags?post=12096"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}