Sample
int-9fa904bc03d4-I11
Split eligible integer literals into pairs of short-named intermediate variables
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 has a clear, logical structure as a small interface with two related methods and a constant. Javadoc comments effectively explain the intent, usage, and constraints of each element. Nesting is flat, and the code is concise without being too terse; each method and constant is defined on its own line, maintaining action granularity. The reading flow is natural: the constant is presented first, followed by the getter and setter overloads of the same method name. Minor deductions are for a slightly ambiguous note about undefined behavior and repetition in comments, but overall the clarity is excellent.
Run 3
The code is highly readable with a clear, logical structure. The interface defines a single, focused contract for priority queue nodes, with each method documented concisely. Nesting is non-existent, keeping the code flat and easy to scan. Intent is explicit through descriptive method names and Javadoc comments that explain usage, edge cases, and the purpose of the INDEX_NOT_IN_QUEUE constant. Code length is minimal and appropriate for the functionality provided. Each method declaration occupies its own line, contributing to clear action granularity. Reading flow is natural: constant, getter, setter, mirroring typical state management patterns. Minor deductions are for the slightly verbose Javadoc (though still valuable) and the lack of a default method for the constant, but overall readability is excellent.
Run 1
Code Structure: The interface is logically organized, with an initialization constant followed by getter and setter declarations. Nesting: There is no nested control flow, making the code easy to scan. Clarity of intent: Descriptive interface and method names, linked Javadoc, and explicit exception warnings clearly explain its internal-state role; the setter parameter name 'i' is slightly vague. Code length: The interface is concise, with documentation proportional to its API responsibilities. Action granularity: Each declaration occupies its own line and represents a single responsibility. Reading flow: The progression from interface purpose to sentinel value to index access and mutation is natural and consistent.
Run 2
Code Structure: The interface logically groups a sentinel constant and related index getter/setter methods. Nesting: Entirely flat, with no nested control flow. Clarity of intent: Class and method documentation clearly explain queue-state maintenance and exception constraints; the overloaded method name and terse parameter 'i' slightly reduce immediate clarity. Code length: Compact, with documentation proportionate to the API's contract. Action granularity: Each declaration occupies its own line and expresses a single responsibility. Reading flow: Natural progression from interface purpose to initialization constant, getter, and setter, with consistent formatting.
Run 3
Code Structure: The interface logically groups a sentinel constant and two related index-access methods. Nesting: No nested logic; declarations are flat and easy to scan. Clarity of intent: Javadoc clearly explains the interface’s purpose, queue-specific state, and exception restrictions. However, overloading the same name for getter and setter is slightly less explicit than distinct names, and parameter 'i' is terse. Code length: Compact, with documentation proportionate to the API’s responsibilities. Action granularity: Each declaration occupies its own line, with no bundled operations. Reading flow: The progression from interface purpose to initialization constant, getter, and setter is natural and consistent.