Sample

int-9d73e963dfaf-I08

Select one of ten high-readability unrelated code templates per class

Matched original source

Lines31

Scores

MethodScoreScale
Posnett0.9160–1; higher is more readable
Scalabrino0.8910–1; higher is more readable
Dorn0.8250–1; higher is more readable
Mi0.5080–1; higher is more readable
LLOC1Logical lines; fewer is more readable
DeepSeek V4 Pro17.670–20; mean of three runs
GPT-6.1 Sol190–20; mean of three runs
BTTF0.7320–1; higher is more readable

Views

Source code

package org.springframework.test.web.reactive.server; import org.jspecify.annotations.Nullable; import org.springframework.http.client.reactive.ClientHttpConnector; import org.springframework.web.server.adapter.WebHttpHandlerBuilder; /** * Contract to encapsulate customizations to a {@link WebTestClient.Builder}. * Typically used by frameworks that wish to provide a shortcut for common * initialization. * * @author Rossen Stoyanchev * @since 5.0 * @see MockServerConfigurer */ public interface WebTestClientConfigurer { /** * Use methods on {@link WebTestClient.Builder} to modify test client * settings. For a mock WebFlux server, use {@link WebHttpHandlerBuilder} * to customize server configuration. For a MockMvc server, mutate the * {@link org.springframework.test.web.servlet.client.MockMvcHttpConnector} * and set it on {@link WebTestClient.Builder}. * @param builder the WebTestClient builder for test client changes * @param httpHandlerBuilder for mock WebFlux server settings * @param connector the connector in use */ void afterConfigurerAdded(WebTestClient.Builder builder, @Nullable WebHttpHandlerBuilder httpHandlerBuilder, @Nullable ClientHttpConnector connector); }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(log-odds)
Source linesThe number of non-empty source lines.31+12.4
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.353.108−11.653
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.818−7.226

Intercept 8.87 + feature contributions = 2.391 (log-odds).
Score = sigmoid(2.391) = 0.916.

Score0.891

Feature contributions

FeatureValueContribution
(log-odds)
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.026+0.685
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.77+0.404
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.69.906+0.323
Indentation frequencyHow rapidly indentation changes from line to line.14−0.253
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.32−0.097
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.30.718+0.02

Intercept 0.07 + feature contributions = 1.55 (log-odds).
Score = sigmoid(1.55) = 0.825.

Score0.508
Score1
Run 1

The code is a well-structured Spring interface with clear intent. It has minimal nesting (none), appropriate length for its purpose, and each parameter is on its own line for readability. The Javadoc provides comprehensive context about how to use the interface, including references to related classes. The package structure and imports are standard and organized. The annotation @Nullable is used consistently. The method signature is clean and logically ordered. Points deducted only because the Javadoc could be slightly more concise, and there is a minor formatting inconsistency with the parameter continuation indentation. Overall, this is exemplary interface design that follows Java conventions perfectly.

Run 2

The code is highly readable. The package declaration and imports are standard. The interface has a single, well-documented method. Javadoc comments clearly explain the purpose of the interface and its method parameters. The method signature is concise, using nullable annotations to clarify optional parameters. There is no nesting and the code has a flat structure. The reading flow is natural: from interface declaration to method definition, supported by clear documentation. The action granularity is appropriate for an interface, with no implementation logic to clutter the code.

Run 3

The code is highly readable. It is a simple interface with a single method, clear Javadoc, and logical structure. The package declaration and imports are minimal and well-organized. There is no nesting or conditional logic. The method signature is clear, though slightly long due to three parameters. The Javadoc effectively explains the purpose and parameters, aiding clarity of intent. Minor vertical alignment of parameters is okay but adds slight visual clutter. Overall, concise, flat, and easy to follow.

Run 1

Code Structure: A single, logically organized interface with imports, documentation, and one method. Nesting: Minimal, with no nested control flow. Clarity of intent: Descriptive names and Javadoc clearly explain the customization contract, parameter roles, and server-specific usage; nullable annotations make optional parameters explicit. Code length: Concise, with documentation that adds useful context rather than unnecessary complexity. Action granularity: One method declaration, with parameters split across lines for readability and no bundled actions. Reading flow: Natural progression from interface purpose to method details and signature. Minor formatting improvements, such as separating the package declaration from imports with a blank line, would improve visual organization.

Run 2

Code Structure: A logically organized interface with imports, interface documentation, and one method. Nesting: Minimal nesting, with no control flow. Clarity of intent: Descriptive names and detailed Javadoc clearly explain the customization contract, parameters, and supported server types; nullable annotations clarify parameter availability. Code length: Concise declaration with proportionate documentation. Action granularity: A single method declaration, with parameters separated across lines for easy scanning. Reading flow: Natural progression from package and imports to contract documentation and method signature. A blank line between the package declaration and imports would slightly improve visual separation.

Run 3

Code Structure: A well-organized interface with imports, interface documentation, and a single method contract. Nesting: Minimal, with no nested control flow. Clarity of intent: Descriptive names and thorough Javadoc clearly explain customization responsibilities; nullable annotations clarify optional parameters. Code length: Concise implementation with proportionate documentation. Action granularity: The single method declaration is cleanly split across lines, with no combined actions. Reading flow: Natural progression from the interface purpose to method guidance and parameters. Minor drawbacks are the missing blank line after the package declaration and documentation that could more explicitly state when nullable parameters are available.