Name: Software Anti-Patterns: How to destroy a codebase for developers
Uploaded: 2020-03-27T19:07:17.000Z
Duration: 10 min 2 s
Description: Thousands of YouTube videos with English-Chinese subtitles! Now you can learn to understand native speakers, expand your vocabulary, and improve your pronunciation...

Hey, Tak, lead here and welcome back to another episode today.

I wanted to talk to you about my seven favor.

Anti patterns were drinking Starbucks iced coffee today.

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.

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

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

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.

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

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.

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.

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.

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 affecting critical system functions, a bunch of different files.

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

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.

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.

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.