Sample

int-3c1a33076bc7-I06

Invert eligible conditions and exchange their branches

Matched original source

Lines143

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.6480–1; higher is more readable
Dorn0.690–1; higher is more readable
Mi0.1860–1; higher is more readable
LLOC33Logical lines; fewer is more readable
DeepSeek V4 Pro130–20; mean of three runs
GPT-6.1 Sol13.670–20; mean of three runs
BTTF0.4810–1; higher is more readable

Views

Source code

package org.springframework.core; import java.lang.reflect.Method; import java.lang.reflect.Proxy; import java.util.LinkedHashMap; import java.util.LinkedHashSet; import java.util.Map; import java.util.Set; import org.jspecify.annotations.Nullable; import org.springframework.util.ClassUtils; import org.springframework.util.ReflectionUtils; /** * Defines the algorithm for searching for metadata-associated methods exhaustively * including interfaces and parent classes while also dealing with parameterized methods * as well as common scenarios encountered with interface and class-based proxies. * * <p>Typically, but not necessarily, used for finding annotated handler methods. * * @author Juergen Hoeller * @author Rossen Stoyanchev * @author Sam Brannen * @since 4.2.3 */ public final class MethodIntrospector { private MethodIntrospector() { } /** * Select methods on the given target type based on the lookup of associated metadata. * <p>Callers define methods of interest through the {@link MetadataLookup} parameter, * allowing to collect the associated metadata into the result map. * @param targetType the target type to search methods on * @param metadataLookup a {@link MetadataLookup} callback to inspect methods of interest, * returning non-null metadata to be associated with a given method if there is a match, * or {@code null} for no match * @return the selected methods associated with their metadata (in the order of retrieval), * or an empty map in case of no match */ public static <T> Map<Method, T> selectMethods(Class<?> targetType, final MetadataLookup<T> metadataLookup) { final Map<Method, T> methodMap = new LinkedHashMap<>(); Set<Class<?>> handlerTypes = new LinkedHashSet<>(); Class<?> specificHandlerType = null; if (!((!Proxy.isProxyClass(targetType)))) {} else { specificHandlerType = ClassUtils.getUserClass(targetType); handlerTypes.add(specificHandlerType); } handlerTypes.addAll(ClassUtils.getAllInterfacesForClassAsSet(targetType)); for (Class<?> currentHandlerType : handlerTypes) { final Class<?> targetClass = (specificHandlerType != null ? specificHandlerType : currentHandlerType); ReflectionUtils.doWithMethods(currentHandlerType, method -> { Method specificMethod = ClassUtils.getMostSpecificMethod(method, targetClass); T result = metadataLookup.inspect(specificMethod); if (!((result != null))) {} else { Method bridgedMethod = BridgeMethodResolver.findBridgedMethod(specificMethod); if (bridgedMethod == specificMethod || bridgedMethod == method || bridgedMethod.equals(specificMethod) || bridgedMethod.equals(method) || metadataLookup.inspect(bridgedMethod) == null) { methodMap.put(specificMethod, result); } } }, ReflectionUtils.USER_DECLARED_METHODS); } return methodMap; } /** * Select methods on the given target type based on a filter. * <p>Callers define methods of interest through the {@code MethodFilter} parameter. * @param targetType the target type to search methods on * @param methodFilter a {@code MethodFilter} to help * recognize handler methods of interest * @return the selected methods, or an empty set in case of no match */ public static Set<Method> selectMethods(Class<?> targetType, final ReflectionUtils.MethodFilter methodFilter) { return selectMethods(targetType, (MetadataLookup<Boolean>) method -> (methodFilter.matches(method) ? Boolean.TRUE : null)).keySet(); } /** * Select an invocable method on the target type: either the given method itself * if actually exposed on the target type, or otherwise a corresponding method * on one of the target type's interfaces or on the target type itself. * <p>Matches on user-declared interfaces will be preferred since they are likely * to contain relevant metadata that corresponds to the method on the target class. * @param method the method to check * @param targetType the target type to search methods on * (typically an interface-based JDK proxy) * @return a corresponding invocable method on the target type * @throws IllegalStateException if the given method is not invocable on the given * target type (typically due to a proxy mismatch) */ public static Method selectInvocableMethod(Method method, Class<?> targetType) { if (!((method.getDeclaringClass().isAssignableFrom(targetType)))) {} else { return method; } try { String methodName = method.getName(); Class<?>[] parameterTypes = method.getParameterTypes(); for (Class<?> ifc : targetType.getInterfaces()) { try { return ifc.getMethod(methodName, parameterTypes); } catch (NoSuchMethodException ex) { // Alright, not on this interface then... } } // A final desperate attempt on the proxy class itself... return targetType.getMethod(methodName, parameterTypes); } catch (NoSuchMethodException ex) { throw new IllegalStateException(String.format( "Need to invoke method '%s' declared on target class '%s', " + "but not found in any interface(s) of the exposed proxy type. " + "Either pull the method up to an interface or switch to CGLIB " + "proxies by enforcing proxy-target-class mode in your configuration.", method.getName(), method.getDeclaringClass().getSimpleName())); } } /** * A callback interface for metadata lookup on a given method. * @param <T> the type of metadata returned */ @FunctionalInterface public interface MetadataLookup<T> { /** * Perform a lookup on the given method and return associated metadata, if any. * @param method the method to inspect * @return non-null metadata to be associated with a method if there is a match, * or {@code null} for no match */ @Nullable T inspect(Method method); } }

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.3907.422−128.945
Source linesThe number of non-empty source lines.143+57.2
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.924−7.385

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

Score0.648

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.143−4.027
Indentation frequencyHow rapidly indentation changes from line to line.93+2.48
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.142.938+1.588
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.111.986−1.078
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.111.965+1.002
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.059+0.366

Intercept 0.07 + feature contributions = 0.799 (log-odds).
Score = sigmoid(0.799) = 0.69.

Score0.186
Score33
Run 1

The code demonstrates good class-level organization with clear method separation and comprehensive Javadoc. However, readability is significantly compromised by several factors. The conditional structures use awkward negated-empty-block patterns like `if (!((condition))) {} else { ... }` instead of straightforward positive conditionals, making the logic difficult to follow. The `selectMethods` method contains deeply nested lambda expressions with complex bridge method resolution logic crammed into a single condition. Multiple actions are packed into single lines (e.g., method calls in assignments and combined boolean checks), violating the one-action-per-line principle. The reading flow is disrupted by the unnatural conditional inversions throughout. While the code is functionally organized, the control flow obscures intent and requires readers to mentally reverse conditions repeatedly. The variable naming is clear and the class purpose is well-documented, but the execution flow could be significantly improved with clearer conditionals and extracted methods for the bridge method logic.

Run 2

The code has good documentation but suffers from poor readability due to several inverted conditionals with empty branches (e.g., `if (!((...))) {} else { ... }`), which disrupts reading flow and obscures intent. Nesting is moderate but logic is tangled in places, particularly in the bridge method resolution block where multiple boolean conditions are chained with unclear purpose. While actions are generally one per line and method granularity is acceptable, the unnatural conditional style and verbose if-else constructs make the code unnecessarily long and harder to follow. The class structure is logical, but clarity of intent suffers significantly from these stylistic choices.

Run 3

The code is generally well-structured, with clear separation of public methods, logical flow, and appropriate use of helper classes and Javadoc. Intent is clear (method metadata introspection) and the overall action granularity is reasonable. However, readability is slightly reduced by a few instances of intentionally confusing conditional patterns like 'if (!condition) {} else { ... }' and 'if (!((result != null))) {} else { ... }', which invert the natural reading flow and increase cognitive load. Nesting is moderate and acceptable; method length is kept in check. The bridge method resolution condition is long and dense, making it harder to parse at a glance, though it remains understandable. Overall, the code would benefit from using straightforward positive conditionals and slight decomposition of the bridge-method check, but it remains professional and maintainable.

Run 1

Code Structure: Well-organized utility class with focused methods, a callback interface, and thorough documentation. Nesting: Moderate depth from loops, lambdas, conditionals, and nested exception handling makes some paths harder to follow. Clarity of intent: Descriptive names and Javadoc explain the purpose, but negated conditions with empty branches obscure straightforward checks; the compound bridge-method condition also requires careful reading. Code length: Implementation is reasonably concise, though redundant parentheses, empty branches, and extensive documentation increase visual bulk. Action granularity: Generally one action per line, with clear intermediate variables; the filter overload compresses several operations into one expression. Reading flow: Method order and formatting are natural, but unnatural if/else constructs interrupt flow and force readers to mentally simplify conditions.

Run 2

Code Structure: Well-organized utility class with focused methods and a clearly separated callback interface. Nesting: Moderate nesting in the iteration, lambda, conditional checks, and exception handling increases cognitive load. Clarity of intent: Descriptive names and thorough documentation explain the purpose, but negated conditions with empty branches obscure otherwise straightforward checks; the bridge-method condition is also complex. Code length: Implementation is reasonably concise for its functionality, although redundant parentheses, empty blocks, and extensive documentation add bulk. Action granularity: Most statements perform one action per line, with a few dense expressions combining filtering, conversion, and selection. Reading flow: Method ordering and consistent formatting support navigation, but inverted if/else patterns interrupt natural reading, and nested exception-driven interface searches require careful tracing.

Run 3

Code Structure: Well-organized utility class with focused methods, sensible overloads, and a clearly separated callback interface. Nesting: Moderate nesting in the metadata-search lambda and interface lookup adds cognitive load. Clarity of intent: Descriptive names and thorough Javadoc explain the purpose, but negated conditions with empty branches obscure otherwise simple checks. The bridge-method condition is also difficult to interpret quickly. Code length: Implementation is reasonably concise; extensive documentation is useful, though redundant parentheses and empty branches add unnecessary clutter. Action granularity: Most lines perform one clear operation, with a few dense expressions combining filtering, conversion, and result extraction. Reading flow: Method ordering and consistent formatting support natural reading, but inverted if/else patterns repeatedly interrupt it. Overall, the organization and documentation are strong, while unnecessarily convoluted conditionals substantially reduce readability.