{"results":{"result":{"added-files":{"code-health":9.113704069027243,"old-code-health":0.0,"files":[{"file":"src/mips/tests/spu/spu-adsr.c","loc":585,"code-health":9.92101847124095},{"file":"src/mips/tests/spu/spu.c","loc":308,"code-health":8.071417696154342},{"file":"src/mips/tests/spu/spu-adpcm-edge.c","loc":283,"code-health":9.6882083290695},{"file":"src/mips/tests/spu/spu-adsr-edge.c","loc":1578,"code-health":8.816158827775617},{"file":"src/mips/tests/spu/spu-irq.c","loc":240,"code-health":10.0},{"file":"src/mips/tests/spu/spu-reverb.c","loc":153,"code-health":8.816158827775617},{"file":"src/spu/adpcm.cc","loc":52,"code-health":9.6882083290695},{"file":"src/spu/interpolation.cc","loc":112,"code-health":9.387218218812514},{"file":"src/spu/noise.cc","loc":23,"code-health":10.0},{"file":"src/spu/volume.cc","loc":17,"code-health":10.0},{"file":"src/mips/tests/spu-revstream/revstream.c","loc":283,"code-health":8.887583048508702},{"file":"src/mips/tests/spu-endx/spu-endx.c","loc":133,"code-health":8.807895773344363},{"file":"tests/pcsxrunner/spu.cc","loc":15,"code-health":10.0},{"file":"src/mips/tests/spu/spu-modeaxes.c","loc":68,"code-health":10.0},{"file":"src/mips/tests/spu-envx/spu-envx.c","loc":176,"code-health":8.187041314146978},{"file":"src/mips/tests/spu-capring/spu-capamp.c","loc":114,"code-health":9.560498726891074},{"file":"src/mips/tests/spu-capring/spu-capring.c","loc":160,"code-health":8.977641209366904},{"file":"src/mips/tests/spu-capring/spu-capphase.c","loc":105,"code-health":9.560498726891074},{"file":"src/mips/tests/spu-capring/spu-capmin.c","loc":104,"code-health":9.560498726891074},{"file":"src/mips/tests/spu-envx/spu-adsrsus.c","loc":171,"code-health":8.679575849015766},{"file":"src/mips/tests/spu-capring/spu-dbuf.c","loc":147,"code-health":9.263932926662653},{"file":"src/mips/tests/spu-offvoice/spu-offvoice.c","loc":163,"code-health":9.213969215774869}]},"external-review-url":"https://github.com/grumpycoders/pcsx-redux/pull/2077","old-code-health":4.862482467553786,"modified-files":{"code-health":4.996039185493912,"old-code-health":4.862482467553786,"files":[{"file":"src/spu/spu.cc","loc":403,"old-loc":595,"code-health":7.083502144396736,"old-code-health":5.318354296531019},{"file":"src/spu/adsr.cc","loc":141,"old-loc":155,"code-health":9.240656298427343,"old-code-health":8.95517096544394},{"file":"src/spu/debug.cc","loc":496,"old-loc":489,"code-health":8.769450206273154,"old-code-health":8.500289110492574},{"file":"src/spu/freeze.cc","loc":105,"old-loc":105,"code-health":10.0,"old-code-health":9.6882083290695},{"file":"src/spu/registers.cc","loc":494,"old-loc":562,"code-health":5.171397807803967,"old-code-health":5.026885908624964},{"file":"src/spu/reverb.cc","loc":131,"old-loc":231,"code-health":8.935561426402087,"old-code-health":7.5565738221844265},{"file":"src/spu/dma.cc","loc":29,"old-loc":31,"code-health":10.0,"old-code-health":10.0},{"file":"src/core/psxcounters.cc","loc":302,"old-loc":310,"code-health":7.154263605338944,"old-code-health":7.134765815706222},{"file":"src/gui/gui.cc","loc":2712,"old-loc":2715,"code-health":1.9424457755627633,"old-code-health":1.9424457755627633},{"file":"src/spu/cfg.cc","loc":70,"old-loc":71,"code-health":9.536386775820924,"old-code-health":9.536386775820924},{"file":"src/spu/xa.cc","loc":108,"old-loc":110,"code-health":8.326221139186547,"old-code-health":8.316927997055405},{"file":"src/supportpsx/binloader.cc","loc":234,"old-loc":230,"code-health":8.076405912320604,"old-code-health":8.076405912320604},{"file":"src/core/sstate.cc","loc":388,"old-loc":390,"code-health":9.240075223506865,"old-code-health":9.240075223506865}]},"removed-files":{"code-health":0.0,"old-code-health":0.0,"files":[]},"external-review-id":"2077","analysis-time":"2026-09-06T02:09:02Z","negative-impact-count":53,"suppressions":{"number-of-types":0,"number-of-files-touched":0,"findings":[]},"affected-hotspots":1,"commits":["89c8dba09008de76a49bd7ea0fcccf616fc9c759","68b9e247fc852011bbc4ade4195d21ba734facd6","e4c33362a15ee52a006078c6acf3f7d108bcdf1a","89328de2431e30ae77210a99e703585b20b034bc","e18c49989bd11332acf4f851e7ecdd706208651e","cb379f6bc0e7d9311b75cdeb12351b67f98c6c17","ef5dcdc4f362a92d4ac000f696e79d1466c21e70","f6d46d6bccca3dfc59d2112a4ea88d625b0e5fe5","11b7d4ecb7c2a2d6df0f2f2e2668f4800df9a8fe","c2e824fea1034b7e8babf242c5b5ac93a1c49f68","605c01d2e3fa80d600d2936aac9e9319ccc1bc1a","7d0cb3f73b54d76244e179ff12a4c652f64d34f1","bd03da16c1d063dc3c05cf06d7597252788c42ce","cd8b249af8bf59175c1d6b7bc14f13eabc6777c0","79424f46ef2d69e7f56fba7b882401f79412a729","386aa5141b78ccc4304813b8bde43b4831656029","537f5a65c4263b979c893e944593732b17718a80","bb3ab76262401f59b83687a8881eb87c28b475cd","b5f39a3eacb8144f28763ac9484f166358cb2464","67140787cef7070224733509631b948027c81836","bacb1515067a99dc65a83d113ff5720ab1a1554c","d128cb78a95fc13ecd84f51adc58262d5198e48f","0ba89776561f17256ddcef200d91d810da12ebfd","8a25325aeb03d708ad91eef2ce7d577badc4bfd8","b55e522f45d05d0880563591faea1945d3b4b78f","78868924734086e8365d8e48019d9485e744724d","7e0b429c6d14d2f68e35a5743398786271554eb9","e4df352d5aa75f838ebfc2d704a9d7438bc93282","67d6c81c374ca32b278d274ec8e6b55de9f6a5b4","395e3bd684a07c19c6be2d8764b650a57d66b3ae","abd391ae2c092a130571f98426d04dac127f0058","92cc559055da69a9629eecaf0ea0ae17f027d18b","75de27a57f1d622a5e817b9bcd97f5458638a6ad","b161d8e4975b5a61ea5a51adf463e7bf70e9f836","38d0db224485996cad7a94b9e5f7b68f20e539eb","7da91e69ce3eba61c9afa7b60129c3687d61b849","b1e94040416d5bda7541e41329d56e443efc18c3","a778b525a6df9aab93b6991efaca2d2bc53ad740","067a0a53277070ae8b42730f354971dff3ed523b","471cf7727a16155f8ad67a31dfbd8451e8ff6558","7c2736e78230f2609b7de2872e4b2c77d7bcb046","ef466312abbf1d4e5db3fec1dc4ef2f216257958","ec8fde4b3a18663fdf6ff559fe3ff3065444e054","4f591091a32b2001ac994b92377494a33bb8d9a1","15b1dc0934c926f16b452f5d6f75f05d59099481","4093427db2f2f4a7ad84b115c6f81d130785cd72","d72ad33e1aeaa0d53ea065f7314543d970eeabdf","1d80ec3b7f6f9f081a9f6ac6983e0276da5771f6","f724ce911ad1d11c0c059fda5a8ee11a2be4b0c4","e9fd92d41847151d2221008a3e18db1dbe9cfc0a","685eb8636b5c89230178e5bd4b14796ee97f9117","f311b0886d4f14eb5459be22304adc55c9584c9f","39d7df32a75222032ace3dc5d428921f08005d1c","c2e7b841b58dd4d399b45e7866805e7cce9cf748","4ebb6e5c78a3ac191e9c4e21dbdd207a42e11314","1468fa5925a65278fc61908b3829d879b6445de9","cf692c6d9c19c2f899e7bfc198e3e52c4cc3e5e2","0042d22da30296ad0695e20337b99b0375e96743","32dced8a424c90f50cc110409661f63593a78196","29d36d51c599886f9bab40b5daabcbce172e51b2","367c848e69d21abc7bd8b6b521f2ebb2ec66f709","e7f9fa9a4aac7f013610e6b5311d82739f4527e4","14f0f069782e1fe130f78eeca7dcbe956d2cb42b","8cb05c7c64fbd38fc8c53d6503731ef079e89067","841ad281df1a9390d7e268e7f91328400cd5c995","703ad59f6e7e4a3076c2a121bf15f72e5d0ed286","30b06fe35db4f5f57ad42584cb96101bfa65b82d","56e0ffdf8a1534edde7ce957a6b0d6baad3d0180","bef3e97ed0f597124bedffc6c2ea1846e845d460","0f31104fe69705d71ced31a95721e3165c08411f","054466f9d89f5823899abddfd0d61e8d6057b569","95d6a6b6a91da10df93f75eedb899b92914e6a94","a9b210c786d7715235cdd2d6a929a8dd10baef73","20e368b2efa663ff1f7c7494e2825a6b05ffed93","7f8c65ce0db1a70855cdf0f2f40ab260b4c02780","d7093e97d2d2d3c82146a53abbdd7de88285b65f","edec4e3c094784562a660f1c07dc8fb527df2a57","858b86953ad373a199031060b711c7a29c5bc1ee","1385648a5746a08f304e0e8028dd576204a6673f","1f7673275425162fbb22b285f9b6976e77f088e8","fc19fb6d24dae58553867168a4e3014112fe076e","41003bfcb43ec2e7dbfb16e30b487a1fd504a486","1d0f560608966fd75a860fd1d43f722d68dd0dd0","d8f62e9b09aeb0fd4b94bbd366b31333457adb67","35d7423929d62918d1cdde09db089c843d0dca67","bba7819fe1e7484d019235c6b1ee06b966268b5b","b690535b4bfdbee933805231cb9dac442f12aedd","4e3dfe5ff9afab4f5c5987751b2db865fb294fbf","9e165e4f6ffd6057fe8d814ad849b8745f2e30fd","be546bc20d287801c08c5897fcf195dae8b4aa13","4e460728fa8008d73c6a59c3c0d23d4cbcff63b5","441ee2db5c156d9ea86deee1316bb1b5e9aa07e4","1825f6c46ccf6ed1bc5651983375222f6978324c","a132d0e1e0998bc415bd2d8e938967da55e1ef71","ba7179fea16997ced74ecc018cea514b48bc7a1e","42fd4c5ff28a1575e02ebdc22f2da5aec75ce4cc","7e9de36c2eeda22a990ac91576719eb41f11b5fe","cf3c16477382a58be702662530e2a8c5403d41c9","1591bc9ba3497df84e77c4c8514609e93f1a1ff9","32f6e8192b18053e71e089c36a80bca4f9dadde7","61cde711d2e88cce5819e64ba496fd8bd1762513","f4d80dcb53bb446448a7d5298ab32a601b1b1005","e9fa673645e68838d941b22efd30adda9a74c903","8474de287a9da8c308412729e885e7be98fba5ca","e487d7d176eda195bcff77bd5d2b3a198a863645","2677bf466f35ca85389d9dc6dfb66007be781b40","3a8e23a5e9e615840aea0e1b0e478a7c91b64b9b","0788a6fee3611f68d339a20f0133155675db99e5"],"is-negative-review":true,"negative-findings":{"number-of-types":8,"number-of-files-touched":19,"findings":[{"why-it-occurs":"Code that uses a high degree of built-in, primitives such as integers, strings, floats, lacks a domain language that encapsulates the validation and semantics of function arguments. Primitive Obsession has several consequences: 1) In a statically typed language, the compiler will detect less erroneous assignments. 2) Security impact since the possible value range of a variable/argument isn't retricted.\n\nIn this module, 31 % of all functions have primitive types as arguments.","name":"Primitive Obsession","file":"src/spu/spu.cc","refactoring-examples":[{"diff":"diff --git a/primitive-obsession.ts b/primitive-obsession.ts\nindex 38bae186cc..24116eddcc 100644\n--- a/primitive-obsession.ts\n+++ b/primitive-obsession.ts\n@@ -1,8 +1,8 @@\n-// Problem: It's hard to know what this function does, and what values are valid as parameters.\n-function getPopularRepositories(String baseURL, String query, Integer pages, Integer pageSize, String sortorder): Json {\n-\tlet pages == null ? 10 : pages\n-\tlet pageSize == null ? 10 : pageSize\n-  return httpClient.get(`${baseURL}?q=${query}&pages=${pages}&pageSize=${pageSize}&sortorder=${sortorder}`)\n+// Refactoring: extract the pagination & API logic into a class, and it will\n+// attract validation and other logic related to the specific query. It's now\n+// easier to use and to maintain the getPopularRepositories function!\n+function getPopularRepositories(query: PaginatedRepoQuery): Json {\n+  return httpClient.get(query.getURL())\n     .map(json => json.repositories)\n     .filter(repository => repositry.stargazersCount > 1000)\n }\n","language":"c++","improvement-type":"Primitive Obsession"}],"change-level":"warning","is-hotspot?":false,"what-changed":"In this module, 31.4% of all function arguments are primitive types, threshold = 30.0%","how-to-fix":"Primitive Obsession indicates a missing domain language. Introduce data types that encapsulate the details and constraints of your domain. For example, instead of `int userId`, consider `User clicked`.","change-type":"introduced"},{"method":"spu_adsr_capture","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/mips/tests/spu/spu-adsr.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":36,"what-changed":"spu_adsr_capture has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"method":"spu_compare_golden","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/mips/tests/spu/spu.c","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"c","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":312,"what-changed":"spu_compare_golden has a cyclomatic complexity of 14, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"spu_dma_sync","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/mips/tests/spu/spu.c","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"c","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":218,"what-changed":"spu_dma_sync has a cyclomatic complexity of 12, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"spu_compare_golden","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/mips/tests/spu/spu.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":312,"what-changed":"spu_compare_golden has 3 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"method":"spu_pcm_analyze","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/mips/tests/spu/spu.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":159,"what-changed":"spu_pcm_analyze has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"why-it-occurs":"Overall Code Complexity is measured by the mean cyclomatic complexity across all functions in the file. The lower the number, the better.\n\nCyclomatic complexity is a function level metric that measures the number of logical branches (if-else, loops, etc.). Cyclomatic complexity is a rough complexity measure, but useful as a way of estimating the minimum number of unit tests you would need. As such, prefer functions with low cyclomatic complexity (2-3 branches).","name":"Overall Code Complexity","file":"src/mips/tests/spu/spu.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"what-changed":"This module has a mean cyclomatic complexity of 4.50 across 12 functions. The mean complexity threshold is 4","how-to-fix":"You address the overall cyclomatic complexity by a) modularizing the code, and b) abstract away the complexity. Let's look at some examples:\n\nModularizing the Code: Do an X-Ray and inspect the local hotspots. Are there any complex conditional expressions? If yes, then do a [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring. Extract the conditional logic into a separate function and put a good name on that function. This clarifies the intent and makes the original function easier to read. Repeat until all complex conditional expressions have been simplified.\n\n","change-type":"introduced"},{"method":"spu_pcm_analyze","why-it-occurs":"Deep nested logic means that you have control structures like if-statements or loops inside other control structures. Deep nested logic increases the cognitive load on the programmer reading the code. The human working memory has a maximum capacity of 3-4 items; beyond that threshold, we struggle with keeping things in our head. Consequently, deep nested logic has a strong correlation to defects and accounts for roughly 20% of all programming mistakes.\n\nCodeScene measures the maximum nesting depth inside each function. The deeper the nesting, the lower the code health. The threshold for the C language is 4 levels of nesting.","name":"Deep, Nested Complexity","file":"src/mips/tests/spu/spu.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":159,"what-changed":"spu_pcm_analyze has a nested complexity depth of 4, threshold = 4","how-to-fix":"Occassionally, it's possible to get rid of the nested logic by [Replacing Conditionals with Guard Clauses](https://refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html).\n\nAnother viable strategy is to identify smaller building blocks inside the nested chunks of logic and extract those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring explains the steps.","change-type":"introduced"},{"method":"spu_adpcm_edge_block","why-it-occurs":"Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.\n\nThe threshold for the C language is 4 function arguments.","name":"Excess Number of Function Arguments","file":"src/mips/tests/spu/spu-adpcm-edge.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":93,"what-changed":"spu_adpcm_edge_block has 5 arguments, max arguments = 4","how-to-fix":"Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring [INTRODUCE PARAMETER OBJECT](https://refactoring.com/catalog/introduceParameterObject.html) to encapsulate arguments that refer to the same logical concept.","change-type":"introduced"},{"name":"Lines of Declarations in a Single File","file":"src/mips/tests/spu/spu-adsr-edge.c","change-type":"introduced","change-level":"warning","is-hotspot?":false,"what-changed":"This module has 1508 lines of data declarations, threshold = 1500","refactoring-examples":null},{"method":"spu_adsr_edge_capture_custom","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/mips/tests/spu/spu-adsr-edge.c","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"c","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":1456,"what-changed":"spu_adsr_edge_capture_custom has a cyclomatic complexity of 11, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"spu_adsr_edge_capture_custom","why-it-occurs":"A complex conditional is an expression inside a branch such as an <code>if</code>-statmeent which consists of multiple, logical operations. Example: <code>if (x.started() && y.running())</code>.Complex conditionals make the code even harder to read, and contribute to the Complex Method code smell. Encapsulate them.","name":"Complex Conditional","file":"src/mips/tests/spu/spu-adsr-edge.c","refactoring-examples":[{"diff":"diff --git a/complex_conditional.js b/complex_conditional.js\nindex c43da09584..94259ce874 100644\n--- a/complex_conditional.js\n+++ b/complex_conditional.js\n@@ -1,16 +1,34 @@\n function messageReceived(message, timeReceived) {\n-   // Ignore all messages which aren't from known customers:\n-   if (!message.sender &&\n-       customers.getId(message.name) == null) {\n+   // Refactoring #1: encapsulate the business rule in a\n+   // function. A clear name replaces the need for the comment:\n+   if (!knownCustomer(message)) {\n      log('spam received -- ignoring');\n      return;\n    }\n \n-  // Provide an auto-reply when outside business hours:\n-  if ((timeReceived.getHours() > 17) ||\n-      (timeReceived.getHours() < 8)) {\n+  // Refactoring #2: encapsulate the business rule.\n+  // Again, note how a clear function name replaces the\n+  // need for a code comment:\n+  if (outsideBusinessHours(timeReceived)) {\n     return autoReplyTo(message);\n   }\n \n   pingAgentFor(message);\n+}\n+\n+function outsideBusinessHours(timeReceived) {\n+  // Refactoring #3: replace magic numbers with\n+  // symbols that communicate with the code reader:\n+  const closingHour = 17;\n+  const openingHour = 8;\n+\n+  const hours = timeReceived.getHours();\n+\n+  // Refactoring #4: simple conditional rules can\n+  // be further clarified by introducing a variable:\n+  const afterClosing = hours > closingHour;\n+  const beforeOpening = hours < openingHour;\n+\n+  // Yeah -- look how clear the business rule is now!\n+  return afterClosing || beforeOpening;\n }\n\\ No newline at end of file\n","language":"c","improvement-type":"Complex Conditional"}],"change-level":"warning","is-hotspot?":false,"line":1484,"what-changed":"spu_adsr_edge_capture_custom has 1 complex conditionals with 2 branches, threshold = 2","how-to-fix":"Apply the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring so that the complex conditional is encapsulated in a separate function with a good name that captures the business rule. Optionally, for simple expressions, introduce a new variable which holds the result of the complex conditional.","change-type":"introduced"},{"method":"spu_adsr_edge_capture_custom","why-it-occurs":"Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.\n\nThe threshold for the C language is 4 function arguments.","name":"Excess Number of Function Arguments","file":"src/mips/tests/spu/spu-adsr-edge.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":1456,"what-changed":"spu_adsr_edge_capture_custom has 6 arguments, max arguments = 4","how-to-fix":"Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring [INTRODUCE PARAMETER OBJECT](https://refactoring.com/catalog/introduceParameterObject.html) to encapsulate arguments that refer to the same logical concept.","change-type":"introduced"},{"method":"spu_adsr_edge_run_trace","why-it-occurs":"Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.\n\nThe threshold for the C language is 4 function arguments.","name":"Excess Number of Function Arguments","file":"src/mips/tests/spu/spu-adsr-edge.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":1493,"what-changed":"spu_adsr_edge_run_trace has 9 arguments, max arguments = 4","how-to-fix":"Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring [INTRODUCE PARAMETER OBJECT](https://refactoring.com/catalog/introduceParameterObject.html) to encapsulate arguments that refer to the same logical concept.","change-type":"introduced"},{"method":"spu_compare_reverb_golden","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/mips/tests/spu/spu-reverb.c","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"c","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":152,"what-changed":"spu_compare_reverb_golden has a cyclomatic complexity of 10, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"spu_compare_reverb_golden","why-it-occurs":"A complex conditional is an expression inside a branch such as an <code>if</code>-statmeent which consists of multiple, logical operations. Example: <code>if (x.started() && y.running())</code>.Complex conditionals make the code even harder to read, and contribute to the Complex Method code smell. Encapsulate them.","name":"Complex Conditional","file":"src/mips/tests/spu/spu-reverb.c","refactoring-examples":[{"diff":"diff --git a/complex_conditional.js b/complex_conditional.js\nindex c43da09584..94259ce874 100644\n--- a/complex_conditional.js\n+++ b/complex_conditional.js\n@@ -1,16 +1,34 @@\n function messageReceived(message, timeReceived) {\n-   // Ignore all messages which aren't from known customers:\n-   if (!message.sender &&\n-       customers.getId(message.name) == null) {\n+   // Refactoring #1: encapsulate the business rule in a\n+   // function. A clear name replaces the need for the comment:\n+   if (!knownCustomer(message)) {\n      log('spam received -- ignoring');\n      return;\n    }\n \n-  // Provide an auto-reply when outside business hours:\n-  if ((timeReceived.getHours() > 17) ||\n-      (timeReceived.getHours() < 8)) {\n+  // Refactoring #2: encapsulate the business rule.\n+  // Again, note how a clear function name replaces the\n+  // need for a code comment:\n+  if (outsideBusinessHours(timeReceived)) {\n     return autoReplyTo(message);\n   }\n \n   pingAgentFor(message);\n+}\n+\n+function outsideBusinessHours(timeReceived) {\n+  // Refactoring #3: replace magic numbers with\n+  // symbols that communicate with the code reader:\n+  const closingHour = 17;\n+  const openingHour = 8;\n+\n+  const hours = timeReceived.getHours();\n+\n+  // Refactoring #4: simple conditional rules can\n+  // be further clarified by introducing a variable:\n+  const afterClosing = hours > closingHour;\n+  const beforeOpening = hours < openingHour;\n+\n+  // Yeah -- look how clear the business rule is now!\n+  return afterClosing || beforeOpening;\n }\n\\ No newline at end of file\n","language":"c","improvement-type":"Complex Conditional"}],"change-level":"warning","is-hotspot?":false,"line":156,"what-changed":"spu_compare_reverb_golden has 1 complex conditionals with 6 branches, threshold = 2","how-to-fix":"Apply the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring so that the complex conditional is encapsulated in a separate function with a good name that captures the business rule. Optionally, for simple expressions, introduce a new variable which holds the result of the complex conditional.","change-type":"introduced"},{"method":"PCSX::SPU::AdpcmDecoder::loadFrom","why-it-occurs":"Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.\n\nThe threshold for the C++ language is 4 function arguments.","name":"Excess Number of Function Arguments","file":"src/spu/adpcm.cc","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":35,"what-changed":"PCSX::SPU::AdpcmDecoder::loadFrom has 8 arguments, max arguments = 4","how-to-fix":"Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring [INTRODUCE PARAMETER OBJECT](https://refactoring.com/catalog/introduceParameterObject.html) to encapsulate arguments that refer to the same logical concept.","change-type":"introduced"},{"method":"PCSX::SPU::Interpolator::interpolateUp","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C++ language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/spu/interpolation.cc","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"c++","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":72,"what-changed":"PCSX::SPU::Interpolator::interpolateUp has a cyclomatic complexity of 9, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"PCSX::SPU::Interpolator::interpolateUp","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/spu/interpolation.cc","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":72,"what-changed":"PCSX::SPU::Interpolator::interpolateUp has 3 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"method":"PCSX::SPU::Interpolator::storeVal","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/spu/interpolation.cc","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":131,"what-changed":"PCSX::SPU::Interpolator::storeVal has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"why-it-occurs":"Code that uses a high degree of built-in, primitives such as integers, strings, floats, lacks a domain language that encapsulates the validation and semantics of function arguments. Primitive Obsession has several consequences: 1) In a statically typed language, the compiler will detect less erroneous assignments. 2) Security impact since the possible value range of a variable/argument isn't retricted.\n\nIn this module, 58 % of all functions have primitive types as arguments.","name":"Primitive Obsession","file":"src/spu/reverb.cc","refactoring-examples":[{"diff":"diff --git a/primitive-obsession.ts b/primitive-obsession.ts\nindex 38bae186cc..24116eddcc 100644\n--- a/primitive-obsession.ts\n+++ b/primitive-obsession.ts\n@@ -1,8 +1,8 @@\n-// Problem: It's hard to know what this function does, and what values are valid as parameters.\n-function getPopularRepositories(String baseURL, String query, Integer pages, Integer pageSize, String sortorder): Json {\n-\tlet pages == null ? 10 : pages\n-\tlet pageSize == null ? 10 : pageSize\n-  return httpClient.get(`${baseURL}?q=${query}&pages=${pages}&pageSize=${pageSize}&sortorder=${sortorder}`)\n+// Refactoring: extract the pagination & API logic into a class, and it will\n+// attract validation and other logic related to the specific query. It's now\n+// easier to use and to maintain the getPopularRepositories function!\n+function getPopularRepositories(query: PaginatedRepoQuery): Json {\n+  return httpClient.get(query.getURL())\n     .map(json => json.repositories)\n     .filter(repository => repositry.stargazersCount > 1000)\n }\n","language":"c++","improvement-type":"Primitive Obsession"}],"change-level":"warning","is-hotspot?":false,"what-changed":"In this module, 57.9% of all function arguments are primitive types, threshold = 30.0%","how-to-fix":"Primitive Obsession indicates a missing domain language. Introduce data types that encapsulate the details and constraints of your domain. For example, instead of `int userId`, consider `User clicked`.","change-type":"introduced"},{"method":"main","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/mips/tests/spu-revstream/revstream.c","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"c","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":355,"what-changed":"main has a cyclomatic complexity of 19, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"spu_dma_write","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/mips/tests/spu-revstream/revstream.c","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"c","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":315,"what-changed":"spu_dma_write has a cyclomatic complexity of 9, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"spu_dma_read","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/mips/tests/spu-revstream/revstream.c","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"c","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":298,"what-changed":"spu_dma_read has a cyclomatic complexity of 9, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"main","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/mips/tests/spu-revstream/revstream.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":355,"what-changed":"main has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"method":"main","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/mips/tests/spu-endx/spu-endx.c","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"c","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":56,"what-changed":"main has a cyclomatic complexity of 32, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"spu_dma_write","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/mips/tests/spu-endx/spu-endx.c","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"c","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":39,"what-changed":"spu_dma_write has a cyclomatic complexity of 10, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"main","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/mips/tests/spu-endx/spu-endx.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":56,"what-changed":"main has 4 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"method":"run_case","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/mips/tests/spu-envx/spu-envx.c","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"c","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":139,"what-changed":"run_case has a cyclomatic complexity of 22, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"spu_dma_write","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/mips/tests/spu-envx/spu-envx.c","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"c","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":75,"what-changed":"spu_dma_write has a cyclomatic complexity of 10, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"run_case","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/mips/tests/spu-envx/spu-envx.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":139,"what-changed":"run_case has 3 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"method":"spu_tick","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/mips/tests/spu-envx/spu-envx.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":94,"what-changed":"spu_tick has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"why-it-occurs":"Overall Code Complexity is measured by the mean cyclomatic complexity across all functions in the file. The lower the number, the better.\n\nCyclomatic complexity is a function level metric that measures the number of logical branches (if-else, loops, etc.). Cyclomatic complexity is a rough complexity measure, but useful as a way of estimating the minimum number of unit tests you would need. As such, prefer functions with low cyclomatic complexity (2-3 branches).","name":"Overall Code Complexity","file":"src/mips/tests/spu-envx/spu-envx.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"what-changed":"This module has a mean cyclomatic complexity of 6.71 across 7 functions. The mean complexity threshold is 4","how-to-fix":"You address the overall cyclomatic complexity by a) modularizing the code, and b) abstract away the complexity. Let's look at some examples:\n\nModularizing the Code: Do an X-Ray and inspect the local hotspots. Are there any complex conditional expressions? If yes, then do a [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring. Extract the conditional logic into a separate function and put a good name on that function. This clarifies the intent and makes the original function easier to read. Repeat until all complex conditional expressions have been simplified.\n\n","change-type":"introduced"},{"method":"run_case","why-it-occurs":"Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.\n\nThe threshold for the C language is 4 function arguments.","name":"Excess Number of Function Arguments","file":"src/mips/tests/spu-envx/spu-envx.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":139,"what-changed":"run_case has 6 arguments, max arguments = 4","how-to-fix":"Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring [INTRODUCE PARAMETER OBJECT](https://refactoring.com/catalog/introduceParameterObject.html) to encapsulate arguments that refer to the same logical concept.","change-type":"introduced"},{"method":"spu_dma","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/mips/tests/spu-capring/spu-capamp.c","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"c","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":45,"what-changed":"spu_dma has a cyclomatic complexity of 13, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"half_lap","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/mips/tests/spu-capring/spu-capamp.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":65,"what-changed":"half_lap has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"method":"spu_dma","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/mips/tests/spu-capring/spu-capring.c","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"c","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":55,"what-changed":"spu_dma has a cyclomatic complexity of 13, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"half_lap","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/mips/tests/spu-capring/spu-capring.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":75,"what-changed":"half_lap has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"why-it-occurs":"Overall Code Complexity is measured by the mean cyclomatic complexity across all functions in the file. The lower the number, the better.\n\nCyclomatic complexity is a function level metric that measures the number of logical branches (if-else, loops, etc.). Cyclomatic complexity is a rough complexity measure, but useful as a way of estimating the minimum number of unit tests you would need. As such, prefer functions with low cyclomatic complexity (2-3 branches).","name":"Overall Code Complexity","file":"src/mips/tests/spu-capring/spu-capring.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"what-changed":"This module has a mean cyclomatic complexity of 4.22 across 9 functions. The mean complexity threshold is 4","how-to-fix":"You address the overall cyclomatic complexity by a) modularizing the code, and b) abstract away the complexity. Let's look at some examples:\n\nModularizing the Code: Do an X-Ray and inspect the local hotspots. Are there any complex conditional expressions? If yes, then do a [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring. Extract the conditional logic into a separate function and put a good name on that function. This clarifies the intent and makes the original function easier to read. Repeat until all complex conditional expressions have been simplified.\n\n","change-type":"introduced"},{"method":"spu_dma","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/mips/tests/spu-capring/spu-capphase.c","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"c","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":53,"what-changed":"spu_dma has a cyclomatic complexity of 13, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"half_lap","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/mips/tests/spu-capring/spu-capphase.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":73,"what-changed":"half_lap has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"method":"spu_dma","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/mips/tests/spu-capring/spu-capmin.c","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"c","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":53,"what-changed":"spu_dma has a cyclomatic complexity of 13, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"half_lap","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/mips/tests/spu-capring/spu-capmin.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":73,"what-changed":"half_lap has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"method":"spu_dma_write","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/mips/tests/spu-envx/spu-adsrsus.c","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"c","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":59,"what-changed":"spu_dma_write has a cyclomatic complexity of 10, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"flip","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/mips/tests/spu-envx/spu-adsrsus.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":76,"what-changed":"flip has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"method":"capture","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/mips/tests/spu-envx/spu-adsrsus.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":109,"what-changed":"capture has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"why-it-occurs":"Overall Code Complexity is measured by the mean cyclomatic complexity across all functions in the file. The lower the number, the better.\n\nCyclomatic complexity is a function level metric that measures the number of logical branches (if-else, loops, etc.). Cyclomatic complexity is a rough complexity measure, but useful as a way of estimating the minimum number of unit tests you would need. As such, prefer functions with low cyclomatic complexity (2-3 branches).","name":"Overall Code Complexity","file":"src/mips/tests/spu-envx/spu-adsrsus.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"what-changed":"This module has a mean cyclomatic complexity of 4.38 across 8 functions. The mean complexity threshold is 4","how-to-fix":"You address the overall cyclomatic complexity by a) modularizing the code, and b) abstract away the complexity. Let's look at some examples:\n\nModularizing the Code: Do an X-Ray and inspect the local hotspots. Are there any complex conditional expressions? If yes, then do a [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring. Extract the conditional logic into a separate function and put a good name on that function. This clarifies the intent and makes the original function easier to read. Repeat until all complex conditional expressions have been simplified.\n\n","change-type":"introduced"},{"method":"cmp","why-it-occurs":"Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.\n\nThe threshold for the C language is 4 function arguments.","name":"Excess Number of Function Arguments","file":"src/mips/tests/spu-envx/spu-adsrsus.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":156,"what-changed":"cmp has 5 arguments, max arguments = 4","how-to-fix":"Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring [INTRODUCE PARAMETER OBJECT](https://refactoring.com/catalog/introduceParameterObject.html) to encapsulate arguments that refer to the same logical concept.","change-type":"introduced"},{"method":"spu_dma","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/mips/tests/spu-capring/spu-dbuf.c","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"c","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":51,"what-changed":"spu_dma has a cyclomatic complexity of 13, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"capture_irq","why-it-occurs":"A complex conditional is an expression inside a branch such as an <code>if</code>-statmeent which consists of multiple, logical operations. Example: <code>if (x.started() && y.running())</code>.Complex conditionals make the code even harder to read, and contribute to the Complex Method code smell. Encapsulate them.","name":"Complex Conditional","file":"src/mips/tests/spu-capring/spu-dbuf.c","refactoring-examples":[{"diff":"diff --git a/complex_conditional.js b/complex_conditional.js\nindex c43da09584..94259ce874 100644\n--- a/complex_conditional.js\n+++ b/complex_conditional.js\n@@ -1,16 +1,34 @@\n function messageReceived(message, timeReceived) {\n-   // Ignore all messages which aren't from known customers:\n-   if (!message.sender &&\n-       customers.getId(message.name) == null) {\n+   // Refactoring #1: encapsulate the business rule in a\n+   // function. A clear name replaces the need for the comment:\n+   if (!knownCustomer(message)) {\n      log('spam received -- ignoring');\n      return;\n    }\n \n-  // Provide an auto-reply when outside business hours:\n-  if ((timeReceived.getHours() > 17) ||\n-      (timeReceived.getHours() < 8)) {\n+  // Refactoring #2: encapsulate the business rule.\n+  // Again, note how a clear function name replaces the\n+  // need for a code comment:\n+  if (outsideBusinessHours(timeReceived)) {\n     return autoReplyTo(message);\n   }\n \n   pingAgentFor(message);\n+}\n+\n+function outsideBusinessHours(timeReceived) {\n+  // Refactoring #3: replace magic numbers with\n+  // symbols that communicate with the code reader:\n+  const closingHour = 17;\n+  const openingHour = 8;\n+\n+  const hours = timeReceived.getHours();\n+\n+  // Refactoring #4: simple conditional rules can\n+  // be further clarified by introducing a variable:\n+  const afterClosing = hours > closingHour;\n+  const beforeOpening = hours < openingHour;\n+\n+  // Yeah -- look how clear the business rule is now!\n+  return afterClosing || beforeOpening;\n }\n\\ No newline at end of file\n","language":"c","improvement-type":"Complex Conditional"}],"change-level":"warning","is-hotspot?":false,"line":160,"what-changed":"capture_irq has 1 complex conditionals with 2 branches, threshold = 2","how-to-fix":"Apply the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring so that the complex conditional is encapsulated in a separate function with a good name that captures the business rule. Optionally, for simple expressions, introduce a new variable which holds the result of the complex conditional.","change-type":"introduced"},{"method":"flip","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/mips/tests/spu-capring/spu-dbuf.c","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":90,"what-changed":"flip has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"method":"main","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/mips/tests/spu-offvoice/spu-offvoice.c","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"c","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":117,"what-changed":"main has a cyclomatic complexity of 17, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"spu_dma_write","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/mips/tests/spu-offvoice/spu-offvoice.c","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"c","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":75,"what-changed":"spu_dma_write has a cyclomatic complexity of 9, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"}]},"positive-impact-count":27,"repo":"pcsx-redux","code-health":6.93390090093589,"version":"3.0","authors":["Nicolas 'Pixel' Noble","Nicolas \"Pixel\" Noble"],"directives":{"added":[],"removed":[]},"positive-findings":{"number-of-types":7,"number-of-files-touched":8,"findings":[{"method":"PCSX::SPU::impl::MainThread","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C++ language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/spu/spu.cc","change-level":"improvement","is-hotspot?":false,"line":407,"what-changed":"PCSX::SPU::impl::MainThread decreases in cyclomatic complexity from 79 to 23, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"improved"},{"method":"InterpolateUp","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C++ language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/spu/spu.cc","change-level":"improvement","is-hotspot?":false,"line":154,"what-changed":"InterpolateUp is no longer above the threshold for cyclomatic complexity","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"fixed"},{"method":"PCSX::SPU::impl::MainThread","why-it-occurs":"A complex conditional is an expression inside a branch such as an <code>if</code>-statmeent which consists of multiple, logical operations. Example: <code>if (x.started() && y.running())</code>.Complex conditionals make the code even harder to read, and contribute to the Complex Method code smell. Encapsulate them.","name":"Complex Conditional","file":"src/spu/spu.cc","change-level":"improvement","is-hotspot?":false,"line":434,"what-changed":"PCSX::SPU::impl::MainThread decreases from 4 complex conditionals with 10 branches to 2 complex conditionals with 4 branches, threshold = 2","how-to-fix":"Apply the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring so that the complex conditional is encapsulated in a separate function with a good name that captures the business rule. Optionally, for simple expressions, introduce a new variable which holds the result of the complex conditional.","change-type":"improved"},{"method":"PCSX::SPU::impl::MainThread","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/spu/spu.cc","change-level":"improvement","is-hotspot?":false,"line":407,"what-changed":"PCSX::SPU::impl::MainThread decreases from 16 to 4 logical blocks with deeply nested code, threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"improved"},{"method":"InterpolateUp","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/spu/spu.cc","change-level":"improvement","is-hotspot?":false,"line":154,"what-changed":"InterpolateUp is no longer above the threshold for logical blocks with deeply nested code","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"fixed"},{"method":"PCSX::SPU::impl::StoreInterpolationVal","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/spu/spu.cc","change-level":"improvement","is-hotspot?":false,"line":337,"what-changed":"PCSX::SPU::impl::StoreInterpolationVal is no longer above the threshold for logical blocks with deeply nested code","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"fixed"},{"name":"Overall Code Complexity","file":"src/spu/spu.cc","change-type":"improved","change-level":"improvement","is-hotspot?":false,"why-it-occurs":"Overall Code Complexity is measured by the mean cyclomatic complexity across all functions in the file. The lower the number, the better.\n\nCyclomatic complexity is a function level metric that measures the number of logical branches (if-else, loops, etc.). Cyclomatic complexity is a rough complexity measure, but useful as a way of estimating the minimum number of unit tests you would need. As such, prefer functions with low cyclomatic complexity (2-3 branches).","how-to-fix":"You address the overall cyclomatic complexity by a) modularizing the code, and b) abstract away the complexity. Let's look at some examples:\n\nModularizing the Code: Do an X-Ray and inspect the local hotspots. Are there any complex conditional expressions? If yes, then do a [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring. Extract the conditional logic into a separate function and put a good name on that function. This clarifies the intent and makes the original function easier to read. Repeat until all complex conditional expressions have been simplified.\n\n","what-changed":"The mean cyclomatic complexity decreases from 6.21 to 4.16, threshold = 4"},{"method":"PCSX::SPU::impl::MainThread","why-it-occurs":"Deep nested logic means that you have control structures like if-statements or loops inside other control structures. Deep nested logic increases the cognitive load on the programmer reading the code. The human working memory has a maximum capacity of 3-4 items; beyond that threshold, we struggle with keeping things in our head. Consequently, deep nested logic has a strong correlation to defects and accounts for roughly 20% of all programming mistakes.\n\nCodeScene measures the maximum nesting depth inside each function. The deeper the nesting, the lower the code health. The threshold for the C++ language is 6 levels of nesting.","name":"Deep, Nested Complexity","file":"src/spu/spu.cc","change-level":"improvement","is-hotspot?":false,"line":407,"what-changed":"PCSX::SPU::impl::MainThread decreases in nested complexity depth from 8 to 6, threshold = 4","how-to-fix":"Occassionally, it's possible to get rid of the nested logic by [Replacing Conditionals with Guard Clauses](https://refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html).\n\nAnother viable strategy is to identify smaller building blocks inside the nested chunks of logic and extract those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring explains the steps.","change-type":"improved"},{"name":"Code Duplication","file":"src/spu/adsr.cc","change-type":"improved","change-level":"improvement","is-hotspot?":false,"why-it-occurs":"Duplicated code often leads to code that's harder to change since the same logical change has to be done in multiple functions. More duplication gives lower code health.","how-to-fix":"A certain degree of duplicated code might be acceptable. The problems start when it is the same behavior that is duplicated across the functions in the module, ie. a violation of the Don't Repeat Yourself (DRY) principle. DRY violations lead to code that is changed together in predictable patterns, which is both expensive and risky. DRY violations can be identified using CodeScene's X-Ray analysis to detect clusters of change coupled functions with high code similarity. [Read More](https://codescene.com/blog/software-revolution-part3/)\n\nOnce you have identified the similarities across functions, look to extract and encapsulate the concept that varies into its own function(s). These shared abstractions can then be re-used, which minimizes the amount of duplication and simplifies change.","what-changed":"reduced similar code in: PCSX::SPU::ADSR::Decay,PCSX::SPU::ADSR::Release"},{"method":"PCSX::SPU::ADSR::Sustain","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C++ language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/spu/adsr.cc","change-level":"improvement","is-hotspot?":false,"line":131,"what-changed":"PCSX::SPU::ADSR::Sustain is no longer above the threshold for cyclomatic complexity","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"fixed"},{"method":"PCSX::SPU::ADSR::Sustain","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/spu/adsr.cc","change-level":"improvement","is-hotspot?":false,"line":131,"what-changed":"PCSX::SPU::ADSR::Sustain is no longer above the threshold for logical blocks with deeply nested code","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"fixed"},{"name":"Code Duplication","file":"src/spu/debug.cc","change-type":"improved","change-level":"improvement","is-hotspot?":false,"why-it-occurs":"Duplicated code often leads to code that's harder to change since the same logical change has to be done in multiple functions. More duplication gives lower code health.","how-to-fix":"A certain degree of duplicated code might be acceptable. The problems start when it is the same behavior that is duplicated across the functions in the module, ie. a violation of the Don't Repeat Yourself (DRY) principle. DRY violations lead to code that is changed together in predictable patterns, which is both expensive and risky. DRY violations can be identified using CodeScene's X-Ray analysis to detect clusters of change coupled functions with high code similarity. [Read More](https://codescene.com/blog/software-revolution-part3/)\n\nOnce you have identified the similarities across functions, look to extract and encapsulate the concept that varies into its own function(s). These shared abstractions can then be re-used, which minimizes the amount of duplication and simplifies change.","what-changed":"reduced similar code in: DrawTableAdsr,DrawTableReverb"},{"method":"PCSX::SPU::impl::load","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C++ language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/spu/freeze.cc","change-level":"improvement","is-hotspot?":false,"line":93,"what-changed":"PCSX::SPU::impl::load is no longer above the threshold for cyclomatic complexity","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"fixed"},{"name":"Code Duplication","file":"src/spu/registers.cc","change-type":"improved","change-level":"improvement","is-hotspot?":false,"why-it-occurs":"Duplicated code often leads to code that's harder to change since the same logical change has to be done in multiple functions. More duplication gives lower code health.","how-to-fix":"A certain degree of duplicated code might be acceptable. The problems start when it is the same behavior that is duplicated across the functions in the module, ie. a violation of the Don't Repeat Yourself (DRY) principle. DRY violations lead to code that is changed together in predictable patterns, which is both expensive and risky. DRY violations can be identified using CodeScene's X-Ray analysis to detect clusters of change coupled functions with high code similarity. [Read More](https://codescene.com/blog/software-revolution-part3/)\n\nOnce you have identified the similarities across functions, look to extract and encapsulate the concept that varies into its own function(s). These shared abstractions can then be re-used, which minimizes the amount of duplication and simplifies change.","what-changed":"reduced similar code in: PCSX::SPU::impl::SetVolumeL,PCSX::SPU::impl::SetVolumeR"},{"method":"PCSX::SPU::impl::readRegister","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C++ language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/spu/registers.cc","change-level":"improvement","is-hotspot?":false,"line":470,"what-changed":"PCSX::SPU::impl::readRegister decreases in cyclomatic complexity from 15 to 14, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"improved"},{"method":"PCSX::SPU::impl::SetVolumeL","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/spu/registers.cc","change-level":"improvement","is-hotspot?":false,"line":642,"what-changed":"PCSX::SPU::impl::SetVolumeL is no longer above the threshold for logical blocks with deeply nested code","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"fixed"},{"method":"PCSX::SPU::impl::SetVolumeR","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/spu/registers.cc","change-level":"improvement","is-hotspot?":false,"line":677,"what-changed":"PCSX::SPU::impl::SetVolumeR is no longer above the threshold for logical blocks with deeply nested code","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"fixed"},{"name":"Code Duplication","file":"src/spu/reverb.cc","change-type":"fixed","change-level":"improvement","is-hotspot?":false,"why-it-occurs":"Duplicated code often leads to code that's harder to change since the same logical change has to be done in multiple functions. More duplication gives lower code health.","how-to-fix":"A certain degree of duplicated code might be acceptable. The problems start when it is the same behavior that is duplicated across the functions in the module, ie. a violation of the Don't Repeat Yourself (DRY) principle. DRY violations lead to code that is changed together in predictable patterns, which is both expensive and risky. DRY violations can be identified using CodeScene's X-Ray analysis to detect clusters of change coupled functions with high code similarity. [Read More](https://codescene.com/blog/software-revolution-part3/)\n\nOnce you have identified the similarities across functions, look to extract and encapsulate the concept that varies into its own function(s). These shared abstractions can then be re-used, which minimizes the amount of duplication and simplifies change.","what-changed":"The module no longer contains too many functions with similar structure"},{"method":"PCSX::SPU::impl::SetREVERB","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C++ language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/spu/reverb.cc","change-level":"improvement","is-hotspot?":false,"line":43,"what-changed":"PCSX::SPU::impl::SetREVERB is no longer above the threshold for cyclomatic complexity","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"fixed"},{"method":"PCSX::SPU::impl::MixREVERBLeft","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C++ language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/spu/reverb.cc","change-level":"improvement","is-hotspot?":false,"line":208,"what-changed":"PCSX::SPU::impl::MixREVERBLeft is no longer above the threshold for cyclomatic complexity","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"fixed"},{"method":"PCSX::SPU::impl::MixREVERBLeft","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"src/spu/reverb.cc","change-level":"improvement","is-hotspot?":false,"line":208,"what-changed":"PCSX::SPU::impl::MixREVERBLeft is no longer above the threshold for logical blocks with deeply nested code","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"fixed"},{"name":"Overall Code Complexity","file":"src/spu/reverb.cc","change-type":"fixed","change-level":"improvement","is-hotspot?":false,"why-it-occurs":"Overall Code Complexity is measured by the mean cyclomatic complexity across all functions in the file. The lower the number, the better.\n\nCyclomatic complexity is a function level metric that measures the number of logical branches (if-else, loops, etc.). Cyclomatic complexity is a rough complexity measure, but useful as a way of estimating the minimum number of unit tests you would need. As such, prefer functions with low cyclomatic complexity (2-3 branches).","how-to-fix":"You address the overall cyclomatic complexity by a) modularizing the code, and b) abstract away the complexity. Let's look at some examples:\n\nModularizing the Code: Do an X-Ray and inspect the local hotspots. Are there any complex conditional expressions? If yes, then do a [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring. Extract the conditional logic into a separate function and put a good name on that function. This clarifies the intent and makes the original function easier to read. Repeat until all complex conditional expressions have been simplified.\n\n","what-changed":"The mean cyclomatic complexity in this module is no longer above the threshold"},{"method":"PCSX::SPU::impl::MixREVERBLeft","why-it-occurs":"Deep nested logic means that you have control structures like if-statements or loops inside other control structures. Deep nested logic increases the cognitive load on the programmer reading the code. The human working memory has a maximum capacity of 3-4 items; beyond that threshold, we struggle with keeping things in our head. Consequently, deep nested logic has a strong correlation to defects and accounts for roughly 20% of all programming mistakes.\n\nCodeScene measures the maximum nesting depth inside each function. The deeper the nesting, the lower the code health. The threshold for the C++ language is  levels of nesting.","name":"Deep, Nested Complexity","file":"src/spu/reverb.cc","change-level":"improvement","is-hotspot?":false,"line":208,"what-changed":"PCSX::SPU::impl::MixREVERBLeft is no longer above the threshold for nested complexity depth","how-to-fix":"Occassionally, it's possible to get rid of the nested logic by [Replacing Conditionals with Guard Clauses](https://refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html).\n\nAnother viable strategy is to identify smaller building blocks inside the nested chunks of logic and extract those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring explains the steps.","change-type":"fixed"},{"method":"PCSX::Counters::update","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C++ language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/core/psxcounters.cc","change-level":"improvement","is-hotspot?":false,"line":158,"what-changed":"PCSX::Counters::update decreases in cyclomatic complexity from 21 to 20, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"improved"},{"name":"Overall Code Complexity","file":"src/core/psxcounters.cc","change-type":"improved","change-level":"improvement","is-hotspot?":false,"why-it-occurs":"Overall Code Complexity is measured by the mean cyclomatic complexity across all functions in the file. The lower the number, the better.\n\nCyclomatic complexity is a function level metric that measures the number of logical branches (if-else, loops, etc.). Cyclomatic complexity is a rough complexity measure, but useful as a way of estimating the minimum number of unit tests you would need. As such, prefer functions with low cyclomatic complexity (2-3 branches).","how-to-fix":"You address the overall cyclomatic complexity by a) modularizing the code, and b) abstract away the complexity. Let's look at some examples:\n\nModularizing the Code: Do an X-Ray and inspect the local hotspots. Are there any complex conditional expressions? If yes, then do a [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring. Extract the conditional logic into a separate function and put a good name on that function. This clarifies the intent and makes the original function easier to read. Repeat until all complex conditional expressions have been simplified.\n\n","what-changed":"The mean cyclomatic complexity decreases from 4.80 to 4.73, threshold = 4"},{"name":"Lines of Code in a Single File","file":"src/gui/gui.cc","change-type":"improved","change-level":"improvement","is-hotspot?":true,"why-it-occurs":"This module has 2602 lines of code (comments stripped away). This puts the module at risk of evolving into a Brain Class. Brain Classes are problematic since changes become more complex over time, harder to test, and challenging to refactor. Act now to prevent future maintenance issues.","how-to-fix":"Look for opportunities to modularize the design. This is done by identifying groups of functions that represent different responsibilities and/or operate on different data. Once you have identified the different responsibilities, then use refactorings like [EXTRACT CLASS](https://refactoring.com/catalog/extractClass.html).","what-changed":"The lines of code decreases from 2606 to 2602, improve code health by reducing it to 1000"},{"method":"PCSX::GUI::configure","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C++ language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"src/gui/gui.cc","change-level":"improvement","is-hotspot?":true,"line":2271,"what-changed":"PCSX::GUI::configure decreases in cyclomatic complexity from 49 to 48, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"improved"}]},"notices":{"number-of-types":0,"number-of-files-touched":0,"findings":[]},"external-review-provider":"GitHub"},"analysistime":"2026-09-06T02:09:02.000Z","project-name":"pcsx-redux","repository":"https://github.com/grumpycoders/pcsx-redux.git"}}