Sample
JetBrains/i13
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.002 | 0–1; higher is more readable | 74.6Δ 6.4 |
| Scalabrino | 0.743 | 0–1; higher is more readable | 58.5Δ 22.5 |
| Dorn | 0.568 | 0–1; higher is more readable | 61.0Δ 19.9 |
| Mi | 0.539 | 0–1; higher is more readable | 61.0Δ 19.9 |
| LLOC | 7 | Logical lines; fewer is more readable | 85.2Δ 4.2 |
| DeepSeek V4 Pro | 17.33 | 0–20; mean of three runs | 78.8Δ 2.1 |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs | 77.5Δ 3.4 |
| BTTF | 0.54 | 0–1; higher is more readable | 75.4Δ 5.5 |
| Human | 0.9 | 0–1; original rating | 80.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. | 415.11 | −13.699 |
| 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.136 | −6.204 |
| Source linesThe number of non-empty source lines. | 12 | +4.8 |
Intercept 8.87 + feature contributions = -6.232 (log-odds).
Score = sigmoid(-6.232) = 0.002.
| Score | 0.743 |
|---|
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. | 57 | +1.251 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 12 | +0.611 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.14 | −0.42 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 12 | −0.322 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 10.759 | −0.259 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 12 | +0.145 |
Intercept 0.07 + feature contributions = 0.272 (log-odds).
Score = sigmoid(0.272) = 0.568.
| Score | 0.539 |
|---|
| Score | 7 |
|---|
Run 1
The code is highly readable. It has a clear, logical structure: a simple class with a main method containing a straightforward loop. Nesting is minimal (one level inside a for-loop and an if-statement). Intent is obvious — identify and print 'evil numbers' (numbers with an even count of 1s in binary). Code length is concise with no unnecessary boilerplate. Each line performs one logical action, and reading flow is natural: loop → convert to binary → count ones → check parity → print. The only minor deductions are the lack of an explanatory comment for the 'evil number' concept and the regex-based counting approach, which is slightly less efficient than bit manipulation but still very clear.
Run 2
The code is clear, concise, and well-structured. It has a flat, single-level loop with no unnecessary nesting. The intent—to print 'evil' numbers (numbers with an even number of 1s in binary) from 0 to 1000—is evident from the logic. Each action is on its own line, and the flow reads naturally: convert to binary, count ones, check parity, print. Variable names are descriptive. Minor improvements could include extracting the counting logic into a helper method for improved modularity, but for a small script this is not necessary.
Run 3
The code is concise and easy to read. It has a flat structure with no nested blocks beyond the loop and conditional, good action granularity (each line does one main thing), and clear intent: list numbers whose binary representation has an even number of 1s. Naming is adequate—`EvilNumber`, `binary`, `ones` are understandable, though a comment or more descriptive variable like `oneCount` might improve clarity. The replaceAll approach is simple but slightly indirect; using bit manipulation or a counting loop could improve both readability and performance, but it does not harm clarity here. Overall, the code is well-structured and readable for its small scope.
Run 1
Code Structure: A single class and method organize a straightforward loop logically. Nesting: The loop and conditional introduce only shallow, easily followed nesting. Clarity of intent: Descriptive variables make binary conversion and counting ones clear, though the definition of an evil number and the upper limit of 1000 are unexplained. Code length: The implementation is concise without unnecessary code. Action granularity: Each statement performs one focused step. Reading flow: Iterating, converting, counting, checking parity, and printing follow a natural sequence.
Run 2
Code Structure: Logically organized in a single main method, with conversion, counting, filtering, and output in sequence. Nesting: Shallow and easy to follow, using only a loop and a conditional. Clarity of intent: The binary and ones variables clearly convey their roles, though the meaning of an evil number and the inclusive limit of 1000 are not explained. Code length: Concise, with no unnecessary code. Action granularity: Each statement performs a distinct step; the chained replacement and length operations are compact but understandable. Reading flow: Natural top-to-bottom progression with consistent indentation. Counting bits through string replacement is slightly less direct than a dedicated bit-counting operation, but remains readable.
Run 3
Code Structure: A single class and main method organize the task logically. Nesting: The loop and conditional introduce only modest, easily followed nesting. Clarity of intent: Descriptive variables make the binary conversion and counting understandable, although the class name assumes familiarity with evil numbers and the 1000 limit is unexplained. Code length: The implementation is concise without unnecessary boilerplate beyond Java requirements. Action granularity: Each statement performs a focused action; the chained replacement and length calculation remain readable. Reading flow: The sequence naturally progresses from iteration to conversion, counting, filtering, and output.