Sample
int-1e4c51492246-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.531 | 0–1; higher is more readable |
| Dorn | 0.188 | 0–1; higher is more readable |
| Mi | 0.521 | 0–1; higher is more readable |
| LLOC | 54 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 12.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.305 | 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. | 4878.391 | −160.987 |
| Source linesThe number of non-empty source lines. | 136 | +54.4 |
| 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.982 | −7.473 |
Intercept 8.87 + feature contributions = -105.19 (log-odds).
Score = sigmoid(-105.19) = 0.
| Score | 0.531 |
|---|
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. | 137 | −3.814 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 123 | +3.517 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 123 | −2.402 |
| 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. | 123.971 | −1.586 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 135.848 | +1.489 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 123.971 | +1.196 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.09 | +0.064 |
Intercept 0.07 + feature contributions = -1.466 (log-odds).
Score = sigmoid(-1.466) = 0.188.
| Score | 0.521 |
|---|
| Score | 54 |
|---|
Run 1
The code is generally well-structured with clear method separation, but it contains a critical readability flaw: an unrelated, extraneous block of code (a running total loop) inserted inside the matches() method. This breaks reading flow, confuses intent, and adds unnecessary nesting. Other issues include duplicate logic in convertKey/convertValue (could be unified), a somewhat convoluted shortcut/copyRequired flow, and a trivial MapEntry class that could be a record or simple pair. The code length is moderate and action granularity is mostly good, but the misplaced code block severely undermines clarity and makes the file ambiguous and disjointed.
Run 2
The code is generally well-structured and readable, with clear class purpose, logical method breakdown, and helpful comments. The main 'convert' method uses flat, linear flow with no deep nesting, and each action is mostly on separate lines. However, there is a serious readability issue: an unrelated block of code (a 'for' loop with 'runningTotal') is mistakenly inserted inside the 'matches' method, disrupting logic and reading flow. Apart from that, helper methods like 'canConvertKey' and 'convertKey' are concise and well-named, and the inner 'MapEntry' class adds clarity. Minor improvements could include reducing the number of null checks and slightly simplifying conditionals, but overall structure and intent are clear.
Run 3
The code is generally well-structured with clear intent, but has a significant flaw: an unrelated code block (a loop summing numbers) is accidentally embedded in the matches() method, disrupting flow and clarity. The class follows a logical organization with methods separated by purpose, and the Javadoc explains the conversion process well. Nesting is mostly flat and readable. However, the convert() method contains multiple actions per line in some cases and the loop body packs several operations. Helper methods like canConvertKey/canConvertValue and the MapEntry inner class improve readability. The accidental code block is a major issue that would confuse any reader and must be removed.
Run 1
Code Structure: Well-organized converter methods, focused helpers, and an encapsulated entry class, but the unrelated summation block in matches disrupts cohesion. Nesting: Mostly shallow, with early returns keeping control flow manageable; the extraneous block adds unnecessary nesting. Clarity of intent: Documentation and descriptive names explain map conversion clearly, although the unused runningTotal calculation is confusing. Code length: Generally appropriate for conversion and copy avoidance, but the summation adds needless lines. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Conversion proceeds naturally from validation through entry conversion to map creation, but inconsistent indentation in matches and the irrelevant calculation interrupt an otherwise clean flow.
Run 2
Code Structure: Well-organized converter methods, focused helpers, and a small entry class, but the unrelated summation block in matches disrupts cohesion. Nesting: Mostly shallow, with early returns keeping conversion logic easy to follow. Clarity of intent: Descriptive names and documentation explain map conversion and copy avoidance; the unused runningTotal calculation has no apparent purpose. Code length: Generally justified, although the summation block is unnecessary and the entry wrapper adds some verbosity. Action granularity: Statements mostly perform one action per line; the loop header is conventional and readable. Reading flow: Conversion proceeds naturally from validation through entry conversion to map creation, but inconsistent indentation in matches and the irrelevant calculation interrupt the otherwise clean flow.
Run 3
Code Structure: Well organized into conversion methods, focused helpers, and a small entry class, but the unrelated summation block in matches disrupts cohesion. Nesting: Generally shallow, with early returns keeping control flow simple; the unnecessary block adds avoidable nesting. Clarity of intent: Descriptive names and documentation clearly explain map conversion, although the unused runningTotal calculation is distracting and unexplained. Code length: Mostly appropriate for the conversion and copy-avoidance logic, but the summation adds needless lines. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Conversion progresses naturally from validation through element conversion to map creation; inconsistent indentation in matches and excess blank lines weaken an otherwise consistent presentation.