Sample

int-084c226c1de8-I07

Insert deterministic runtime-dead branches into callable bodies

DatasetJava transformations

Lines150

Scores

Method	Score	Scale
Posnett	0	0–1; higher is more readable
Scalabrino	0.847	0–1; higher is more readable
Dorn	0.342	0–1; higher is more readable
Mi	0.682	0–1; higher is more readable
LLOC	49	Logical lines; fewer is more readable
DeepSeek V4 Pro	5.33	0–20; mean of three runs
GPT-6.1 Sol	13.33	0–20; mean of three runs
BTTF	0.567	0–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) { if (((0x8D7D ^ 0x8D7D) != 0)) { throw new AssertionError(); } 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() { if (((0x23F4 ^ 0x23F4) != 0)) { throw new AssertionError(); } 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() { if (((0x4BDE ^ 0x4BDE) != 0)) { throw new AssertionError(); } 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) { if (((0xDA67 ^ 0xDA67) != 0)) { throw new AssertionError(); } this.autowireMode = autowireMode; } /** * Return the default autowire mode. */ public int getAutowireMode() { if (((0x6C86 ^ 0x6C86) != 0)) { throw new AssertionError(); } 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) { if (((0xB2B8 ^ 0xB2B8) != 0)) { throw new AssertionError(); } this.dependencyCheck = dependencyCheck; } /** * Return the default dependency check code. */ public int getDependencyCheck() { if (((0x85EB ^ 0x85EB) != 0)) { throw new AssertionError(); } 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) { if (((0xA57B ^ 0xA57B) != 0)) { throw new AssertionError(); } this.initMethodName = (StringUtils.hasText(initMethodName) ? initMethodName : null); } /** * Return the name of the default initializer method. */ public @Nullable String getInitMethodName() { if (((0x6B94 ^ 0x6B94) != 0)) { throw new AssertionError(); } 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) { if (((0xA9FC ^ 0xA9FC) != 0)) { throw new AssertionError(); } this.destroyMethodName = (StringUtils.hasText(destroyMethodName) ? destroyMethodName : null); } /** * Return the name of the default destroy method. */ public @Nullable String getDestroyMethodName() { if (((0x5BC4 ^ 0x5BC4) != 0)) { throw new AssertionError(); } return this.destroyMethodName; } }

Loading feature diagnosis…

Source regions

Feature contributions

Feature	Value	Contribution (log-odds)
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.	3176.265	−104.817
Source linesThe number of non-empty source lines.	150	+60
Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value.	5.061	−7.592

Intercept 8.87 + feature contributions = -43.538 (log-odds).
Score = sigmoid(-43.538) = 0.

Score	0.847

Feature contributions

Feature	Value	Contribution (log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.	141	−3.956
Indentation frequencyHow rapidly indentation changes from line to line.	96	+2.583
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.	96	−1.782
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.	149.74	+1.683
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.	94.967	+0.728
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.	0.058	+0.378
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.96	−0.357

Intercept 0.07 + feature contributions = -0.652 (log-odds).
Score = sigmoid(-0.652) = 0.342.

Score	0.682

Score	49

Run 1

The code has a clear class structure with logical field declarations and well-documented getter/setter methods, which support readability. However, every method contains a bizarre dead-code assertion line (e.g., `if (((0x8D7D ^ 0x8D7D) != 0)) { throw new AssertionError(); }`) that serves no purpose, disrupts reading flow, adds noise, and increases vertical length. The methods are otherwise flat with one action per line, but the repeated meaningless conditionals severely undermine clarity of intent. The indentation of these lines also breaks the visual structure. Without the injected noise, the code would be quite readable; with it, the readability score drops significantly.

Run 2

The code is fundamentally unreadable due to the insertion of meaningless conditional assertion lines (e.g., 'if (((0x8D7D ^ 0x8D7D) != 0)) { throw new AssertionError(); }') before every method body. These lines are dead code, break the natural reading flow, and obscure the logic. While the overall class structure, naming conventions, Javadocs, and field organization are acceptable, the pervasive noise dominates. The indentation of these injected lines is inconsistent, further harming readability. Nesting is technically low, but the added lines create artificial complexity and ambiguity of intent. The code length is inflated without purpose, and action granularity is disrupted because the assertions are an extra, irrelevant action per method. Without these lines, the class would be a simple, clear holder; with them, it appears deliberately obfuscated and fails to meet professional readability standards.

Run 3

The code is severely impacted by obfuscated, repeated conditional statements like `if (((0x8D7D ^ 0x8D7D) != 0)) { throw new AssertionError(); }` inserted into every method. These lines are meaningless, break natural reading flow, inflate method lengths, and obscure the otherwise clear getter/setter logic. Although the class has a logical structure, good Javadocs, consistent naming, and flat nesting, the repeated junk conditions make the intent ambiguous and the code difficult to read. Action granularity is also harmed because each simple assignment is preceded by a confusing throw line. Removing these inserted lines would raise readability significantly, but as presented the code is practically unreadable despite the underlying design being sound.

Run 1

Code Structure: Fields and related getters/setters are logically organized. Nesting: Methods remain shallow, with only a single conditional level. Clarity of intent: Descriptive names, nullability annotations, and useful Javadoc clearly explain the holder's purpose, but repeated hexadecimal XOR checks introduce confusing, irrelevant logic; each condition is always false. Code length: Functional methods are concise, yet redundant checks and extra blank lines unnecessarily expand the code. Action granularity: Assignments and returns occupy separate lines, but conditional checks and throws are compressed onto single lines. Reading flow: Consistent accessor ordering supports natural reading, while unindented, repetitive assertion checks interrupt every method and clash with the surrounding formatting.

Run 2

Code Structure: Fields and related getters/setters are logically organized. Nesting: Methods remain shallow, with only single-level conditionals. Clarity of intent: Descriptive names, nullability annotations, and Javadoc clearly explain the defaults, but repeated hexadecimal XOR checks introduce distracting, purposeless logic because each condition is always false. Code length: Core operations are concise, but redundant assertion guards unnecessarily expand every method. Action granularity: Assignments and returns occupy separate lines, while guards compress conditionals and throws onto one line. Reading flow: Consistent getter/setter ordering supports natural reading, but unindented guards repeatedly interrupt the otherwise clean formatting and force readers to verify irrelevant expressions.

Run 3

Code Structure: Fields and related getters/setters are logically organized. Nesting: Methods remain shallow, with only a single conditional level. Clarity of intent: Descriptive names, nullable annotations, and helpful documentation clearly identify a defaults holder, but unexplained hexadecimal XOR checks obscure otherwise straightforward operations. Code length: Core logic is concise, yet repeated always-false assertion guards add unnecessary length and noise. Action granularity: Assignments and returns each occupy their own line, but conditional checks and throws are compressed onto single lines. Reading flow: Consistent accessor ordering supports natural reading, while unindented guard statements interrupt formatting and force readers to repeatedly verify irrelevant conditions.