Sample
int-b38bdcae3336-SRC
Unmodified source class
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 | 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 due to its clear structure and consistent patterns. It follows a logical organization where mutating methods throw UnsupportedOperationException and read methods return unmodifiable views, making intent explicit. Nesting is minimal, with simple if-else caching logic. Each method performs one action per line, and method names clearly convey purpose. The class-level Javadoc explains the caching caveat. Minor deductions: some methods like headerSet() have slightly complex stream chains, and the forEach implementation has a ternary expression that could be extracted for clarity. Overall, the code is concise, well-structured, and easy to follow.
Run 3
The code demonstrates strong readability through clear class structure, consistent formatting, and a logical organization of methods. The intent is explicit—enforcing immutability on an HttpHeaders variant—with each mutating method throwing UnsupportedOperationException in a predictable pattern. Nesting is minimal; caching logic uses simple if-else blocks, and method bodies are generally flat. Action granularity is appropriate, with one operation per line in most cases. The code is concise, avoiding unnecessary verbosity while maintaining clarity. Minor deductions arise from the extensive list of override methods that add visual repetition, and the headerSet() method’s stream pipeline, while readable, introduces slightly more complexity. Inline comments like 'No-op.' and 'Retain original ordering of entries' aid comprehension. Overall, the code follows a natural reading flow and is easy to scan and understand.
Run 1
Code Structure: Well-organized class with short, focused overrides, though related read and mutation methods could be grouped more consistently. Nesting: Shallow conditionals and a single loop keep complexity low; the nested collector expression is slightly harder to parse. Clarity of intent: The class name, documentation, descriptive identifiers, and explicit mutation exceptions clearly communicate read-only behavior and caching limitations. Code length: Mostly concise; repetitive mutation overrides are justified by the interface, while cache getters could omit their else branches after early returns. Action granularity: Statements generally perform one action per line, with only stream chaining and the forEach ternary combining several operations. Reading flow: Consistent formatting and familiar delegation patterns support smooth reading, although scattered mutation methods and the headerSet collector briefly interrupt the flow.
Run 2
Code Structure: Well-organized class with small, focused overrides, though read methods and mutation-blocking methods are somewhat interleaved. Nesting: Shallow conditionals and a single loop keep complexity low; cache getters could omit else after returning. Clarity of intent: The class name, documentation, descriptive identifiers, and explicit unsupported operations clearly communicate its read-only purpose and caching caveat. Code length: Most methods are concise; repeated mutation-blocking overrides add length but serve the inherited API. Action granularity: Statements generally perform one action per line, although the stream collector and forEach callback combine several operations. Reading flow: Consistent formatting and predictable override patterns make scanning easy; the headerSet collector requires slightly more effort to follow.
Run 3
Code Structure: Well-organized class with focused overrides, though read-only accessors and rejected mutators are somewhat interleaved. Nesting: Shallow conditionals and a single loop keep complexity low; the nested collector expression is slightly harder to scan. Clarity of intent: The class name, documentation, descriptive identifiers, and consistent UnsupportedOperationException behavior clearly communicate its purpose. Code length: Most methods are concise; repeated mutator overrides add length but are justified by the inherited API. The cache getters could omit their else blocks after early returns. Action granularity: Statements generally perform one action per line, with only stream chaining and the forEach ternary combining several operations. Reading flow: Consistent formatting and annotations support easy reading, although the headerSet collector and switching between accessors and mutators mildly interrupt the flow.