{"results":{"result":{"added-files":{"code-health":9.847167502649933,"old-code-health":0.0,"files":[{"file":"planning/autoware_trajectory_concatenator/src/detail/trajectory_concatenator.cpp","loc":68,"code-health":10.0},{"file":"planning/autoware_trajectory_validator/src/trajectory_validator_wrapper.cpp","loc":239,"code-health":9.536386775820924},{"file":"planning/autoware_trajectory_concatenator/test/test_trajectory_concatenator.cpp","loc":198,"code-health":10.0},{"file":"planning/autoware_trajectory_concatenator/test/test_trajectory_concatenator_wrapper.cpp","loc":124,"code-health":10.0},{"file":"planning/autoware_trajectory_selector/src/trajectory_selector_node.cpp","loc":96,"code-health":10.0}]},"external-review-url":"https://github.com/autowarefoundation/autoware_universe/pull/12532","old-code-health":9.6675543980958,"modified-files":{"code-health":9.34416264214521,"old-code-health":9.6675543980958,"files":[{"file":"planning/autoware_trajectory_validator/src/detail/trajectory_validator.cpp","loc":77,"old-loc":77,"code-health":8.95517096544394,"old-code-health":8.95517096544394},{"file":"planning/autoware_trajectory_selector/test/dummy_plugin/dummy_validator_plugin.cpp","loc":33,"old-loc":33,"code-health":10.0,"old-code-health":10.0},{"file":"planning/autoware_trajectory_selector/test/node/test_trajectory_selector_node.cpp","loc":193,"old-loc":132,"code-health":9.387218218812514,"old-code-health":10.0}]},"removed-files":{"code-health":0.0,"old-code-health":0.0,"files":[]},"external-review-id":"12532","analysis-time":"2026-06-05T01:40:22Z","negative-impact-count":3,"suppressions":{"number-of-types":0,"number-of-files-touched":0,"findings":[]},"affected-hotspots":0,"commits":["eefd12c56cf80570f74561d6b762491d05439b48","d88524b80700da7580dbc5716fec6453e0058412","55dcd1f70a71f70aaa0b5bfe8538d45b209ebc4a","f7b26fd4595c8406c9066f29c7968cf8d6352349","9ae6914dc5f3dd3c0059376503077efbd7b13da5","f0eca28858b77e986c269dbe3955f1d8217993f1","2579804ac413344824803b9ab197ddcfcbc6b394","be70db539df6514032b3465872890ef77bfe31cc","fbebe4d11ee134f6c3ff16cfdd8e9857a1b775e4","543db0a3ab8bb84a7c9b6c8316c8ef5188899003","6a6ed25c6db7ba845ae09a65d48e63901e8ecd11","4c62e5f433d3249699d0fe0f974e1e3513f5a953","0db7a23740c6cc28263c25837e37fe4fd8a7e8b2","8316c23bf95426b0ed0e6411412c50ca51184c27","9906bbb9b0e5096bdb5e82e643e552edb4cc6310","e6a39e4f4fe69605b861fede1e86ee1f632a8518","135b5417b375065fdc6af3ce76236349a997a4cd","03a1770246fb24eec49c3ba6022c0d38b5c58f19","f14c68f278bdb52407f6dd087564c8c579fe532f","b72339baa6a7fc8a1a98de52d26da5b4b8d63cbe","3e1338730422039f473043feca5bbed7b03faf21","f1aa45502cfaff6d47930769a30478181fb172d8","5d2403d4d0177b19ccbc836db91d83061124951a","ffd182e913119aabe6a39229f4131d175b303162","70a4b913a0b3751832e91b0cb7c7e7de258ec83f"],"is-negative-review":true,"negative-findings":{"number-of-types":3,"number-of-files-touched":2,"findings":[{"method":"TrajectoryValidatorWrapper::publish_plugins_report_text","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":"planning/autoware_trajectory_validator/src/trajectory_validator_wrapper.cpp","refactoring-examples":[{"architectural-component-id":null,"author-name":"Taekjin LEE","training-data":{"loc-added":"11","loc-deleted":"14","delta-cc-mean":"0.0","delta-cc-total":"0","delta-penalties":"1.0","delta-n-functions":"0","current-file-score":"10.0"},"author-email":"taekjin.lee@tier4.jp","commit-full-message":"* feat(tracker_processor): set existence probability for tracked objects\n\nSigned-off-by: Taekjin LEE \n\n* refactor(tracker): rename classification parameter for clarity in updateClassification method\n\nSigned-off-by: Taekjin LEE \n\n* fix(association): ensure minimum covariance values to prevent large Mahalanobis distance\n\nSigned-off-by: Taekjin LEE \n\n* feat(tracker): disable trust in existence probability for input channels\n\nSigned-off-by: Taekjin LEE \n\n* fix(tracker): update decay rate for existence probability to reflect a 0.5s half-life\n\nSigned-off-by: Taekjin LEE \n\n* style(pre-commit): autofix\n\nSigned-off-by: Taekjin LEE \n\n* fix(association): correct spelling of \"mahalanobis\" in comment for clarity\n\nSigned-off-by: Taekjin LEE \n\n---------\n\nSigned-off-by: Taekjin LEE \nCo-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>","commit-date":"2025-08-04T07:38:26Z","current-rev":"47a0fb82f4","filename":"autoware_universe/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp","previous-rev":"70be106253","commit-title":"fix(autoware_multi_object_tracker): existence probability adjustment to mitigate tracker lost (#11109)","language":"C++","id":"410ebd13723902158abcb4c2d1698bc1c3c4c442","model-score":0.54,"author-id":null,"project-id":29372,"delta-file-score":0.31179166,"diff":"diff --git a/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp b/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp\nindex 094c9537a9..7c34b30b36 100644\n--- a/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp\n+++ b/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp\n@@ -46,3 +46,3 @@ float decayProbability(const float & prior, const float & delta_time)\n constexpr float minimum_probability = 0.001;\n- const float decay_rate = log(0.5f) / 0.3f; // half-life (50% decay) of 0.3s\n+ const float decay_rate = log(0.5f) / 0.5f; // half-life (50% decay) of 0.5s\n return std::max(prior * std::exp(decay_rate * delta_time), minimum_probability);\n@@ -135,7 +135,4 @@ bool Tracker::updateWithMeasurement(\n // update total existence probability\n- const double existence_probability = channel_info.trust_existence_probability\n- ? object.existence_probability\n- : types::default_existence_probability;\n total_existence_probability_ = updateProbability(\n- total_existence_probability_, existence_probability * probability_true_detection,\n+ total_existence_probability_, object.existence_probability * probability_true_detection,\n probability_false_detection);\n@@ -195,3 +192,3 @@ bool Tracker::updateWithoutMeasurement(const rclcpp::Time & timestamp)\n void Tracker::updateClassification(\n- const std::vector & classification)\n+ const std::vector & input)\n {\n@@ -223,6 +220,6 @@ void Tracker::updateClassification(\n // Normalize the input\n- auto classification_input = classification;\n+ auto classification_input = input;\n normalizeProbabilities(classification_input);\n \n- auto & classification_ = object_.classification;\n+ auto & classification = object_.classification;\n \n@@ -231,3 +228,3 @@ void Tracker::updateClassification(\n bool found = false;\n- for (auto & old_class : classification_) {\n+ for (auto & old_class : classification) {\n if (new_class.label == old_class.label) {\n@@ -242,3 +239,3 @@ void Tracker::updateClassification(\n adding_class.probability *= gain;\n- classification_.push_back(adding_class);\n+ classification.push_back(adding_class);\n }\n@@ -247,10 +244,10 @@ void Tracker::updateClassification(\n // If the probability is less than the threshold, remove the class\n- classification_.erase(\n+ classification.erase(\n std::remove_if(\n- classification_.begin(), classification_.end(),\n+ classification.begin(), classification.end(),\n [remove_threshold](const auto & a_class) { return a_class.probability < remove_threshold; }),\n- classification_.end());\n+ classification.end());\n \n // Normalize tracking classification\n- normalizeProbabilities(classification_);\n+ normalizeProbabilities(classification);\n }\n","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":218,"what-changed":"TrajectoryValidatorWrapper::publish_plugins_report_text 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":"TrajectoryValidatorWrapper::publish_plugins_report_text","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":"planning/autoware_trajectory_validator/src/trajectory_validator_wrapper.cpp","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":218,"what-changed":"TrajectoryValidatorWrapper::publish_plugins_report_text 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":"planning/autoware_trajectory_selector/test/node/test_trajectory_selector_node.cpp","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":191,"what-changed":"The module contains 3 functions with similar structure: TEST:TrajectorySelectorNodeTest:NoPublishWhenAccelerationMissing,TEST:TrajectorySelectorNodeTest:NoPublishWhenObjectsMissing,TEST:TrajectorySelectorNodeTest:NoPublishWhenOdometryMissing","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":3,"repo":"autoware_universe","code-health":9.698908287929182,"version":"3.0","authors":["Zulfaqar Azmi","pre-commit-ci-lite[bot]"],"directives":{"added":[],"removed":[]},"positive-findings":{"number-of-types":3,"number-of-files-touched":1,"findings":[{"method":"ValidationStage::process","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":"planning/autoware_trajectory_validator/src/detail/trajectory_validator.cpp","change-level":"improvement","is-hotspot?":false,"line":29,"what-changed":"ValidationStage::process 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":"ValidationStage::process","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":"planning/autoware_trajectory_validator/src/detail/trajectory_validator.cpp","change-level":"improvement","is-hotspot?":false,"line":29,"what-changed":"ValidationStage::process 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":"ValidationStage::process","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":"planning/autoware_trajectory_validator/src/detail/trajectory_validator.cpp","change-level":"improvement","is-hotspot?":false,"line":29,"what-changed":"ValidationStage::process 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"}]},"notices":{"number-of-types":0,"number-of-files-touched":0,"findings":[]},"external-review-provider":"GitHub"},"analysistime":"2026-06-05T01:40:21.000Z","project-name":"autoware.universe","repository":"https://github.com/autowarefoundation/autoware_universe.git"}}