Sample

int-495e5c28966a-I13

Lower every eligible classic and enhanced for loop to a while loop

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 Pro180–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

The code is highly readable. Structure is logical: fields, then setters/getters. Nesting is minimal with no deep branching. Intent is clear—a simple holder for BeanDefinition defaults. Length is justified by Javadoc documentation typical of Spring. Action granularity is one action per line. Reading flow is natural, grouping related fields and methods with thorough explanations. Minor deductions: some Javadoc could be slightly more concise, and boolean logic in isLazyInit could be simplified, but overall clarity is excellent.

Run 3

The code is highly readable. It follows a clear, logical structure with fields at the top and consistent getter/setter pairs below. There is no deep nesting — all methods are flat and straightforward. Intent is explicitly documented via Javadoc on every accessor, plus inline references to related definitions. The code is concise: each method performs one action and is only as long as necessary. Reading flow is natural, with related methods grouped in a predictable order. Minor deductions: the use of nullable Boolean with separate isLazyInit/getLazyInit could be slightly confusing to newcomers, and Javadoc comments are verbose for simple getters/setters. Still, overall clarity and maintainability are excellent.

Run 1

Code Structure: Fields are grouped first, followed by logically paired setters and getters. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, explicit defaults, nullable annotations, and Javadoc clearly explain behavior, including the distinction between unset and false lazy initialization. Code length: Implementations are concise, though extensive documentation and extra blank lines add some verbosity. Action granularity: Each statement performs a single assignment or return; ternary expressions provide straightforward input normalization. Reading flow: Consistent formatting and predictable accessor ordering make the class easy to scan from top to bottom.

Run 2

Code Structure: Fields are grouped 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 helpful Javadocs clearly explain behavior, including the distinction between unset and false lazy initialization. Code length: Implementations are concise, although repetitive accessor documentation adds some length. Action granularity: Each statement performs a single assignment or return; the short conditional expressions remain easy to understand. Reading flow: Consistent formatting and property-by-property ordering make the class easy to scan. Minor readability costs come from documentation verbosity and integer modes whose meanings require consulting external constants.

Run 3

Code Structure: Fields are grouped first, followed by consistently paired setters and getters. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, explicit defaults, nullable annotations, and useful Javadoc clearly explain behavior, including the distinction between isLazyInit() and getLazyInit(). Code length: Implementations are concise; extensive documentation adds length but mostly provides valuable context, with minor repetition. Action granularity: Each statement performs one clear assignment or return; the short ternary expressions remain easy to understand. Reading flow: Consistent formatting and predictable accessor ordering make the class straightforward to scan. Minor documentation verbosity and reliance on externally defined integer constants keep it just below a perfect score.