Good work on the presentation. It's an essential lesson for junior devs, though I'd expect seniors to already know this. Code in a function should be at the same approximate level of abstraction, and function names should reflect exactly what they're doing, such that you can read a function and instantly grasp the overall logical flow.
the basic inline - easier to maintain , the more abstraction / interface making the code hard to manage . Once we work company like that , every month programmer run away because too way many abstraction / interface . Keep is simple s *** . A junior will think good but not .
It’s a good suggestion and you’re right. Sometimes I had to zoom out to show what the entire function looked like but it probably would have been better to just use a smaller function. Thanks for the tip!
Make functions that do a single thing (single responsibility) and give them a name that self-explains what the function does. As an extra effort of good developer experience, write doc strings above the function signature so your editor can show the explanation of the function when hovering over it.
@squishy-tomato yes, you are correct. I tried my best to show your point about what the video should have focused on. But you’re right, I should have tried to emphasis that point more.
@@kantancoding Indirection is a problem when you have to context switch. This is bad when you have to go through several files. When functions are on the same file the problem mostly goes away.
Inlining is great, just not with screeds of imperative code. The problem is people try to abstract things down to 1 line, putting us back in the first scenario of too much useless abstraction.
It actually depends A LOT on what you're doing. Sometimes it's just better to inline, even if it's complex. It's called software engineering. You need to engineer a solution BASED on your context, not on some well-defined general rules.
@@kantancoding I don’t know about that. I see a lot of engineers get their brain lobotomised by some clean code and TDD books 😄 and can only think that way.
I'm curious of what cases you are thinking about, because what is exposed here is quite general. I wouldn't say it depends A LOT. As for me, I would consider inlining in scripts code but in application code, most of the time, I go for abstracting complexity as shown in the video
@@og-ncho yeah true, without an example it’s difficult to visualise. What I meant is like not abstracting too much and everything, especially if it’s not much reused. It will just make things way harder to understand and maintain, because things will become more coupled. I was thinking about the fanatics that says SOLID, hexagonal architecture and CLEAN CODE are the absolute way to go. While none of the FAANG compagnies uses that bullshiet (confirmed publicly on Reddit and others forums by directors of engineering at Google, Apple…). They think they write the best code with 10000 deep abstractions.
OMG! This is some pulp fiction level of story telling. Entire video I was getting mad at whatever you were saying, aren't we going back or something to the problem we're solving. But I all went away with the last scene. Moral of the story: Just read through the fucking chain and if you hate it try to do that linearly but you'll always fall into this trap of going back.
That's a long, but useful explanation why you need to give your functions good names. If I'm using more generic functions that I can't rename, I like to define variables that explain what is being done. Sometimes, I even split things up, even if I could chain them, if it's not causing big performance losses. This makes my code look more like "const, const, const, ..., return". You should only have to understand the left side then and can put debug statements in there easily. Here's an example in JS: function getAllMembersEligibleForBadge(badgeName) { const allPeople = getAllPeopleFromDatabase(); const allMembers = allPeople.filter(isMember); const badge = getBadgeByName(badgeName); const eligibleMembers = allMembers.filter(p => isEligibleForBadge(badge, p)); return eligibileMembers; }
Good observation! I like your example. Also, my hat goes off to anybody who can explain why it’s important to give functions good names in under 4 minutes 😂😅
My lead dev might murder me if I write four one-time-use variables when I could inline. But his code is a mess of terrible names and nested function calls. So I settle for a good comment explaining what my one-liner does. I may have less job security, but hopefully my coworkers won't hate me when they have to fix my bugs 😂
Man I honestly think that indirection is way worse than inline code. Is well known that the average person can remember about 7 items in a list on the fly (RAM), so I can spend my 7 slots jumping around or just use about 2, jus reading the function, that say, if the function is about a "screen" long. That's what I have come to. And please no arbitrary function extraction, a good excuse to create a function is that the code inside will used in at least 2 separate places.
You dont need to approach it like this. Each function small should stay at the same level of abstraction and be well named verbs for action functions or a noun for a query fuction or a is/has/should prefixed function name for a function that returns a boolean. Then you can quickly grep the code at a high level and treat the inners as a black box to be inspected piecewise when needed.
@@coolcodingcat Everybody does that kind of stuff, tell me something I don't know. Just stop preaching for people to cut the code into small pieces, I've even seen a function to abstract a , it's nonsense, but they claim "clean code"
Funny thing is inline code is the same mess as indirection.. it takes a good developer to balance both and convey an easy to understand mental model of the process
I just want to say that I just completed " Go for absolute beginners " taught by you on from freecodecamp yt channel, and I am really amazed by the golang. So what should I do next in order to get strong in Go language from the jobs point of view. And i just saw a playlist on your channel about Devops, so I just want to ask that whether the playlist is complete or not. I am in a really bad situation right now and I seriously want to study from where I can land a job. Please answer. Love from India ❤
Hey bro. The DevOps series won’t be getting any new videos due to low demand. But, you can actually learn a lot from what’s there so if you are interested in DevOps, by all means, give it a shot! As for your other question, try to build things on your own using the language.
Good work on the presentation. It's an essential lesson for junior devs, though I'd expect seniors to already know this. Code in a function should be at the same approximate level of abstraction, and function names should reflect exactly what they're doing, such that you can read a function and instantly grasp the overall logical flow.
Thank you! All very good points 💯
the basic inline - easier to maintain , the more abstraction / interface making the code hard to manage . Once we work company like that , every month programmer run away because too way many abstraction / interface . Keep is simple s *** . A junior will think good but not .
One suggestion I would have is to increase your font size a bit in certain parts of the video, good work though
It’s a good suggestion and you’re right. Sometimes I had to zoom out to show what the entire function looked like but it probably would have been better to just use a smaller function. Thanks for the tip!
Most importantly those segments are testable! Unit testing is a must to writing well organized code
Yes! We are 100 percent on the same page :)
Make functions that do a single thing (single responsibility) and give them a name that self-explains what the function does. As an extra effort of good developer experience, write doc strings above the function signature so your editor can show the explanation of the function when hovering over it.
Good point about doc strings above the function sig!
amazing video. btw what video editor do you use?
Thanks! I use Davinci Resolve
Which vscode yheme did u use in this video
I think gruvbox. The king of themes
amazing video. btw what's the font name?
hey! what vscode theme are you using? nice video btw!
Hey! Thanks for watching. The theme is Gruvbox most likely :)
Excellent pedagogy!
Thank you! I’m happy you think so 😊
You sometimes use inline and sometimes you extract methods, it depends on the application
Yes, you’re right!
I don't know dude, I think you ended up with same level of deep function calls or am I missing something
It’s different whem functions are on the same file
@squishy-tomato yes, you are correct. I tried my best to show your point about what the video should have focused on. But you’re right, I should have tried to emphasis that point more.
@cryptonative how so?
@@kantancoding Indirection is a problem when you have to context switch. This is bad when you have to go through several files. When functions are on the same file the problem mostly goes away.
I see! In the example the functions are not in the same file. Here is the code: github.com/docker/compose/blob/main/cmd/compose/compose.go#L683
Inlining is great, just not with screeds of imperative code. The problem is people try to abstract things down to 1 line, putting us back in the first scenario of too much useless abstraction.
I’m curious, why do you say that the abstraction in the first example is useless?
Thanks for this helpful content.
Thank you for watching brother!
Love these videos.
Thank you for supporting!
It actually depends A LOT on what you're doing. Sometimes it's just better to inline, even if it's complex.
It's called software engineering. You need to engineer a solution BASED on your context, not on some well-defined general rules.
I see your point and it’s a good one but I think that people get the idea and as engineers will be able to determine the extreme cases on their own.
@@kantancoding I don’t know about that. I see a lot of engineers get their brain lobotomised by some clean code and TDD books 😄 and can only think that way.
I agree and who says there are two laws to programming?
I'm curious of what cases you are thinking about, because what is exposed here is quite general. I wouldn't say it depends A LOT. As for me, I would consider inlining in scripts code but in application code, most of the time, I go for abstracting complexity as shown in the video
@@og-ncho yeah true, without an example it’s difficult to visualise. What I meant is like not abstracting too much and everything, especially if it’s not much reused. It will just make things way harder to understand and maintain, because things will become more coupled.
I was thinking about the fanatics that says SOLID, hexagonal architecture and CLEAN CODE are the absolute way to go. While none of the FAANG compagnies uses that bullshiet (confirmed publicly on Reddit and others forums by directors of engineering at Google, Apple…). They think they write the best code with 10000 deep abstractions.
Love your content, bro. Keep it up!
Thanks for the support bro!
What color theme is this?
gb
Nice video! I love it, very deliberaate
Thank you! And thanks for watching :)
What software do u used to make presentation ??
??
Please can you create a full backend course with lots of feature or just have a skool platform with quality courses?
Hmm I already have a few free backend courses on my channel. Just look for the really long videos (like 4 hours)
I think you emphasis on "high cohesion, low coupling" but not on code modules but on code segments. Am I right?
@arkantos14821 hey! You’re still here 😊 thanks for watching. And yes, you are correct.
what is this font?
Agave nerd font
I like your accent. Which part of India are you from?
The part called California, USA 😂
@@kantancoding Great. But where are your parents from?
They’re also American. My accent is from California.
OMG! This is some pulp fiction level of story telling. Entire video I was getting mad at whatever you were saying, aren't we going back or something to the problem we're solving.
But I all went away with the last scene.
Moral of the story: Just read through the fucking chain and if you hate it try to do that linearly but you'll always fall into this trap of going back.
excellent video!
Glad you liked it! Thanks for watching :)
That's a long, but useful explanation why you need to give your functions good names.
If I'm using more generic functions that I can't rename, I like to define variables that explain what is being done. Sometimes, I even split things up, even if I could chain them, if it's not causing big performance losses. This makes my code look more like "const, const, const, ..., return". You should only have to understand the left side then and can put debug statements in there easily. Here's an example in JS:
function getAllMembersEligibleForBadge(badgeName) {
const allPeople = getAllPeopleFromDatabase();
const allMembers = allPeople.filter(isMember);
const badge = getBadgeByName(badgeName);
const eligibleMembers = allMembers.filter(p => isEligibleForBadge(badge, p));
return eligibileMembers;
}
Good observation! I like your example. Also, my hat goes off to anybody who can explain why it’s important to give functions good names in under 4 minutes 😂😅
My lead dev might murder me if I write four one-time-use variables when I could inline. But his code is a mess of terrible names and nested function calls. So I settle for a good comment explaining what my one-liner does. I may have less job security, but hopefully my coworkers won't hate me when they have to fix my bugs 😂
Good video!
Thanks for watching!
what font do you use?
Agave from nerdfont
@@sneakybug thank you Sir
If you will write too much code you will not get much more money because of it.😊
Man I honestly think that indirection is way worse than inline code.
Is well known that the average person can remember about 7 items in a list on the fly (RAM), so I can spend my 7 slots jumping around or just use about 2, jus reading the function, that say, if the function is about a "screen" long. That's what I have come to.
And please no arbitrary function extraction, a good excuse to create a function is that the code inside will used in at least 2 separate places.
You dont need to approach it like this. Each function small should stay at the same level of abstraction and be well named verbs for action functions or a noun for a query fuction or a is/has/should prefixed function name for a function that returns a boolean. Then you can quickly grep the code at a high level and treat the inners as a black box to be inspected piecewise when needed.
@@coolcodingcat Everybody does that kind of stuff, tell me something I don't know. Just stop preaching for people to cut the code into small pieces, I've even seen a function to abstract a , it's nonsense, but they claim "clean code"
Funny thing is inline code is the same mess as indirection.. it takes a good developer to balance both and convey an easy to understand mental model of the process
@@ProtectedClassTest yes, for sure, there aren't shortcuts or laws, just rules of thumb and later experience in conveying ideas
@@ProtectedClassTest I'm sticking with a
talk by Avdi Grimm: Confident Code.
I just want to say that I just completed " Go for absolute beginners " taught by you on from freecodecamp yt channel, and I am really amazed by the golang. So what should I do next in order to get strong in Go language from the jobs point of view. And i just saw a playlist on your channel about Devops, so I just want to ask that whether the playlist is complete or not. I am in a really bad situation right now and I seriously want to study from where I can land a job.
Please answer. Love from India ❤
Hey bro. The DevOps series won’t be getting any new videos due to low demand. But, you can actually learn a lot from what’s there so if you are interested in DevOps, by all means, give it a shot!
As for your other question, try to build things on your own using the language.
@@kantancoding Got it. Thanks buddy!!
thnks
The problem here is I'm not into JS. I'm pythonic
It’s Go 😉
@@kantancoding really?
Yes. But actually, this isn’t a language specific topic so it wouldn’t really make a difference even if it was Python
Did this man just tell us not to use function just so he can tell us to use functions?
🤣
what language is this? hahaha
Golang
× goto definition multiple times and lose track
○ .d.ts