Name: クリーンコードの神話 (The Myth of Clean Code)
Uploaded: 2021-01-14T10:50:03.000Z
Duration: 12 min 12 s
Description: VoiceTubeの動画で発音を聞きながら英語表現を覚えよう！学べる英語：

程度の副詞を表す句型

When we think about writing clean code, we often think of code that is written with purpose, where each line is perfectly thought out code that was planned out before it was written so well planned that the first time we run it, it just works.

But why is it that for most of us when we write code, it is far from this ideal?

A lot of times writing code can feel like being in an intense battle with your machine.

No matter what you do, the errors just keep coming.

To make matters worse, the error messages are on specific, which means that when you google them, you get nowhere.

Your frustration just keeps rising, and the bug that you thought would be a quick five minute fix right before lunch is now running on hour four and you have no intention of eating.

You've now resolved to using prints statements as your debug method of choice.

I think that the perception that we have of what clean code is and how it's written is kind of flawed, and I think that that perception is something that can scare off a lot of beginners that, that is the standard that their code is meant to be held to.

When the reality of programming is often far more messy, where you pretty much write a line of code, and all of a sudden an error occurs in the old part of the code base that someone really should take a look at and refactor.

But you're under a time constraint, so you don't have the time to actually do that.

And all of a sudden, that tiny feature that you were going to implement has become a complete mess.

That's usually how it works unless you're working on a project where you've done all of it before, where you know exactly what to write next and where it should go, Which is sometimes the case if you've worked somewhere for ages doing the same thing.

But if you're doing anything that's new to you or that you haven't done 1000 times before, then the story is a lot different, and there may be code reviewers and a signed documents and whatever else that's created to help you write clean code.

So if we take a look at your code, the unit test will be there, then.

I think maybe you should talk to Joe because he's because he's in you.

Maybe I should go go home because I might have the flu.

But at the end of the day, in most suffer engineering jobs, things aren't as well organized as you would expect.

Mostly, the code that you write on a day to day basis is subject to a lot of outside factors like time constraints, old code basis that aren't maintained, other people's bad practices, et cetera.

So the expectation that you're going to be able to write a piece of code that works perfectly and it's purposeful every single time, or even just most of the time, it's far from what writing code actually looks like.

You should still, of course, aspire to do all those things.

But in most cos it's not only your job to write a clean piece of code, it's actually you and your code reviewers job to produce a clean piece of code.

There's also a trade off between writing clean code and being efficient, thinking that every piece of code that you write has to be perfection itself is neither realistic nor what anyone expects from you.

I would say that in general, trying to write perfect code is super inefficient, because in order to do that, you need to spend so much time thinking through everything that you do that you become very slow the way that you should usually work or think about your work is right re factor and review.

You first focus on writing the code and making it run without errors.

Then, after you've got that, you can spend some time re factoring the code you've written renaming variables, methods, simplifying methods, adding comments, et cetera.

It's easier to re factor existing code than it is to ride it like that from the beginning.

And then finally, once you've spent a bit of time re factoring and essentially cleaning up your code because send it in for code review after it's been reviewed, I would say that you have successfully written a pretty solid piece of code while also maintaining a reasonable level of efficiency.

What I'm mostly trying to say is that the perception that we have that clean code is equal to perfect code is usually far from true.

And that's why big companies have practices like code review because the first implementation of something is usually far from perfect, and it's just there to kind of get it toe work.

And then that piece of code can be worked on and re factored.

You can remove all of the prints statements that you added in to find out where the error occurs, and you can rename and re factor different methods.

And then once you've worked on that for a while, you can send it in for code review, and then the code reviewer can check out your code and your mess and give you some advice and tips for how to re factor it further and make it even cleaner.

And then once all that is done, that's when I would say you have a clean piece of code.

This video is sponsored by Nord Locker, nor looker is an easy to use file encryption tool.

This is something that you can use if you want to store files with sensitive daughter Somewhere.

For instance, if you want to upload financial records to Google drive, you can then use nor locker to encrypt the file before you upload it.

That way, no one can see the contents of your file except you.

You simply dragged the files that you want to encrypt into your Nord Locker folder and you're done.

And this works on both Mac and Windows, so it really is super simple, and it also features superfast encryption times by using nor looker.

You can keep your file safe from unwanted ice anywhere you want to.

It also supports multiple devices, and they, of course, offers 24 7 technical support because it's 2020.

So I definitely recommend getting Nord Locker.

Go to nora walker dot net slash holden and use a coupon code Holden to get north looking for free and to also get a 32% discount on the premium version, even though it may be inefficient to write clean code from the start.

This doesn't mean that you shouldn't try.

So the fact that our perception of clean code being equal to perfect code and the fact that writing clean code is inefficient is not an excuse for writing shitty code.

The aim should, of course, be to write the best code you can at the time.

But if you end up spending several minutes thinking of what the most appropriate variable name is, then I think it's a good idea to move on.

Basically, as you write you often no way fast and a sloppy way of doing something and the slower but more proper way of doing it.

This is when you should opt for the slower, more proper way.

Instead of writing three nested four loops, it may be worth spending a couple minutes trying to figure out if you could come up with or Google a recursive function that could remove some of the four loops.

I do think that most of us know what we're being sloppy and just can't be bothered doing things the right way, even though we know how to do it the right way.

And that's what I would suggest, spending that extra amount of time, doing it the right way from the start.

But on the other hand, let's say that we're implementing a new feature.

Usually there's like an infinite amount of waste to implement new features.

And that's what I would say, that it doesn't make sense to spend several hours trying to research the most optimal way of implementing that feature.

Instead, I would suggest just implementing the feature in the best way that you can, and then spending some time re factoring that and making your implementation a lot more elegant, because then at least you made something that works.

A trendy term right now is action bias, which means that you're biased towards taking action over inaction, and I think that that is how you should be thinking.

When you're creating clean code, you should write clean code with an action bias, meaning that you can spend time researching things and trying to do it better.

If you keep that in mind as you write code than I think you'll be well off.

So writing clean code in the way that we perceive clean code is a myth.

Usually clean code is the product of several people working on a project together and not just one individual.

So if you're feeling like I believe a lot of people are feeling like a crappy programmer because your code usually looks like a giant mess, then you're not alone.

And especially if you haven't worked at a company before, writing suffer professionally where they have the right systems in place for it.

I would say that for most of us, our own personal projects are super messy, and they're kind of like the closer that we have, where we just shove all our shift into and try to shut it and hope that no one looks in there.

And before you go, I just want to mention that I've created something called Clean Code Friday, which is very fitting with this video, which is a short email that I sent out once every week.

So every Friday that contains a few of the most interesting things that I found throughout that week, and that would be things like books.

I'm reading articles of red productivity tips, coding tips and tricks and really just anything that I think you might enjoy.

So if that sounds interesting to you that you could go to caltech dot com slash clean code or you can sign up using the link in the description, that's it for this one.

I hope you enjoyed it, and I hope we'll see you next.

But then I was worried, cause I'm like, Oh, my God, I'm, like, so unproductive And I'm getting wallowing in this like guilt.

So, like this Catholic guilt of like not, you know, I'm not working hard enough.

This company's not successful, and I found my daughter at it and just, like, totally not helpful, but and so I'm like, Oh my God, Oh, my broken like, Am I not capable of working hard?

I started working on this like poker baht that started, and it played with real money like a like got past the security on the poker client this John six.

So I figure out howto make all that work and then watch kind of my Frankenstein moment as the thought comes to life and starts playing on riel poker tables.

And so this idea you can't poker box was like totally false, but and but I was possessed.