Sample
JetBrains/e63
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 11.9Δ 5.9 |
| Scalabrino | 0.209 | 0–1; higher is more readable | 7.6Δ 1.7 |
| Dorn | 0.199 | 0–1; higher is more readable | 14.4Δ 8.5 |
| Mi | 0.285 | 0–1; higher is more readable | 22.0Δ 16.1 |
| LLOC | 15 | Logical lines; fewer is more readable | 43.6Δ 37.7 |
| DeepSeek V4 Pro | 12.67 | 0–20; mean of three runs | 20.8Δ 14.8 |
| GPT-6.1 Sol | 14.33 | 0–20; mean of three runs | 12.7Δ 6.8 |
| BTTF | 0.547 | 0–1; higher is more readable | 78.0Δ 72.0 |
| Human | 0.39 | 0–1; original rating | 5.9 |
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. | 1162.89 | −38.375 |
| Source linesThe number of non-empty source lines. | 28 | +11.2 |
| Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value. | 3.88 | −5.82 |
Intercept 8.87 + feature contributions = -24.126 (log-odds).
Score = sigmoid(-24.126) = 0.
| Score | 0.209 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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 |
| 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. | 74 | +0.531 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.125 | −0.275 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 28 | −0.222 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 28 | +0.045 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 26.653 | −0.037 |
Intercept 0.07 + feature contributions = -1.395 (log-odds).
Score = sigmoid(-1.395) = 0.199.
| Score | 0.285 |
|---|
| Score | 15 |
|---|
Run 1
The code has some positive aspects: it uses a clear data-driven approach with the SEGMENTS array, the main method is reasonably flat, and variable names are mostly descriptive. However, there are significant readability issues. First, the SEGMENTS array layout does not visually map to actual seven-segment display patterns — characters are positioned in a confusing 3x7 grid, making it hard to interpret what each segment represents. Second, the indexing logic using `c - '0'` assumes ASCII ordering and would silently produce wrong output for non-digit characters; no validation exists. Third, the nested loops are not deeply nested but the inner logic mixes indexing, character conversion, and concatenation in a way that obscures intent. The code also lacks helper methods or comments to explain the rendering approach. Overall, it is understandable but requires careful mental mapping to grasp the visual output, reducing its readability.
Run 2
The code has a clear overall structure with a static SEGMENTS array and a simple main method. However, the segment data is incorrect and doesn't form valid 7-segment digits, making the intent ambiguous. The SEGMENTS array is declared as [7][3] but indexed as [i][index] where index is a digit 0-9, which would cause an ArrayIndexOutOfBoundsException for digits 3-9. Loops are nested two levels deep, which is acceptable, but the reading flow suffers because the relationship between rows and digit positions is not explained. The code is concise but contains a critical bug. Variable names 'i', 'j', 'c', and 'index' are too generic. Action granularity is reasonable with one operation per line, but the lack of comments or named constants for dimensions makes it harder to follow.
Run 3
The code is simple and concise, with clear intent and a flat structure. However, several issues reduce readability: the SEGMENTS array is confusing because it appears to represent three columns per digit but uses only indices 0-9 for digits, cutting off letters A-F. The variable name 'c' is ambiguous; a clearer name like 'digitChar' would help. The nested loop is easy to follow but could be improved with a helper method per row. Action granularity is good, but reading flow is slightly unnatural because the outer loop iterates rows while inner loops columns, making it hard to see the final output shape. Handling non-digit characters robustly would also improve clarity.
Run 1
Code Structure: The constant segment table and main method are logically separated, with input checking before rendering. Nesting: Two nested loops are manageable and appropriate for row-by-row output. Clarity of intent: The class name, usage message, and StringBuilder indicate the purpose, but generic names such as i, j, and index obscure the row/digit relationship. More importantly, SEGMENTS has seven rows and only three columns, yet digits index its columns; this mismatch makes the intended representation confusing. Code length: Compact without unnecessary repetition in the control flow. Action granularity: Each statement performs a single clear operation. Reading flow: Execution proceeds naturally from argument checking to character conversion, line construction, and printing, although the unexplained table layout interrupts understanding.
Run 2
Code Structure: Clearly separates segment data from execution, though rendering remains entirely in main. Nesting: Two nested loops are shallow and easy to follow. Clarity of intent: The class name, usage message, and variable names communicate the goal, but SEGMENTS has seven rows and only three columns while index represents digits 0–9; this mismatch makes the intended representation confusing. Code length: Compact without unnecessary verbosity. Action granularity: Each statement performs a distinct operation, making execution easy to trace. Reading flow: Naturally progresses from argument checking to input extraction, rendering, and output. Overall, the straightforward organization supports readability, but the unclear segment mapping and unexplained data layout significantly weaken understanding.
Run 3
Code Structure: The class separates display data from execution logic, with straightforward argument checking and rendering. Nesting: Two nested loops are reasonable for rendering rows and digits, and the early return avoids additional nesting. Clarity of intent: The class name, usage message, and variable names convey the goal, but SEGMENTS has seven rows of three elements while index can range from 0 to 9, making the intended digit mapping unclear. Code length: Compact without unnecessary repetition in the execution logic. Action granularity: Each statement performs a focused action, although loop headers conventionally combine initialization, testing, and incrementing. Reading flow: Execution proceeds naturally from validation to input extraction, rendering, and output. Overall, the code is easy to follow locally, but the confusing data representation and lack of digit validation undermine confidence in understanding its behavior.