Sample
int-e56f646da357-I08
Select one of ten high-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.906 | 0–1; higher is more readable |
| Dorn | 0.245 | 0–1; higher is more readable |
| Mi | 0.726 | 0–1; higher is more readable |
| LLOC | 32 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 13.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs |
| BTTF | 0.362 | 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. | 2332.299 | −76.966 |
| Source linesThe number of non-empty source lines. | 121 | +48.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.44 | −6.659 |
Intercept 8.87 + feature contributions = -26.355 (log-odds).
Score = sigmoid(-26.355) = 0.
| Score | 0.906 |
|---|
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. | 122 | −3.283 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 80 | +2.03 |
| 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.951 | −1.458 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 80 | −1.415 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 120.852 | +1.279 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 120.975 | +1.147 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.045 | +0.505 |
Intercept 0.07 + feature contributions = -1.124 (log-odds).
Score = sigmoid(-1.124) = 0.245.
| Score | 0.726 |
|---|
| Score | 32 |
|---|
Run 1
The code is generally readable but has issues. The Time interface is well-documented and methods are logically organized. However, there is a significant error: a stray code block ({ int factorial = 1; ... }) has been accidentally inserted inside the timer(Duration) method, which breaks flow and introduces unrelated logic. This severely impacts clarity and professionalism. The nesting in waitObject is moderate but acceptable, and the while(true) loops in waitObject and waitForFuture are straightforward. Method names like hiResClockMs and waitForFuture are clear. Code length is reasonable, though waitForFuture has an unnecessary timeoutException variable pattern that adds slight complexity. Action granularity is mostly one action per line. The reading flow is mostly natural but disrupted by the insertion error. Without that stray block, the code would score around 16.
Run 2
The code is well-structured and mostly readable, with clear Javadoc comments and logical organization of methods. However, there are significant flaws that lower the score: an inexplicable block of dead code inside the timer(Duration) method that computes factorial and serves no purpose in this context. The waitForFuture method has moderate nesting with a while loop and try-catch block, but the logic is reasonably clear. The waitObject method has a synchronized block with nested while loop and conditionals, though it remains understandable. Most operations follow one-action-per-line, and the method signatures are clear. The main issues are the confusing dead code block and some deep nesting in the wait methods. Overall, the code is generally readable but marred by the unexpected factorial code and slightly complex control flow in places.
Run 3
The code has clear intent and good documentation, but is undermined by a critical flaw: an unrelated, broken code fragment (`{ int factorial = 1; ... }`) was accidentally inserted inside the `timer(Duration)` method. This destroys the logical structure and interrupts the reading flow. The 'waitForFuture' method's loop and exception handling create mild nesting but remains understandable. The code length is reasonable and actions are generally granular, but the insertion of foreign code is a major readability issue. The structure would be clean and readable if the extraneous fragment were removed.
Run 1
Code Structure: The interface logically groups clock, timer, and waiting operations, but an unrelated factorial block disrupts timer(Duration). Nesting: Most methods are flat; synchronized loops and exception handling introduce moderate, manageable nesting. Clarity of intent: Descriptive names and useful documentation explain time semantics and deadlines, although the unused factorial calculation is confusing. Code length: Most implementations are concise; the factorial block adds unnecessary code, while extensive documentation is generally justified. Action granularity: Statements mostly perform one action per line, making execution easy to follow. Reading flow: Method organization and early returns support natural reading, but inconsistent indentation, the stray block, omitted braces on some conditionals, and uneven signature formatting interrupt it.
Run 2
Code Structure: The interface logically groups time operations, but an unrelated factorial block disrupts timer(Duration). Nesting: Most methods are flat; waitObject has moderate synchronized/loop/conditional nesting, and the factorial block adds unnecessary nesting. Clarity of intent: Descriptive names and helpful documentation explain clock semantics and deadlines, but the unused factorial calculation is confusing. Code length: Most implementations are concise; the factorial block adds needless code. Action granularity: Statements generally perform one action per line, supporting readability. Reading flow: Method ordering and documentation are natural overall, but inconsistent indentation in the factorial block, missing braces around some conditionals, and uneven formatting interrupt the flow.
Run 3
Code Structure: The interface logically groups time access, waiting, and timer utilities, but an unrelated factorial block disrupts timer(Duration). Nesting: Generally shallow; waitObject has moderate nesting, and the factorial block adds unnecessary depth. Clarity of intent: Descriptive method names and useful documentation clarify clock semantics and deadlines, but the unused factorial calculation is confusing. Code length: Most methods are concise; the factorial block is unnecessary, while detailed time-source documentation is justified. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Method ordering and documentation support natural reading, but inconsistent indentation, the extraneous block, and minor formatting inconsistencies interrupt it.