Sample
int-d1d7b072eeb3-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.751 | 0–1; higher is more readable |
| Dorn | 0.313 | 0–1; higher is more readable |
| Mi | 0.642 | 0–1; higher is more readable |
| LLOC | 69 | 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.364 | 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. | 5031.212 | −166.03 |
| Source linesThe number of non-empty source lines. | 154 | +61.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. | 4.77 | −7.154 |
Intercept 8.87 + feature contributions = -102.714 (log-odds).
Score = sigmoid(-102.714) = 0.
| Score | 0.751 |
|---|
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. | 154 | −4.416 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 147 | +4.347 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 147 | −2.952 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 153.879 | +1.741 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 97.955 | +0.776 |
| 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. | 97.974 | −0.485 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.083 | +0.131 |
Intercept 0.07 + feature contributions = -0.787 (log-odds).
Score = sigmoid(-0.787) = 0.313.
| Score | 0.642 |
|---|
| Score | 69 |
|---|
Run 1
The code is well-structured with clear separation of concerns: the outer class handles configuration and serialization, while the inner class implements hashing. Nesting is minimal and logical. Intent is clear through descriptive method and variable names. The code is concise without unnecessary verbosity, though the two constructors have some duplication. Each line focuses on a single action. Reading flow is natural, following the class's lifecycle. Minor deductions for the constructor duplication and slight complexity in the serialization handling.
Run 2
The code is well-structured and readable. It uses clear naming conventions, follows a logical organization with public API methods before private helpers, and maintains flat nesting with only one or two levels of indentation. Each method performs a single action, and most lines contain one operation. The intent is clear: adapting MessageDigest into a Guava HashFunction. Some minor deductions: the 'supportsClone' method has a confusing unused variable, and the serialization logic (writeReplace, readObject, SerializedForm) adds complexity without immediate clarity. Overall, the code is concise, purposeful, and follows good Java practices.
Run 3
The code is well-structured and readable for an expert audience. It follows a logical organization, with related methods grouped and clear separation of concerns (e.g., serialization logic in `SerializedForm`, hashing in `MessageDigestHasher`). Nesting is minimal, and most methods are small, with one action per line. Intent is clear from method and variable names, with validation done early via `checkArgument` and `checkNotNull`. The code is moderately concise; some duplication exists between constructors, but it is acceptable. Reading flow is natural, and comments are sparse but effective. Minor deductions: the fall-through in `newHasher` relies on a comment and exception catch, slightly interrupting flow; the `supportsClone` method uses a dummy assignment to ignore the clone result, which is idiomatic but not immediately obvious to all readers.
Run 1
Code Structure: Responsibilities are cleanly separated into digest creation, serialization, and a dedicated hasher class. Nesting: Mostly shallow; the clone fallback adds only modest nesting. Clarity of intent: Descriptive method names, validation, and comments make behavior clear, though the toString field name and hexadecimal constants slightly reduce clarity. Code length: Methods are concise; repeated constructor initialization and update checks are minor duplication. Action granularity: Statements generally perform one action per line, with only the final hashing expression combining digesting, truncation, and wrapping. Reading flow: Consistent formatting and straightforward control flow support easy reading, although serialization methods interrupt the progression from factory logic to hashing implementation. The validation message also says '<' while the condition permits equality, creating a small interpretive inconsistency.
Run 2
Code Structure: Responsibilities are logically separated into the hash-function adapter, serialization proxy, and digest hasher, with small focused methods. Nesting: Mostly flat; the clone attempt inside a conditional adds only modest nesting. Clarity of intent: Descriptive method names, validation, and comments make behavior clear. Minor distractions include the field named toString, hexadecimal constants, and a validation message that says '<' while the condition allows equality. Code length: Appropriately concise for the functionality, with limited constructor and update-method repetition. Action granularity: Statements generally perform one action per line; the final conditional expression combines digest creation, optional truncation, and wrapping but remains understandable. Reading flow: Consistent formatting and cohesive method grouping support natural reading, although serialization machinery interrupts the main hashing flow slightly.
Run 3
Code Structure: Responsibilities are logically separated into digest creation, serialization, and a dedicated hasher class. Nesting: Control flow is shallow; the nested try/catch in newHasher is manageable. Clarity of intent: Descriptive method names, explicit state checks, and brief comments clearly communicate behavior. Minor distractions include the toString field name, hexadecimal constants, and a validation message that says '<' despite an inclusive upper bound. Code length: Methods are short and focused; constructor duplication and repetitive update methods add modest length but remain understandable. Action granularity: Statements generally perform one action per line, although the final ternary combines digest generation, optional truncation, and conversion. Reading flow: Consistent formatting and cohesive method groupings make the code easy to follow, with minor interruptions from serialization boilerplate and the silent clone-failure fallback.