Junior Vs Senior Code - How To Write Better Code
Vložit
- čas přidán 27. 04. 2020
- 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:
Template Literals Article: blog.webdevsimplified.com/202...
Guard Clause Article: blog.webdevsimplified.com/202...
Destructoring Video Tutorial: • Why Is Array/Object De...
Reduce Function Tutorial: • 8 Must Know JavaScript...
GitHub Code: github.com/WebDevSimplified/N...
🧠 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:
My Blog: blog.webdevsimplified.com
My Courses: courses.webdevsimplified.com
Patreon: / webdevsimplified
Twitter: / devsimplified
Discord: / discord
GitHub: github.com/WebDevSimplified
CodePen: codepen.io/WebDevSimplified
#NoobVsPro #WDS #CleanCode
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” - Martin Fowler
Cringe worthy
Reading between the lines Mr Fowler is saying: "A good programmer has to have too much time on their hands and doesn't really need to write efficient code." I'd personally go with "a good programmer writes code so well it never needs to be read again by human eyes". However, an ivory tower programmer writes code in hieroglyphs/dreams in regular expressions - good or bad doesn't apply.
"i am stupid"
-Me(Guyed game)
@@paulphillips3783 I guess you don't work with pull request and everyone can just submit there code then?
@Mortar - Lol - if a good programmer has written 'good' code, then it'd be an inferior programmer that would pull it to 'adapt for new requirements'. Another good programmer would inherit/polymorphise/override it into a new function with wider/different scope.
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.
weird you didnt get more likes:p finally someone mentions flowcharts:p so old-schoold, me like it;>
@@geraldjoe-smith-mcnea6829 I'm 31 and I can't remember any of my passwords. There are too many to remember. You should switch your phone password to a swipe to unlock or something easier.
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.
Agreed. This video is not that great. Yea there is objectively good code but at a certain point it is subjective.
I wonder what you feel about one liner if statements WITH braces. In my view, if you don't get over the 80 character limit, then putting everything in one line is fine.
There are some cases when I am a fan of single-line if-statements. The thing I use it most for is guard checks that simply return. For example the if (input == null) return; is really concise to me. I'm not a fan of putting much more there though, and I also dislike using it for more complex logic checks...
I agree, I am actually in favor of creating wrapping functions with dedicated guard functions if your logic it's too complex, that's better than creating one liners a hundred characters long with your code still being compact and easy to read, this video is lacking some good functional programming principles and also some good test driven development principles
Ironically I think a common mark of novice programmers is mistaking concision for efficiency. Clean code is readable first and foremost, there's really no advantage to minimizing line count for it's own sake. If the length of your code is suspicious, dropping braces and using ternary statements probably shouldn't be your first reaction.
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.
This!
Throwing an error is the way to go. Fail fast and spectacularly - less bugs in production that way.
How About if(number) //.....
@@piyushupadhyay4571 0 is a number, but is considered falsy and would not go into that if block.
I am not even close to a pro, but is it even necessary to check the type here? Even if we are expecting string numbers, we can just rely on the less_than condition to account for nullish values since javascript type coercion will automatically recognize a number string as a number in our condition -- like so:
const numberToAccountingString = number => number < 0 ? `(${Math.abs(number)})` : number?.toString();
Today i realized i am a mix of noob, advanced and pro programmer.
Awekening Bro noob, advanced, and 'pro'-grammer
So you are awkward programmer🤣
i am a (prog)r(am)m(er)
We call that LEGENDS
-1 + 0 + 1 = 0 so your just average
When you watch this, you realize how many errors typescript prevents
Absolutely! Don’t blame programming language faults on programmers. They would use anything that the language offers. This is the problem of a fully dynamic language... why think about naming the variable so that you can guess that it takes a number, but not adding a type description???
John Yepthomi
?
@@user-vs1mn8ig8w go read what a type script is
@@johnyepthomi892 ?
@@hashnoodle2499 noob
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
I agree about cherry picking, but not so sure about "not validating and trusting your application" part. in this scenario, it does work, but if there is a class that is just storing things, and you are not the only developer working on the project, should you not validate what other data sources are sending to the class? or is there a better way to handle it? I am in the habit of writing validations in all parts of the program :)
@@szwimzs it depends on separation of concerns. You should trust the code you have influence over. If there is another team developing another modules, you may treat them as external input. It really comes down to architecture. If architecture mirrors team structure it may be nice to add validation on the borderline.
If you are talking about domain objects, then it is good behavior to ensure they are built correctly, as it is not function performing operation, but the data itself.
With that being said what are your versions?
@@soanvig Why have another layer when the advanced level in itself is difficult for most. Let us not forget that most of the crowd out here would be very happy just getting to the advanced level. If you go on adding layers you will agree that there will always be a guy out there much smarter than you are and who can write code better than you.
I don't agree with you that you shouldn't validate your functions or methods. I believe it's crucial to validate functions or methods, especially when they're intended for use by other teams or programs. Let's consider an example: imagine we have a function named calculateInterest(amount). We might trust that it's implemented correctly and will return the expected interest amount so no validation checks are written, just the logic that calculates the interest. However, in practice, mistakes happen, and in our haste, we might accidentally pass in incorrect values, potentially breaking the code.
The real problem arises when the function fails silently, without raising an error. In such cases, the code continues execution, unaware that something went wrong but returning the wrong results. This silent failure can lead to significant issues, especially when even small discrepancies in calculations, like one percent versus eighty percent, can result in substantial differences for users - either paying more or less than they should.
To mitigate this risks, validation checks must incorporated into our methods or functions. We can even separate the validation logic to keep our code organized. The validation checks should also address edge cases and ensuring inputs are valid. A function or method without checks is a function or method doomed to fail.
I like that you take the time to work us through the beginner, advanced and pro versions. Very nice touch.
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.
Thank you for this insight!
Thanks
I've seen "pro" code in production that looks worse than the "noob" code.
HAHAHAHAHAHAHA true that
Sorry about that.
I see these jr. vs. sr. code quite often as if these seniors don't write ugly codes as well.. why not just call it "write better code"...
true xDDDD
I think a lot of this 'pro' programming comes from people in their late 20s and early 30s who have already gathered quite some experience in coding but not lost their passion that much, like myself(just talking 'bout my age here xD). But in practice it is usually more important to get things done than getting it done with nicely formatted code
I pulled my hair apart looking at "pro" code in production
I pulled my hair apart looking at my own code I wrote a few weeks ago
I retired from coding and changed industry
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
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.
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....
um...seems if you need to make the function ensure it got the right data you have a bigger flaw this function shouldn't be addressing!
Very true... it's makes debugging easy. and that way you can manage all the errors from diff functions in one places
Sir, you have my vote. I literally wrote the same comment, longer tough, and then scrolled through what's already written.
How can you prevent thread exception errors without a try catch?
@@M1KE9815 make sure you pass right datum?
What differentiates a junior and a senior dev is the fact that seniors can solve problems way faster due to their experience. Seniors are not always the 'better' ones. Good video!
I think this covers my sentiments too, but I would also say that a good senior also knows to listen to juniors as well.
Started watching your videos today and instantly became a fan! This here is code gold!
This really gave me some simple actionable advice to improve my code. Thank you!
Thanks for the emphasis on using 'constant' patterns. Something I 'kind of'' do but without really realising its worth
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.
I love how every question i began to ask as i was watching was answered by the end of the video. Thank you!
I enjoy the style and how clean, quick and succinct you are with your class. Nice work!
as a noob, this was good to see the path in front of me and some practical uses. of course real code is more extensive, but still a good launch pad, thanks!
Thumbnail be like:
Minified code vs formatted code
minified code is certainly not noob code, it's more just pro code that's been made to look impossible to read
@@sodiboo what? minified code is just code that is run through a minifier/compressor... having minified code does not really suggest/imply that the quality of code being written is "pro" lol.
Terrain
Yes.
But the thumbnail is minified code on the top under “noob” and formatted code under “pro code” which - as you stated - is inaccurate. I was pointing out the, understandable (how does one portray noob code in a thumbnail?) but inaccurate nature of the thumbnail.
It just struck me as odd, is all.
We work with minified javascript packages daily in production - but (at least I do) prefer to use the regular versions during development. Certain IDE’s don’t really like indexing minified code very well and will miss imported functions quite often...Particularly Jetbrains IDE.
Despite this, they are still my favorite development environments to work with.
The pro code is also not very good. If you need comments to explain what you are doing then you need to introduce more functions.
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.
Thank you! How enlightening! I should start checking this channel every Sunday morning as a routine.
if we're so concerned about the number parameter being a number; We can just use the typeof operator. (typeof number == 'number'). This is how I would approach this problem set when it comes to validating the argument(s).
you're right, with the exception that it should be === instead of ==, in javascript. (not that yours wouldn't work, it's just best practice)
Yes, but you forgot that typeof NaN == 'number' too in JS. And so it would be better to use (typeof number === 'number' && isFinite(number))
man hear this from a noob: I wouldn't use any function, i'd just write the whole code every time i need it... duh
then you are ultra pro max bro
I didn't know they were called "guard clauses" but I used them all the time. It just seemed smarter to me. But I got criticized by senior programmers saying that the code in functions should flow from top to bottom and returning early was bad. So now I use noob programming styles to keep the senior programmers happy.
I don't know what kind of 'seniors' you're working with but returning early is not a bad thing whatsoever.
@@_yakumo420 Dijkstra's grandsons probably.
I used to go back and forth all the time about this myself. I finally settled on making it as visible and as obvious as possible. If I can put all my guard clauses at the top I do so, and if not I like to create a small “island” and comment it so it stands out. Also, I notice they looking through either my old code or other examples, a lot of early returns could be circumvented by doing validation elsewhere or just making type safe objects. Granted, you can go overboard with that quite easily. I’d say for simple programs and small functions guard clauses are totally fine. For bigger beasts, some rewriting to include the above might be a good tool to use. Had to learn all this the hard way when someone looked over my work and told me I was “primitive obsessed” and I though, “I have no idea what that means, but it doesn’t sound good!” 😂
@@Ultrajuiced A bad joke, since most of the time he was 💯 percent right. The worst thing about programmers is that they are like normal people - they want a solution that always work, a paradigm that is always the best. There is no universal formula. But people are people.
You the man Kyle, these videos are very helpful. I spent the last couple of days practicing what I've learned so far (not much) to create a calculator, so now I have good pointers on how to go back and make it slightly better than terrible :)
Really surprised you didn’t use an example where helper functions would be beneficial. Learning to decompose a problem into smaller steps that are solved by well-named functions is a key aspect of writing “pro” code. Still, there were some good tips in there when it comes to writing a single function or block of logic.
Agree. In the second example, the function should use helper functions for readability and clean code practices. Otherwise, a good video but could be a bit shorter tho.
Thank you, was looking for this comment. That code is not 'pro' yet
but multiple function calls increase time complexity
@@siddharthverma4017 news flash: people rarely give a fuck about a few extra extra function calls in real codebases. And even if they did, good engineers know that you should almost always be willing to sacrifice microseconds of performance for code readability.
@@siddharthverma4017 in some old or dynamic languages, but most languages inline those kinds of small functions
Totally awesome man! \m/ . Would love to see more of these advanced videos as well and real scenarios and good practices.
Would you also consider doing projects where you can cover different JS frameworks? I would be interested in Svelte a lot.
Once I realized guard clauses were a thing (didn't have a word for them until now), I've always done my best to use them. It makes so much sense, and is cleaner.
11:20 Would definitely trip me up since my primary language is Ruby. In Ruby (0 || 5 ) would evaluate to 0, because 0 is not "Falsey", it's "Truthy".
What about ternary operators , simple and elegant.
That's too pro :+)
Yup, I was looking for the one-liner.
Ternary is for only who is become Advance Pro in programming. 😂😀
Ternary operators are hard to read. It's better to use if-else instead of ternary operators
@@sinamirhejazi268 I disagree. I find them very readable. Admittedly you have to know what they are to read them but when you do it's very easy to construct readable operations. user.isAuthenticated? : null
vs
if (user.isAuthenticated) {
return
} else {
return null
}
Great video explaining the difference in readability. Just one nitpick, I'd expect the pro version of the last sample of code dealing with cost to be accurate to the required decimals. If we're going to go all the way with professional grade code, floating point numbers need to be handled carefully when it comes to money. We actually had a discrepency crop up at an insurance firm that was not rounding the values before adding the total resulting in decimals that couldn't be reconciled, which is a super important detail when dealing with money.
I don't remember where i read this quote from, but it's one of my favorites
"write your codes like your colleague is a serial killer that knows where you live"
Another great watch, thank you for taking the time to explain the difference.
Congratulations on this great video, a pleasure to watch! But with all the respect, let me disagree with you regarding 5:09. You mentioned a very good point regarding edge cases. However, returning `undefined` is also not ideal. I’d suggest either throwing an Error with a descriptive message here or using a Maybe type (like in FP) and chain any further computation. Returning `undefined` will simply defer the problem as the caller needs to check what kind of value the function returned. For example, the following snippet might fail due to the same reason: numberToAccountingString().charAt(1). What do you think?
I had a guy downvote me on a SO answer over this exact point… I really dislike returning undefined. It always reminds me of returning NULL in Java.
yeah, the good old 10mio dollar mistake..
I also tend to agree. When something unforseen happens then functions should rather crash (verbosely in the best case) than trying to defer the crash - what if some later part of the program writes the accounting records one by one to a file and crashes then - with a half written file. Being processed by a booking system, detecting the change and... ok, I stop here ;-)
So yeah, better assert than return, agreed.
if i ran something with console on and got undefined returned, i'd just think there is an error with the code.
A hundred percent i agree
Do function()?.methode(1)
What do you think
@@kybkap8686 In my opinion the use of "?" only disguises the "if-else". The problem is that there's no "else"-branch when "?" is used. But, often there must be one. Imagine, you click a button, the "if" part evaluates to false and the button does nothing. This is the worst for the user - a "sometimes-do-something" button.
That was very interesting, but as a pro, you need to do a better kind of type checking and throw an error if you pass wrong data. You can test your script using other data types (like an object or a string) to see what happens. This can be avoided by using a better comparison operator (always prefer === over ==). For example, you don't want to return something other than a string (your function name has to...String 🤷♂️). So, you should consider using some kind of type validation and throw an error. There are many options for doing that. You can use typeof number === 'number', trying to convert to number with Number(), parseInt() or parseFloat(), but my favorite is using isNaN: if (isNaN(number)) throw new Error('Not a number'). That way you can use string representations of numbers like "-0.75", but keep in mind that you need to use Number(number) after validation to turn the strings into numbers for good results.
This freaking function thing i ran away for long.bbut now i start understanding pro functional programming and its benefits, thanks to tutorials like this. Thanks sir.
I was writing code just like the advanced version 4-5 months back. Recently, I learnt about writing clean code and now I think I write like a pro.😁 I was requesting you in comment section of your other videos to create videos on refactoring/clean code since long time. 😄 I like your explanation. Keep bringing more videos like this. Thanks. 👍🏼
How and where did you learn to write clean code please?
Mikael Borhzka geektrust.in
Juan2003gtr Yeah. I know most of the experienced guys don’t know about clean code because either they are not interested in learning or they don’t even know that the code they write can be made better. Many of us(young coders) are very good at DSA due to the growing competitive programming culture. It will take some time to develop the culture of clean code.
@@mikaelborhzka7627 Robert C. Martin - "Clean Code: A Handbook of Agile Software Craftsmanship" is a nice read :-)
Great video, but as a tech lead I have some complaints about your pro code :p
First of all you should always fail early. Instead of returning undefined in your function you should definitely throw!
Also the name numberToAccountingString implies:
- should always return a string
- should only accept numbers
So if you decide to check inputs you need to make sure that its a number.
You need to ensure that only strings are returned.
If your turning a number into a string you should use toLocaleString(). If you want to disrespect locale to is explicitly by giving it as param to toLocaleString().
One down side to that reduce function is not everyone can follow that function. But i've learnt more from your decomposition of code in the last 4 videos i've watched than years of grind vs uni. More! im hooked!
You're helping me get a lot better at Javascript and React! You're the man!
The first example you should really test number is of type number , rather than test for null imo
Alifka Aditya Putra one reason is because a different variable type, specially object, could be the value and it would make the code break. If you check for number type, it prevents more possible errors, and is not any more complex
Alifka Aditya Putra just to elaborate, we are expecting a number , so it makes sense to only proceed if it is a number being passed in, this will cover all non number scenarios in one test.. 🤘
I would use this: if (!NaN(number)) return number > 0 ? number.toString : '('+number.toString+')' in the first example. Simple and clean solution.
Lazy you may use it, but I wouldn't .. it looks like a spider ran across your code while the ink was still wet😬
@@PaulBrownclk-me Why? You mean ugly or unreadable? It checks type for you... And specifically returns result in parenthesis like he wanted for negative numbers. Sure you can use just a standard if else if you don't like this "? :" syntax. I just wanted emphasize that there is something like NaN.
Kyle: "noob programmer-"
Me: what is it?
Thanks for this cool video. It'd be great to see more videos on the topic of writing more professional code in JS and React specifically.
This was an excellent video. You nailed the refactoring of those examples.
"And that is the important thing about programming - It's not about writing something that works, Its about writing something that easy to read and easy to maintain"
"[...] something that easy to read and easy to maintain **and works**"
@@HenriqueErzinger Code that works needs no maintenance .... ;-)
At least 60% of professional (paid for ...) programmers dont know this.
AsgaiaMetal that’s not true at all. What happens if you’re linking to an external library and that library changes? What if there are features added, removed, or changed? What if new devices use hardware that’s incompatible with your code and induces bugs or outright breaks your code; for example, a domino effect from some change in the way an op code works cascades down and disrupts out of date libraries and APIs? Of course you need maintenance.
It is, but there is this one little trick : good code, doesn't need to be improved, and thus doesn't need to be maintained. There's no perfect code, but I know when I'm looking at code that has very little bugs. It's very hard to achieve, but it is possible.
In the first example, I expected to see ```-number``` instead of ```Math.abs(number)``` in the number < 0 case. After all, you know the number variable is a negative number by then, so you can save yourself the hassle of calling a function that checks for it again.
Also, I checked and updated my Python miniproject while watching this to make it cleaner. The concepts work the same.
Also, for other pythonistas out there watching this: Have docstrings. The feature is in the spec for a reason.
Came here to comment this about ```-number``` instead of expensive library function Math.abs(). Good eye @Alchemist!!
+num works either way
there used to be a site, codefights, that was great for this. They posted problems and you could code a solution in any language they listed. Once you submitted your solution and it passed the test suite, here's the great part: you could look at other solutions that passed. It was great for seeing how other people successfully solved the issue and compare efficiency, and number of lines used, big O complexity, etc.
Wow never thought of it this way. Thanks for sharing
I don't like the inconsistency of single line if statements. It makes it more difficult for other programmers to add any updates. "Clean" is nice, but consistent is a lot better!
I agree, sir!
agree
I prefer single-line to non-block two-liners.
I basically always use blocks, except for one scenario, in Guard Clauses - "if (True) return;".
for `logic/pro` I would also recommend using a ternary operator to better explain the if then else behavior, and it also keeps it in one lines (unless you wanna break each statement for better readability) and it also makes you not repeat the return statement more than the number of times you need to ;)
I thought the same thing!
that was a great video especially that you gave three stages of improvement and not only two like most of the videos on the internet, thanks and sending greetings from france 🙏
Im absolutely a beginner, but my first version was your pro example. That's how I was taught.
Really interesting, but I would say sometime nested if statement is clearer than in the pro version of the first example 'logic'.
But yeah for this example it's perfect, really more clean the pro version.
Just depends of the situation actually.
In my opinion functions should be simple as possible so checking value if it's null or it's not a number etc should be handle before you execute it, so your function can do exactly what you want if the right value and with JSDoc you can have comments to know what type is attended (or with TypeScript), only my opinion but both are good.
It's really important to write good code so you in the future or others people can see exactly what is doing your code etc.
Serious question regarding the guard clause:
Wouldnt it be cleaner to just use e.g. if (!items || .....)
This option will catch null and undefined
It was pretty awesome and simple at the same time! Thank you for the video!
Nice stuff! I Would love to see more "best practices" video like this!
The thumbnail for the "Noob" code is just a min.js file :D I don't think a noob could write a minimized js :D
Some developer follow the theory - "If it was not easy to write, it shouldn't be easy to read".
A philosophy or a saying, not a theory.
This video made so much sense to me. Thank you for sharing it, I definitely followed and liked
Thanks! Always appreciate video that talks about clean code.
This video makes noob to think he can write advanced and advanced a pro.....Amazing video Kyle as always.....🤚🏻👌🏻
This video makes noob think he just became a pro and tomorrow will go ask for wage rise :))
@@Borlays 😂😂
Seniors also use TypeScript these days. You don't need to do all the monotonous manual type checking
I cannot remember the last time I did manual type checking; if the project utilizes TS, great, we can catch a lot of runtime bugs that way but if not we still don't go around manually checking each argument value for everything it is not allowed to be. That just creates bloatware.
I am not understanding why type checking is even necessary here. We should be able to rely on the less_than condition to perform the type coercion if the user passes in a string number, and it will return false if the user passes in a nullish value.
Even if you don't use typescript, you can still use doc comments for typechecking (using the typescript compiler on any IDE, but it doesn't require your code to actually be typescript code).
TypeScript compiles really shitty non performance code, really do not like it
Ahhh... there is no guarantee that the values that trickle through the code at runtime are what the TS type annotations say they are. You can easily end up with lots of bugs if you don't do any type checking.
Calculation can go bad and result in numbers being NaN or Infinite; DOM input values, when parsed/validated, can end up as the wrong type (null, undefined, invalid Date objects, etc.); data from APIs and databases can change without your knowledge or may contain invalid data, causing values to be some completely different type; and so on.
It doesn't mean that types are useless, not at all. You just need to know when explicit type checking is necessary and to be very strict about outside data, that you have little or no control over, always being properly validated, parsed and typed (e.g. using a helper function, like "const dateOfBirth = getDateFromString(unknownValue);").
Just a few from me:
- Document (state the allowed argument type and return type, for other languages you can data type) at the beginning of the function/method and comment less in the block.
- Indentation is key, space out and line out.
- Middleware: Quick exit or safe guard blocks at the beginning when needed.
- Less depth of code blocks (one to two way deep is okay).
- One line - No braces for blocks: if the code block is less than 50 chars or less than your ruler, use one line.
- Ternary operator.
- I use concise variable,function/method names.
- Less return keywords.
- Less code size: The less block of code, the better.
That's the very moment when a lot of us remember ourself at the beginning :D That's how every programmer transforms with experience. I myself am writing these long informative names not only for others who might read my code later but for myself too
From my 16 years of IT experience; I can say even senior or super senior also end up writing spaghetti code most of the times.
For me writing code is like preparing omlette or lemon tea, everyone is proud of their own recipe and sometimes ego clash.
What's your take on this ? In case of arguments how to come to conclusion if it's good , bad or ugly code ?
answer: don't try to assess the code that way. does the code work, yes or no.
@@A_Lesser_Man Does your code work? Yes!
One year later: Can you change a few things? Sure! _looks at code_ Oh f***.
I have been there.
@@the8flo1 lol i have too, its hell.
@@A_Lesser_Man
That's a very stupid (sorry) answer.
The worst programmers are those who doesn't want their code to be better and cleaner. They just smash something, yes, fast, it's working. But you can't do anything else with it later. Poor guy who will need to make any changes in the future :)
@@enjay86 although I agree code should be readable, no matter how much better it is it can never be perfect. Get it working. Clean it up. Refine over time
In the first example you could've made it even simpler with a ternary operator:
return number < 0 ? `(${Math.abs(number)})` : number.toString()
even further:
return number != null && number < 0 ? `(${Math.abs(number)})` : `${number}`;
Thanks mate. Inputs and outputs definitely are in high priority.
The variable manipulation, pro part of the video reminds me of the video "Fast Inverse Square Root - A Quake III Algorithm".
At the first look, the code is not intuitive at all, but it somehow makes a lot of sense.
Noob programmer here. The best thing I learned from this video is to write a bunch of console.logs at the end instead of running the thing every time for each case. Thank you very much.
Then there is the grand master level, that is basically the same as noob but with good names and all the checking needed. With this the poor junior fella that wins the terrific opportunity to maintain it will not call you every 5 minutes to ask you how that line works, for every line of course...
Yeah. I usually prefer to write "dumb" code because anyone can read it. No ternary operators for example. While they're great it's also confusing if you are not used to them.
I kind of feel the same way about the whole stack. By all means, refactor everything into the coolest new frameworks if you need your resume to stay hot. But if not, just go for stable reliable stuff that anyone understands. A regular LAMP setup works great for a whole truckload of use cases :)
In the first example, you can avoid the function call to absolute since you already know the value is negative. Just negate the value. This would keep the program from making a function call that just replicates your negative check.
Would love to get a general talk on large code concepts like class structures building the universe, instantiations, enumerations, slicing and grouping
It was nice to mention good code isnt written like that in one go but is the result of several revisions, trial and error, meaning discipline is key to better outputs
my issue is that i always just try to get things work first and only after im done with the whole thing then i go back and clean up everything . but sometimes i get lazy and even end up with unused code lines lol a total mess .
That’s me except for the fact that I clean up the code after
A little code review of the 'pro' version at 6:14 -
1. A 'pro' would simplify function name to accountingFormat() or just format() if the module name has the word 'accounting' in it (which it should). No need to say 'number' because you already have an argument named number. There is also very little value in suffixing function names with return types so that can be omitted as well.
2. A 'pro' should use semicolons at the end of each statement. Consistency and clearly communicating intent is more important than omitting a single character.
3. A 'pro' should avoid returning null or undefined if at all possible. Returning null or undefined usually forces the calling code to do an immediate null/undefined check on the returned value.
4. A 'pro' would either use null object pattern with a meaningful string value or throw an exception.
2. A 'pro' should use semicolons at the end of each statement. :surprisedPikachu:
@@foxyl0l A 'pro' knows that consistent usage of semicolons in JS is considered best practice. Not only that, but a 'pro' actually understands the importance of semicolons in JS. Even though one can get away with not using them, they provides significant benefits:
- Avoiding rare but very hard to detect bugs (with potentially significant consequences).
- Avoiding issues with minification.
- Making code more readable by clearly differentiating statements from expressions and other code elements.
- Better communicating developer's intent.
- Making code easier to understand for less experienced colleagues (the ones that don't have intimate knowledge of how JS ASI behaves).
- In consistent usage, a missing semicolon can indicate a potential error.
All of the above in exchange for just a single extra character per statement.
A 'pro' would encourage their team to stop bikeshedding about semi-colons and just pick a standard linter, e.g. StandardJS or Prettier.
@@milosmrdovic7233 Agreed to all you said.
In addition, I think a real pro knows when to weight the benefits of code performance, maintainability, readability and conciseness depending on what it's used for and project time limitations.
For example not all code has to be super-performing when there's really no real need for it, in which case it's better to sacrifice some performance for something that's easier to maintain, read and more concise.
On another note, I also see a heavy lack of code comments in his example. It's a misconception no code requires comments as long as it's well written, even if it's super simple a comment is always nice.
For instance, if the code he wrote threw an error when the number is null or undefined, then that would be nice to know by the consumer of the function without even needing to looking at the code. Adding jsdoc to this function would be ideal here overall, but especially @throws
Really appreciate your work. Great job!
Great video and great tips. Thank you!
This was a very well made video, super useful!
Thank you. It was really fun to make.
You could make that "pro" code better by checking that input value is of a number type instead of just a null value. Secondly, you can use a ternary operator to condense the last two checks into a simple, single line.
PLEASE do more of these... SOOO helpful
Always tell people programming is really about controlling complexity (otherwise your code is hard to follow, maintain and scale). There's so many cool techniques out there that can make you better. Great book on this topic is Code Complete (Microsoft Press).
My friend who is a PHP developer said that no curly brackets for single expression(guard clause) syntax is very unreadable for him. Can someone confirm it is the best practice?
It's fairly subjective isn't it? A lot of people avoid doing it, because it could be a bit more work to change if you need more lines, but I've also seen a lot of people do it. It's more readable if you're used to it, and in my opinion isn't that bad to modify anyway
@@bakk. I can see that a code without any indents might be unreadable because someone might be expecting only one scope when in fact there are many. I think there is involved aspect of getting used to it
It's mostly a preference thing, I know some people prefer the single line syntax for short functions, but I'd say as long as there is consistency across the project then it's fine regardless of what code style is used.
I think that there are two schools of logic here:
1: Removing the braces encourages short functions and diving your logic into multiple functions.
2: Keeping the braces makes the code easier to change.
For instance if an additional option had to be added it is easier to add to that specific if statement rather than in functions called, since there might be multiple callers.
Just agree on one style in your team and that is the best one.
Source: Been a programmer for 7 years now.
@@Shadow10011 Yes!
Our developers make sure the code they write is readable and straightforward to edit.
If you have a "sum" function, and the parameters are x and y. It's kinda obvious what the arguments will be. But using strongly typed languages like Typescript and Elm helps a lot.
When you're working with really abstract things, It's not much of a problem if you're using a language strongly typed or has specs like Elixir or Clojure.
Thank you Kyle. Good stuff.
using a statically typed language makes everyone an advanced programmer according to your definition
legendary mode: ternary with coalescing
lmao
Really great video. Great explanation about code structure and thinking behind each improvement. Instant subscribe.
nothing is more satisfying than a clean code!!
16:14 Some would argue, including some Google employees, that .reduce() not only is able to reduce your code, but often also its readability
Yes, those discussions are part of the pro mode 😄
I would argue, that not understanding a concept and not understanding someones thinking are two completely different things. What I mean by that, is that if you are having trouble reading a fundamental aspect of the language, then that may be your own fault. If you are having trouble understanding they way somebody used it however, that's probably on them.
I personally prefer reduce() because it encourages early declaration of intentions. Something like this:
const weighedAvg = arr.reduce((acc, cv) => acc + cv.val * cv.weight, 0) / arr.length;
You know instantly what the code is trying to achieve without necessarily needing to read the implementation.
I guess the problem is when people try to fit too many things into one reduce(), then it can surely cause readability issues. Therefore I always (try to) keep my reduce() statements short and sweet, and make sure that it does one thing only.
@@scheimong Why are you all using "reduce" function to actually increase the values. That's oxymoron. This is the main reason why one should never use such things. Especially if there will be another noob who will have to take over the project and will try to read. He will spend countless hours reading up on all these functions just to find out, that this all could have been done in a much easier, cleaner and clearer way.
@@alet3348 reduce, also known as fold in other languages, is a *VERY* common operation on array/list/vector. Any self-respecting person who calls themselves a developer should know this by heart. If not, they should not be taking over any project.
What, just because noobs can't understand something means I have to code stupidly? Get real here.
Thank you for sharing your ideas, I'd love to see more such videos :) I prefer such notation:
return number < 0
? `(${Math.abs(number)})`
: number.toString()
Your videos have been a massive help to me as someone newly diving into the world of coding. Thank you for putting the time and effort into putting these out, they are already filling up my favorites list to use as resources when I'm refactoring my code.
but being the pedantic asshat that I am, I have to tell you that there's no "K" in "especially". haha
Brilliant advice! Thanx!
The "pro" version you introduced at 6:15 - Would a "pro" actually put the return statements on the same line as the if() clauses? I don't think so. I think what you have there is actually a stage between noob and pro where the developer thinks they're good enough to do away with formatting rules because they can read it just fine. Later they realize that those formatting rules are really for the folks that come after them.
I don't know why, I start code with the "pro" one for the first time. But now, I think my code just like "amature" programer. Just because you are overuse if() clause. And don't know when is the right time to use the "else" statement. If posible, I just write code into one single line.
@@Rhidayah It is almost never necessary to use an else clause. It must be years since I've written one, because they are just so unnecessary, most of the time. And yes, the function here should've been one single line. This is not pro code; it just tries to pass itself as such.
And how could be more cleaner ? 🧐
@@lucas.campora Personally my issue is with #1 the double equals operator. This is simply a no-no; If you're not using the triple equals operator, you're doing it wrong. Guaranteed this would be flagged in a peer review.
#2 Why are you type checking anyway? If the type concerns you, use TypeScript. Otherwise, passing the wrong type is a user error. If you absolutely have to type check, throw an error. Returning nothing is not helpful and causes side-effects.
#3 Removing brackets from your conditional doesn't make it "better." The brackets are there to partition the code, to provide readability.
Here are examples of how I would've done it --> www.paste.org/105678
usually those types of statements are at the top of a function, and are the "guard clauses" he spoke of.
i write my functions to have a "let rv = false" at the top, and modify rv, then return rv at the end of the function. one return statement, essentially. rarely do i use guard clauses, even. i tend to use the nested if statements. if you use a decent editor, you can collapse code blocks, making it far easier to read code, and debug. i find advanced code, although pretty, difficult to read - at least it takes me longer to decypher it. shrugs.
Everyone who is programming professionally: "use proper names for functions and variables"
Meanwhile what university courses use: function, func, x, y, z, a, b, c for pretty much everything
Ilja Knis God the pain of trying to understand professors random variables.
Anyone noticed there are adds on this channel. Glad to see and thanks Kyle.
These noob vs. pro videos are the best! Please make more!
I really dislike having multiple exit points from a function. It leads to return type discrepancies and it’s often easy to miss that an early return statement has been triggered when debugging.
Yes, and he doesn't need to write "number" in the function name when the parameter is called "number". I have fixed this...
const accountingStyle = num => {
if (!isNaN(num)) {
return num < 0 ? `(${Math.abs(num)})` : num.toString()
}
}