Skip to content

DevNotes_DevGuide_CodeSceneIntegration

Jump to bottom Edit New page
Jeff Krzywon edited this page Feb 6, 2026 · 4 revisions

[WIP] Code Scene Pull Request Integration

CodeScene is a code analysis tool that helps to identify technical debt in software projects, gives insights in how to improve the technical debt, and offers planning and integration tools to minimize technical debt in existing and future work.

CodeScene has two primary modes of operation; the first is to run weekly scans on a repository, and the second is to analyze pull requests to analyze new code. Currently, the weekly scans are run for sasview, sasdata, and sasmodels, with pull request integration to come in a phased manner

The weekly scan gives each project file a score out of ten based on the existing technical debt in the file. The summary page shows the average code health score, the average score for files with the highest development activity (Hotspots), and the worst performer. The summary also lists files recently improved and those that declined in health.

Pull request integration is an automated tool that analyzes new code submitted through pull requests. If the analysis finds a critical health issue, which are outlined below, the bot will give comments on each failing issue, and submit a review with changes requested.

Scoring System

Code Health is an aggregated metric based on 25+ factors scanned from the source code. The code health factors correlate with increased maintenance costs and an increased risk for defects. Code Health is a model that correlates measurable aspects of your code with positive or negative outcomes for your project.

The scoring system is from 0.0 to 10.0, with 10.0 being the highest possible score. The coding rules, listed below, are used as criteria for determining the score, but the algorithm is not published. To achieve a 10.0, all code must meet the default code rules and thresholds, as defined by CodeScene. For pull requests in sasview repositories that use the tool, CodeScene will only accept a pull request if all of the rules and thresholds set in our configuration files are met.

https://codescene.com/product/code-health

Pull Request Integration Scheme

Pull request integration will be implemented in a staged process. Currently, sasdata is the only repository with any integration, setup using a configuration file in the repo, but every check is turned off to start.

