Remembering C# absolutely fisting me over implementation of interface Character after I decided foolishly to change it to abstract class made me realise how much I want to know if I'm using an interface or a class...

yea... that's a nope. utopian ideal. comments are super useful even when code is very clean. it has uses beyond describing code. in large production codebases it's not going to matter how self-evident a highly refactored part of the code is, you want to minimize human confusion and effort spent later teaching or correcting usage by new hires etc. if you are working on smaller codebases it also contributes to formal documentation efforts and human approach to code. they can serve as warnings about pitfalls that code doesn't currently demonstrate properly, and they can also genuinely make your own projects or small collaborations more fun to develop, because there's a clear voice and social aspect to it. good commenting is mostly instructive. what i would recommend is to get rid of comments that are making code LESS readable, and those cases are really quite obvious when you run across them. rather than suggesting we should not write comments, i'd try to touch the ground and suggest a pattern of commenting that engages you in such a way that you clean the code as a result of the comment and then more often than not will also end up getting rid of most comments, i think that's much more realistic.

1:30 i had a colleague take this too far and used "identifier" instead "id" would actually write "const postIdentifier ="

This is an outstanding video.

Why is it all or nothing? You can make pure functions in OOP and vice versa. The right tool for the right job, not fn( fn( fn( fn( return; for everything.

Comments are useful when they explain WHY rather than WHAT. Like, if you've done some horrible hack to get round a nightmare of a legacy module... you can leave a comment that says "Yes, I know this is disgusting but I had to do it because..........." and it may prevent somebody breaking your horrible hack by "fixing" it.

i only write warnings 😇

Immutability by default, mutable when declared is a good compromise many new languages (Kotlin, Rust) are adopting, instead of the pure functional way of no mutation.

Amazing thank you. What are you using to animate the code? And the diagrams?

I never knew I was a never nester.. I hate having long codes in one function.. So I instinctively used extraction without knowing it's actually a thing.. 🎉🎉

Y’all it is 2024. All the context you need is in the commit message in the PR (that means pull request) if you are looking directly at code you didn’t write, that’s on you to figure it out or use the tools.

The inverse of > is <= not <

I thought I avoided nesting to make my code easier to understand, now I think it's just cus I hated nests fck

FONT NAME? please

My variable names: __eoc __cpass __cpassl

I think the possible downsides of abstraction are worth it, because it forces you to think more about the design of your program and code. If you think your program has too much abstraction, you could be correct, or you could just have bad design.

"When you add abstraction you add coupling" Uhhhhhhhhh......

Me casually going 8 deep:

This take feels wrong. It seems like you are taking pieces out randomly based on repitition as opposed to creating a logical abstraction. In your save example, you would never just be delivering a file name, you would also have different formatting that would need to be performed. Using dictionary lookups or case logic to get the appropriate subtype allows easy removal and addition of different subtypes. I think what I’m seeing here is also abstraction without abstraction. You’ve gone from delivering a file name to delivering a file name to different different formats. You haven’t changed the scope of the task, only tried to cram more in. Elevating the scope and providing the necessaries to accomplish a higher level task is much better than trying to not repeat yourself.

I'm a hyper nester.

These are just two different styles of abstraction: Inheritance versus Composition. None of them is better than the other. It's just a matter of decision. And a good programmer should always be able to make the right choice depending on the circumstance.

Fuck this videos is old

This was such a good video. Tnx

But when you extract that block of code to a function and then call the function in the for loop, that's still the same for the stack, just less nested curly brackets, but technically the same, no?

Damn bro that was beautiful 🥹

This helped me understand a little more about Functional Programming

I never knew of the never nesting thing, but separating everything into small functions is a great idea. Then, your main run function looks like psuedocode

Very dry!

im not a big fan of "extraction" just for the sake of making code appear cleaner. especially if that routine is only used in one place. makes chasing the logic more of a rabbithole than just dealing with the blahhhh of having the logic in-situ. i'd rather have a comment and extra newlines around the lil block of mini-logic than bounce around through a bunch of functions defined elsewhere. particularly if those functions have sub-par names. however, "inversion" is unquestionably an S-tier tip! nesting aside, there's simply no reason NOT to get all your "early-out" conditions out of the way, so you can follow a really clear path down to the meat of the routine

What programming language is this? Bro, I got to say that your videos are making feel like an experienced coder although I am a total noob. Seriously, with all this insight I feel ahead of the game and my code has been beautified indeed. I also followed the NASA method of avoiding mistakes. Great videos!

Thanks for the video, one suggestion tho: removing the bg music would be nice

You definitely explain and make a great case for not abstracting code with implementation inheritance as it inherently increases the coupling between derived classes. That being said I do feel it odd to conflate abstraction by implementation inheritance with abstraction in general. Or that is to say that suggesting that all abstraction increases coupling is misleading. In the example you gave, you could add a level of abstraction using interface inheritance to define a common api for your saving objects and that would fundamentally reduce the coupling of the inherited classes with their consumers. I don't believe that it would be necessary to reach for that abstraction immediately as it potentially increases obfuscation without meaningfully impacting the future maintenance of the codebase. So I definitely agree with the thesis. I just felt uncomfortable with the conflation of abstraction by implementation inheritance and abstraction generally.

Yea, so the ethic now is: comments are generally poor, so better to just not use them. I hope you like to talk to other programmers, because the new ones at your company will be bothering you constantly for explanations of your code. Or you could just learn to write documents.

I find the music a little bit ambitious for a video about programming naming conventions

This is good advice.

10 nests deep == upsidedown from stranger things lol

Python is enemy

currying your monads. lol

wowwwww

What a horrible video. Computers are faster so programs don't need to be programmed better. Load of nonsense. Just because you CAN make a browser that uses 2GB of RAM and 20% of a CPU to render 15MB of script doesn't mean you SHOULD or HAVE TO. What a horrible mentality, it's like saying "it doesn't matter if you drive a battle tank to work if there's always more gas to put in it." Poor coding practice wastes a large amount of electricity and every year that fraction of unnecessary waste keeps going up.

Was trampolining mentioned?

This video MUST be required training for programmers! Excellent 👌🏽

For small code projects I always have a UTILS class to hold the simple methods. It keeps the main code cleaner to read and understand.

As someone who spent 5 decades in software development, I have seen this kind of paradigm shift every 5 years or so. 'Structured programming', 'Object oriented', Pascal, C/C++, Java, Rust, Python, each iteration seemingly 'fixing' the limitations or flaws of the previous one. I suspect that by 2030 there will be yet another wave of uber-geek alphas claiming to fix the 'problems' with the current magic du jour, 'Functional programming'. That being said, each wave has important things to contribute to the discipline of creating efficient, user-friendly software. All of which, IMHO, can be implemented in assembler. Just takes some discipline.

"if you write code clearly enough with well-thought out naming and structure, other people will understand it" is a delightful bit of optimism at the most diplomatic and an indication of one's position on the spectrum at the least. Doc systems for functions are excellent and should be the first line of documenting code because they also feed IDEs which do code hinting, but in real world conditions we will write code that LOOKS like an inefficient way of doing something because we've discovered flaws, even bugs in native methods that seem like a better way and we must remind ourselves never mind others not to go back and "fix" that line later. Comments shouldn't be a substitute for writing clear code but beyond that, this is like style checkers that complain about lines going over 80 characters: it doesn't matter to performance and we should mind our own business about it.

Good advise mixed in with academic advise. Even Hungarian notation has still its merits where you can fast see what the type is on use location.

"never abbreviate, period" Aight, lemme just catch my HyperTextTransportProtocolRequestException

How I would approach this example: Get to know the semantics of cookie headers and their parts (RFC6265), and use those names as identifiers. cookie-header = "Cookie:" OWS cookie-string OWS cookie-string = cookie-pair *( ";" SP cookie-pair ) cookie-pair = cookie-name "=" cookie-value So, I'd choose the following identifiers: cookiePairs for "s" cookiePair for "c" cookieName for "n" cookieValue for the return if stored in a variable

:)

"dependency injection sounds a lot more fancy than it is", yes.