Sample
Scalabrio58
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 2.5Δ 43.0 |
| Scalabrino | 0.281 | 0–1; higher is more readable | 25.1Δ 20.4 |
| Dorn | 0.033 | 0–1; higher is more readable | 6.0Δ 39.4 |
| Mi | 0.026 | 0–1; higher is more readable | 14.6Δ 30.9 |
| LLOC | 30 | Logical lines; fewer is more readable | 4.3Δ 41.2 |
| DeepSeek V4 Pro | 6.67 | 0–20; mean of three runs | 5.5Δ 39.9 |
| GPT-6.1 Sol | 14 | 0–20; mean of three runs | 9.5Δ 35.9 |
| BTTF | 0.214 | 0–1; higher is more readable | 2.5Δ 43.0 |
| Human | 3.56 | 1–5; original rating | 45.5 |
Views
Select the downloaded ZIP or its extracted folder. Files stay in your browser.
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. | 2427.62 | −80.111 |
| Source linesThe number of non-empty source lines. | 39 | +15.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.658 | −6.987 |
Intercept 8.87 + feature contributions = -62.629 (log-odds).
Score = sigmoid(-62.629) = 0.
| Score | 0.281 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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. | 112.949 | −1.119 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 1 | −0.703 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 39 | −0.474 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 39 | −0.345 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.111 | −0.137 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 37.789 | +0.118 |
Intercept 0.07 + feature contributions = -3.393 (log-odds).
Score = sigmoid(-3.393) = 0.033.
| Score | 0.026 |
|---|
| Score | 30 |
|---|
Run 1
The code scores low due to multiple readability issues. While it follows a linear flow, it lacks logical organization: bit manipulation, UUID generation, and debugging output are intertwined. The nesting is shallow, which is good, but the intent is often unclear—magic numbers like 0x3f and the bit-shift operation lack explanatory comments or named constants. The code is unnecessarily long, primarily due to extensive debug printing that obscures the core logic. Action granularity is mixed; some lines perform multiple actions (e.g., bitwise OR and shift), while others are single-purpose print statements. Reading flow is disrupted by excessive output blocks and visual separators. The loop structure is straightforward, but the overall implementation is verbose and cryptic without domain context. The code would benefit from extracting helper methods, using named constants, and separating debugging from core logic.
Run 2
The code has a clear overall purpose (testing UUID generation) and follows a linear, sequential logic. However, readability is severely impacted by excessive verbose output and noisy console formatting, which obscures the core logic. The main method is long and mixes low-level bit manipulation with I/O and assertions without separating concerns. Nesting is minimal, and each line performs a single action, but the heavy use of System.out.println and repeated separator strings creates clutter. Variable names like loBits, hiTime, and loTime are somewhat clear, but the bit-setting section lacks comments explaining the magic numbers (0x3f, 2 << 6). The code length is inflated by diagnostic prints, making it harder to scan. Overall, the structure is straightforward but buried under debugging noise, reducing clarity and maintainability.
Run 3
The code is highly unreadable due to several factors. The structure is tangled, with setup, bit manipulation, and output all mixed together in one large loop. Nesting is moderate but the lengthy repetitive output blocks create visual clutter. Intent is unclear—it's not obvious why the bit manipulation is performed or what the test is validating without deep analysis. The code is unnecessarily long with excessive whitespace and verbose print statements that obscure the core logic. Multiple actions are packed into some lines (e.g., array copies and bit operations combined with print calls). Reading flow is disorganized, jumping between system time extraction, bit twiddling, and formatting. The method lacks separation of concerns, proper naming, or helper functions to break down the generation and validation steps.
Run 1
Code Structure: The loop follows logical stages—assemble bytes, inspect and modify bits, construct a UUID, and validate its variant—but diagnostic output obscures the core operations. Nesting: Shallow, with only a loop and a simple conditional. Clarity of intent: UUID construction and validation are apparent, but abbreviated names, unexplained byte offsets, and magic bit constants make the encoding details harder to understand. Code length: Repeated print statements and long separator strings add unnecessary bulk. Action granularity: Most lines perform one action, although nested conversions in array-copy and output calls require extra interpretation. Reading flow: Execution proceeds naturally, with whitespace separating stages, but verbose logging interrupts the algorithm. Named constants and extracted encoding or logging helpers would improve readability.
Run 2
Code Structure: The loop follows logical stages: assemble bytes, inspect them, set bits, construct a UUID, and validate it, but diagnostic output obscures the core logic. Nesting: Shallow nesting, with one loop and one conditional, makes control flow easy to follow. Clarity of intent: UUID generation and variant validation are apparent, but abbreviated names, unexplained byte offsets, and magic bit masks require domain knowledge. Code length: Repetitive print statements and long decorative separators make the method unnecessarily lengthy. Action granularity: Most statements perform one action per line, although some combine conversions with copying or output. Reading flow: Execution proceeds naturally, and before/after labels help, but repeated logging interrupts the algorithm; extracting diagnostic output and naming constants would improve readability.
Run 3
Code Structure: Initialization, byte assembly, bit modification, and UUID validation follow a logical sequence, but diagnostic printing dominates and could be extracted into helpers. Nesting: Shallow, with only a loop and a simple conditional. Clarity of intent: UUID construction and variant checking are apparent, but magic numbers, bit shifts, byte offsets, and abbreviated names obscure the encoding details. Code length: Reasonable for a diagnostic example, though repeated output statements and decorative separators add substantial visual bulk. Action granularity: Most lines perform one action, making individual operations easy to follow. Reading flow: Execution proceeds naturally from construction to inspection and validation, but verbose logging interrupts the core logic, and inconsistent spacing and redundant casts introduce minor distractions.