Sample
int-ac8cbec81cad-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.546 | 0–1; higher is more readable |
| Dorn | 0.778 | 0–1; higher is more readable |
| Mi | 0.282 | 0–1; higher is more readable |
| LLOC | 50 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.379 | 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. | 4610.646 | −152.151 |
| Source linesThe number of non-empty source lines. | 129 | +51.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.973 | −7.459 |
Intercept 8.87 + feature contributions = -99.141 (log-odds).
Score = sigmoid(-99.141) = 0.
| Score | 0.546 |
|---|
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. | 130 | −3.567 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 116 | +3.275 |
| 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.977 | −1.586 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 128.864 | +1.391 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 123.985 | +1.196 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.089 | +0.079 |
Intercept 0.07 + feature contributions = 1.257 (log-odds).
Score = sigmoid(1.257) = 0.778.
| Score | 0.282 |
|---|
| Score | 50 |
|---|
Run 1
The code is highly readable. It has a clear and logical structure, with the main conversion method followed by well-named helper methods and a private static inner class. Nesting is minimal; the only conditional inside the loop is a simple check. The intent of each method is clear from its name and the Javadoc explains the overall conversion process. Code length is appropriate and not verbose, though the targetEntries list could be avoided in simple cases. Action granularity is excellent, with one main action per line. Reading flow is natural—the convert method tells a story of checking for shortcuts, preparing entries, and building the target map. Overall, this follows clean code principles effectively.
Run 2
The code is well-structured with clear separation of concerns: public conversion logic, internal helpers, and a private MapEntry class. Nesting is shallow – the deepest is one level inside the convert method's loop. Intent is clearly expressed through descriptive method names like canConvertKey, convertValue, and the Javadoc explaining the conversion strategy. The code is concise, though slightly verbose due to Spring's TypeDescriptor pattern. Each major operation occupies its own line, improving readability. The reading flow is natural: null check, shortcut, type extraction, iteration, map construction, and entry addition. Minor deductions: the copyRequired shortcut logic requires careful reading, and the conversion method signatures involve many parameters, though this is typical for Spring's conversion framework.
Run 3
The code is well-structured with clear separation of concerns: type checking, conversion, and entry storage. Nesting is minimal, with early returns and guard clauses reducing indentation. Intent is clear through descriptive method names and concise comments. The convert method breaks actions into logical steps—null checks, shortcut handling, entry conversion, and target map creation. However, there is a minor readability issue: the MapEntry class adds a layer of abstraction that can make the flow slightly harder to follow at first glance. Line lengths and method granularity are appropriate. Overall, the code follows Spring’s style and is highly readable for an experienced Java developer.
Run 1
Code Structure: Logically organized into converter methods, focused helpers, and a small entry holder. Nesting: Shallow loops and conditionals, with early returns keeping control flow flat. Clarity of intent: Descriptive names and class documentation make map conversion clear; identity comparisons and deferred copying require slightly more thought. Code length: Mostly concise, though parallel key/value helpers and the intermediate entry class add some verbosity. Action granularity: Statements generally perform one action per line, making conversion steps easy to follow. Reading flow: Naturally progresses from validation and shortcuts through element conversion to target-map creation; the two-pass approach introduces modest cognitive overhead but remains well structured.
Run 2
Code Structure: Well organized into interface methods, focused conversion helpers, and a small entry class. Nesting: Shallow conditionals and loops, with early returns keeping control flow flat. Clarity of intent: Descriptive names and class documentation clearly communicate map conversion; identity comparisons and copyRequired tracking require some thought. Code length: Mostly concise, though the intermediate entry list, two-pass processing, and wrapper class add complexity to preserve source-map reuse. Action granularity: Statements generally perform one action per line, with compound expressions remaining manageable. Reading flow: Natural progression from null handling through conversion, reuse checks, and target population; consistent formatting and helper extraction support scanning.
Run 3
Code Structure: Well organized into converter methods, focused helpers, and a small entry holder. Nesting: Shallow loops and conditionals, with early returns preventing deep nesting. Clarity of intent: Descriptive names and documentation clearly communicate map conversion; reference-identity checks and deferred copying require slightly more thought. Code length: Generally concise, though parallel key/value helpers and the MapEntry wrapper add some verbosity. Action granularity: Statements consistently perform one action per line, making intermediate conversions easy to follow. Reading flow: Natural progression from null handling and shortcuts through conversion to target construction. The two-pass approach and copyRequired state introduce minor cognitive overhead, but formatting and method boundaries keep the implementation highly readable.