The Art of the Redundant Comment

Level 1: Saying It Twice

Think about sorting your toy cars into a box and then sticking a note on the box that says “Toy Cars.” If the box is see-through and you can already see the cars inside, that note isn’t telling you anything new – it’s kind of silly, right? That’s exactly what happened here, but with code. The programmer made an “array” (which is like a container for a bunch of values, similar to that box for toys) and then wrote a comment that basically says “this is an array.” Everyone can already tell it’s an array from the code itself, so the comment is unnecessary. We find it funny for the same reason it’s funny to label a dog’s photo with the word “dog” – it’s stating the obvious. The joke is that the person was being too literal with their note, and now their future self (and all of us) can’t help but laugh and say, “Yes, we know it’s an array – you didn’t need to tell us twice!”

Level 2: Explaining the Obvious

Let’s break down what’s happening in that code and why developers are reacting to it. Even if you’re new to programming, the humor becomes clear once you understand the pieces:

• PHP Code and Variables: This is written in PHP, a programming language often used for web development. In PHP, variables start with a $ sign. So $array is a variable named “array.” Think of a variable as a container for data. Here, $array is our container’s name.

• What is array()? In PHP, array() is a way to create an array, which is basically a list of items. Writing $array = array(); means “create an empty list and store it in the container called $array.” In newer versions of PHP, there’s a shorter way to do the same thing: $array = [];. Both do the exact same thing – they make an empty array. The code in the meme uses the older array() style, which hints that it came from an older codebase or an old-school coder. It’s like telling us this project lived in the days before PHP had the nicer, shorter syntax. (It’s a bit like saying “do not” instead of “don’t” – both are correct, one’s just a more modern style.)

• The Comment // array: In code, anything after // on a line is a comment. Comments are notes for humans; the computer ignores them. They’re usually used to explain tricky parts of code or to provide context. In the snippet, the comment is literally the word “array”. So the whole line reads: “$array equals an empty array; comment: array.” Essentially, the programmer wrote a note to themselves that this variable is an array. But… that’s obvious from the code itself! It’s as if the code is saying, “I’m making an array (by the way, this is an array).” Redundant, right? This is what we call a redundant comment – it doesn’t add any new information. It’s the programming equivalent of explaining a joke right after telling it.

• Why Developers Facepalm at This: When you’re learning to code, you might have heard “always comment your code.” New developers sometimes take that advice a bit too literally and comment every single line. The result can be comments that simply restate the code. For example: x = 5; // assign 5 to x. These don’t help anyone understand the code – they just repeat it. As you gain experience, you learn a better rule: comment why the code does something, not what it’s doing. The code already shows the “what.” In our snippet, any programmer can see $array = array(); and know it’s creating an empty array. A useful comment might have said why we need an empty array or what it will hold (e.g. // list of active users to be filled later). But just saying // array is a bad practice because it states the obvious. It’s like labeling a legacy codebase folder “old code” – you already know it’s old code by looking at it!

• Meaningless Variable Name: Another thing here is the choice of the variable name $array. In programming, a good variable name describes the role of the data. If this array was meant to hold, say, customer orders, a good name might be $orders. Naming it $array is not helpful to anyone reading the code later. It would be like calling a file “file.txt” – the name doesn’t tell you if it’s a resume, a recipe, or a list of passwords. 🤦‍♂️ It’s considered poor CodeQuality to use such generic names. Combined with the comment, it looks like the coder was unsure or just trying to fill something in. Often, when we see code like this, we suspect it was written by someone early in their learning journey or someone rushing. It’s a little coding mistake that many of us have made starting out.

• Legacy Systems and Nostalgia: The person who posted this said it was from an “old project.” In tech, we call old, outdated code legacy code. Working with legacy code often feels like archaeology – you dig up strange artifacts from the past. This // array comment is one of those artifacts. It’s a tiny peek into how code was written (or how this person wrote code) years ago. Maybe back then, the team had no code reviews or no standards, so these things slipped in. Or maybe the author was just learning PHP and was overly cautious. Now, discovering it years later is both funny and educational. It shows how the author has grown as a developer – they recognize this is silly now. Refactoring is the process of improving old code without changing what it does. If someone were refactoring this code today, they’d probably do two things immediately: rename $array to something more descriptive and delete that useless comment. The code might become:

  $customers = [];  // an empty list of customers to start with
  

  Here, $customers tells us what this array is for, and the short [] syntax is modern PHP. We might still include a comment, but it would convey info (“list of customers to start with”) instead of stating the obvious.

• Shared Laughs in the Dev Community: Why is this meme popular? Because so many developers have done the exact same thing at some point! It’s a form of developer self-deprecation – we laugh at our past selves. Maybe you haven’t written // array, but perhaps you’ve written a comment like // loop through list on a loop, or named a variable temp that lived for 5 years in production. The meme is essentially saying, “Look at this goofy thing I once did.” And the response from others is, “Haha, I’ve been there. We’ve all got silly old code hiding somewhere.” It’s a lighthearted reminder that coding is a learning process. What was acceptable or unnoticed in a legacy codebase years ago might look ridiculous against today’s best practices. And that’s okay – it means we’ve improved our craft.

