Sample
int-a1c7cfb558fb-I09
Select one of ten low-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.999 | 0–1; higher is more readable |
| Scalabrino | 0.791 | 0–1; higher is more readable |
| Dorn | 0.795 | 0–1; higher is more readable |
| Mi | 0.296 | 0–1; higher is more readable |
| LLOC | 2 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 19 | 0–20; mean of three runs |
| BTTF | 0.776 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 29 | +11.6 |
| 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.655 | −6.983 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 206.716 | −6.822 |
Intercept 8.87 + feature contributions = 6.666 (log-odds).
Score = sigmoid(6.666) = 0.999.
| Score | 0.791 |
|---|
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. | 117.967 | −1.331 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 114.167 | +1.038 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 1 | +1.001 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.02 | +0.75 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 13 | −0.287 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 13 | +0.123 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 28.773 | −0.008 |
Intercept 0.07 + feature contributions = 1.354 (log-odds).
Score = sigmoid(1.354) = 0.795.
| Score | 0.296 |
|---|
| Score | 2 |
|---|
Run 1
The code is highly readable with clear structure and intent. It defines a small interface with two overloaded methods and a constant, logically organized with Javadoc explaining purpose and constraints. Nesting is nonexistent, and the flat structure aids comprehension. Clarity of intent is strong: method names and documentation clearly describe their roles in maintaining queue state. Code length is concise—no unnecessary complexity or verbosity. Action granularity follows interface conventions, with each method declaration on separate lines. Reading flow is natural: constant declaration, getter, setter. Minor deductions for relying on Javadoc to explain 'undefined behavior' rather than encoding constraints in the type system, and for the slightly ambiguous wording in the first method's documentation.
Run 2
The code is highly readable. It is a clean, well-documented interface with a clear single responsibility: defining a contract for priority queue node index management. Structure is logical and flat, with no nesting. Intent is clear from method names and Javadoc, which explains purpose, usage, and edge cases. Length is concise—no unnecessary members or abstraction. Action granularity is one operation per method declaration, supporting straightforward reading flow. Javadoc slightly increases verbosity but meaningfully clarifies behavior, especially regarding exceptions and the INDEX_NOT_IN_QUEUE constant.
Run 3
The code is highly readable. It is a small, well-structured interface with clear Javadoc comments explaining the purpose and usage of each method and constant. The naming is descriptive and consistent, and there is no nesting or unnecessary length. Each method and constant serves a single, well-documented action. The reading flow is natural, moving from constant declaration to getter and setter methods. Minor deductions are only for the slightly terse mention of undefined behavior, though this is acceptable for internal API documentation.
Run 1
Code Structure: A focused interface cleanly groups the sentinel constant and related getter/setter methods. Nesting: No nested logic, making the code easy to scan. Clarity of intent: Descriptive names and Javadoc explain the queue-specific index and usage restrictions; the setter parameter 'i' could be more descriptive. Code length: Concise declarations with appropriately scoped documentation. Action granularity: Each declaration occupies its own line and represents one responsibility. Reading flow: The interface description, initialization constant, getter, and setter follow a natural order. Minor documentation awkwardness and identical getter/setter names slightly reduce immediate clarity.
Run 2
Code Structure: The interface logically groups a sentinel constant with related getter and setter declarations. Nesting: Flat declarations introduce no control-flow nesting. Clarity of intent: Descriptive interface and method names, linked documentation, and exception warnings clearly explain the internal queue-index contract; the setter parameter name 'i' is less descriptive than 'index'. Code length: The implementation is minimal, with documentation adding useful context rather than unnecessary bulk. Action granularity: Each constant or method declaration occupies its own line and expresses a single responsibility. Reading flow: The progression from interface purpose to initialization constant, getter, and setter is natural and easy to follow.
Run 3
Code Structure: A focused interface logically groups a sentinel constant and two related index-access methods. Nesting: No nested control flow; the structure is flat and easy to scan. Clarity of intent: Descriptive names and Javadoc explain the interface's internal-state role, queue-specific indexing, and exception constraints. The overloaded getter/setter names and terse parameter name 'i' slightly reduce immediate clarity. Code length: Compact, with documentation proportionate to the API. Action granularity: Each constant or method declaration occupies its own line, with no combined actions. Reading flow: The progression from interface purpose to initialization constant, getter, and setter is natural and coherent.