Sample
int-ae1c115f107d-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.545 | 0–1; higher is more readable |
| Dorn | 0.093 | 0–1; higher is more readable |
| Mi | 0.119 | 0–1; higher is more readable |
| LLOC | 50 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 15.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.312 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 8343.63 | −275.34 |
| Source linesThe number of non-empty source lines. | 162 | +64.8 |
| Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value. | 4.73 | −7.095 |
Intercept 8.87 + feature contributions = -208.765 (log-odds).
Score = sigmoid(-208.765) = 0.
| Score | 0.545 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 163 | −4.735 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 139 | +4.071 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 139 | −2.769 |
| Identifier layout (horizontal)How rapidly the visual pattern of identifier characters changes from left to right. It measures spatial frequency, not the meaning of the names. | 146.988 | −2.561 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 161.98 | +1.854 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 146.086 | +1.553 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.072 | +0.244 |
Intercept 0.07 + feature contributions = -2.273 (log-odds).
Score = sigmoid(-2.273) = 0.093.
| Score | 0.119 |
|---|
| Score | 50 |
|---|
Run 1
The code is generally well-structured and readable. It has clear separation of concerns with methods like `processExtraArgs` and `parseConnectorConfigurationFile` doing specific tasks. The nesting is mostly flat with clear exception handling. Intent is clear through good method naming and comprehensive Javadoc comments. Code length is reasonable though the `parseConnectorConfigurationFile` method could be slightly shorter. Action granularity is well-maintained with one operation per line. Reading flow is natural and follows logical progression. Points deducted for slightly complex catch blocks with multiple exception types and the moderately long parsing method that could benefit from extraction into smaller helper methods. The callback usage in `processExtraArgs` is clear but slightly verbose.
Run 2
The code is generally well-structured with clear separation of concerns — the class hierarchy, Javadocs, and method responsibilities are understandable. The parsing logic is segmented into separate try/catch blocks, which aids in maintaining flat nesting. However, there are several readability issues: the long method `parseConnectorConfigurationFile` performs multiple fallback parsing attempts with duplicated validation logic (e.g., checking for `NAME_CONFIG`), which obscures the overall flow. The inline lambda for the `FutureCallback` contains multi-statement logic on one line, violating the 'one action per line' principle. Some error messages are overly verbose and wrapped inconsistently. The imports are extensive but standard for this codebase. The method signature wrapping in `createHerder` is awkward. Overall, the intent is mostly clear, but the parsing method's length and duplicated blocks, along with the compacted callback logic, reduce readability.
Run 3
The code is well-structured with clear separation of concerns, following a logical flow from CLI argument processing to connector configuration parsing. The nesting is minimal and flat, with only one level of indentation in the main loop. Each method has a clear purpose, and the Javadoc for parseConnectorConfigurationFile is excellent, explaining the file format fallback strategy. Action granularity is mostly good — one logical operation per line. The parseConnectorConfigurationFile method is somewhat long but uses early returns and clear try-catch blocks to handle different formats, making the flow readable. Minor readability issues: the FutureCallback lambda could be extracted for clarity, long parameter lists in method signatures, and some lines exceed typical length preferences. The reading flow is natural, moving from high-level processExtraArgs to lower-level details. Error handling is consistent and informative.
Run 1
Code Structure: Responsibilities are logically separated into argument processing, configuration parsing, and runtime construction. Nesting: Generally shallow, though the callback and nested connector-name validation add some complexity. Clarity of intent: Descriptive names, useful documentation, and explicit logging make the purpose clear; the abbreviated variable 'cb' is less expressive. Code length: Mostly concise, but repeated mandatory-name validation and a relatively long parsing method introduce duplication. Action granularity: Statements generally perform one action per line; chained calls and nested construction expressions slightly increase cognitive load. Reading flow: Startup and sequential parsing fallbacks are easy to follow, aided by documentation describing their order. Exception-driven format detection, tightly packed imports, and inconsistent continuation indentation modestly reduce readability.
Run 2
Code Structure: Well-organized methods separate CLI behavior, configuration parsing, and runtime construction; parsing includes some duplicated validation. Nesting: Generally shallow, though the loop with a callback and nested name-validation condition add moderate complexity. Clarity of intent: Descriptive names and detailed documentation clearly explain standalone operation and parsing precedence; the abbreviated callback variable 'cb' is less informative. Code length: Mostly appropriate, but repeated missing-name checks and lengthy exception messages could be consolidated. Action granularity: Statements generally perform one action per line, with a few nested calls and chained accesses requiring extra attention. Reading flow: Startup and sequential parsing fallbacks follow a logical progression. Exception-driven format detection, inconsistent continuation indentation, and imports without grouping slightly interrupt otherwise natural reading.
Run 3
Code Structure: Well-separated methods handle CLI usage, connector processing, configuration parsing, and runtime construction; parsing contains some duplicated validation. Nesting: Mostly shallow, with moderate nesting in the callback and connector-name consistency checks. Clarity of intent: Descriptive identifiers and detailed documentation clearly explain the standalone execution model and supported configuration formats, although the abbreviated callback name 'cb' is less informative. Code length: Generally proportionate to functionality, but repeated missing-name checks and lengthy exception messages add verbosity. Action granularity: Most statements perform one action; chained calls and nested constructor expressions occasionally require extra effort to unpack. Reading flow: Startup and configuration fallback paths follow a logical sequence, aided by early returns. Exception-driven parsing, dense imports, omitted braces in the callback, and inconsistent continuation indentation slightly interrupt the otherwise natural flow.