Sample
int-c8ec7d0a6acf-I11
Split eligible integer literals into pairs of short-named intermediate variables
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.477 | 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. | 5431.521 | −179.24 |
| 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.11 | −7.666 |
Intercept 8.87 + feature contributions = -109.636 (log-odds).
Score = sigmoid(-109.636) = 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.832 | +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
This code is highly readable. Structure is logical, grouping mutating methods that throw exceptions and read methods that return unmodifiable views. Nesting is minimal, with simple if-else caching blocks and a small lambda pipeline. Intent is clear: a read-only wrapper offering cached parsed headers and defensive copies. Code length is appropriate, with small focused methods. Action granularity is mostly one action per line; the headerSet lambda and forEach expression are slightly denser but still understandable. Reading flow is natural, following class declaration, caching methods, no-op overrides, mutators, accessors, and iteration helpers.
Run 2
The code is highly readable with clear structure and intent. The class has a single, well-defined purpose as a read-only wrapper around HttpHeaders, and this is clearly documented. Mutating methods consistently throw UnsupportedOperationException, making the read-only contract explicit. Nesting is minimal, with only simple if-else blocks for caching. The code is concise, avoiding unnecessary verbosity while maintaining clarity. Most methods perform a single action per line. The reading flow is natural, grouping related methods together. Minor deductions: the headerSet() method has a slightly complex stream/collection chain, and the forEach method combines null-checking with value transformation in a single expression, slightly reducing clarity. Overall, the code is exemplary in its readability and would be easy for another developer to understand and maintain.
Run 3
This code demonstrates excellent readability. The class structure is logical and follows a clear purpose: an immutable wrapper around HttpHeaders. The class-level Javadoc explains the caching behavior and potential staleness concerns. Methods are well-organized, grouping related mutating operations together. Nesting is minimal, with only necessary conditional checks. Each method has a clear, single responsibility—getters handle caching, mutators throw UnsupportedOperationException, and read operations return unmodifiable views. The code length is appropriate, avoiding unnecessary verbosity. Action granularity is strong, with one logical operation per line. Reading flow is natural, from field declarations to constructors to method overrides. The use of @Nullable annotations enhances clarity about potential null returns. Even complex methods like headerSet() are reasonably readable with clear stream operations and comments explaining intent. The only minor concern is the repeated exception-throwing boilerplate, but this is necessary for enforcing immutability. Overall, the code is highly maintainable and follows clean code principles.
Run 1
Code Structure: Well-organized class with short overrides separating cached access, read-only views, and prohibited mutations, though related methods could be grouped more consistently. Nesting: Shallow conditionals and a single loop keep complexity low; the collector expression is slightly harder to parse. Clarity of intent: Descriptive names, class documentation, explicit exceptions, and the no-op comment clearly communicate read-only behavior and caching limitations. Code length: Most methods are concise; repeated mutation-blocking overrides add length but make the contract explicit. Cache getters could omit their else blocks after early returns. Action granularity: Statements generally perform one action per line, with only the stream pipeline and callback expression combining several operations. Reading flow: Consistent formatting and predictable override patterns support easy scanning, although switching between accessors and mutators slightly interrupts the flow.
Run 2
Code Structure: Well-organized class with focused overrides, although read operations and rejected mutations 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, descriptive identifiers, and consistent exceptions clearly communicate read-only behavior and caching limitations. Code length: Most methods are concise; repeated mutation-blocking overrides add length but are justified by the inherited API. Action granularity: Statements generally perform one action each, though the headerSet stream pipeline and forEach ternary require slightly more interpretation. Reading flow: Consistent formatting and annotations support easy scanning, with minor interruptions from mixed method ordering and the comparatively dense collector expression.
Run 3
Code Structure: Well-organized class with small, focused overrides, though read methods and prohibited mutations are somewhat interleaved. Nesting: Shallow throughout; caching uses simple if/else blocks, and iteration has one loop. Clarity of intent: The class name, documentation, unmodifiable wrappers, and explicit exceptions clearly communicate read-only behavior and caching limitations. Code length: Mostly concise; repeated mutation-blocking overrides are necessary boilerplate, while caching branches could omit else after an early return. Action granularity: Statements generally perform one action each; the headerSet stream chain combines several transformations but remains manageable. Reading flow: Consistent formatting, descriptive names, and predictable methods support smooth reading. The nested collector expression and occasional long lines introduce minor friction.