Sample
int-b548e2baa90b-I09
Select one of ten low-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.897 | 0–1; higher is more readable |
| Dorn | 0.255 | 0–1; higher is more readable |
| Mi | 0.31 | 0–1; higher is more readable |
| LLOC | 33 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 11.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15.33 | 0–20; mean of three runs |
| BTTF | 0.311 | 0–1; higher is more readable |
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. | 2370.587 | −78.229 |
| Source linesThe number of non-empty source lines. | 116 | +46.4 |
| 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.527 | −6.79 |
Intercept 8.87 + feature contributions = -29.75 (log-odds).
Score = sigmoid(-29.75) = 0.
| Score | 0.897 |
|---|
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. | 117 | −3.106 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 75 | +1.857 |
| 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. | 120.974 | −1.459 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 75 | −1.3 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 115.836 | +1.209 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 120.957 | +1.147 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.044 | +0.511 |
Intercept 0.07 + feature contributions = -1.07 (log-odds).
Score = sigmoid(-1.07) = 0.255.
| Score | 0.31 |
|---|
| Score | 33 |
|---|
Run 1
The code is generally well-structured with clear method separation and good Javadoc documentation, which improves readability. However, there is a glaring issue: an obfuscated line of dead code inside the `hiResClockMs()` method that serves no purpose and significantly harms clarity. The `waitObject` method uses an infinite `while(true)` loop with multiple exit points, making the control flow harder to follow than a more direct condition-based loop. The `waitForFuture` method also uses an infinite loop and a somewhat convoluted approach to rethrowing a timeout exception, which reduces clarity. Nesting is moderate, with one synchronized block and one try-catch inside loops. Overall, the code is maintainable but could be improved by removing the obfuscated code, simplifying loop conditions, and streamlining the timeout handling logic.
Run 2
The code is generally well-structured and documented, but readability is severely damaged by a confusing, obfuscated unreachable loop in the `hiResClockMs()` method. This block significantly obscures intent and breaks the reading flow. The `waitObject` and `waitForFuture` methods use infinite loops with multiple exit conditions, adding moderate nesting and making the logic harder to follow at a glance. While the code is concise overall and each line performs a single action, the presence of the misleading loop and the tight looping constructs reduce clarity. The Javadocs are helpful, but they cannot compensate for the unnecessary complexity in a few key methods.
Run 3
The code is generally well-structured, with clear method names and Javadoc explaining intent. However, readability is significantly hurt by an obfuscated block of dead code in `hiResClockMs()`, which serves no purpose and disrupts the reading flow. The `waitObject` method is somewhat deeply nested (synchronized block containing a while loop and multiple conditionals), though each action is on its own line and the logic is understandable. The `waitForFuture` method has a loop with a somewhat complex timeout handling pattern, but it remains reasonably clear. Overall, the code is functional and mostly readable but the unnecessary obfuscated block and occasional nesting reduce the score.
Run 1
Code Structure: Methods are logically organized within a focused time abstraction, although an unrelated block disrupts hiResClockMs. Nesting: Generally shallow; waitObject has moderate, understandable nesting, while the injected do-while block adds unnecessary complexity. Clarity of intent: Descriptive method names and helpful documentation make most behavior clear, but cryptic variable names and meaningless operations obscure the injected block's purpose. Code length: Mostly concise, with appropriate documentation; the extraneous block adds avoidable code. Action granularity: Most statements occupy separate lines, but the injected block compresses declarations, assignments, and control flow onto one line. Reading flow: Consistent formatting and straightforward methods support natural reading, except for the abrupt, unindented obfuscation in hiResClockMs.
Run 2
Code Structure: The interface logically groups clock access, waiting, and timer creation, but hiResClockMs contains an unrelated obfuscated block. Nesting: Most methods are flat; synchronized waiting and retry loops have moderate, manageable nesting. Clarity of intent: Descriptive method names and documentation make the API clear, while meaningless variable names and redundant operations obscure the injected block's purpose. Code length: Most implementations are concise, but the no-op block adds unnecessary code. Action granularity: Normal code generally uses one action per line; the injected block compresses declarations, assignments, and a loop onto one line. Reading flow: Methods and comments follow a natural sequence, but the unindented obfuscated block sharply interrupts otherwise consistent formatting.
Run 3
Code Structure: The interface logically groups clock access, waiting, and timer creation into focused methods. Nesting: Mostly shallow; synchronized and loop blocks in waitObject introduce manageable nesting. Clarity of intent: Descriptive method names and useful documentation explain the API, but the meaningless variables and do-while block in hiResClockMs obscure an otherwise simple conversion. Code length: Most methods are concise, though the injected block adds unnecessary code. Action granularity: Most statements occupy separate lines; the injected block compresses several declarations and operations into one line, substantially reducing readability locally. Reading flow: Method organization and consistent formatting generally support natural reading, but the unindented, obfuscated block interrupts that flow. Overall, the code is readable apart from a conspicuous and distracting fragment.