Integration plan:

  • Write an ADR on CodeScene usage and code health (In progress - https://github.com/orgs/SasView/discussions/3171#discussioncomment-14214525)
  • Write a wiki outlining the errors associated with CodeScene and how to fix them (in progress - this wiki!)
  • Add a codescene configuration file to every repo, with every check turned off (In progress - done for sasdata, todo for sasview and sasmodels)
  • Enable the Minimal Safety Net for the sasdata repo
  • Enable the Minimal Safety Net for all repos, and add the Quality Guardians checks to sasdata
  • Enable the Quality Guardians checks to all repos and add the Elevate Code Health checks to sasdata
  • Enable the Elevate Code Health checks to all repos
  • Use project planning tools in CodeScene to improve code health in hot spots for all repos

Pull Request Blockers and How to Fix Them

Definitions:

  • Module: Either an importable python module, or a class for the purpose of this wiki section.
  • Function: Either a top-level, stand-alone function, or a class-level method.
  • Variable: Any variable within a module or function as defined here.
  • Element: A variable or function as defined here.

Coding Rules:

  • Brain Class (God Class)
    • Indicates: A class has a large set of related logic, but has grown large and some of that logic can likely be separated into multiple modules.
    • Why This Should Be Fixed: Large classes can be difficult to modify, extend, and debug.
    • How to Fix: Create smaller logical sub-classes and refer to those class from the original God Class.
    • Example Fix: https://github.com/SasView/sasview/pull/3776 - The FittingWidget class once housed all fitting-related logic, making it difficult to change due to its enormity. The staged refactoring separated the God Class into a series of logical sub-widgets.
  • Brain Method (God Method)
    • Indicates: A single, large method or function that does a large number of tasks.
    • Why This Should Be Fixed: Large modules can be difficult to modify and debug.
    • How to Fix: Separate logical parts of the larger method in many, smaller methods.
    • Example Fix:
  • Bumpy Road Ahead
    • Indicates: A function has deeply nested conditional statements within it.
    • Why This Should Be Fixed:
    • How to Fix:
    • Example Fix:
  • Code Duplication
    • Indicates: Similar logic is duplicated in multiple places, and when one area is modified, the other also requires changes.
    • Why This Should Be Fixed:
    • How to Fix:
    • Example Fix:
  • Complex Conditional
    • Indicates: An expression has multiple, branched logical operations within it.
    • Why This Should Be Fixed:
    • How to Fix:
    • Example Fix:
  • Complex Method
    • Indicates:
    • Why This Should Be Fixed:
    • How to Fix:
    • Example Fix:
  • Constructor Over-Injection
    • Indicates:
    • Why This Should Be Fixed:
    • How to Fix:
    • Example Fix:
  • Cyclomatic Complexity
    • Indicates: A high number of conditional statements in a function.
    • Why This Should Be Fixed:
    • How to Fix:
    • Example:
  • Deep, Global Nested Complexity
    • Indicates:
    • Why This Should Be Fixed:
    • How to Fix:
    • Example Fix:
  • Deep, Nested Complexity
    • Indicates: Conditional statements within conditional statements, within conditional statements...
    • Why This Should Be Fixed:
    • How to Fix:
    • Example Fix:
  • Duplicated Assertion Blocks
    • Indicates: Multiple functions have the same assert statements.
    • Why This Should Be Fixed:
    • How to Fix:
    • Example Fix:
  • Excess Number of Function Arguments
    • Indicates:
    • Why This Should Be Fixed:
    • How to Fix:
    • Example Fix:
  • Global Conditionals
    • Indicates:
    • Why This Should Be Fixed:
    • How to Fix:
    • Example Fix:
  • Large Assertion Blocks
    • Indicates: A function has consecutive assert statements.
    • Why This Should Be Fixed:
    • How to Fix:
    • Example Fix:
  • Large Embedded Code Block
    • Indicates:
    • Why This Should Be Fixed:
    • How to Fix:
    • Example Fix:
  • Large Method
    • Indicates: Modules with a large number of lines of code.
    • Why This Should Be Fixed:
    • How to Fix:
    • Example Fix:
  • Lines of Code in a Single File
    • Indicates:
    • Why This Should Be Fixed:
    • How to Fix:
    • Example Fix:
  • Lines of Declarations in a Single File
    • Indicates:
    • Why This Should Be Fixed:
    • How to Fix:
    • Example Fix:
  • Low Cohesion
    • Indicates: A module has multiple unrelated tasks.
    • Why This Should Be Fixed: If elements in a module are unrelated, finding the logical element and debugging them will be more difficult for developers.
    • How to Fix: Move the unrelated element(s) to its/their own module, or to an existing module that makes more sense.
    • Example Fix: https://github.com/SasView/sasview/pull/3535 - Moved many user-specific file handling methods into the user.py module to better enable developers in finding these methods.
  • Missing Arguments Abstractions
    • Indicates:
    • Why This Should Be Fixed:
    • How to Fix:
    • Example Fix:
  • Number of Functions in a Single Module
    • Indicates: A module has a large number of functions in it.
    • Why This Should Be Fixed: The larger logic base a module has, the more likely you will be able to separate the module into smaller, more focused modules. Doing this makes the code more human readable and maintainable.
    • How to Fix:
    • Example Fix:
  • Overall Code Complexity
    • Indicates:
    • Why This Should Be Fixed:
    • How to Fix:
    • Example Fix:
  • Overall Function Size
    • Indicates: A function with more lines of code than is set in the configuration setting function_lines_of_code_alert.
    • Why This Should Be Fixed: Large functions can almost always be separated into smaller, logical bits. By separating, the code becomes more human readable, thus, more maintainable.
    • How to Fix:
    • Example Fix:
  • Primitive Obsession
    • Indicates: Basic types (e.g. str, float, int, etc.) are used to represent complex concepts (e.g. EmailAddress, Money, ZipCode, etc.)
    • Why This Should Be Fixed:
    • How to Fix:
    • Example Fix:
  • String Heavy Function Arguments
    • Indicates: A function is passed a large number of strings as a part of the function call.
    • Why This Should Be Fixed: Strings are often used in lieu of other objects that should be used instead.
    • How to Fix:
    • Example Fix:

Thresholds:

The following thresholds are set in the .codescene/code-health-rules.json file.

  • constructor_max_arguments - 7
  • file_lines_of_code_for_alert - 5000
  • file_lines_of_code_for_critical_alert - 2500
  • file_lines_of_code_for_warning - 1000
  • file_mean_cyclomatic_complexity_warning - 8
  • function_bumpy_road_bumps_for_warning - 8
  • function_bumpy_road_nesting_level_depth - 25
  • function_complex_conditional_branches_alert - 25
  • function_complex_conditional_branches_warning - 10
  • function_cyclomatic_complexity_alert - 25
  • function_cyclomatic_complexity_warning - 5
  • function_lines_of_code_alert - 2500
  • function_lines_of_code_warning - 100
  • function_max_arguments - 7
  • function_nesting_depth_warning - 10
Add a custom footer

HOME

The Developers' Corner

(Potential) Contributors Resources

Helping others to use SasView

Code & Contributor Camps

Clone this wiki locally