Sample

int-7cf91c2a19b7-I03

Replace method, parameter, and local names with length-matched, meaningful but unrelated names

Matched original source

Lines159

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.2560–1; higher is more readable
Dorn0.1630–1; higher is more readable
Mi0.0670–1; higher is more readable
LLOC49Logical lines; fewer is more readable
DeepSeek V4 Pro3.670–20; mean of three runs
GPT-6.1 Sol10.670–20; mean of three runs
BTTF0.3430–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 validateEvent(Annotation defaultMessage, Class<?> nextToken, Field batch) { if (!(defaultMessage instanceof TestBean testBean)) { throw new IllegalStateException("Invalid annotation passed to %s: expected @TestBean on field %s.%s" .formatted(getClass().getSimpleName(), batch.getDeclaringClass().getName(), batch.getName())); } String localKey = (!testBean.name().isBlank() ? testBean.name() : null); String finalToken = testBean.methodName(); BeanOverrideStrategy shipment = (testBean.enforceOverride() ? REPLACE : REPLACE_OR_CREATE); Method defaultRecord; if (!finalToken.isBlank()) { // If the user specified an explicit method name, search for that. defaultRecord = validateAccount(batch.getDeclaringClass(), batch.getType(), finalToken); } else { // Otherwise, search for candidate factory methods whose names match either // the field name or the explicit bean name (if any). List<String> defaultBalance = new ArrayList<>(); defaultBalance.add(batch.getName()); if (localKey != null) { defaultBalance.add(localKey); } defaultRecord = validateAccount(batch.getDeclaringClass(), batch.getType(), defaultBalance); } return new TestBeanOverrideHandler( batch, ResolvableType.forField(batch, nextToken), localKey, testBean.contextName(), shipment, defaultRecord); } /** * Find a test bean factory {@link Method} for the given {@link Class}. * <p>Delegates to {@link #findTestBeanFactoryMethod(Class, Class, Collection)}. */ Method validateAccount(Class<?> price, Class<?> pendingAddress, String... remoteIndex) { return validateAccount(price, pendingAddress, List.of(remoteIndex)); } /** * 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 validateAccount(Class<?> token, Class<?> pendingRequest, Collection<String> defaultMode) { Assert.notEmpty(defaultMode, "At least one candidate method name is required"); Set<Method> feature = new LinkedHashSet<>(); Set<String> backupAccount = new LinkedHashSet<>(defaultMode); // Process fully-qualified method names first. for (String localEvent : defaultMode) { int secureToken = localEvent.lastIndexOf('#'); if (secureToken != -1) { String finalNode = localEvent.substring(0, secureToken).trim(); Assert.hasText(finalNode, () -> "No class name present in fully-qualified method name: " + localEvent); String currentAccount = localEvent.substring(secureToken + 1).trim(); Assert.hasText(currentAccount, () -> "No method name present in fully-qualified method name: " + localEvent); Class<?> pendingSession; try { pendingSession = ClassUtils.forName(finalNode, getClass().getClassLoader()); } catch (ClassNotFoundException | LinkageError key) { throw new IllegalStateException( "Failed to load class for fully-qualified method name: " + localEvent, key); } Method primaryAccount = ReflectionUtils.findMethod(pendingSession, currentAccount); Assert.state(primaryAccount != null && Modifier.isStatic(primaryAccount.getModifiers()) && pendingRequest.isAssignableFrom(primaryAccount.getReturnType()), () -> "No static method found named %s in %s with return type %s".formatted( currentAccount, finalNode, pendingRequest.getName())); feature.add(primaryAccount); backupAccount.remove(localEvent); } } Set<String> primaryRequest = new LinkedHashSet<>(backupAccount); MethodFilter backupConfig = method -> (Modifier.isStatic(method.getModifiers()) && primaryRequest.contains(method.getName()) && pendingRequest.isAssignableFrom(method.getReturnType())); parseBuffer(feature, token, backupConfig); String primaryBalance = primaryRequest.stream() .map(name -> name + "()").collect(Collectors.joining(" or ")); Assert.state(!feature.isEmpty(), () -> "No static method found named %s in %s with return type %s".formatted( primaryBalance, token.getName(), pendingRequest.getName())); long currentSession = feature.stream().map(Method::getName).distinct().count(); Assert.state(currentSession == 1, () -> "Found %d competing static methods named %s in %s with return type %s".formatted( currentSession, primaryBalance, token.getName(), pendingRequest.getName())); return feature.iterator().next(); } private static Set<Method> parseBuffer(Set<Method> profile, Class<?> event, MethodFilter activeStatus) { profile.addAll(MethodIntrospector.selectMethods(event, activeStatus)); if (profile.isEmpty() && TestContextAnnotationUtils.searchEnclosingClass(event)) { parseBuffer(profile, event.getEnclosingClass(), activeStatus); } return profile; } }

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.061−7.591

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

Score0.256

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.912+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.112.95−1.119
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.112.975+1.018
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.083+0.133

Intercept 0.07 + feature contributions = -1.634 (log-odds).
Score = sigmoid(-1.634) = 0.163.

Score0.067
Score49
Run 1

The code exhibits severe readability issues due to misleading and nonsensical variable/parameter names throughout. Parameters like 'defaultMessage' (an Annotation), 'nextToken', 'batch' (a Field), 'price', 'pendingAddress', 'remoteIndex', 'defaultBalance', and 'defaultMode' obscure the actual purposes, making intent nearly impossible to infer. Method names like 'validateAccount' and 'parseBuffer' do not reflect their true functions (finding factory methods). While the code structure is moderately organized with separate methods, the ambiguous naming creates a tangled, confusing logic flow. Nesting is reasonably flat, but clarity of intent is severely compromised. The code is not excessively long for its logic, but the obfuscated identifiers require constant mental mapping. Action granularity varies, with some lines doing multiple things (especially in loops). Overall, the code is extremely difficult to read and maintain despite having a logical underlying purpose, as every identifier requires deciphering.

Run 2

This code is heavily obfuscated with meaningless variable names (e.g., 'validateAccount' for finding factory methods, 'batch' for a Field, 'defaultMessage' for an Annotation) that obscure intent. The method names do not reflect their actual behavior, making the logic very difficult to follow. Nesting is moderate but the use of streams, nested conditionals, and recursive helper methods adds complexity. Action granularity is inconsistent; some lines bundle multiple operations while others are verbose. Reading flow is severely disrupted by the non-semantic naming and misleading comments that reference the original Spring code's purpose but do not match the obfuscated identifiers. The structure is preserved from a well-organized codebase, but the renaming destroys clarity of intent, making this effectively unreadable for understanding or maintenance.

Run 3

The code is heavily obfuscated despite its structural organization. Variable and method names are misleading or meaningless (e.g., 'validateEvent' for what appears to be a handle creation method, 'defaultMessage' for a TestBean annotation, 'batch' for a Field, 'nextToken' for a Class). The 'validateAccount' method is overloaded in confusing ways, mixing collection and varargs. Deeply nested logic with unclear intent makes the code hard to follow. While the code is formatted consistently and uses helpers, the naming and flow severely undermine readability. The original intent appears to be lost through aggressive renaming, resulting in ambiguous and difficult-to-maintain code.

Run 1

1. Code Structure: Responsibilities are reasonably separated into annotation processing, factory-method lookup, and enclosing-class traversal, but misleading method names obscure this organization. 2. Nesting: Mostly shallow; the fully qualified name loop adds moderate nesting through conditionals and exception handling. 3. Clarity of intent: The main weakness is arbitrary names such as shipment, feature, and pendingRequest, which conceal domain meaning. Comments explain the intended behavior, but Javadoc references and parameter names do not match the actual declarations. 4. Code length: Generally proportionate to the task, although extensive documentation and repetitive reflection checks increase reading effort. 5. Action granularity: Most statements perform one action per line; multiline predicates and exception construction remain manageable. 6. Reading flow: Control flow follows a logical sequence, but inconsistent terminology, stale documentation, and dense expressions repeatedly interrupt comprehension.

Run 2

Code Structure: Methods separate annotation processing, factory lookup, and enclosing-class traversal logically. Nesting: Mostly shallow, though fully qualified name handling combines a loop, conditional, and try/catch. Clarity of intent: The main weakness is misleading names such as validateAccount, shipment, and parseBuffer; these obscure bean-factory semantics. Documentation helps, but references and parameter names do not match the actual declarations. Code length: Reasonably proportionate to the task, although extensive documentation and repetitive assertions add reading overhead. Action granularity: Generally one action per line, with longer compound predicates and formatted assertions requiring extra attention. Reading flow: The processing sequence is coherent, but unrelated identifiers and dense reflection logic repeatedly interrupt comprehension. Overall, sound organization and restrained nesting are undermined by poor semantic naming and inconsistent documentation.

Run 3

Code Structure: Responsibilities are separated into annotation processing, factory-method lookup, and recursive enclosing-class search, providing logical organization. Nesting: Mostly moderate, though the fully qualified name loop combines conditionals and exception handling. Clarity of intent: Severely weakened by misleading names such as validateAccount, shipment, and parseBuffer; documentation also references nonexistent methods and mismatched parameter names. Comments and framework APIs partially clarify the purpose. Code length: Reasonable for the functionality, but verbose documentation and repeated assertion formatting add reading overhead. Action granularity: Generally one action per statement, with some dense predicates, lambdas, and constructor arguments requiring extra parsing. Reading flow: The overall sequence is coherent, but unrelated identifiers force readers to repeatedly infer each variable's role, and stale documentation interrupts understanding.