Sample

int-b22b2c04d181-I08

Select one of ten high-readability unrelated code templates per class

Matched original source

Lines150

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.6060–1; higher is more readable
Dorn0.2040–1; higher is more readable
Mi0.1850–1; higher is more readable
LLOC37Logical lines; fewer is more readable
DeepSeek V4 Pro12.670–20; mean of three runs
GPT-6.1 Sol15.330–20; mean of three runs
BTTF0.4040–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() { { boolean featureEnabled = false; for (int toggleCount = 0; toggleCount < 3; toggleCount++) { featureEnabled = !featureEnabled; } } } /** * 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)) { 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) { 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)) { 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.3985.205−131.512
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.4.923−7.385

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

Score0.606

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.150−4.275
Indentation frequencyHow rapidly indentation changes from line to line.100+2.722
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.100−1.874
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.149.903+1.686
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.967−1.077
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.111.947+1.002
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.058+0.383

Intercept 0.07 + feature contributions = -1.364 (log-odds).
Score = sigmoid(-1.364) = 0.204.

Score0.185
Score37
Run 1

The code is generally well-structured and readable. It has a clear purpose, logical organization, and good use of generics. However, there are a few issues. A stray code block inside the private constructor (`{ boolean featureEnabled = false; ... }`) appears to be a copy-paste error and is confusing. The lambda in `selectMethods` has a complex conditional with multiple `||` conditions involving `bridgedMethod` and `metadataLookup.inspect`, which could be simplified or extracted for clarity. The nested try-catch blocks in `selectInvocableMethod` are acceptable but add slight nesting. Overall, the code could benefit from minor refactoring to improve intent clarity.

Run 2

The code has serious readability issues. The private constructor contains a nonsensical block with an unused loop and dead code, indicating clutter or an accidental insertion. The selectMethods method is overly complex: it uses a long conditional chain with repeated null-check logic, making the intent unclear. The nested loop in selectInvocableMethod has deep nesting (three levels including try-catch blocks), reducing readability. Several lines combine multiple actions (e.g., adding to handlerTypes while calling ClassUtils methods), violating the 'one action per line' guideline. The overall structure is logical at a high level but the implementation details feel tangled. Method names and Javadocs are good, but the code length is unnecessarily long in places, and reading flow is disrupted by the confusing conditional expressions and the dead code in the constructor.

Run 3

The code is largely well-structured with clear class-level documentation, logical method grouping, and reasonably flat nesting in core methods. However, it includes an anomalous, purposeless nested block inside the private constructor that adds confusion and unnecessary nesting. The selectMethods method contains a convoluted boolean condition with multiple redundant equality checks, reducing clarity. The selectInvocableMethod uses nested try-catch blocks, which, while necessary for the logic, slightly impairs readability. Javadocs are strong, and naming is clear, but the mentioned issues prevent a higher score.

Run 1

Code Structure: Well-organized utility methods and a clearly defined callback interface, but the constructor contains an unrelated, unused toggle loop. Nesting: Mostly manageable, though the method-selection lambda has nested conditionals and invocable-method lookup uses nested try/catch blocks. Clarity of intent: Descriptive names and thorough Javadoc explain the reflection logic; the compound bridge-method condition requires careful reading, and the constructor obscures intent. Code length: Generally appropriate for the functionality, with unnecessary constructor code and somewhat verbose documentation. Action granularity: Most lines perform a single action, although chained calls and the filter lambda compress several operations. Reading flow: Methods follow a coherent progression, with helpful comments and consistent formatting outside the poorly indented constructor block.

Run 2

Code Structure: Methods and the callback interface are logically organized, but the constructor contains an unrelated, poorly formatted toggle loop. Nesting: Mostly moderate, with additional complexity from the nested lambda conditions and try/catch inside a loop. Clarity of intent: Descriptive names and thorough Javadoc explain the reflection and proxy handling; the compound bridge-method condition requires careful reading, and the unused constructor logic has no clear purpose. Code length: Core methods are reasonably concise, though extensive documentation and pointless constructor code add bulk. Action granularity: Statements generally perform one action per line; the filter overload compresses adaptation and result extraction into one expression. Reading flow: Method order and consistent formatting support natural reading, interrupted by the constructor's indentation and dense conditional logic.

Run 3

Code Structure: Methods and the callback interface are logically organized, but the constructor contains an unrelated, unused toggle loop with inconsistent formatting. Nesting: Generally moderate; the method-selection lambda has nested conditionals, and invocable-method resolution uses nested try/catch blocks. Clarity of intent: Descriptive names and comprehensive Javadoc explain the API well, although the compound bridge-method condition requires careful interpretation and the constructor loop has no apparent purpose. Code length: Mostly appropriate for the functionality, with some verbosity from documentation and exception text; the constructor block is unnecessary. Action granularity: Statements generally perform one action per line, though the filter overload compresses selection, conversion, and key extraction into one expression. Reading flow: The main algorithms progress naturally, with useful early returns and comments, but the oddly indented constructor block and dense conditional expressions interrupt readability.