I wanted to talk to you about my seven favor.

Anti patterns were drinking Starbucks iced coffee today.

Not too shabby now.

Why our anti patterns important to know about.

And there's two main reasons I can think about, but there may be plenty more.

The first is very useful for job security.

You can use anti patterns to essentially obvious Kate.

The code so much make it so incomprehensible.

Turned the coat into such garbage quality that nobody else is able to understand.

And you'll be the only person who is able to understand the code.

You'll be the only one who can read it.

Everyone on the team will soon become into you to ask, How does the code function?

How does that work?

Because it is so loopy and so strange.

Practiced over time.

The strategy can help you secure your job and even help you obtain the row of tack.

Lied like it did for myself.

The second obvious usage for anti patterns is revenge.

If you're just out to destroy a code base because you're a disgruntled employee, or maybe you just want to watch the world burn then and time partners are an excellent way to do it.

The reason is that many people will not approve code that is obviously bad.

You need the code to look at least legitimate to at least get through code reviews.

Anti patterns have that certain quality, where it looks like the code is legitimate.

Looks like the code is good, and yet it will turn the code base into absolute mush.

Overtime in this sort of damage to code health is essentially irreversible.

It will take a long time and a lot of effort for people to re factor and make a cleaner.

And one thing that would discuss here is that many teams simply will not take the time to re factor Coach Bass to make it cleaner just for cleanliness sake.

That sort of structural damage to a code base, once it's done, is very difficult to reverse.

You know, an anti pattern is just a tool.

It can be used for good or bad.

I'm just here to explain how to use them.

Let's get into it.

Tip number one, Create the tons of functions.

If you already have a function that's doing something, break it down into three or four other functions each and for each of those, break them down into other functions to.

And pretty soon, the only way to read your code is the jump from function to function to function.

It's essentially spec Eddie code, and yet it's not going to read like it is not going to look like it, because everything is broken down into neat little functions and you'll be able to easily get this sort of code passed through code review.

Now, if anybody ever asks you, why are you doing this?

You could just say that you're making it more units testable.

And so for each function, you write a unit test, and you could help justify why you need so many different functions.

You're making it easily testable.

Thea Other thing that you can do is you can try removing any lines of duplicate coat.

You can just say, Hey, this ad, the operation is being done in two different places in the code, so you're just going to make a function so that you don't have to duplicate that all over the place.

You can create a function like adds two numbers.

That's the name of the function, and it just ask two different numbers.

You can create another function like creates function or create four loop create switch statement.

If you look through a code base, you almost certainly be able to find some area where there's some duplicate coat being used.

Most programmers are trained to believe that you should not be duplicating code.

You're easily be able to get this through code review.

The second tip is to use as many one liners and cryptic code as possible.

If there are multiple lines of code, you can usually join them all together into a single line using, say, the end or the or operator.

I also love using bit manipulations.

Instead of using multiple bullies, you can combine them, are into a single bite array and then do bit manipulation to figure out the bullion values.

When people ask, you can just say that this is going to be more efficient.

Everyone loves but manipulations.

They think it's more advanced.

Another trick you can do, which I've seen some people on my team, do is any time.

There's an if statement in the condition you put a double exclamation mark.

So you're taking the not not of a value and technically, this is more correct because it turns the value into an actual bullion.

Before you compare in the F statement, it looks extra cryptic.

You wanna be our checking all of your parameters for our checking all over the place, and you could just say they were trends of safe your guard your code against not only malicious users but potentially malicious the flippers as well.

Who may be trying to hack your program, who may be using the program incorrectly?

You know, there could even be gamma raised are flipping the valleys of variables randomly, or your coat could potentially be running in the multi threaded environment in which the variables could be changing every single line, and so that you want to check and validate the variable values each line you want to add and synchronization locks all over the place.

Tip number three is to use Riker JH in Now.

While we all know that any recursive function can be made intuitive, the reverse is also true.

You can take any intuitive function and make it recursive as well.

What you do is you just create a recursive function at an extra parameter.

That's the adoration count a increment that each cycle this essentially simulates a four loop.

