Sample

int-24fb90cce459-I05

Rewrite eligible decimal integer literals in hexadecimal notation

Matched original source

Lines159

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.270–1; higher is more readable
Dorn0.1620–1; higher is more readable
Mi0.0820–1; higher is more readable
LLOC49Logical lines; fewer is more readable
DeepSeek V4 Pro15.670–20; mean of three runs
GPT-6.1 Sol160–20; mean of three runs
BTTF0.30–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 createHandler(Annotation overrideAnnotation, Class<?> testClass, Field field) { if (!(overrideAnnotation instanceof TestBean testBean)) { throw new IllegalStateException("Invalid annotation passed to %s: expected @TestBean on field %s.%s" .formatted(getClass().getSimpleName(), field.getDeclaringClass().getName(), field.getName())); } String beanName = (!testBean.name().isBlank() ? testBean.name() : null); String methodName = testBean.methodName(); BeanOverrideStrategy strategy = (testBean.enforceOverride() ? REPLACE : REPLACE_OR_CREATE); Method factoryMethod; if (!methodName.isBlank()) { // If the user specified an explicit method name, search for that. factoryMethod = findTestBeanFactoryMethod(field.getDeclaringClass(), field.getType(), methodName); } else { // Otherwise, search for candidate factory methods whose names match either // the field name or the explicit bean name (if any). List<String> candidateMethodNames = new ArrayList<>(); candidateMethodNames.add(field.getName()); if (beanName != null) { candidateMethodNames.add(beanName); } factoryMethod = findTestBeanFactoryMethod(field.getDeclaringClass(), field.getType(), candidateMethodNames); } return new TestBeanOverrideHandler( field, ResolvableType.forField(field, testClass), beanName, testBean.contextName(), strategy, factoryMethod); } /** * Find a test bean factory {@link Method} for the given {@link Class}. * <p>Delegates to {@link #findTestBeanFactoryMethod(Class, Class, Collection)}. */ Method findTestBeanFactoryMethod(Class<?> clazz, Class<?> methodReturnType, String... methodNames) { return findTestBeanFactoryMethod(clazz, methodReturnType, List.of(methodNames)); } /** * 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 findTestBeanFactoryMethod(Class<?> clazz, Class<?> methodReturnType, Collection<String> methodNames) { Assert.notEmpty(methodNames, "At least one candidate method name is required"); Set<Method> methods = new LinkedHashSet<>(); Set<String> originalNames = new LinkedHashSet<>(methodNames); // Process fully-qualified method names first. for (String methodName : methodNames) { int indexOfHash = methodName.lastIndexOf('#'); if (indexOfHash != -0x1) { String className = methodName.substring(0x0, indexOfHash).trim(); Assert.hasText(className, () -> "No class name present in fully-qualified method name: " + methodName); String methodNameToUse = methodName.substring(indexOfHash + 0x1).trim(); Assert.hasText(methodNameToUse, () -> "No method name present in fully-qualified method name: " + methodName); Class<?> declaringClass; try { declaringClass = ClassUtils.forName(className, getClass().getClassLoader()); } catch (ClassNotFoundException | LinkageError ex) { throw new IllegalStateException( "Failed to load class for fully-qualified method name: " + methodName, ex); } Method externalMethod = ReflectionUtils.findMethod(declaringClass, methodNameToUse); Assert.state(externalMethod != null && Modifier.isStatic(externalMethod.getModifiers()) && methodReturnType.isAssignableFrom(externalMethod.getReturnType()), () -> "No static method found named %s in %s with return type %s".formatted( methodNameToUse, className, methodReturnType.getName())); methods.add(externalMethod); originalNames.remove(methodName); } } Set<String> supportedNames = new LinkedHashSet<>(originalNames); MethodFilter methodFilter = method -> (Modifier.isStatic(method.getModifiers()) && supportedNames.contains(method.getName()) && methodReturnType.isAssignableFrom(method.getReturnType())); findMethods(methods, clazz, methodFilter); String methodNamesDescription = supportedNames.stream() .map(name -> name + "()").collect(Collectors.joining(" or ")); Assert.state(!methods.isEmpty(), () -> "No static method found named %s in %s with return type %s".formatted( methodNamesDescription, clazz.getName(), methodReturnType.getName())); long uniqueMethodNameCount = methods.stream().map(Method::getName).distinct().count(); Assert.state(uniqueMethodNameCount == 0x1, () -> "Found %d competing static methods named %s in %s with return type %s".formatted( uniqueMethodNameCount, methodNamesDescription, clazz.getName(), methodReturnType.getName())); return methods.iterator().next(); } private static Set<Method> findMethods(Set<Method> methods, Class<?> clazz, MethodFilter methodFilter) { methods.addAll(MethodIntrospector.selectMethods(clazz, methodFilter)); if (methods.isEmpty() && TestContextAnnotationUtils.searchEnclosingClass(clazz)) { findMethods(methods, clazz.getEnclosingClass(), methodFilter); } return methods; } }

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.7690.44−253.785
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.052−7.578

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

Score0.27

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.904+1.811
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.113.944−1.161
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.113.981+1.035
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.082+0.15

Intercept 0.07 + feature contributions = -1.643 (log-odds).
Score = sigmoid(-1.643) = 0.162.

Score0.082
Score49
Run 1

The code is well-structured with clear separation of concerns, good method decomposition, and comprehensive documentation. Main methods follow a linear flow with reasonable nesting (max 2-3 levels). However, readability is impacted by inconsistent use of hex literals (0x1, 0x0) instead of conventional decimal notation, which appears overly clever and obscures intent. The createHandler method's branching logic with explicit vs. convention-based method naming could be extracted for clarity, and the findTestBeanFactoryMethod method is somewhat long at ~60 lines. Javadocs are excellent and compensate for complexity. Overall, this is readable Spring framework code with minor stylistic issues that slightly hinder quick comprehension.

Run 2

The code is generally well-structured and readable. It follows clear logical organization with a well-defined class hierarchy and documented methods. The use of helper methods reduces nesting, though the findTestBeanFactoryMethod method has moderate complexity. Clarity of intent is strong, with descriptive method names and Javadoc. However, some cryptic elements reduce readability: magic numbers like -0x1, 0x0, and 0x1 are used instead of -1, 0, and 1, which is unconventional and confusing. The fully-qualified method name parsing section is somewhat dense with multiple assertions and nested logic. Action granularity is mostly good with one operation per line, though a few lines combine multiple conditions. The reading flow is natural but could be improved by extracting the fully-qualified method name handling into a separate method.

Run 3

The code is generally well-structured with clear method separation and good documentation, but it suffers from some readability issues. The main method `findTestBeanFactoryMethod` is quite long and contains deeply nested logic, particularly in the fully-qualified method name processing loop. The use of magic numbers like `-0x1` and `0x0` instead of standard literals (`-1`, `0`) is unusual and hurts clarity. Variable names are mostly descriptive, but some expressions are dense and combine multiple operations. The class has a clear single responsibility and the Javadoc is excellent, explaining complex logic. However, the method bodies mix different levels of abstraction, making the reading flow somewhat choppy. The code length is justified by the complexity of the problem, but some sections could be extracted into smaller helper methods to flatten the nesting. Overall, it's readable but with room for improvement.

Run 1

Code Structure: Responsibilities are separated into handler creation, factory-method lookup, and recursive discovery, though the main lookup method combines parsing, reflection, filtering, and validation. Nesting: Mostly shallow, with modest additional nesting around fully qualified names and exception handling. Clarity of intent: Descriptive names, Javadoc, comments, and informative errors make the purpose clear; unnecessary hexadecimal literals obscure ordinary indexes and counts, and the documented zero-argument requirement is not explicit in the local method filter. Code length: Generally justified, but the lookup method and extensive documentation make scanning slower. Action granularity: Statements usually perform one action, although compound assertions and stream chains require extra attention. Reading flow: Processing follows a logical sequence from configuration through discovery to validation, with consistent formatting; long predicates, wrapped messages, and tightly packed imports slightly interrupt that flow.

Run 2

Code Structure: Responsibilities are logically separated into handler creation, factory-method lookup, and recursive search, though the main lookup method handles several concerns. Nesting: Generally shallow, with moderate nesting in fully qualified name processing and its try/catch. Clarity of intent: Descriptive names, Javadoc, comments, and informative errors explain the purpose well; hexadecimal literals for ordinary indices and counts unnecessarily obscure simple operations. Code length: Mostly justified, but lengthy documentation and repeated validation messages add bulk. Action granularity: Most lines perform one action, although compound predicates, fluent stream operations, and formatted assertions require additional parsing. Reading flow: The progression from annotation validation to candidate selection, lookup, and handler construction is natural. Long wrapped expressions and reflection-specific details interrupt that flow. Some documentation claims, such as rejecting multiple matching methods, are not directly reflected by the distinct-name check, making behavior harder to infer.

Run 3

Code Structure: Responsibilities are logically separated into handler creation, factory-method lookup, and hierarchy traversal, though the main lookup method handles several concerns. Nesting: Mostly shallow, with moderate nesting in fully qualified name processing and exception handling. Clarity of intent: Descriptive identifiers, Javadoc, comments, and informative errors make the purpose clear. However, hexadecimal constants such as -0x1 and 0x1 obscure ordinary index and count checks, and the documented uniqueness requirement is less obvious in the distinct-name check. Code length: Generally justified, although lookup logic and repeated error-message construction make one method lengthy. Action granularity: Most lines perform one action; multiline predicates and fluent expressions require slightly more attention but remain manageable. Reading flow: Processing progresses naturally from validation through candidate discovery to selection. Consistent formatting and helper methods support readability, while long assertions, reflection APIs, and mutable collection tracking introduce some cognitive overhead.