Sample
int-5d9fe0206e2c-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.547 | 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 | 13.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.32 | 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. | 8359.833 | −275.875 |
| 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.732 | −7.098 |
Intercept 8.87 + feature contributions = -209.302 (log-odds).
Score = sigmoid(-209.302) = 0.
| Score | 0.547 |
|---|
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 follows clear separation of concerns with methods for parsing, creation, and processing. The class hierarchy and overridden methods are logical. Nesting is mostly flat, with the main loop in processExtraArgs being straightforward. Intent is clear through method names and Javadoc, especially for parseConnectorConfigurationFile which explains the three supported formats. Code length is appropriate but some sections (e.g., the lambda callback and exception handling) are slightly verbose. Action granularity is mostly good—one logical operation per line—but the error handling in processExtraArgs packs multiple actions into a single catch block. Reading flow is natural, with imports grouped and methods ordered logically. The main weakness is the inline lambda with an if-else for logging, which could be extracted for clarity. Overall, this code demonstrates good engineering practices and maintains readability despite handling complex configuration parsing scenarios.
Run 2
The code is moderately readable. Structure is logical with clear method separation, but the parsing method is long and has multiple responsibilities. Nesting is reasonable, though the exception handling in parseConnectorConfigurationFile creates some depth. Intent is mostly clear, especially in the main workflow. Code length is somewhat excessive in the parsing method due to three fallback parsing attempts. Action granularity is good in most places but the putConnectorConfig call spans multiple lines with many parameters. Reading flow is natural in the main execution path but becomes convoluted in the parsing logic with multiple try-catch blocks. The imports are well-organized and the class javadoc is helpful.
Run 3
The code has a reasonable overall structure and follows a typical CLI/worker pattern, but it suffers from several readability issues. The `processExtraArgs` method is long and mixes concerns: parsing configuration files, creating a callback, calling the herder, and handling errors all in one block. The callback uses ternary-like logging with an empty lambda style that harms clarity. `parseConnectorConfigurationFile` is very long and tries three different parsing strategies in a chain of try/catch blocks with minimal separation. Deep nesting is moderate, but the method length and multiple responsibilities make intent harder to follow. Some line breaks and indentation are inconsistent, especially in exception handling and the `createHerder` signature. Imports are numerous but organized, and the Javadoc is helpful. Overall, the code is understandable to experienced developers but requires effort to follow, and it would benefit from extracting smaller methods and simplifying the error-handling flow.
Run 1
1. Code Structure: Well-separated methods organize CLI setup, connector loading, configuration parsing, and worker construction. Parsing could be split into smaller helpers. 2. Nesting: Generally shallow, though the callback inside a loop and nested connector-name validation add complexity. 3. Clarity of intent: Descriptive names, documentation of supported formats, and informative logging make the purpose clear; abbreviated 'cb' and the hexadecimal exit code are less explicit. 4. Code length: Mostly concise, with some duplicated mandatory-name validation and lengthy expressions. 5. Action granularity: Statements generally perform one action per line; chained calls and nested constructor arguments modestly increase cognitive load. 6. Reading flow: Startup and parsing steps follow a logical sequence. Exception-driven parsing fallbacks, tightly packed imports, and inconsistent continuation indentation slightly interrupt otherwise natural reading.
Run 2
Code Structure: Well-organized class with focused methods separating CLI behavior, configuration parsing, and runtime construction. Nesting: Mostly shallow, though the callback inside a loop and nested configuration validation add some complexity. Clarity of intent: Descriptive names, helpful documentation, and informative logging make the purpose clear; abbreviated 'cb' and exception-driven format detection slightly reduce clarity. Code length: Reasonably concise, but repeated mandatory-name validation and the lengthy parsing method could be extracted into helpers. Action granularity: Generally one action per statement, with a few chained calls and nested constructor expressions requiring extra attention. Reading flow: Methods follow a natural progression, and parsing fallbacks match the documented order. Dense imports, inconsistent continuation indentation, and unbraced conditionals slightly interrupt otherwise readable formatting.
Run 3
Code Structure: Well-separated methods organize CLI behavior, configuration parsing, and runtime construction; parsing could be split into smaller helpers. Nesting: Mostly shallow, though the callback and nested connector-name validation add complexity. Clarity of intent: Descriptive names, documentation, and meaningful log messages explain the purpose and parsing order; the abbreviated callback variable and hexadecimal exit code are less clear. Code length: Generally appropriate, but repeated mandatory-name validation and verbose generic declarations introduce some duplication. Action granularity: Most statements perform one action, with a few nested constructor and utility calls requiring extra attention. Reading flow: Methods and sequential parsing fallbacks follow a logical progression; exception-driven format detection, dense imports, and inconsistent continuation indentation slightly interrupt readability.