Sample
Scalabrio144
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 51.8Δ 48.2 |
| Scalabrino | 0.634 | 0–1; higher is more readable | 63.8Δ 36.2 |
| Dorn | 0.361 | 0–1; higher is more readable | 42.7Δ 57.3 |
| Mi | 0.287 | 0–1; higher is more readable | 55.3Δ 44.7 |
| LLOC | 10 | Logical lines; fewer is more readable | 68.6Δ 31.4 |
| DeepSeek V4 Pro | 15.33 | 0–20; mean of three runs | 66.6Δ 33.4 |
| GPT-6.1 Sol | 17.67 | 0–20; mean of three runs | 74.1Δ 25.9 |
| BTTF | 0.472 | 0–1; higher is more readable | 29.6Δ 70.4 |
| Human | 4.89 | 1–5; original rating | 100.0 |
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. | 649 | −21.417 |
| 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.188 | −6.282 |
| Source linesThe number of non-empty source lines. | 12 | +4.8 |
Intercept 8.87 + feature contributions = -14.029 (log-odds).
Score = sigmoid(-14.029) = 0.
| Score | 0.634 |
|---|
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 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| 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. | 103 | −0.697 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| 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. | 9.788 | −0.273 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.091 | +0.059 |
Intercept 0.07 + feature contributions = -0.569 (log-odds).
Score = sigmoid(-0.569) = 0.361.
| Score | 0.287 |
|---|
| Score | 10 |
|---|
Run 1
The code is reasonably structured for a debugging/logging method, but it relies heavily on repetitive print statements with hardcoded separator lines, making it verbose and harder to maintain. There is no nesting, so that aspect is strong. Intent is clear—comparing SQL and suffixes between a walker and query details—but the method name 'compare' is vague since it only prints data. Action granularity is one action per line, which is good, but the long concatenations across multiple lines reduce readability. Reading flow is natural, but the excessive separator lines and redundant println calls clutter the output. The method could be improved by extracting a helper for formatting or using a logging framework, and by using more descriptive naming or comments to clarify purpose.
Run 2
The code is moderately readable, scoring well on action granularity and reading flow since each print statement is on its own line and follows a logical sequence. The structure is recognizable as a debug/diagnostic method, clearly separating SQL and suffix sections with visual dividers. However, the method loses points for clarity of intent—its purpose ('compare') is not evident from the method name or output labels, and there's no explanation of why things are being compared or what constitutes a difference. Nesting is flat, which is good, but the long string concatenation lines and heavy use of System.out.println make it verbose and somewhat cumbersome. The repeated print statements could be consolidated using a helper method or formatted output. Overall, the code is readable in a straightforward procedural way, but lacks semantic clarity and conciseness.
Run 3
The method is logically organized into clearly labeled sections for SQL and suffixes, making the intent easy to follow. Nesting is minimal and the reading flow is natural. However, readability is somewhat reduced by the repeated System.out.println calls and manual separator lines, which make the code longer than necessary. Additionally, some lines are quite long and combine multiple string concatenations, slightly lowering action granularity. Using a helper method or a more structured output approach could further improve readability.
Run 1
Code Structure: Output is logically organized into clearly labeled SQL and suffix sections. Nesting: The method is flat, with no conditional or loop nesting. Clarity of intent: The compare method and WALKER/LOAD-PLAN labels clearly indicate diagnostic comparison, although the suffix section displays only walker values. Code length: Short overall, but repeated separators and print statements introduce minor verbosity. Action granularity: Each statement performs one output action; the suffix statement combines several values but remains understandable. Reading flow: Output proceeds naturally from SQL to suffixes, with blank lines separating sections. The long separator literals and uneven alignment of the continued concatenation slightly reduce readability.
Run 2
Code Structure: Output is logically grouped into SQL and suffix sections. Nesting: The method is flat, with no nested control flow. Clarity of intent: Labels clearly identify the compared SQL sources, though the generic method name and walker-only suffix output slightly obscure its scope. Code length: Short and focused, but repeated separators and print statements add minor verbosity. Action granularity: Each statement performs one printing action; the suffix statement combines two related values in a readable expression. Reading flow: Sequential output and blank lines create a natural progression, although the heavily indented continuation line slightly disrupts visual consistency.
Run 3
Code Structure: Output is logically grouped into SQL and suffix sections, although repeated separator statements add clutter. Nesting: The method is flat, with no nested control flow. Clarity of intent: Labels clearly identify diagnostic output, but compare is slightly misleading because the method prints values rather than comparing them, and suffixes are shown only for the walker. Code length: Short overall, though repetitive printing and long separator literals could be simplified. Action granularity: Each statement performs one printing action; the suffix statement combines several formatting operations but remains understandable. Reading flow: Output proceeds naturally from SQL to suffixes, with blank lines separating sections; the long wrapped concatenation slightly disrupts scanning.