Sample
int-1e22a714520d-I08
Select one of ten high-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 small, well-organized interface with clear naming and logical separation. Structure is clean, with no nesting and a single responsibility per method. Javadoc comments explain intent and contract, including edge cases (e.g., exceptions leading to undefined behavior). Action granularity is ideal—one operation per line, and the constant is clearly defined. The only minor drawbacks are the slightly verbose comments and the generic wildcard parameter, which may require domain knowledge. Overall, the code is concise, natural to follow, and maintainable.
Run 3
The code is a small, well-structured interface with clear intent and high readability. It is logically organized with related members grouped together. Nesting is absent, and the structure is flat. Each method serves a distinct purpose, and the documentation clearly explains the intended use and constraints. The code is concise and avoids unnecessary length. Action granularity is not applicable as the interface contains only method signatures and a constant. Reading flow is natural, moving from the constant to the getter and then the setter. Minor deductions for slightly repetitive parameter names and the presence of exception warnings that could be expressed more concisely, but overall the code is highly readable.
Run 1
Code Structure: The interface is logically organized, with an initialization constant followed by related getter and setter declarations. Nesting: There is no nested control flow, making scanning effortless. Clarity of intent: Descriptive names and Javadoc clearly explain the queue-state contract and exception restrictions, though the setter parameter 'i' could be named 'index' for greater clarity. Code length: The interface is concise, with documentation proportionate to its public contract. Action granularity: Each declaration occupies its own line and expresses a single responsibility. Reading flow: The progression from interface purpose to sentinel value and index accessors is natural; matching getter and setter names reinforce their relationship.
Run 2
Code Structure: The interface logically groups a sentinel constant and two related index-access methods. Nesting: It is flat, with no nested control flow. Clarity of intent: Javadoc clearly explains the interface’s internal purpose, queue-specific index storage, and exception restrictions; the setter parameter name 'i' is slightly less descriptive than 'index'. Code length: The code is concise, and its documentation is relevant rather than excessive. Action granularity: Each declaration occupies its own line, with no combined operations. Reading flow: The progression from interface purpose to initialization constant, getter, and setter is natural and easy to follow.
Run 3
Code Structure: The interface logically groups a sentinel constant and related index getter/setter methods. Nesting: It is flat, with no nested control flow. Clarity of intent: Javadocs clearly explain queue-specific state, initialization, and exception constraints; however, the overloaded getter/setter names and parameter name 'i' are slightly less explicit than alternatives. Code length: The interface is concise, with documentation proportional to its contract. Action granularity: Each declaration occupies its own line and expresses one responsibility. Reading flow: The progression from interface purpose to constant, getter, and setter is natural and easy to follow.