Sample
int-72cd367a8f0b-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.597 | 0–1; higher is more readable |
| Dorn | 0.194 | 0–1; higher is more readable |
| Mi | 0.749 | 0–1; higher is more readable |
| LLOC | 56 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.452 | 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. | 5497.885 | −181.43 |
| Source linesThe number of non-empty source lines. | 171 | +68.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. | 5.103 | −7.654 |
Intercept 8.87 + feature contributions = -111.814 (log-odds).
Score = sigmoid(-111.814) = 0.
| Score | 0.597 |
|---|
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. | 172 | −5.054 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 160 | +4.797 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 160 | −3.251 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 170.841 | +1.978 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 105.942 | +0.905 |
| 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. | 105.948 | −0.822 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.102 | −0.048 |
Intercept 0.07 + feature contributions = -1.425 (log-odds).
Score = sigmoid(-1.425) = 0.194.
| Score | 0.749 |
|---|
| Score | 56 |
|---|
Run 1
The code is highly readable with a clear, focused purpose: a read-only wrapper around HttpHeaders. The structure is logical, grouping mutating overrides together and separating read operations. Nesting is minimal—only simple if/else blocks with early returns. Intent is explicit through method names like clearContentHeaders() with a No-op comment, and UnsupportedOperationException makes the immutable contract obvious. Code length is appropriate; each mutator is concise. Action granularity is strong—most methods perform one action per line. The reading flow is natural, progressing from caching accessors to protective read methods to forbidden mutators. The only minor complexity is the headerSet() streaming pipeline, which is slightly denser but still understandable with its inline comment. Overall, this is well-structured, self-documenting code.
Run 2
The code is highly readable due to its clear, logical structure and consistent patterns. Each method has a single, obvious purpose (either caching, returning unmodifiable views, or throwing UnsupportedOperationException), making intent unambiguous. Nesting is minimal, with only simple if-else blocks and one stream pipeline. Action granularity is excellent—most lines perform one operation. The mutating methods are concise and self-documenting, while read methods consistently wrap results in unmodifiable collections. The class-level Javadoc clearly explains the caching limitation. Minor deductions: the headerSet() stream could be slightly more readable with a helper method, and the null-coalescing ternary in forEach is slightly dense. Overall, the flat structure, consistent naming, and predictable patterns make this code easy to follow and maintain.
Run 3
The code is generally readable with clear intent and logical organization as an immutable HttpHeaders wrapper. Class structure is straightforward, with overridden methods grouped logically. Nesting is minimal, mostly limited to simple if/else blocks and one stream pipeline. Method names and exception-based mutators clearly communicate read-only behavior. However, the headerSet() method's stream pipeline is somewhat dense, combining mapping, collection, and wrapping operations with an inline comment. The forEach method accepts null values inconsistently, slightly obscuring intent. Overall, the code is concise and action granularity is mostly appropriate, though a few methods have multiple operations per line. The import list includes unused items (Map.Entry, List, etc.), but these are minor. Reading flow follows natural class structure, though the grouping of mutator methods before some accessor methods feels slightly disorganized.
Run 1
Code Structure: Well-organized class with clearly separated fields, constructor, and short overrides, though read and mutation methods are somewhat interleaved. Nesting: Minimal, limited to simple conditionals and one loop; the collector expression adds slight complexity. Clarity of intent: The class name, documentation, descriptive identifiers, and explicit mutation exceptions clearly communicate read-only behavior and caching limitations. Code length: Most methods are concise; repeated exception-throwing overrides add length but are appropriate for the inherited API. The caching methods could omit their else branches after early returns. Action granularity: Statements generally perform one action each; stream chaining and nested collector calls are the main exceptions. Reading flow: Consistent formatting and familiar delegation patterns make the code easy to follow, with minor friction from annotations, repetitive overrides, and the denser headerSet implementation.
Run 2
Code Structure: Small, consistently formatted overrides logically implement a read-only wrapper, although read and mutation methods are somewhat interleaved. Nesting: Minimal, limited to simple conditionals and one loop; the collector expression is slightly harder to parse. Clarity of intent: The class name, documentation, descriptive names, unmodifiable wrappers, and explicit mutation exceptions clearly convey purpose. Code length: Mostly concise; repeated mutation overrides are necessary API boilerplate, while redundant else blocks after early returns add minor verbosity. Action granularity: Statements generally perform one action per line, with modest complexity in the stream pipeline and conditional callback argument. Reading flow: Consistent annotations, spacing, and short methods make scanning easy, though grouping all mutation overrides together would improve navigation.
Run 3
Code Structure: Well-organized class with small, focused overrides, though read and mutation methods could be grouped more consistently. Nesting: Shallow conditionals and a single loop keep complexity low; caching methods could omit else after early returns. Clarity of intent: The class name, documentation, explicit exceptions, and unmodifiable wrappers clearly communicate read-only behavior and caching limitations. Code length: Mostly concise; repeated mutation overrides add length but are justified by the inherited API. Action granularity: Statements generally perform one action per line, although the headerSet stream pipeline packs several transformations together. Reading flow: Consistent formatting, descriptive names, and straightforward methods support easy scanning; the collector expression and interleaving of accessors with rejected mutations slightly interrupt the flow.