This is the 15th day of my participation in the August More Text Challenge

This article will show you five bad code practices that any programmer would hate to have.

1. Make variable naming a puzzle game

A. ParseDBMXML. B. Parse DB MXML. C, parse DB Mx markup language D. Parsing DB Mx machine learning.

First, start with the simplest things, adding unnecessary abbreviations to function or variable names. Good code practices recommend that people make their purpose as clear as possible in naming, such as handleFormSubmit, getUserConfiguration, or parseCustomerInformation.

Bad code practice is to use as many abbreviations and abbreviations as possible in your naming, so that the next developer who takes over your code has to guess what you’re trying to do.

Names like handleBtnClick, getConfig, or parseInfo are pretty arbitrary. The names don’t tell you much about the functions, but they are acceptable to others doing code reviews. Unnecessary abbreviations are even more confusing. BTN, func, config, or CB are just too hard to understand.

Variable naming can move more hands and feet! Have a list of unconfirmed users? Instead of writing unconfirmedUsers, use Users so that the developer who takes over will have to read through your entire code to figure out what the variable refers to. Don’t use discountedProducts for this poor developer, just product.

Want to stoke the fire? Yes, capitalization is your next toy, and I promise you, the people who take over your code will hate you. Instead of using the good code example readXmlDocument (abbreviations should have the same case as other words), readXmlDocument will make other developers read your code more carefully, and read your variable names more carefully to figure out what you’re trying to say.

Sure, all of these obfuscations will die during the code review phase, but you’re not going to let it go, are you? Maybe it’s laziness or your rebellious personality, but either way, you can always brag, fix it in your next PR, and cross your fingers and hope your colleagues forgive your SINS (which they probably will).

2. Complicate code

Me: Trying to write the entire function in one call

I don’t know if you’ve ever had a chance to prove yourself the Rick Sanchez of software development.

All you have to do is add unnecessary complexity to your code.

Like reusing three lines of code in two places by generalizing? All you have to do is write a little function that takes five variables. To be a little more clever, you can even abbreviate these three lines of code into an elaborate three-tiered nested triple operation! Imagination has no limits, my friend!

Sure, this makes the app harder to read and maintain, but that burden probably only falls on your colleagues, right? That would be great!

So go ahead and use the code to prove you’re the real hacker. I would suggest you try chained functions, nested conditional statements, overblown design patterns, and clever single-line code that takes advantage of some little-known tricks of programming languages. Why use the cliched date.now () when we can use the more arcane +new Date()? I’m sure your colleagues on the project will thank you very much as they figure out what’s going on with your code!

Keep in mind that the more elaborate and prematurely optimized the code, the worse it will be for your colleagues handling it. Add a lot of respect to each reduce function you use, and add a hundred points to each recursive call. By the end of the project, you will be a real master programmer. Come on!

3. Messy import

I: Trying to explain the dependency level of the project

We mentioned earlier that these tricks are likely to fail during the code review phase, but if you’re a Web developer using JS or PSP, there’s a good chance that all of your files will start with a string of import or use statements. Developers don’t bother with these things when they’re doing reviews, they just focus on the juicy bits.

That’s why dependencies are a good place to mess with code.

Try to imagine that you have a call in the React UserSubscriptions view, and then create a helper function called calculateTimeToSubscriptionEnd. So, now the question is, where do you put this helper function? In a separate file that holds all domain logic related to subscriptions or payments? How boring. Put it right next to your new view!

Planning ahead to create the admin panel and the Subscription view in this example, you can import the helper functions you want directly from the user’s view. After all, no one cares about the import list. Mixing two unrelated modules makes it hard for someone else to modify or refactor your code. Trust me, developers hate poorly structured projects more than anything else.

What did you say? “That’s not messy enough”? Novice programmers probably won’t touch your code for a while, struggling with the mess you’ve created and thinking it’s best to keep it that way. Every time a new developer tries to understand the structure of your project, it brings a new round of torture, which is doubly returned when something is updated or removed from the development that you mentioned in the import. A bad mess for everyone, a mess that only a warrior can save, maybe you could try to be that warrior?

4. The same function that operates in different ways

Man: I added a new user-specific node in the admin interface that returns new data

W: Does it accept a user ID just like any other user-specific node?

M :(what do you think?)

Woman:… Will receive the user ID just like any other user-specific node, right?

Maybe you think of yourself as a creative and artistic person. Allow me to introduce you to a new form of torture.

The world is changing so fast that no one ever said everything had to stay the same. No one ever said that consistency and predictability are the keys to a good development experience and a successful project. Maybe someone did, but we don’t have to listen to them, right?

Our job is to ruin someone else’s day by allowing a function in the code base to have a little bit of variability.

For example, a validation function returns True if the data is validated and a failure message if it fails. So, if this function returns False or undefined if the data is correct, your colleagues will probably have to write a few more cases to handle your return, which is pretty neat.

Of course, you can accept arguments of different shapes in all functions. Take the above image for example, let some functions accept user ids, and others accept the entire user object when they could just use the user ID at all. Maybe you can find some way to accept users’ email addresses? The guy who takes over your code is going to face hell.

You can even add an element of surprise to make things unpredictable. Forget consistency, long live randomness! Of course, don’t worry about the entire codebase. It would be nice to go file by file. What’s the point of being an engineer? It’s better to be an artist! I’m sure your fellow developers will hate you with their hearts. But what’s the point? You’ve got an early lead.

5. Copy and paste code everywhere

My code base: copy and paste the same code from other files into different files

And when you do, I’m sure no one will ever want to work with you again.

Don’t spread the same logic into different functions, classes, and components. Just copy and paste the few lines of code you need.

After all, your code is perfect and meaningful, and everyone has to see it multiple times in different parts of the project. Let your code shine!

But as you know, that’s not why you’re copying code like crazy. In some updates, developers are required to change a large number of files at once. If the test scope is insufficient, someone might forget to delete the repeat logic once or twice and have to start a second or even a third update. What could be more fun than searching for duplicate code in hundreds of files? Your colleagues are going to enjoy it.

Remember when I said that good abbreviations are hard and a waste of time? So why don’t we just copy the code where we need it? Otherwise, you’ll probably have to spend a lot of time explaining why you keep copying your old code. I believe you, you can do it!

6, summary

Obviously, this article is just for fun. Please do not try any of the operations I describe in this article. This is not a “50 cent bet” joke.

Be sure to do the opposite in practice:

  • Keep naming clean in your code

  • Keep your code simple and easy to understand

  • Maintain a clean project structure

  • Remember to use constants and predictable interfaces

  • Split the same logic while keeping the code clean

And most importantly, be nice to your co-workers!

There is a saying in the development community that you should always write code as if it were taken over by a serial killer. You don’t want to be targeted by a serial killer, do you? I think you should write code thinking about how you would feel if you were the next person to take over the code. As you program, always ask yourself, “Would I want to see this code if I couldn’t remember what it was for?”