Sample

int-b3d148e58235-I07

Insert deterministic runtime-dead branches into callable bodies

Matched original source

Lines29

Scores

MethodScoreScale
Posnett0.9990–1; higher is more readable
Scalabrino0.7910–1; higher is more readable
Dorn0.7950–1; higher is more readable
Mi0.2960–1; higher is more readable
LLOC2Logical lines; fewer is more readable
DeepSeek V4 Pro17.330–20; mean of three runs
GPT-6.1 Sol190–20; mean of three runs
BTTF0.7760–1; higher is more readable

Views

Source code

package io.netty.util.internal; /** * Provides methods for {@link DefaultPriorityQueue} to maintain internal state. These methods should generally not be * used outside the scope of {@link DefaultPriorityQueue}. */ public interface PriorityQueueNode { /** * This should be used to initialize the storage returned by {@link #priorityQueueIndex(DefaultPriorityQueue)}. */ int INDEX_NOT_IN_QUEUE = -1; /** * Get the last value set by {@link #priorityQueueIndex(DefaultPriorityQueue, int)} for the value corresponding to * {@code queue}. * <p> * Throwing exceptions from this method will result in undefined behavior. */ int priorityQueueIndex(DefaultPriorityQueue<?> queue); /** * Used by {@link DefaultPriorityQueue} to maintain state for an element in the queue. * <p> * Throwing exceptions from this method will result in undefined behavior. * @param queue The queue for which the index is being set. * @param i The index as used by {@link DefaultPriorityQueue}. */ void priorityQueueIndex(DefaultPriorityQueue<?> queue, int i); }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(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.

Score0.791

Feature contributions

FeatureValueContribution
(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.

Score0.296
Score2
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 well-structured interface with a clear purpose: defining the contract for priority queue nodes. The structure is logical, with fields and methods clearly separated and documented. Nesting is minimal—just an interface with two methods. Each method has clear intent, and the Javadoc gives helpful context. Code length is concise, containing only the essential methods and constant. Action granularity is appropriate, with one action per line. Reading flow is natural, especially due to the descriptive Javadoc. The only minor deduction is that the Javadoc is slightly verbose for such a simple interface, which slightly impacts conciseness.

Run 3

The code is well-structured as a clean interface with clear separation of concerns, focused on maintaining queue state. It has no nesting and remains flat, which aids readability. The intent is explicit: storing and retrieving priority queue indices, and the Javadoc enhances clarity by explaining usage and edge cases like undefined behavior on exceptions. The code is concise, containing only two methods and one constant, with no unnecessary verbosity. Each method signature and constant declaration is on its own line, respecting action granularity. Reading flow is natural: the constant precedes the getter and setter methods logically. Minor deductions arise from the slightly abstract nature of the 'undefined behavior' warning and the use of generic wildcard, which might require prior familiarity with Netty internals.

Run 1

Code Structure: The interface logically groups a sentinel constant and two related index-access methods. Nesting: There is no nested control flow, making the code easy to scan. Clarity of intent: Javadocs clearly explain queue-specific state management and usage restrictions, though the overloaded getter/setter names and parameter name 'i' are slightly less explicit than alternatives. Code length: The interface is concise, with documentation proportionate to its API contract. 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 consistent.

Run 2

Code Structure: The interface logically groups a sentinel constant and paired index getter/setter methods. Nesting: No nested control flow or implementation blocks complicate reading. Clarity of intent: Descriptive names and Javadoc clearly explain queue-specific state and usage constraints; the setter parameter 'i' could be more descriptive. Code length: The interface is concise, with documentation proportionate to its contract. Action granularity: Each declaration occupies its own line and represents one responsibility. Reading flow: The package, interface description, constant, getter, and setter follow a natural order. Overloaded getter/setter naming is understandable, though explicit accessor names could marginally improve scanning.

Run 3

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 names and Javadoc clearly explain the queue-index contract and exception constraints, though the setter parameter 'i' is less descriptive than 'index'. Code length: The interface is concise, with documentation proportionate to its small API. Action granularity: Each declaration occupies its own line and expresses a single responsibility. Reading flow: The progression from interface purpose to constant, retrieval, and update is natural. Using the same method name for getter and setter slightly reduces immediate distinction, but their signatures and documentation resolve the ambiguity.