Sample

int-5ab92647f409-I02

Shorten method, parameter, and local names without collisions

Matched original source

Lines159

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.2470–1; higher is more readable
Dorn0.1920–1; higher is more readable
Mi0.1530–1; higher is more readable
LLOC49Logical lines; fewer is more readable
DeepSeek V4 Pro70–20; mean of three runs
GPT-6.1 Sol120–20; mean of three runs
BTTF0.4010–1; higher is more readable

Views

Source code

package org.springframework.test.context.bean.override.convention; import java.lang.annotation.Annotation; import java.lang.reflect.Field; import java.lang.reflect.Method; import java.lang.reflect.Modifier; import java.util.ArrayList; import java.util.Collection; import java.util.LinkedHashSet; import java.util.List; import java.util.Set; import java.util.stream.Collectors; import org.springframework.core.MethodIntrospector; import org.springframework.core.ResolvableType; import org.springframework.test.context.TestContextAnnotationUtils; import org.springframework.test.context.bean.override.BeanOverrideProcessor; import org.springframework.test.context.bean.override.BeanOverrideStrategy; import org.springframework.util.Assert; import org.springframework.util.ClassUtils; import org.springframework.util.ReflectionUtils; import org.springframework.util.ReflectionUtils.MethodFilter; import static org.springframework.test.context.bean.override.BeanOverrideStrategy.REPLACE; import static org.springframework.test.context.bean.override.BeanOverrideStrategy.REPLACE_OR_CREATE; /** * {@link BeanOverrideProcessor} implementation for {@link TestBean @TestBean} * support, which creates a {@link TestBeanOverrideHandler} for annotated * fields in a given class and ensures that a corresponding static factory method * exists, according to the {@linkplain TestBean documented conventions}. * * @author Simon Baslé * @author Sam Brannen * @author Stephane Nicoll * @since 6.2 */ class TestBeanOverrideProcessor implements BeanOverrideProcessor { @Override public TestBeanOverrideHandler create(Annotation override2, Class<?> test2, Field fie) { if (!(override2 instanceof TestBean testBean)) { throw new IllegalStateException("Invalid annotation passed to %s: expected @TestBean on field %s.%s" .formatted(getClass().getSimpleName(), fie.getDeclaringClass().getName(), fie.getName())); } String bean2 = (!testBean.name().isBlank() ? testBean.name() : null); String method2 = testBean.methodName(); BeanOverrideStrategy str = (testBean.enforceOverride() ? REPLACE : REPLACE_OR_CREATE); Method factory; if (!method2.isBlank()) { // If the user specified an explicit method name, search for that. factory = find(fie.getDeclaringClass(), fie.getType(), method2); } else { // Otherwise, search for candidate factory methods whose names match either // the field name or the explicit bean name (if any). List<String> candidate = new ArrayList<>(); candidate.add(fie.getName()); if (bean2 != null) { candidate.add(bean2); } factory = find(fie.getDeclaringClass(), fie.getType(), candidate); } return new TestBeanOverrideHandler( fie, ResolvableType.forField(fie, test2), bean2, testBean.contextName(), str, factory); } /** * Find a test bean factory {@link Method} for the given {@link Class}. * <p>Delegates to {@link #findTestBeanFactoryMethod(Class, Class, Collection)}. */ Method find(Class<?> cla, Class<?> method3, String... method4) { return find(cla, method3, List.of(method4)); } /** * Find a test bean factory {@link Method} for the given {@link Class}, which * meets the following criteria. * <ul> * <li>The method is static.</li> * <li>The method does not accept any arguments.</li> * <li>The method's return type matches the supplied {@code methodReturnType}.</li> * <li>The method's name is one of the supplied {@code methodNames}.</li> * </ul> * <p>This method traverses up the type hierarchy of the given class in search * of the factory method, beginning with the class itself and then searching * implemented interfaces and superclasses. If a factory method is not found * in the type hierarchy, this method will also search the enclosing class * hierarchy if the class is a nested class. * <p>If multiple factory methods are found that match the search criteria, * an exception is thrown. * @param clazz the class in which to search for the factory method * @param methodReturnType the return type for the factory method * @param methodNames a set of supported names for the factory method * @return the corresponding factory method * @throws IllegalStateException if a matching factory method cannot * be found or multiple methods match */ Method find(Class<?> cla2, Class<?> method5, Collection<String> method6) { Assert.notEmpty(method6, "At least one candidate method name is required"); Set<Method> met = new LinkedHashSet<>(); Set<String> original = new LinkedHashSet<>(method6); // Process fully-qualified method names first. for (String method7 : method6) { int index = method7.lastIndexOf('#'); if (index != -1) { String class2 = method7.substring(0, index).trim(); Assert.hasText(class2, () -> "No class name present in fully-qualified method name: " + method7); String method8 = method7.substring(index + 1).trim(); Assert.hasText(method8, () -> "No method name present in fully-qualified method name: " + method7); Class<?> declaring; try { declaring = ClassUtils.forName(class2, getClass().getClassLoader()); } catch (ClassNotFoundException | LinkageError ex) { throw new IllegalStateException( "Failed to load class for fully-qualified method name: " + method7, ex); } Method external = ReflectionUtils.findMethod(declaring, method8); Assert.state(external != null && Modifier.isStatic(external.getModifiers()) && method5.isAssignableFrom(external.getReturnType()), () -> "No static method found named %s in %s with return type %s".formatted( method8, class2, method5.getName())); met.add(external); original.remove(method7); } } Set<String> supported = new LinkedHashSet<>(original); MethodFilter method9 = method -> (Modifier.isStatic(method.getModifiers()) && supported.contains(method.getName()) && method5.isAssignableFrom(method.getReturnType())); find2(met, cla2, method9); String method10 = supported.stream() .map(name -> name + "()").collect(Collectors.joining(" or ")); Assert.state(!met.isEmpty(), () -> "No static method found named %s in %s with return type %s".formatted( method10, cla2.getName(), method5.getName())); long unique = met.stream().map(Method::getName).distinct().count(); Assert.state(unique == 1, () -> "Found %d competing static methods named %s in %s with return type %s".formatted( unique, method10, cla2.getName(), method5.getName())); return met.iterator().next(); } private static Set<Method> find2(Set<Method> met2, Class<?> cla3, MethodFilter method11) { met2.addAll(MethodIntrospector.selectMethods(cla3, method11)); if (met2.isEmpty() && TestContextAnnotationUtils.searchEnclosingClass(cla3)) { find2(met2, cla3.getEnclosingClass(), method11); } return met2; } }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(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.7723.315−254.869
Source linesThe number of non-empty source lines.159+63.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.5.086−7.629

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

Score0.247

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.160−4.629
Indentation frequencyHow rapidly indentation changes from line to line.120+3.414
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.120−2.333
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.158.913+1.811
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.102.956+0.857
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.102.963−0.696
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.09+0.067

Intercept 0.07 + feature contributions = -1.439 (log-odds).
Score = sigmoid(-1.439) = 0.192.

Score0.153
Score49
Run 1

The code is significantly hampered by poor variable naming throughout, with parameters like 'override2', 'test2', 'fie', 'bean2', 'method2', 'cla', 'method3', 'method4', etc. These numeric suffixes obscure meaning and make the code very hard to follow. The nested method 'find2' compounds this confusion. While the code has logical structure with clear method separation and good Javadoc on the main 'find' method, the implementation within methods suffers from unclear intent. The use of abbreviations ('fie' for field, 'cla' for class, 'met' for methods) further degrades readability. Nesting is moderate - not deeply indented but the logic flow is disrupted by poor naming. Code length is reasonable and action granularity is acceptable, with most operations on separate lines. Reading flow is natural in terms of procedural logic, but the constant mental mapping of numbered variables makes comprehension difficult. The code structure is solid, but clarity of intent is severely impaired by naming conventions.

Run 2

The code suffers from severe readability issues due to mangled variable names (e.g., override2, test2, fie, cla, cla2, method3-method11, met, met2), which obscure intent and violate self-documenting code principles. While the overall class structure is logical with separated find() overloads and a helper method, the naming destroys reading flow. Nesting is moderate—the candidate method name processing in find() contains deep conditional loops, but it's not egregiously tangled. Action granularity is generally acceptable, with single logical operations per line. Code length is reasonable given the functionality, but Javadocs don't compensate for poor parameter naming. Clarity of intent is severely compromised: method variables like 'method5' give no indication they represent return types, and 'fie' for field reads like a typo. The intent of the logic is discernible from structure and documentation, but the identifiers create constant cognitive friction. This appears to be code that hasn't been refactored after heavy editing.

Run 3

This code has significant readability problems. Variable names are cryptic and inconsistent (override2, test2, fie, bean2, method2 through method11, cla, cla2, cla3, met, met2, find2). The numbered suffix approach (method3, method4, method5, etc.) forces readers to constantly track which variable is which, increasing cognitive load. Method names like find2 are ambiguous and provide no insight into their purpose. The find method overloads are overloaded with confusing parameter renames across the same semantic concept. While the Javadoc is comprehensive, the code itself contradicts the clarity that good documentation should support. Deep nesting in find() with multiple conditionals and try/catch blocks makes the flow hard to follow. Some logic is well-structured (candidate method names collection, filtering), but the naming choices and multiple overloaded methods undermine readability. The code structure is logical but execution details are obfuscated by poor naming conventions, making it feel like obfuscated or auto-generated code rather than maintainable production code.

Run 1

Code Structure: Responsibilities are reasonably separated into handler creation, factory lookup, and hierarchy traversal, though the main lookup method combines parsing, reflection, filtering, and validation. Nesting: Mostly shallow, with moderate nesting in fully qualified method processing and exception handling. Clarity of intent: Documentation and explanatory comments help, but vague identifiers such as fie, cla2, method5, and find2 substantially obscure meaning. Stale Javadoc references and parameter names further undermine clarity. Code length: Generally proportionate to the functionality, although extensive documentation and repeated error-message construction add reading overhead. Action granularity: Most statements perform one action per line; compound predicates and fluent expressions remain manageable. Reading flow: The progression from annotation validation to factory selection is logical, but numbered identifiers, multiline assertions, and reflection details force frequent backtracking.

Run 2

Code Structure: Responsibilities are reasonably separated into creation, factory lookup, and recursive enclosing-class search. Nesting: Mostly shallow, although fully qualified name processing combines a loop, conditional, and try/catch. Clarity of intent: Comments explain the algorithm, but names such as fie, cla2, method5, and find2 obscure roles. Documentation also references an absent method and parameter names that do not match the signatures. Code length: Reasonable for reflection-based lookup, though verbose documentation and repeated diagnostic formatting add reading overhead. Action granularity: Most lines perform a single action; multiline predicates and assertions are somewhat dense. Reading flow: The sequence from validation through lookup to handler creation is logical, but numbered identifiers and documentation inconsistencies force readers to repeatedly infer meaning.

Run 3

Code Structure: Responsibilities are reasonably separated into creation, factory lookup, and recursive search, although the main lookup method combines several tasks. Nesting: Mostly shallow, with moderate nesting in fully qualified name processing and exception handling. Clarity of intent: Comments and assertions explain the factory-method conventions, but names such as method5, cla2, met, and find2 obscure meaning. Stale Javadoc references and parameter names further undermine clarity. Code length: Generally proportionate to the reflection logic, though extensive documentation and repeated error-message construction add reading overhead. Action granularity: Most statements perform one action, with compound predicates and chained stream operations remaining manageable. Reading flow: Processing follows a logical sequence from validation through lookup to handler creation, but numbered identifiers force frequent backtracking to determine variable roles.