Sample
int-c62841e74667-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.392 | 0–1; higher is more readable |
| Dorn | 0.179 | 0–1; higher is more readable |
| Mi | 0.305 | 0–1; higher is more readable |
| LLOC | 146 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 2.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 7.67 | 0–20; mean of three runs |
| BTTF | 0.116 | 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. | 9594.534 | −316.62 |
| Source linesThe number of non-empty source lines. | 195 | +78 |
| 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.382 | −6.574 |
Intercept 8.87 + feature contributions = -236.323 (log-odds).
Score = sigmoid(-236.323) = 0.
| Score | 0.392 |
|---|
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. | 196 | −5.903 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 183 | +5.593 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 183 | −3.778 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 194.912 | +2.315 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 100.969 | +0.825 |
| 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. | 100.969 | −0.611 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.1 | −0.031 |
Intercept 0.07 + feature contributions = -1.522 (log-odds).
Score = sigmoid(-1.522) = 0.179.
| Score | 0.305 |
|---|
| Score | 146 |
|---|
Run 1
The code is extremely difficult to read due to deliberate obfuscation. Constants are replaced with meaningless variables like 'h', 'j', 'k' and simple arithmetic is used instead of literal values (e.g., 'f + g' instead of 56). The switch statement fall-through logic and hardcoded offsets in the 'macHash' method are confusing and non-idiomatic. Multiple actions are packed into single lines and the natural flow of the algorithm is destroyed by the variable naming scheme. While the constructor is relatively clear, the core hashing logic is unreadable and unmaintainable.
Run 2
This code is nearly unreadable due to deliberate obfuscation. The macHash method replaces standard constants (7, 8, 24, etc.) with meaningless single-letter variables (h, j, k, n, o) that compute simple arithmetic. The switch statement uses calculated case labels like case (h + j) and computes offsets with expressions like (k + l), hiding the actual byte positions. The sipround method similarly hides rotation amounts behind variables like bb, bc, bd, be. Intention is completely obscured—what should be straightforward SipHash implementation becomes a puzzle. Comments that could clarify are absent or misleading. Scanning horizontally through dense arithmetic expressions breaks reading flow. The code violates every readability criterion: it has terrible structure, no clarity, unnecessary length from constant declarations, and absurd action granularity. While variable names like compressionRounds and initialStateV0 are fine, the obfuscated constant arithmetic destroys all maintainability and code review potential.
Run 3
The code is extremely unreadable due to deliberate obfuscation of constants and control flow. Logical structure is obscured by hundreds of meaningless single-letter variables (a through bm) representing simple arithmetic operations (e.g., final int bb = 6; final int bc = 7; then rotate by (bb + bc)). Nesting is acceptable, but clarity of intent is destroyed; the SipHash algorithm becomes unrecognizable. Code length is bloated massively by unnecessary local variable declarations. Action granularity is inconsistent; some lines combine actions, while others declare a trivial constant. Reading flow is disjointed, forcing the reader to mentally decode dozens of arbitrary variables to understand even a single shift amount. This appears intentionally mangled rather than simply poorly formatted, making maintenance impossible.
Run 1
Code Structure: The class separates initialization, hashing, and rounds logically, but excessive local constants clutter the methods. Nesting: Mostly shallow, with manageable nested loops and conditionals. Clarity of intent: The SipHash reference, descriptive field names, and comments help, but meaningless variables such as aa through bm and arithmetic expressions obscure simple constants and algorithm steps. Code length: Substantially inflated by unnecessary declarations that could be replaced with direct numeric values or meaningful constants. Action granularity: Generally one action per line, although repeated constant setup fragments otherwise straightforward operations. Reading flow: Initialization and hashing phases follow a sensible sequence, but readers must repeatedly resolve trivial sums; undocumented switch fall-through and dense bit manipulation further interrupt comprehension.
Run 2
Code Structure: The constructor, hashing method, and round helper provide logical organization, but excessive temporary constants clutter the implementation. Nesting: Mostly shallow, with only a conditional and inner loop inside the main loop. Clarity of intent: The SipHash reference, descriptive configuration fields, and endian comments help, but meaningless names such as aa and bm and arithmetic expressions for simple constants obscure the algorithm. The switch's intentional fall-through is not explained. Code length: Substantially inflated by unnecessary constant declarations that could be replaced with direct values. Action granularity: Generally good, with one assignment or operation per line. Reading flow: Initialization, compression, tail processing, and finalization follow a natural sequence, but readers must repeatedly resolve trivial sums and scan unrelated declarations, interrupting that flow.
Run 3
Code Structure: The constructor, hashing method, and round helper provide logical organization, but excessive local constants clutter the implementation. Nesting: Generally shallow, with only a conditional and inner loop inside the main loop. Clarity of intent: Descriptive fields, named initialization constants, and specification references help, but arbitrary names such as aa and bm and arithmetic substitutions obscure simple values. The switch's intentional fall-through is not explained. Code length: Significantly inflated by unnecessary constant declarations that could be replaced with direct literals. Action granularity: Mostly one action per line, making individual state updates easy to distinguish. Reading flow: The overall initialization, compression, and finalization sequence is natural, but repeated declarations interrupt it and force readers to mentally calculate offsets, shift counts, and loop initializers.