Sample
int-d31fdedc58aa-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.597 | 0–1; higher is more readable |
| Dorn | 0.188 | 0–1; higher is more readable |
| Mi | 0.753 | 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 | 17 | 0–20; mean of three runs |
| BTTF | 0.471 | 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. | 5510.033 | −181.831 |
| Source linesThe number of non-empty source lines. | 169 | +67.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. | 5.114 | −7.671 |
Intercept 8.87 + feature contributions = -113.032 (log-odds).
Score = sigmoid(-113.032) = 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. | 170 | −4.983 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 157 | +4.693 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 158 | −3.205 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 168.832 | +1.95 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 105.947 | +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.965 | −0.823 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.104 | −0.069 |
Intercept 0.07 + feature contributions = -1.461 (log-odds).
Score = sigmoid(-1.461) = 0.188.
| Score | 0.753 |
|---|
| Score | 56 |
|---|
Run 1
This code is highly readable. It demonstrates a clear, single-purpose class with a well-documented responsibility. The structure is logical, grouping related methods (getters, mutators) together. Nesting is minimal and flat; the getContentType and getAccept methods are straightforward, although the double negation in the if condition `!((this.cachedContentType != null))` is a minor readability flaw. Clarity of intent is excellent—each mutator clearly throws UnsupportedOperationException, making the read-only nature evident. Code length is appropriate; no methods are unnecessarily verbose. Action granularity is mostly one action per line, especially in the handler methods. The reading flow is natural, moving from cached getters to enforced immutability. The only slight complexity is in the headerSet method with its streaming and collection operations, which could be simplified, but it remains understandable. Overall, it is a very clean and maintainable implementation.
Run 2
The code is highly readable with clear structure and intent. The class purpose is documented, and method names are self-explanatory. Caching logic in getContentType() and getAccept() follows a consistent pattern, though the double negative condition (!((this.cachedContentType != null))) is slightly awkward. Most mutators throw UnsupportedOperationException cleanly, making the read-only nature explicit. Nesting is minimal throughout. Action granularity is well-maintained, with one operation per line in most cases. The headerSet() method uses streams appropriately with a helpful comment about preserving ordering. The forEach() method properly wraps values in unmodifiable lists. Minor readability improvements could include simplified null-check syntax, but overall this is clean, maintainable code that clearly expresses the read-only wrapper pattern.
Run 3
The code is highly readable with a clear, consistent structure. The class purpose and caching caveats are well-documented. Methods are short, focused, and follow a predictable pattern: mutating methods throw UnsupportedOperationException, while read methods return unmodifiable views. Nesting is minimal, with only a few single-level conditionals in getContentType/getAccept and headerSet. Intent is unambiguous throughout, and actions are generally one per line. The only minor weaknesses are slightly redundant null-check negation in getContentType/getAccept (e.g., if (!(x != null))) and the headerSet lambda pipeline being somewhat dense, but overall the reading flow is natural and maintainable.
Run 1
Code Structure: Well organized into small overrides, with consistent formatting and a clear read-only wrapper design, though related read and mutation methods could be grouped more tightly. Nesting: Shallow throughout; only simple conditionals and a single loop. Clarity of intent: Descriptive names, documentation, and explicit mutation exceptions make the purpose clear. However, negated, over-parenthesized null checks obscure otherwise straightforward cache logic. Code length: Most methods are concise; repetitive overrides are largely justified by the API, but caching methods could avoid temporary variables and unnecessary else branches. Action granularity: Statements generally perform one action per line; the headerSet stream pipeline compresses several transformations and requires more attention. Reading flow: Consistent annotations and spacing support scanning, while interspersed mutators and accessors, redundant conditional syntax, and the nested collector expression slightly disrupt the flow.
Run 2
Code Structure: Well organized into small overrides, although read operations and rejected mutations could be grouped more consistently. Nesting: Shallow throughout; only simple conditionals and one loop, with a somewhat denser collector expression. Clarity of intent: The class name, documentation, unmodifiable wrappers, and explicit exceptions clearly communicate read-only behavior. Negated, excessively parenthesized null checks obscure otherwise straightforward caching logic. Code length: Most methods are concise; repeated mutation overrides are justified by the API, but redundant else branches and extra blank lines add minor bulk. Action granularity: Statements generally perform one action per line; stream chaining combines several transformations but remains manageable. Reading flow: Consistent naming, formatting, and annotations support easy scanning, though interleaved method categories and the nested collector slightly interrupt the flow.
Run 3
Code Structure: Small, clearly separated overrides provide logical organization, though read operations and prohibited mutations could be grouped more consistently. Nesting: Mostly flat, with only shallow conditionals and a simple loop; the nested collector expression is slightly harder to parse. Clarity of intent: Class documentation, descriptive names, unmodifiable wrappers, and explicit exceptions clearly communicate read-only behavior. However, negated null checks with redundant parentheses obscure otherwise straightforward caching logic. Code length: Most methods are concise; repetitive mutation overrides are justified by the interface, but caching methods could omit unnecessary else branches. Action granularity: Statements generally perform one action per line, although the stream pipeline and forEach argument combine several operations. Reading flow: Consistent formatting and annotations support easy scanning, while excessive blank lines, mixed method grouping, and awkward conditions introduce minor friction.