if-statmeent which consists of multiple, logical operations. Example: if (x.started() && y.running()).Complex conditionals make the code even harder to read, and contribute to the Complex Method code smell. Encapsulate them.","name":"Complex Conditional","file":"src/modules/services/components/FilePicker/constraints.js","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":"javascript","improvement-type":"Complex Conditional"}],"change-level":"warning","is-hotspot?":false,"line":61,"what-changed":"getActionDisabledState 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":"getActionDisabledState","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/modules/services/components/FilePicker/constraints.js","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":41,"what-changed":"getActionDisabledState 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":"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.","name":"Code Duplication","file":"src/modules/services/components/FilePicker/constraints.spec.jsx","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":83,"what-changed":"The module contains 2 functions with similar structure: 'should disable when allowedMimeTypes is set and the file mime does not match','should disable when the file is larger than maxFileSize'","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.","change-type":"introduced"},{"method":"matchMimeType","why-it-occurs":"A complex conditional is an expression inside a branch such as an if-statmeent which consists of multiple, logical operations. Example: if (x.started() && y.running()).Complex conditionals make the code even harder to read, and contribute to the Complex Method code smell. Encapsulate them.","name":"Complex Conditional","file":"src/modules/services/components/FilePicker/helpers.js","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":"javascript","improvement-type":"Complex Conditional"}],"change-level":"warning","is-hotspot?":false,"line":35,"what-changed":"matchMimeType 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"},{"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.","name":"Code Duplication","file":"src/modules/services/components/Picker.spec.jsx","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":239,"what-changed":"The module contains 3 functions with similar structure: 'should return a DOWNLOAD_LINK_FAILED error code when temporary link generation fails','should return a SHARING_LINK_FAILED error code when public link generation fails','should return an ITEM_NOT_FOUND error code when metadata loading fails'","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.","change-type":"introduced"},{"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.","name":"Code Duplication","file":"e2e/tests/file-picker.spec.ts","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":183,"what-changed":"The module contains 2 functions with similar structure: 'File Picker'.'download-only config hides public link and returns a download link','File Picker'.'sharing-only config hides download link and returns a sharing link'","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.","change-type":"introduced"}]},"positive-impact-count":0,"repo":"twake-drive","code-health":9.76267112908335,"version":"3.0","authors":["doubleface"],"directives":{"added":[],"removed":[]},"positive-findings":{"number-of-types":0,"number-of-files-touched":0,"findings":[]},"notices":{"number-of-types":0,"number-of-files-touched":0,"findings":[]},"external-review-provider":"GitHub"},"analysistime":"2026-07-03T14:31:01.000Z","project-name":"twake-drive","repository":"https://github.com/linagora/twake-drive.git"}}