Junior Vs Senior Code - How To Write Better Code

Writing code is easy. Writing clean code, though, is much harder. In this video I take a look at two different code examples from a beginner, intermediate, and advanced level. The goal of this is to show you how a senior developer will think while programming and how they will structure their code to be as clean and well-written as possible.

📚 Materials/References:

🧠 Concepts Covered:

- How senior developers think
- Using guard clauses to clean up code
- The differences between senior and junior developers
- What to think about when programming

🌎 Find Me Here:

#NoobVsPro #WDS #CleanCode

[paper.clouds]

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” – Martin Fowler

[syaleni]

I think planning is also very important. I find myself doing a much cleaner code when I spend some time drawing some flowchart and wrtting down sort of a plan on a piece of paper before jumping on my keyboard. I would also add to that, separation of concerns and decouplized code is the key to maintain a large piece of code.

[deswpNET]

About the first pro function "numberToAccountingString":
While "==" (double equal signs) does indeed cover both "undefined" and "null", I'd argue that using "===" (triple equal signs) in general is more readable. And as others already mentioned, "typeof number === 'number'" would be the most readable and logically correct way to check for the type.

And when entering undefined/null, it would just return undefined. Wouldn't I expect a string? Let it throw, preferrably with a custom message "throw new Error('Invalid parameter type')". If the function expects a number parameter and receives something else, it should stop so the stacktrace to debug will be as short as possible.

[TheNacropolice]

As a professional developer, I greatly dislike one liner if statements. In my view it makes it harder to see the logic if it does something even slightly long. Adding some spacing, and curly braces is always good.

[awekeningbro]

Today i realized i am a mix of noob, advanced and pro programmer.

[alonsojimenez]

One thing for the new programmers to know (at least from my perspective as I consider my self a mid/advanced programmer) is that not always you get the code as the last file for the first time writing a function. I think the 90% of the time we will write the "noob" code and then start depurating code readability and errors caused by un-programmed test cases. So, if there's a new programmer around here, don't worry if your code doesn't look as the "pro" code at first, but make sure it ends looking and working as so. And remember it's a never ending journey of learning, there's no programmer in the world that has nothing to learn or improve.

[George-oruv]

I like that you take the time to work us through the beginner, advanced and pro versions. Very nice touch.

[ankushsharma]

Started watching your videos today and instantly became a fan! This here is code gold!

[aaronrothwell]

I've seen "pro" code in production that looks worse than the "noob" code.

[jtomes]

When you watch this, you realize how many errors typescript prevents

[berenscott]

Back in the old days of having to insert cards into a machine, efficiency of code was the most important aspect. You didn't have any capacity to fuck around. Technology moved forward in such a way that optimization became an after thought. Back in the day you had no choice but to make your code as best as possible.

[soanvig]

Seing your "pro" or "senior" code I would recommend creating one more level above it, since still few things can be fixed, so the whole is more maintanable.
First of all, if you have function `numberToString` you should throw if you get anything other than number.
You actually made code *worse* by returning undefined, since you are silently failing that way, and it will throw in completely another place, will take longer time to debug, and the error will be less meaningul. It's even better to not handle it at all, and let it fall naturally, since then you get an error in precise place, which caused it.
The same applies to handling "null" in second function.
Further more: if you insist on handling such things, don't cherry pick. What's the point of validating if argument is null or not, if you expect array? You are still not validating the content of the array, but you get the impression, that you have validated the code. You quickly come to a place when you are either still cherry-picking or validating absolutely everything, and the code becomes unreadable.
You need to trust your own application, you need to add validation mostly only on I/O layer (reading unexpected input like files or API), and you need to *let it fail*. Failing is good, because it shows during simple input testing, if everything works.
Each one used `if` or some kind of condition, or nesting is literally making code worse. The less the better.
I would even imply, that most of the things do not require handling anything more than happy-path (and any states, that are actually valid and possible), because if something fails, then it means you have the bug in your code: either your validation on input is not right, or you have typo or something. By not handling it, you are going to find it ten times quicker, usually during manual testing

[neolectron]

I disagree on the pro code.
the function silence the error, it's not a good practice.
if the function isn't design to get an undefined or a null, just make it crash and catch the error elsewhere.
.
if you don't you gonna have hard times finding bugs when you'll get an undefined...
because the function just silence the error....

[Avean]

I am only a hobby programmer and first time i heard about Guard Clauses. I really love it! Looking at others code specially with tons of if else statements can be a nightmare. This is so much cleaner! Looking at guard clauses i see immediatly what its doing.

[beefcakees]

Yo, I have been learning from your channel all morning. I just wanted to say, thanks for putting these up, thanks for showing your passion and making code fun. Also thank you for keeping almost all of your videos around 30-60 minutes. It really helps me focus and take it like a small class, take a break and then come to the next one. Keep up the great work my guy. Rock on

[SecretEyeSpot]

I love how every question i began to ask as i was watching was answered by the end of the video. Thank you!

[IragmanI]

Thanks for the emphasis on using 'constant' patterns. Something I 'kind of'' do but without really realising its worth

[kenn]

What about ternary operators, simple and elegant.

[nicklandreth]

This really gave me some simple actionable advice to improve my code. Thank you!

[bhupenderKeswani]

Loved it, this how we roll. Everytime I visit our code, I stare it for a while and see if I can apply something I learnt recently. JavaScript has evolved like anything, specially since last few years. From FOR loops to MAP, REDUCE and FILTER, makes Dev's life interesting.