Sample

int-cd266e4051bb-I06

Invert eligible conditions and exchange their branches

Matched original source

Lines128

Scores

MethodScoreScale
Posnett0.9960–1; higher is more readable
Scalabrino0.9390–1; higher is more readable
Dorn0.7950–1; higher is more readable
Mi0.6870–1; higher is more readable
LLOC27Logical lines; fewer is more readable
DeepSeek V4 Pro18.330–20; mean of three runs
GPT-6.1 Sol190–20; mean of three runs
BTTF0.720–1; higher is more readable

Views

Source code

package org.springframework.beans.factory.support; import org.jspecify.annotations.Nullable; import org.springframework.util.StringUtils; /** * A simple holder for {@code BeanDefinition} property defaults. * * @author Mark Fisher * @author Juergen Hoeller * @since 2.5 * @see AbstractBeanDefinition#applyDefaults */ public class BeanDefinitionDefaults { private @Nullable Boolean lazyInit; private int autowireMode = AbstractBeanDefinition.AUTOWIRE_NO; private int dependencyCheck = AbstractBeanDefinition.DEPENDENCY_CHECK_NONE; private @Nullable String initMethodName; private @Nullable String destroyMethodName; /** * Set whether beans should be lazily initialized by default. * <p>If {@code false}, the bean will get instantiated on startup by bean * factories that perform eager initialization of singletons. * @see AbstractBeanDefinition#setLazyInit */ public void setLazyInit(boolean lazyInit) { this.lazyInit = lazyInit; } /** * Return whether beans should be lazily initialized by default, i.e. not * eagerly instantiated on startup. Only applicable to singleton beans. * @return whether to apply lazy-init semantics ({@code false} by default) */ public boolean isLazyInit() { return (this.lazyInit != null && this.lazyInit); } /** * Return whether beans should be lazily initialized by default, i.e. not * eagerly instantiated on startup. Only applicable to singleton beans. * @return the lazy-init flag if explicitly set, or {@code null} otherwise * @since 5.2 */ public @Nullable Boolean getLazyInit() { return this.lazyInit; } /** * Set the autowire mode. This determines whether any automagical detection * and setting of bean references will happen. Default is AUTOWIRE_NO * which means there won't be convention-based autowiring by name or type * (however, there may still be explicit annotation-driven autowiring). * @param autowireMode the autowire mode to set. * Must be one of the constants defined in {@link AbstractBeanDefinition}. * @see AbstractBeanDefinition#setAutowireMode */ public void setAutowireMode(int autowireMode) { this.autowireMode = autowireMode; } /** * Return the default autowire mode. */ public int getAutowireMode() { return this.autowireMode; } /** * Set the dependency check code. * @param dependencyCheck the code to set. * Must be one of the constants defined in {@link AbstractBeanDefinition}. * @see AbstractBeanDefinition#setDependencyCheck */ public void setDependencyCheck(int dependencyCheck) { this.dependencyCheck = dependencyCheck; } /** * Return the default dependency check code. */ public int getDependencyCheck() { return this.dependencyCheck; } /** * Set the name of the default initializer method. * <p>Note that this method is not enforced on all affected bean definitions * but rather taken as an optional callback, to be invoked if actually present. * @see AbstractBeanDefinition#setInitMethodName * @see AbstractBeanDefinition#setEnforceInitMethod */ public void setInitMethodName(@Nullable String initMethodName) { this.initMethodName = (StringUtils.hasText(initMethodName) ? initMethodName : null); } /** * Return the name of the default initializer method. */ public @Nullable String getInitMethodName() { return this.initMethodName; } /** * Set the name of the default destroy method. * <p>Note that this method is not enforced on all affected bean definitions * but rather taken as an optional callback, to be invoked if actually present. * @see AbstractBeanDefinition#setDestroyMethodName * @see AbstractBeanDefinition#setEnforceDestroyMethod */ public void setDestroyMethodName(@Nullable String destroyMethodName) { this.destroyMethodName = (StringUtils.hasText(destroyMethodName) ? destroyMethodName : null); } /** * Return the name of the default destroy method. */ public @Nullable String getDestroyMethodName() { return this.destroyMethodName; } }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(log-odds)
Source linesThe number of non-empty source lines.128+51.2
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.1427.996−47.124
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.888−7.331

