Sample
JetBrains/b10
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 11.0Δ 9.3 |
| Scalabrino | 0.268 | 0–1; higher is more readable | 12.7Δ 11.0 |
| Dorn | 0.46 | 0–1; higher is more readable | 37.3Δ 35.6 |
| Mi | 0.495 | 0–1; higher is more readable | 51.7Δ 50.0 |
| LLOC | 24 | Logical lines; fewer is more readable | 11.4Δ 9.7 |
| DeepSeek V4 Pro | 13 | 0–20; mean of three runs | 23.3Δ 21.6 |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs | 15.3Δ 13.6 |
| BTTF | 0.295 | 0–1; higher is more readable | 8.5Δ 6.8 |
| Human | 0.32 | 0–1; original rating | 1.7 |
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. | 1241.238 | −40.961 |
| 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. | 4.017 | −6.026 |
Intercept 8.87 + feature contributions = -26.917 (log-odds).
Score = sigmoid(-26.917) = 0.
| Score | 0.268 |
|---|
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. | 1 | +1.001 |
| 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. | 64.821 | +0.92 |
| 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 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.137 | −0.387 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 28 | −0.222 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 26.788 | −0.035 |
Intercept 0.07 + feature contributions = -0.16 (log-odds).
Score = sigmoid(-0.16) = 0.46.
| Score | 0.495 |
|---|
| Score | 24 |
|---|
Run 1
The code is reasonably structured and follows a clear linear flow, but several readability issues prevent a higher score. The logic is understandable: find vampire numbers in a range by checking factor pairs whose concatenated digits match the original number. However, there is a missing import for java.util.Arrays, and method extraction would improve intent clarity. The code uses multiple nested loops and conditionals, but nesting depth is moderate (2–3 levels). Variable names like s, s1, s2, arr1, arr2 are vague and reduce clarity. Action granularity is mixed—some lines combine operations (e.g., char[] arr1 = str.toCharArray()), but mostly one action per line. The overall reading flow is acceptable, though the repeated digit-sorting comparison could be a helper method. Terseness is good, but at the cost of self-documentation.
Run 2
The code is logically organized but lacks helper methods, so the main method handles all work. Nesting is moderate: two for-loops and several if-continue statements avoid deep indentation, though the inner block has multiple consecutive conditionals. Intent is fairly clear—finding vampire numbers—but the algorithm is not explained and variable names like s1, s2, s, arr1, arr2 are vague. Code length is concise for the task. Action granularity is mostly one action per line, but lines like 'int len = str.length();' and chained sorting could be slightly clearer. Reading flow is mostly linear, but the early loop from 10 to sqrt(num) may seem non-obvious without comments. Overall, the code is understandable to experienced readers but lacks explanatory structure and descriptive naming.
Run 3
The code has a clear overall purpose (finding vampire numbers) and uses simple, linear logic, but readability is compromised by several factors. The structure is a single method with nested loops and multiple conditional continues, creating moderate nesting. Clarity of intent is weakened by terse variable names (str, len, s1, fang1) and lack of comments explaining the 'vampire number' rule. Action granularity is generally good—one action per line—but some lines combine logic (e.g., the for-loop condition with Math.sqrt). Reading flow is disrupted by the repeated early continues and the absence of helper methods. The code is concise but would benefit from extracting the digit-anagram check into a named function and adding a brief comment explaining the algorithm to improve maintainability.
Run 1
Code Structure: The search follows a logical sequence, but all logic resides in main rather than named helper methods. Nesting: Two nested loops and a final conditional create moderate depth; early continue statements avoid further nesting. Clarity of intent: The class name and fang variables suggest the purpose, though abbreviated names such as s, s1, and arr1 obscure the digit comparison. Code length: Compact and mostly necessary, with little redundant code. Action granularity: Each statement performs one clear action, making individual steps easy to follow. Reading flow: Candidate selection, factor validation, digit comparison, and output occur naturally, but missing braces on conditional statements, inconsistent operator spacing, and no visual separation between stages reduce readability.
Run 2
Code Structure: The search is logically organized, but all filtering and digit comparison are embedded in main rather than extracted into helpers. Nesting: Two loops and a final conditional create moderate nesting; early continues avoid deeper branches. Clarity of intent: VampireNumbers and fang names convey the purpose, though abbreviated variables such as s, s1, and arr1 obscure intermediate roles. Code length: Compact and mostly necessary, with some repetitive string conversions. Action granularity: Each statement performs a distinct action, making operations easy to follow. Reading flow: Candidate generation, factor filtering, digit comparison, and output follow a natural sequence. Inconsistent spacing and omitted braces around single-line conditionals slightly reduce scanability.
Run 3
Code Structure: Logically organized as a sequential candidate-and-factor search, but extracting digit comparison into a helper would improve organization. Nesting: Two nested loops and a final conditional create moderate nesting; early continues avoid deeper branches. Clarity of intent: VampireNumbers and fang names convey the purpose, though abbreviated variables such as str, s, and arr1 obscure details, and the filtering rules lack explanation. Code length: Compact without substantial unnecessary code. Action granularity: Each statement performs a distinct action on its own line. Reading flow: Checks proceed naturally from number length to divisibility, factor lengths, and digit matching. Inconsistent spacing and omitted braces on conditional statements slightly reduce readability.