Sample
int-9fb71c024eb8-I08
Select one of ten high-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.51 | 0–1; higher is more readable |
| Dorn | 0.088 | 0–1; higher is more readable |
| Mi | 0.119 | 0–1; higher is more readable |
| LLOC | 54 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 10 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs |
| BTTF | 0.24 | 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. | 8625.031 | −284.626 |
| Source linesThe number of non-empty source lines. | 169 | +67.6 |
| 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.733 | −7.099 |
Intercept 8.87 + feature contributions = -215.255 (log-odds).
Score = sigmoid(-215.255) = 0.
| Score | 0.51 |
|---|
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. | 170 | −4.983 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 146 | +4.313 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 146 | −2.929 |
| 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.982 | −2.56 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 168.98 | +1.952 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 146.947 | +1.566 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.073 | +0.233 |
Intercept 0.07 + feature contributions = -2.338 (log-odds).
Score = sigmoid(-2.338) = 0.088.
| Score | 0.119 |
|---|
| Score | 54 |
|---|
Run 1
The code has severe readability issues. The most critical problem is a random, unrelated block of code (a factorial calculation) embedded in the usage() method, which is completely out of context and breaks all logical flow. The parseConnectorConfigurationFile method has deeply nested try-catch blocks and multiple exception handling paths, making it hard to follow. There are multiple actions crammed into single lines, especially in the processExtraArgs method where callbacks and connector configuration are handled in dense lambda expressions. The method signatures and class structure are reasonable, but the implementation details are tangled. Variable naming is generally clear, but the overall reading flow is disrupted by the misplaced factorial code and the complex nested exception handling patterns. Code structure is inconsistent with some methods being well-organized while others are chaotic.
Run 2
The code has clear purpose and follows some logical structure, but suffers from several readability issues. The most glaring problem is an accidental code block in the usage() method that computes a factorial (lines 58-63) which is completely unrelated to the method's purpose - this is either leftover debug code or a serious error. The parseConnectorConfigurationFile method is overly long with three separate try-catch blocks that create repetition and make the flow harder to follow. Multiple operations are packed into single lines, especially in createHerder. The processExtraArgs method has reasonable structure but the lambda callback could be more clearly expressed. While imports are organized and the class hierarchy is clear, the method signatures and error handling create unnecessary complexity. The code would benefit from extracting the three parsing strategies into separate methods and removing the erroneous factorial block.
Run 3
The code is generally readable but has notable issues. Structure is logical with clear method separation, but the accidental inclusion of an unrelated factorial loop inside the usage() method severely breaks flow and intent. Nesting is mostly flat except for the try-catch blocks. The parsing method is well-documented and follows a clear sequential logic, though it's somewhat long. Action granularity is good - most lines perform one action. The lambda callback in processExtraArgs demonstrates clear intent but could be extracted for better readability. The multi-catch approach reduces duplication but the repeated error messages are verbose. Import organization is standard. Overall, the code would benefit from removing the stray code block, extracting some of the repeated error handling, and potentially simplifying the parsing logic. The factorial loop appears to be accidental code insertion and significantly impacts readability.
Run 1
Code Structure: Methods separate startup, configuration parsing, and component creation logically, but the unrelated factorial block in usage() disrupts organization. Nesting: Mostly moderate, with deeper nesting in the connector callback and configuration-name validation. Clarity of intent: Descriptive names and detailed documentation explain the main behavior; the unused factorial calculation is confusing. Code length: Generally reasonable, although repeated mandatory-name checks and verbose parsing logic could be extracted into helpers. Action granularity: Most statements perform one action per line; chained calls and compound constructor expressions slightly increase reading effort. Reading flow: The documented parsing order and sequential startup steps are natural, but inconsistent indentation, tightly packed imports, long lines, and omitted conditional braces reduce consistency. Overall, the code is understandable, with a conspicuous irrelevant block and several formatting issues preventing a higher score.
Run 2
Code Structure: Well-separated methods organize startup, configuration parsing, and component creation, but an unrelated factorial block disrupts usage(). Nesting: Mostly shallow, with moderate nesting in callbacks and configuration validation. Clarity of intent: Descriptive names, documentation, and logging explain the main behavior; the unused factorial calculation is confusing. Code length: Generally reasonable, though repeated mandatory-name validation and verbose parsing could be consolidated. Action granularity: Most statements perform one action per line; chained calls and long constructor expressions add some reading effort. Reading flow: The documented parsing order and sequential initialization are natural, but inconsistent indentation, ungrouped imports, and the extraneous block interrupt the flow.
Run 3
Code Structure: Methods separate configuration parsing, connector startup, and runtime construction logically, but the unrelated factorial block in usage() disrupts cohesion. Nesting: Mostly shallow, with moderate nesting in the startup callback and connector-name validation. Clarity of intent: Descriptive names, documentation, and logging explain most behavior; the unused factorial computation is confusing, and 'cb' is less descriptive. Code length: Generally appropriate, though repeated mandatory-name checks and the irrelevant computation add unnecessary length. Action granularity: Most statements perform one action per line; chained calls and inline object construction slightly increase cognitive load. Reading flow: The documented sequence of parsing attempts is easy to follow, and helper methods provide a natural progression. However, inconsistent indentation, densely grouped imports, long expressions, and unbraced callback conditionals reduce visual consistency.