And so any time you need to reiterate through loop instead, you can create a recursive function, and everybody loves these recursive functions.

They're going to look so advanced, so cool.

In reality, when people are reading through, the code is going to stop them every time they hit this function.

And they need to mentally think, What is this Ryker shin doing?

It's just loopy in your head, trying to figure out was trying to do but the serve coast.

Just have no problem getting through could review, you know, technically, the other thing you can even do is you could take your entire program and put the inside the recursive function.

You'll create a function, accepts an integer that's a line of code.

I should be executed increments each recursive integration.

And so the body of the function would essentially be a bunch of if statements checking which line of code to execute it would then execute that line of code, and they recursive Lee call itself again.

You could essentially right your entire program in the recursive manner like this.

You know, the more workers in the better every college course teachers Rikers in you want put this knowledge to good to use, safeguard your career this way.

Tip number four is to make good use of your comments.

I love writing huge paragraphs of comments that describe exactly what the code is doing.

One great thing about this is that it makes it such that the coat becomes incredibly difficult to change.

Because wouldn't you start modifying that you need to modify a huge paragraphs of text?

The more comments you write, the more you can solidify this chunk of code, such that no one else is able to modify.

One great low trick you can do is at the end.

You could just say, Please do not modify this piece of code.

It is very delicate.

It is affecting critical system functions, a bunch of different files.

It is legacy code, and they should not be touched.

It should not be modified.

And then nobody was going to be able to modify this piece of code except you, even though it may not be doing any critical functions.

Overtime.

No one else will know how to touch this piece of code, and then when you leave, is going to stay there and remain ancient code and schooling to just sit there and run the other great them by having lots of comments, especially at the top of a file.

If you have a huge page of comments, as people are reading the code, they need to be jumping back and forth between the code and the comments to try to understand what the program is doing.

Things get especially funding when the comments don't exactly match what the code is doing.

And yet the common say to not modify the code.

That's great.

My fifth tip is to start adding code that you might need but never will.

And so this is about at the inn tons of additional functionality, extra features, lots of extra configuration options that nobody's ever going to use, the coast not even being run.

No one's using it, but you know you can say, Well, hey, this might be used for one day.

Someone might be using it.

You can also do this by over engineering classes, So instead of credit and simple class for like a dog.

You can say that this dog object inherits from Ah canine object, which inherits from mammal object and the animal object than the person.

You can also have a conformed to additional protocols and interfaces such that this object and 1/2 additional behaviors, he said.

That credit and single class you can create, like five different classes, interfaces, protocols for each thing that you're trying to create.

And if you're good, you're going to name each of the's something different.

It could be like dog view, canine controller, pet class, just all sorts of random names.

And people are going to have a really hard time trying to follow your code because everything is named something differently.

Tip number six is to use lots of variables.

The more the better.

You may only need one variable, but you could just say that you're trying to cash the values, be more performance and create, like 10 different variables that all depend on this one single variables value.

This is a great way to add additional complexity to a class, and it's especially great if you don't keep the valleys of thes variables updated like you might have a variable called is done, but you have another very broke off is not done.

And sometimes these values are going to be the same.

And that's simply because you didn't update that you only updated the initialization or something like that, and then later it changes and you don't update it.

That's going to cause a lot of confusion.

You can also start Mon to find the value of these variables in places people aren't expecting, like in get her methods.

When people are getting the value of a parameter or something like that, you can change the value like you could have a function called get temperature.

But every time you call it another variable, value changes like, say, the location changes functional test.

They're not going to be able to catch this sort of thing because they may only call them function once.

If they were to call the function twice, it might fail.

But usually tests are only made to call Once my last and seventh IP is to just start re factoring the code because you think it's messy and you know chances are people are going to agree with you and just tell people that you're going to make it cleaner.

You're going clean things up and make it look better for you.

It's always fun to see when engineers start re factoring code to make their own personal lives.

Better to solidify the current feature set when they have no understanding of the future road map or current business needs.

So that'll do for me.

Let me know what your favorite anti patterns are.

If you like the video, give the like and subscribe and see you next time bye.