Yes, you are not mistaken. The Internet is already full of articles with good recommendations and tutorials for developers. You can find a certain number of them in my blog . This article, excuse me, will differ radically from them, but only for the better! I will talk about five deadly sins that can be committed in code. Thanks to these disgusting practices, anyone who has to work with your code will hate you. If you are ready to accept this secret knowledge, then let's go.
Bad Practice # 1: Make Puzzles Out of Names
Let's take something simple to warm up. A good place to start is to add more abbreviations to variable and function names. I know, I know, everyone says that good names should describe the purpose as clearly as possible. Well, there is handleFormSubmit , getUserConfiguration or parseCustomerInformation . But we are not chasing good things.
For the worst result, try to shorten words and use acronyms as often as possible. Then the next developer will have to puzzle over to figure out what you mean. Here are some good examples: handleBtnClick , getConfig , parseInfo... They don't give too much information, but they can be easily guided through code inspection. In addition, unnecessary abbreviations like btn , func , config , cb will help to complicate the perception .
And with the names of variables in general you can turn around. Do you have a list of unverified users? Don't call it uncofirmedUsers , just users . Then the next developer will be forced to read all the code that returns the variable in order to understand what is the point. No discountedProductsfor this poor fellow, a simple product in the name will be enough for him.
If you want to add some more spice to the names, you can play with the register. Colleagues will be ready to kill you, I guarantee. Instead of creating something in the spirit of readXmlDocument (that is, starting abbreviations with a capital letter, like simple words, according to the precepts of good practices), you can always construct a readXMLDocument method , which you will not immediately grasp and you need to read it carefully.
Of course, code inspections may try to stop all this madness, but your task is to fight. It does not matter for what - because of the fact that you are too lazy to rule, or out of a desire to preserve your reputation as a brawler. In any case, the main thing here is not to forget: you can always promise to change everything for the next pull request and hope that by that time everyone will be forgiven and forgotten (most likely, it will happen).
Bad Practice # 2: Write Extremely Complex Code
Here lies the opportunity to prove that you are the true Rick Sanchez of programming. You just need to make the code a little more clever than required. You might be able to generalize so that you can use three lines of code twice by creating a method that takes five parameters. You might want to reduce three lines of code to one with a clever ternary nesting operator. Let your imagination run wild!
It will of course become more difficult to read and maintain the code after that. But this will surely be a headache for your colleagues, and not yours? So that's great.
So come on, show that you are a real hacker. I advise you to use method chaining, nested conditionals, bloated design patterns, and one-liners that take advantage of the hipster, niche features of the language as much as possible. After all, why write Date.now () if you can get the same result with the somewhat more mysterious + new Date () ? I am sure that other project participants will hang over the code with a great sense of gratitude, trying to understand what is going on in general.
And do not forget: the more you wise and over-optimize in the code, the more difficult it will be for your colleagues later with it. You get ten points for each reduce function and one hundred for each recursive call. By the end of the project, at such a pace you will become a real professional, with which I congratulate you.
Bad practice three: import as much as possible
I admit: problems with the previous technique can arise during the code inspection stage. But on the other hand, if you write in JS or PHP, then you will have a whole bunch of import / use statements at the beginning of almost every file. Many developers do not even look at them during the inspection, they immediately move on to what they consider to be the pulp itself. This is why dependencies are the perfect opportunity to create horror in your code. Imagine
that you have a view UserSubscriptions in a React application. You create a file with the calculateTimeToSubscriptionEnd helper function ... Perfectly. But where to place it? In a separate directory, where everything is stored, from which the domain logic of subscriptions and payments is built? Of course not. Put it better next to the view you just created.
This is how you think for the future, because when you finally have the admin panel (and in it - view Subscriptions ), nothing can stop you from importing the helper function from custom views. And no one is likely to notice, because no one cares about the import. This will link two completely extraneous modules and create hell on earth for anyone who tries to refactor or make changes. Trust me, nothing will drive a developer crazy faster than a project with a terrible structure.
You might say, "Well, that's not a big deal either." Inexperienced developers won't try to fix something for a long time. They will suffer with this confusion out of the conviction that, probably, nothing should be touched here. Each new attempt to understand the structure of the application will cause suffering. And if anything related to the function is updated or removed, it will get even worse. The confusion is not great, but everyone will suffer from it until there is some hero who will fix everything. It might even be you.
Bad practice four: write different behavior for the same functions
Do you consider yourself a creative, artistically gifted person? Then here's a torture idea you'll love.
The world is an unpredictable place, and no one has ever said that everything will work according to the same principle. And that consistency and predictability are the key to the productive work of the developer and the success of the project, no one said either ... I mean, many said, but today we do not listen to them. We intend to ruin someone's day by throwing similar functions into their codebase that behave slightly differently.
For example, suppose you have a validation function that returns true if the data is valid and an error message if something is wrong. What if the next validator returns falseor undefined for valid data? Any plans to neatly spell out the form data validation will fall apart. That's good.
Or, say, you can accept arguments in each function in a new format. Suppose that one accepts user IDs, and the other accepts only the entire object as a whole (even if in fact only the ID is needed). Or maybe you can request the user's email? This will spoil the blood of the developer who will be handed your code.
I am sure that you will come up with even more ingenious ways to surprise your colleagues - you can make anything unpredictable. Down with consistency, long live arbitrariness! And one more thing: never think at the level of the codebase as a whole, try to add something interesting to each file separately. In other words, be an artist, not an engineer. The other developers on the team will hate you with all their hearts - because, of course, you were ahead of your time.
Bad practice # 5: copy everything
If you bring this to life, your code will definitely not be touched by anyone. Don't split common logic across different functions, classes, or components. Just copy and paste the lines you want from file to file. In the end, your code is very valuable and flawless, let people admire it throughout the project. Let it shine!
However, this is not the only reason for duplication. In case of updates, developers will have to make changes to several files at once. Moreover, if someone misses one or more cases of copying logic (and if the tests in the project are tight, someone will definitely miss it), then he will have to re-punch the code a second, or even a third time. What could be more fun than looking for duplicate chunks in hundreds of files in your codebase? I am sure your colleagues will appreciate it.
Remember, abstraction is difficult and time consuming to do well, so don't bother with it - just copy the code as needed. At code inspections, this will be treated with understanding. If not, then you can spend the saved time explaining why your invaluable code must be reproduced. Everything will work out, I believe in you.
Well, okay, Satan is calling me here, round off.
Of course, this is a joke article. Do not do what I wrote here (seriously, don’t, I don’t grow weak). Do the opposite:
- make sure titles are clear and informative;
- write simple, understandable code for everyone;
- create a clear project structure;
- don't forget about consistency and predictability in interfaces;
- share common logic where possible without compromising clarity.
Yes, and never make your colleagues angry. There is a saying in the programming community: write code as if a serial killer would continue to work with it. Nobody wants to ruin a relationship with a serial killer, do they? That's the same. But I don't like this logic. It seems to me that it is better to write the code as if you yourself will continue to work with it. Just ask yourself: "I would like to come across this fragment after I forget why I wrote it?"