Reference guide for detecting AI slop patterns in code including generic variable names, obvious comments, and unnecessary abstractions. Use as reference when reviewing code quality.
This reference documents common "AI slop" patterns in code that indicate low-quality, AI-generated content that should be cleaned up.
Bad: data, result, temp, value, item, thing, obj, info
These names appear frequently in AI-generated code and provide no semantic meaning.
Better: Name things after what they represent:
userData → currentUser, userProfile, activeSessionresult → parsedDocument, sortedItems, validationErrortemp → formattedDate, normalizedInput, previousValueBad: getUserDataFromDatabaseByUserIdAndReturnResult(), calculateTotalSumOfAllItemPricesInCart()
Better: getUser(userId), calculateCartTotal()
The function signature and context provide enough information.
Watch for repeated use of:
foo, bar, baz in production codetest1, test2, test3 as function namesMyClass, MyFunction, MyVariable prefixesHelper, Manager, Handler suffixes without specificityComments that restate what the code clearly does:
# Bad
# Create a user
user = User()
# Increment the counter
counter += 1
# Return the result
return result
# Loop through the items
for item in items:
process(item)Rule: If the code is self-documenting, delete the comment.
# Bad
# TODO: Implement this function
# TODO: Add error handling
# TODO: Optimize this code
# TODO: Refactor this
# Better
# TODO(user): Handle case where API returns 429 rate limit
# TODO(user): Profile this loop - suspected O(n²) bottleneck with n>10000Include WHO should do it, WHAT specifically, and WHY if not obvious.
# Bad
# Check if the user is authenticated by examining the session token
# and verifying it matches our stored tokens in the database
if session.token in valid_tokens:
# If authenticated, proceed with the request
process_request()Better: Just write clear code, or if truly complex, explain the business rule, not the syntax.
# Bad
########################################
# INITIALIZATION
########################################
########################################
# MAIN PROCESSING LOGIC
########################################Better: Use functions or classes to organize code. Comments shouldn't be needed to show structure.
# Bad - AI-generated overengineering
class UserManagerFactory:
def create_user_manager(self):
return UserManager()
class UserManager:
def get_user_repository(self):
return UserRepository()
class UserRepository:
def get_user(self, user_id):
return db.query(User).filter(User.id == user_id).first()
# Better
def get_user(user_id):
return db.query(User).filter(User.id == user_id).first()Rule: Don't add abstraction layers until you need them. YAGNI.
Not everything needs to be:
Use patterns when they solve real problems, not because you learned about them.
# Bad
try:
result = dangerous_operation()
except Exception as e:
print(f"An error occurred: {e}")
pass # Continue anywayBetter: Catch specific exceptions and handle them appropriately.
# Bad
try:
risky_operation()
except:
passThis is nearly always wrong. If you truly need to ignore an exception, explain why in a comment.
# Bad - AI overthinking simple tasks
def is_even(n):
"""Check if a number is even using mathematical properties."""
return (n / 2) == (n // 2)
# Better
def is_even(n):
return n % 2 == 0# Bad - optimizing before profiling
# Using bit manipulation for "performance"
def multiply_by_two(n):
return n << 1
# Better - clear and correct
def multiply_by_two(n):
return n * 2Rule: Clear code first, then optimize based on profiling data.
Watch for:
Better: Extract common logic into shared functions.
# Bad
if len(input) > 255:
raise ValueError()
# Better
MAX_INPUT_LENGTH = 255 # Database column limit
if len(input) > MAX_INPUT_LENGTH:
raise ValueError(f"Input exceeds maximum length of {MAX_INPUT_LENGTH}")# Bad
def process_data(data):
"""Process the data.
Args:
data: The data to process
Returns:
The processed data
"""
passThis adds zero information. Either document properly or don't document at all.
Watch for:
Not everything needs exhaustive documentation:
# Bad - Internal helper function
def _format_date(date_obj):
"""Format a date object into a string.
This function takes a date object and formats it according to
ISO 8601 standards. It is used internally by the DateProcessor
class to ensure consistent date formatting across the application.
Args:
date_obj (datetime): A datetime object representing the date
to be formatted. Must be a valid datetime
instance with timezone information.
Returns:
str: A string representation of the date in ISO 8601 format.
The format includes year, month, day, hour, minute, and
second components with timezone offset.
Raises:
ValueError: If date_obj is None or not a datetime instance.
TypeError: If date_obj is of an incompatible type.
Example:
>>> dt = datetime.now()
>>> _format_date(dt)
'2024-01-15T14:30:00+00:00'
Note:
This is an internal function and should not be called directly
by external code. Use the public DateProcessor.format() method
instead.
See Also:
- DateProcessor.format()
- parse_date()
- validate_date()
"""
return date_obj.isoformat()
# Better for internal helper
def _format_date(date_obj):
"""Return ISO 8601 formatted string."""
return date_obj.isoformat()lambda when a function would be clearer*args, **kwargs without clear needexcept Exception:any types in TypeScriptObject types instead of genericsresult that holds different typeshandleData, processInfo, manageItemsSometimes patterns that look like slop are actually appropriate:
i, x, acc in a 3-line function is fineThe key is distinguishing between intentional engineering decisions and mindless pattern repetition.