Intercept 8.87 + feature contributions = 5.615 (log-odds).
Score = sigmoid(5.615) = 0.996.

Score0.939

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.123−3.319
Indentation frequencyHow rapidly indentation changes from line to line.74+1.822
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.127.781+1.376
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.94.961+0.728
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.032+0.635
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398
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.94.953−0.357

Intercept 0.07 + feature contributions = 1.354 (log-odds).
Score = sigmoid(1.354) = 0.795.

Score0.687
Score27
Run 1

The code is highly readable. Package and imports are clear, and the class has a focused responsibility. Fields are logically organized with sensible defaults. All public methods are simple, flat, one-action-per-line getters/setters with no deep nesting. Javadoc comments clearly explain intent, constraints, and defaults, aiding understanding. Method names are descriptive, and the use of @Nullable improves contract clarity. The only minor issue is the slight redundancy of having both isLazyInit() and getLazyInit(), but this is a common spring pattern to distinguish primitive boolean semantics from nullable Boolean. Code length is concise and not bloated. Overall, it follows clean code practices consistently.

Run 2

This code is highly readable. It follows a clear, consistent structure with fields grouped at the top and paired setters/getters below. Nesting is minimal, with a single ternary expression in two setters. The intent of each method is explicitly documented with concise Javadoc, including edge cases and defaults. Code length is appropriate for a simple data holder class—no unnecessary methods or logic. Each statement generally performs one action, and the reading flow is natural: definition, then behavior. Minor deductions: some Javadoc is sparse for getters and the ternary adds slight cognitive load, but overall this is excellent.

Run 3

The code is highly readable. It follows a clear, consistent structure with grouped fields and standard getter/setter pairs. Nesting is minimal — only simple ternary expressions in two setters do any conditional work, keeping the logic flat. Intent is explicit through descriptive method names and comprehensive Javadoc comments that explain behavior, defaults, and related methods. Code length is appropriate: it avoids redundancy while still providing separate getters for primitive boolean and nullable Boolean semantics where needed. Each line performs a single action, and the overall flow is natural, with fields first, then methods in logical order. Minor deductions might come from the slight cognitive load of having both isLazyInit() and getLazyInit(), but this is well-documented and purposeful.

Run 1

Code Structure: Fields are declared together, followed by logically paired setters and getters. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, explicit default constants, nullable annotations, and Javadocs clearly explain behavior, including the distinction between isLazyInit() and getLazyInit(). Code length: Implementations are concise; documentation adds useful context but is somewhat repetitive for simple accessors. Action granularity: Each statement performs one assignment or return; the short ternary expressions remain easy to understand. Reading flow: Consistent formatting and property-by-property organization make the class easy to scan. Minor verbosity and excess blank lines prevent a perfect score.

Run 2

Code Structure: Fields precede logically paired setters and getters, creating a well-organized holder class. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, explicit default constants, nullability annotations, and helpful documentation clearly communicate behavior, including the distinction between nullable getLazyInit() and boolean isLazyInit(). Code length: Implementations are concise, although extensive and occasionally repetitive Javadoc makes the class longer to scan. Action granularity: Each statement performs one focused assignment or return; the simple ternary expressions remain easy to understand. Reading flow: Consistent formatting and property-by-property ordering support natural reading. Minor readability costs come from documentation verbosity and integer-based modes that require consulting external constants.

Run 3

Code Structure: Fields precede logically paired setters and getters, creating a well-organized holder class. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, explicit defaults, nullability annotations, and helpful Javadocs clearly explain behavior, including the distinction between unset and false lazy initialization. Code length: Implementations are concise; extensive documentation and repetitive accessor boilerplate slightly increase reading length but remain useful. Action granularity: Each statement performs one clear assignment or return; ternary expressions provide straightforward normalization without obscuring intent. Reading flow: Consistent formatting and predictable method ordering make the class easy to scan. Minor verbosity and reliance on externally defined integer constants prevent a perfect score.