In plain terms, this meme highlights why clear coding practices matter. It teaches newcomers that comments should be meaningful, and names should convey intent. It also reassures everyone that making mistakes is normal – even the person who wrote that comment can now smile and say “What was I thinking?” So if you’re a junior dev, take note: avoid redundant comments and choose good names, but also know one day you’ll look back and chuckle at some of your own old code. That’s just part of the programmer’s journey!

Level 3: Department of Redundancy Dept.

This meme captures a classic code smell that makes seasoned engineers smirk and cringe at the same time. In the screenshot, a line of PHP code defines a variable and then immediately explains it in the most pointless way possible:

$array = array(); // array

Let's unpack why this line is both humorous and horrifying to a senior developer:

• Overly Literal Naming: The variable is literally named $array. It tells us nothing about what the array contains or why it exists. It’s as if the original coder couldn’t think of a descriptive name, so they just named the thing after its type. In a large codebase, seeing $array is a nightmare – it’s too generic. Imagine a codebase with $array1, $array2, ... $arrayN scattered around; it’s a maintainability disaster because no one knows the purpose of each array without diving into usage. This naming is a hallmark of legacy code where meaningful naming conventions were ignored or the author was a beginner who hadn't yet learned that naming things is hard (and important!).

• Redundant Comment (Don't Repeat Yourself – DRY? What’s that?): The inline comment // array is stating exactly what the code already says. It’s the coding equivalent of a sign on a door that reads “Door.” Comments are supposed to clarify or provide insight (like the why or how), not reiterate the obvious what. This comment violates the DRY principle: it duplicates information with zero value added. Experienced devs often joke about comments like i++; // increment i – they provide no new knowledge and become “noise” in the code. Here, the comment is as if the code itself is in the “Department of Redundancy Dept.”: repeating “array” to describe an array. Senior engineers have encountered this in old projects and often roll their eyes. It’s funny in a tragic way: someone (perhaps our own past self) thought this was helpful documentation!

• Legacy PHP Syntax: The snippet uses array() to initialize an empty array. Modern PHP (versions 5.4 and above, circa 2012+) introduced the short syntax [] for arrays. By 2019, any active PHP project had likely moved on to [] because it’s cleaner and more concise. Seeing array() is a dead giveaway that this is legacy code – either the project is old or the coder learned PHP back in the day and stuck to old habits. It’s a tiny detail, but to a seasoned developer it screams “time capsule”. It places the code in an earlier era of PHP, before current style standards. That adds to the humor: not only is the comment redundant, but it’s written in an outdated way, ticking multiple CodeQuality warning boxes at once.

• Context – Why It’s Relatable: The tweet caption says, “just found this in one of my old projects.” Every experienced programmer has been there – digging through a legacy codebase (perhaps preparing for a big refactoring) and stumbling upon a gem of a comment or absurd variable name from years ago. It’s a mix of embarrassment and nostalgia. The developer is essentially laughing at their younger self, a common form of DeveloperSelfDeprecation. We’ve all written questionable code in our early days (maybe in a rush or out of ignorance) and later discovered it with horror. The meme triggers that shared memory: “Oh wow, I remember when I commented every line because I thought I had to!” or “I once named a variable data and commented // data – what was I thinking?” It’s a bonding moment for senior devs, who often swap war stories of CodingMistakes and BadPractices they committed in the past.

• Why This Is Funny (and a Bit Sad) in Practice: From an architectural or CodeQuality perspective, this line is harmless in functionality – it won’t crash anything. But it speaks volumes about the code’s maintainability and the coder’s mindset. It hints that the project might be full of such overly literal, unhelpful comments and poorly named variables. That’s the kind of technical debt that makes refactoring tedious: you have to read through mountains of noise to figure out what the code is doing. Senior devs find humor in it because it's a benign, almost cute example of bad code (nobody died from a // array comment), especially compared to more serious legacy horrors. It’s like finding an ancient artifact of programming naïveté. You can almost hear past-you saying, “I better comment that this is an array, just to be clear,” and present-you facepalming. The meme crystallizes that moment of “I can’t believe I wrote that” which is simultaneously funny, humbling, and universal in our industry.

In summary, the combination of an obviously-named variable, a redundant comment, and an outdated syntax creates a perfect storm of legacy code cringe. It’s painfully on the nose. Every element in that single line is a mini anti-pattern. Seasoned developers laugh because it’s an absurdly literal example of what not to do, and yet it’s utterly believable – we’ve seen it (heck, we’ve done it). This one screenshot manages to satirize a whole class of coding mistakes in one go. RefactoringNeeded? Absolutely. But first, let’s have a chuckle and thank the coding gods that we’ve learned a few things since then.