AI Is Terrible at Naming Things (And So Am I)

"There are only two hard things in Computer Science: cache invalidation and naming things." - Phil Karlton

He forgot the third: stopping AI from naming everything like a government form. Last week, AI named a function `processDataAndReturnProcessedDataResult()`. I'm not joking.

The AI Naming Hall of Shame

Real names AI has suggested in production code:

// For a function that gets a user
getUserDataByUserIdForUser()

// For a boolean flag
isUserLoggedInBooleanFlag

// For a click handler
handleClickEventHandlerFunction()

// For a data transformation
transformDataFromOldFormatToNewFormat()

// For a simple counter
currentCounterValueNumber

It's like AI learned naming from Java enterprise architects who get paid by the character.

The Opposite Problem: Too Abstract

// AI's "clean" names
function process(data) { }
function handle(thing) { }
function execute(param) { }
function perform(input) { }
function doWork(stuff) { }

// What do any of these do? Nobody knows!

The Department of Redundancy Department

AI loves redundant names:

// The word "array" appears 3 times
const userArrayArray = new Array();

// We know it's a method, it's inside a class
class UserService {
  getUserMethod() { }
  saveUserMethod() { }
  deleteUserMethod() { }
}

// The "Manager" manages managers
class UserManagerManager {
  manageUserManager() { }
}

The Boolean Naming Disasters

// AI's boolean names
let isNotInvisible = true;        // Just use isVisible
let isNotUnavailable = false;     // My brain hurts
let hasNoErrors = true;           // Why not isValid?
let isNotFalse = true;            // This is just true with extra steps

// The worst one I've seen
let isActiveStatusEnabledFlag = true; // Pick ONE word!

The Type-In-Name Syndrome

// TypeScript already tells us the type!
const userString: string = "John";
const ageNumber: number = 25;
const isActiveBoolean: boolean = true;
const userObjectInterface: User = { };

// Arrays get it worst
const userArrayList: User[] = [];
const stringArrayOfNames: string[] = [];

Real Naming Disasters From Code Reviews

The Kitchen Sink Function

// AI tried to name a function that does too much
async function fetchUserDataAndOrdersAndUpdateCacheAndLogActivityAndSendEmailIfNeeded(userId) {
  // 200 lines of code
}

// Should have been 5 different functions

The Acronym Soup

// AI loves meaningless acronyms
const UDAM = getUserDataAndMetrics();
const PRMQR = processRawMetricsQueryResult();
const FTCDWP = fetchTokenizedContentDataWithParams();

// Six months later: "What the hell is FTCDWP?"

The Timestamp Confusion

// All in the same file
const created = Date.now();
const createdAt = Date.now();
const createdDate = Date.now();
const createdTime = Date.now();
const createdTimestamp = Date.now();
const createTime = Date.now();
const creation = Date.now();

// They're all the same thing!

Why AI Is Bad at Naming

1. No context understanding - Doesn't know what's important
2. Overfitting to patterns - Saw long names in enterprise code
3. No sense of irony - Takes "descriptive names" too literally
4. Conflicting training data - Mixed clean and terrible examples

The Naming Rules That Actually Work

1. The Goldilocks Principle

// Too short
function p(d) { }

// Too long
function processUserDataAndReturnTransformedResult(data) { }

// Just right
function transformUser(data) { }

2. Boolean Naming Rules

// Start with is, has, can, should
isActive
hasError
canEdit
shouldUpdate

// Avoid negatives
isVisible > isNotHidden
hasData > doesNotHaveNoData

// Be specific
isLoggedIn > isUser
hasAdminRole > isSpecial

3. Function Naming Patterns

// Actions: verb + noun
getUser()
saveOrder()
calculateTotal()

// Conversions: noun + To + noun
csvToJson()
userToDTO()

// Checks: is/has/can + condition
isValid()
hasAccess()
canDelete()

The AI Naming Prompt That Works

"Suggest names following these rules:
- Maximum 3 words
- No type in name (no 'String', 'Array', etc)
- No redundant words
- Use common verbs: get, set, create, update, delete
- Boolean: starts with is/has/can
- Avoid generic names: data, info, process, handle
- If you can't name it clearly, the function does too much"

My Favorite AI Naming Fails

// The Stutterer
UserUser.getUserUser()

// The Philosopher
AbstractDataTransformationFactoryInterface

// The Liar
quickSort() // Uses bubble sort

// The Optimist
temporaryFix() // Still in production 3 years later

// The Pessimist
probablyWillWork()

// The Honest One
noIdeaWhatThisDoes()

The Evolution of a Variable Name

// Day 1
data

// Day 2 (code review)
userData

// Day 3 (another review)
userResponseData

// Day 4 (getting ridiculous)
userApiResponseData

// Day 5 (please stop)
userApiResponseDataObject

// Day 6 (I give up)
u

Tips for Better Names (For Humans and AI)

1. Name by purpose, not type - `users` not `userArray`
2. Use searchable names - `MAX_RETRY_COUNT` not `3`
3. Avoid mental mapping - `user` not `u`
4. Be consistent - `getUser` and `getOrder`, not `fetchCustomer`
5. Question long names - They often hide design problems

The Naming Game

Next time AI suggests a name like `processDataAndReturnProcessedDataResultObject()`, try this:

1. What does it actually do? (transforms user input)
2. What's the input? (raw user data)
3. What's the output? (validated user)
4. Better name: `validateUser()`

AI naming things is like asking a robot to name a baby - technically correct suggestions like "Human_Offspring_2024_Instance" that miss the point entirely. Good names tell a story, bad names require one. And if you find yourself typing more than three words, you're probably compensating for a function that does too much. Remember: the best code is written for humans, not compilers. Even if an AI is doing the writing.