Sample
JetBrains/e44
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 64.4Δ 46.2 |
| Scalabrino | 0.3 | 0–1; higher is more readable | 14.4Δ 3.8 |
| Dorn | 0.091 | 0–1; higher is more readable | 5.9Δ 12.3 |
| Mi | 0.009 | 0–1; higher is more readable | 2.5Δ 15.7 |
| LLOC | 4 | Logical lines; fewer is more readable | 92.8Δ 74.6 |
| DeepSeek V4 Pro | 5.33 | 0–20; mean of three runs | 0.8Δ 17.4 |
| GPT-6.1 Sol | 14 | 0–20; mean of three runs | 10.2Δ 8.1 |
| BTTF | 0.525 | 0–1; higher is more readable | 71.2Δ 53.0 |
| Human | 0.5 | 0–1; original rating | 18.2 |
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. | 417.547 | −13.779 |
| 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.686 | −7.029 |
| Source linesThe number of non-empty source lines. | 9 | +3.6 |
Intercept 8.87 + feature contributions = -8.338 (log-odds).
Score = sigmoid(-8.338) = 0.
| Score | 0.3 |
|---|
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. | 122 | −1.502 |
| 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. | 9 | +0.718 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 9 | −0.426 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 7.772 | −0.301 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.125 | −0.269 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 9 | +0.214 |
Intercept 0.07 + feature contributions = -2.301 (log-odds).
Score = sigmoid(-2.301) = 0.091.
| Score | 0.009 |
|---|
| Score | 4 |
|---|
Run 1
The code is short but suffers from several serious clarity and correctness issues. The import, class, and method structure are present, but the logic is tangled in a single-line expression that mixes BigDecimal and double calculations awkwardly. Nesting is not a major issue, but clarity of intent is poor: the code attempts to compute the golden ratio to high precision but does so incorrectly. It first calculates sqrt(5) as a double, losing precision immediately, then wraps it in BigDecimal, defeating the purpose of using BigDecimal. The setScale call is not assigned, so it has no effect on the printed output, and the deprecated rounding constant is used. The action granularity is poor because several operations are squeezed into one line, making it hard to follow. Reading flow is disrupted by the expression's density and the mismatch between intent and implementation.
Run 2
The code has a clear purpose but suffers from several readability issues. The structure is minimal but logically flat, with only one method and no helper functions, which keeps nesting low. However, the calculation for the golden ratio is tangled into a single line, making intent ambiguous and hard to follow. The use of Math.sqrt(5).add(BigDecimal.ONE) is especially problematic because Math.sqrt returns a double, not a BigDecimal, so the code doesn't compile as written and shows a fundamental confusion of types. There are multiple operations chained per line, violating action granularity and natural reading flow. The setScale call is ignored since BigDecimal is immutable, and the result is not reassigned, adding to the confusion. Finally, importing BigDecimal but then mixing it with primitive double values undermines the goal of using arbitrary precision for a 1000-decimal result.
Run 3
The code is short and has a clear intent: computing the golden ratio to 1000 decimal places. However, it has significant readability issues. The single-line calculation is dense and mixes Math.sqrt (double precision) with BigDecimal, losing precision before setting scale. The logic is flawed: `setScale` return value is discarded, and `Math.sqrt(5).add(BigDecimal.ONE)` will not compile because Math.sqrt returns double, not BigDecimal. The code also attempts to call `add` on a double, which is invalid. Action granularity is poor; multiple operations are crammed into one line. Nesting is minimal, but the flawed expression makes reading flow poor. The code structure lacks helper methods or comments. It is concise but unnecessarily complicated and incorrect, reducing clarity. Overall, while short, it is not readable due to critical errors and ambiguous mathematical logic.
Run 1
Code Structure: The class and main method are logically organized. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: The class name and phi variable suggest calculating the golden ratio, but Math.sqrt(5) returns a double, so calling add on it is invalid Java. The ignored return value from setScale also obscures the intended precision handling. Code length: The code is concise, although the calculation would be clearer with intermediate variables. Action granularity: Statements occupy separate lines, but initialization combines several operations and conversions in one dense expression. Reading flow: Calculation, scaling, and output follow a natural sequence, though the malformed expression and ineffective scaling interrupt comprehension.
Run 2
Code Structure: Simple, logically organized class with a single main method. Nesting: Minimal nesting makes it easy to scan. Clarity of intent: The class and variable names suggest calculating the golden ratio, but calling add on Math.sqrt(5), which returns a primitive double, is invalid and obscures the numeric approach. Code length: Concise, although the calculation would benefit from intermediate variables. Action granularity: Most lines perform one action, but the initialization compresses several operations and conversions into one expression. Reading flow: Calculation, scaling, and output follow a natural sequence; however, ignoring the return value of setScale makes the apparent scaling step misleading.
Run 3
Code Structure: A single class and short main method provide straightforward organization. Nesting: Minimal nesting makes the code easy to follow. Clarity of intent: The class name and phi variable indicate a golden-ratio calculation, but the expression incorrectly calls BigDecimal methods on Math.sqrt(5), which returns a double. The ignored return value of setScale also obscures whether precision adjustment is intended or achieved. Code length: Concise, though the calculation would benefit from intermediate variables. Action granularity: Each statement occupies its own line, but the initialization combines several operations into one dense expression. Reading flow: The calculate-adjust-print sequence is natural, although the invalid method chain interrupts comprehension.