A Casing Style So Bad, Not Even Hell Wants It

Level 1: Too Messy Even for the Naughty List

Programmers have spelling rules for naming things, like agreeing that everyone on a team writes dates the same way so nobody gets confused. This person named something in a way that breaks every rule at the same time — capital letters in random places, dashes and underscores mixed together, letters disguised as numbers. The joke is that he's so bad at it that when he shows his work to the devil — the one guy whose whole job is welcoming bad people — even the devil gasps in horror and won't let him in. It's like showing up to a monster's house and being too scary for the monster.

Level 2: A Field Guide to Casing

The joke assumes you know the casing taxonomy, so here it is:

Each language community standardized on one or two of these, and a naming convention simply means: pick the local one and never deviate. The meme's identifier deviates in every direction at once.

Why anyone cares: you read code far more than you write it. Consistent casing lets you skim — you see MAX_RETRIES and instantly know it's a constant without checking. Inconsistent casing forces a tiny conscious decision on every name, and those micro-costs compound across a 100k-line codebase. This is also why your first week at a real job involves a linter (a tool that flags style violations automatically) and a formatter rejecting your pull request. It's not hazing; it's the team outsourcing arguments to a config file so code review can focus on logic instead of aesthetics. And one practical warning from lOOk: never put characters in names that can be confused for others (l/1, O/0) — someday, someone will debug for an hour because of it, and that someone is usually future you.

Level 3: Crimes Against the Style Guide

Satan: So what are you in hell for? Me: Because of my casing style Satan: Can't go to hell because of casing style Me: here_lOOk-At_it Satan:

— and the final panel is a vintage cartoon devil recoiling in wide-eyed horror, hand to his face. The Prince of Darkness, who presumably processes war criminals before lunch, draws the line at this identifier.

Dissect here_lOOk-At_it and you find it's not one violation — it's a combinatorial one, which is why it reads as genuinely cursed rather than merely sloppy. It mixes snake_case (here_), kebab-case (-At), and arbitrary mixed capitalization (At_it) in a single name, which in most languages isn't even legal: the hyphen makes it a subtraction expression in Python, JavaScript, Java, and C — here_lOOk - At_it — so this identifier doesn't violate the style guide so much as the parser. And the middle segment, lOOk, weaponizes lookalike characters: a lowercase l followed by two capital Os, visually impersonating 100k. That's the same homoglyph trick used in actual supply-chain attacks (typosquatted package names, spoofed domains), which means this name isn't just ugly — it's adversarial. Code review exists precisely because some defects are invisible to compilers but obvious to a horrified human face.

The deeper truth being satirized: naming conventions are one of the few zero-cost, high-leverage agreements a team can make, and yet they generate the most theological conflict. Casing carries semantic weight by convention — PascalCase for types, camelCase for variables, SCREAMING_SNAKE for constants, kebab-case for CSS and URLs — so a reader's brain pattern-matches on shape before reading letters. An identifier that scrambles those signals doesn't just look bad; it actively lies to the reader about what kind of thing it is. That's why teams enforce this with linters and formatters rather than trust: the entire point of tools like ESLint's camelcase rule or gofmt's opinionated tyranny is to make this meme impossible by construction. The joke's framing is perfect — the sinner doesn't get condemned for the identifier, he gets rejected. Even hell has standards, and this fails intake review.