Sample
int-d22ad162ebb0-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.752 | 0–1; higher is more readable |
| Dorn | 0.285 | 0–1; higher is more readable |
| Mi | 0.592 | 0–1; higher is more readable |
| LLOC | 71 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.42 | 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. | 5145.633 | −169.806 |
| Source linesThe number of non-empty source lines. | 156 | +62.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. | 4.763 | −7.145 |
Intercept 8.87 + feature contributions = -105.681 (log-odds).
Score = sigmoid(-105.681) = 0.
| Score | 0.752 |
|---|
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. | 156 | −4.487 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 149 | +4.417 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 149 | −2.998 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 155.864 | +1.769 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 101.968 | +0.841 |
| 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. | 101.987 | −0.655 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.084 | +0.123 |
Intercept 0.07 + feature contributions = -0.92 (log-odds).
Score = sigmoid(-0.92) = 0.285.
| Score | 0.592 |
|---|
| Score | 71 |
|---|
Run 1
The code demonstrates strong readability with clear logical organization, separating constructors, factory methods, serialization concerns, and the inner hasher class. Nesting is minimal, with only a single try-catch block inside methods. Intent is well-expressed through descriptive method names like supportsClone and checkNotDone, and the class purpose is documented. Code length is appropriate—no unnecessary verbosity, though two constructors have slight duplication in initialization that could be consolidated. Action granularity is generally one action per line, enhancing clarity. Reading flow is natural: fields flow into constructors, then methods, then inner classes. Minor deductions: the unused 'a' and 'c' variables in the second constructor are confusing and should be removed or named meaningfully; the nested lambda-like conditional return in hash() could be slightly clearer with an if-else. Overall, very readable with trivial areas for improvement.
Run 2
The code is well-structured with clear separation of concerns, logical class organization, and purposeful method grouping. Nesting is minimal and flat, avoiding deep conditional or loop nesting. Intent is explicit through descriptive names like supportsClone, checkNotDone, and SerializedForm. Code length is appropriate for the functionality, though the dual constructors introduce minor duplication. Each method performs a single, focused action, maintaining good action granularity. Reading flow is natural, progressing from construction to hashing operations. A few minor issues slightly reduce readability: the meaningless constants 'a' and 'c' in the validation check obscure intent, and the catch-and-fall-through pattern in newHasher requires careful reading. Overall, this is production-quality Java code with strong readability.
Run 3
The code demonstrates strong readability through clear organization and logical structure. Class responsibilities are well-separated with nested serialization/hasher implementations. Nesting is minimal (2-3 levels max). Variable and method names clearly express intent (e.g., `checkNotDone`, `supportsClone`). Action granularity is mostly one operation per line with helper methods. Serialization handling shows thoughtful design. Minor deductions: the magic numbers `4` and `2` in the constructor's checkArgument are unclear without context, and the `a`/`c` variables are redundant. The fall-through comment in `newHasher()` could be more explicit. Overall, this is production-quality, idiomatic Java code that is easy to follow and maintain.
Run 1
Code Structure: Well-organized adapter with focused helper methods and separate nested classes for serialization and hashing. Nesting: Generally shallow; only the clone attempt adds modest nesting. Clarity of intent: Descriptive names, annotations, and comments clarify most behavior, but arbitrary constants a and c obscure the minimum digest length, and the validation message says '<' while the condition allows equality. Code length: Mostly concise, with minor constructor duplication and unnecessary constants. Action granularity: Statements generally perform one action per line; the final conditional expression combines digest generation, optional truncation, and wrapping but remains manageable. Reading flow: Natural progression from construction to hash creation and supporting classes, although serialization details interrupt the main hashing flow slightly.
Run 2
Code Structure: Well-organized methods and focused nested classes separate hashing, construction, and serialization. Nesting: Generally shallow; the clone fallback introduces only modest nesting. Clarity of intent: Descriptive method names and comments explain the adapter and lifecycle, but arbitrary constants a and c obscure the minimum digest length. The validation message also says '<' while the condition allows equality. Code length: Mostly concise, though constructor duplication and unnecessary constants add clutter. Action granularity: Statements generally perform one action per line; the final ternary combines digest generation, truncation, and wrapping but remains manageable. Reading flow: Consistent formatting and short methods support natural reading, although serialization machinery interrupts the main hashing flow and the field named toString is slightly awkward.
Run 3
Code Structure: Well-organized methods and nested classes separate digest creation, serialization, and hashing responsibilities. Nesting: Generally shallow, with only modest nesting in clone handling. Clarity of intent: Descriptive names, overrides, and comments make the adapter's purpose clear; however, arbitrary constants a and c obscure the minimum digest length, and the validation message says '<' while the condition permits equality. Code length: Mostly concise, though constructor initialization is duplicated and the artificial constants add unnecessary lines. Action granularity: Statements generally perform one action per line, making state changes easy to follow. Reading flow: Consistent formatting and small methods support natural reading, although serialization machinery interrupts the main hashing flow and the final ternary requires slightly more attention.