Our professor used to call nesting "bad style". She was kniving points left and right whenever she saw it.

Amazing video! Thank you!

Is there any reason why not use _ in your variable names, like trailer_truck

I literally name every variable “shit”,”cum”,”fuck”,or “balls”

is coding hard? i want to study AI

What a masterpiece of a video

The key insight I take from functional programming is about determinism. State isn't a problem when you have a full understanding of all possible states you expect. The biggest source of bugs is when a program sometimes, for some reason, gets in an unknown or unhandled state. I really love logical tree structures, are all the possible permutations of inputs accounted for? Is the class/function handling the data a mess of edge cases or special exceptions?

Counterpoint: I write python in Notepad. It's awful and unjustifiable in every way. But it gives me the excuse to abbreviate.

This video is really good, but I found the music to be a little bit too loud at times. Thanks!!

Oh, please, this BS. See? I abbreviated and you knew exactly what I meant faster than reading "bullshit".

If I'm writing a small piece of code that uses time or coordinates. I'm using x,y and t. Your argument is that such names need context? Good. You should know the context before reading the code anyway. Your long names on small-scoped variables are making the code a pain to read and follow. And if anyone ever comes and tells me to use index instead of i, I will procceed to wake up immediately from the nightmare I was having in which JR coders with 0 experience are reviewing my code for some reason.

I'm more worried about never-testers.

What is a more general term for this? Sometimes we over complicate an issue that we have not even solved.

You would hate the code on the shader toy website

Things like "number%2==0? number:0;" do count? And what about sum += number * ((number+1)%2);

100% agreed with all of this. I'd also add a few more: 1. Functions that are designed to return something should start with `get`. `myData()` doesn't tell me anything, but I know instantly what `getMyData()` does. 2. Function names in general should describe what they're doing. e.g. `getData()` is worse than `getDataToPrefillForm`, and it's fine to have an entire sentence in there sometimes if the function is particularly complicated. Only comment if absolutely necessary to describe the function's interface in detail or to explain something. 3. Booleans should imply what they are. `reload` could be anything, `shouldReload` is a boolean. Although this is sort of conflicting with the "types in names" thing, I'd argue that this is more for intent readability than suggesting the type. 4. Actually solve naming conflicts. If you have e.g. `formData`, and you get new form data, call it `updatedFormData` or `newFormData` instead of `_formData` or `formData2` or something. 5. For tests specifically, it should basically read like English. `assertEqual(result, expected)` is less readable than `assert(result).is(expected)`.

In scientific codes where we do complex condition-checking, I've seen codes go twelve-deep and not even indent. No-whitespace languages be like that. (FORTRAN)

Theres a big difference between Interface and Class in C#. You cant say `thing = new ISortable()`. But you also dont need to know the exact class when accepting a parameter. The interface is just "this is a list of attributes I'm looking for on this parameter".

There is nothing to add. Thanks for the video.

I'm still learning to code (I've only just started properly using functions and classes) and im glad this showed up in my recommended, it makes a lot of sense and I'm gonna try to implement in my future projects. When I saw the title I thought you meant you didn't indent instead of not nesting lol.

The Java standard library (e.g. in the collections framework) has several classes named "Abstract‹Name of Interface›", which provide a skeleton of an implementation (using other not implemented methods), so people writing their own implementation can just subclass from that instead of starting from scratch (and implementing all the methods). That's less needed nowadays where you can just have default methods instead.

Under the right context single letters can be insightful enough, i for iterations, x,y,z for coordinates and even a,b for simple operations like overriding operators "return a+b" but most times i agree looks much better when full names are writen like row instead of r

JS Framework programmers: Guess we die then

Good old documentation solves this (no matter how tedious making the docs are)

I, too, am a never nester. Discovering this video has been cathartic to know i'm not the only one refactoring out else statements lol😅

That’s a bad practice, every function should have one point of return

I have been talking about this for so long that I don't even remember. I hate comments. In the last 2 companies, I have protested every time people ask for more comments in the code; as if it was obvious that more comments make the code more readable. I have convinced them each time that comments reduce the maintainability of the code and it is tiresome to write and maintain them. It is just easier and faster to write good, readable code. And I agree with your exceptions as well. I also use comments in that case. In fact, the most often that you will find me using /* * */ comments is to create code documentation. You write that kind of a comment in the code right before a function, for example, and the IDE helps anyone calling that function to use it efficiently. Although, this is only helpful for dynamically typed languages like Python and JavaScript. Recently, I have also moved almost all my JS work into TS projects so I don't have to write those comments as well.

Working on a video game at the moment and sometimes a comment like "F = ma" above a line/block that calls vectors and does some math clues someone in that you are trying to impliment a pre-existing formula. This lets it be ignored if its not relevant and skip to some other section of logic

The first satisfying/soothing code video

Just started learning programming and I've actually been doing the never nesting stuff without anyone telling me. I create functions for every little thing. Not to make it more readable for others, but for myself to be able to understand it 😂

You can either write comments, or write perfect code. I think I'll keep writing comments.

One reason to use "Base" is in languages where it is traditional to put parent classes and subclasses in the same package. In these languages, you often end up in a scenario where avoiding "Truck.Base" or "Truck.Generic" means you'll have a class called "Truck.Truck."

"People don't update comments when they update code" is not a valid reason. That's just being a bad developer. It's no different then not updating documentation or not testing before pushing. Good engineered code needs less commenting. But you aren't starting a block of code every time with designing a space ship, and you shouldn't if you value accomplishing tasks in a timely manner and not bloating your codebase. I often write everything out in comments and then fill in the code after. Other times when I've planned less or am debugging, I write out my thinking as comments as I go. A year later this helps me more quickly absorb this code into my mind space. I tend to comment loops, conditions, and function calls that transform data. I don't explain every single line. I think its just bad to tell people to not write comments. Yes, good semantic code is good. No, comments aren't bad. If you have an elitist issue reading comments, you're free to parse them out and pretend you're a compiler so long as you don't commit that and rob less skilled devs.

clickbait title. It should say "Abstraction can sometimes increase coupling", and that's true. But not all abstractions increase coupling (some reduce it), and not all coupling is bad.

The only time I use comments is when outlining a function. If the function needs to do 5 things, I'll start by writing out the 5 things it needs to do. Usually, functions that do more than 2 things pass the responsibility off to smaller functions, and the comments disappear with that refactor (The comment is in the function's name, now); but on occasion a function needs to be atomic for one reason or another

I spend probably 50% of my research into naming things (because the topics I’m usually programming have to be accurate- sometimes the names for concepts don’t exist/ are ambiguous/ correspond to different topics- so, I try to choose the ones that are the most systemic or scientifically accurate)… Naming things is really hard. Some words need to be better defined in the scope of math / CS: “Modular”, “Order”, “Degree”, “Shape”, and *“Connected” are some of the ones Ive had issues with.

hey!! have a question hopefully someone can answer! do interfaces provide runtime polymorphism (though polymorphism is probably not the term anymore)? Just curious how it behaves

I aim for at most 3, 4 if absolutely necessary. Never had to go for 5 deep. I am also a performance freak because of my ICPC background.

If it fits, it ships

"Choosing the RIGHT dæta structure can give dramatically better results over the WRONG dAta structure." I agree.

I've been working with Golang for a few years now and inversion is quite natural there, which makes you a never nester by default. Now I am doing some work in C# and I have to force myself to never nest, which is awkward, but satisfying.

Good luck writing jsx or html lol

Conceptually correct; however, nobody is going to make such a generalized class name + not have any comments. Enums help sometimes to fix some issues that come like this. * nobody should write code like that,,, but people do all of the time. I love Java, but the constant need to use class hierarchy is frustrating. It’s not unique to the language, but I think I abstract more in Java that other languages: Due to interfaces, FunctionalInterfaces, creating wrappers for primitives, annotationprocessing, etc…

great video! I disagree with the recommendation to avoid the Utils type of stuf... wish you would have elaborated more on they "why"

What you called Currying might be more pedagogical to call a closure. Currying is a related pattern where a function with multiple arguments is transformed into a sequence of functions that are all single-argument functions. Currying can be achieved by repeatedly creating and returning closures, each one capturing one argument. In this particular case where you have a two-argument function and use a closure to create a one-argument function you are ending up with a Curried function, however the explanation you give where an inner function captures an external variable and the inner function is returned out, still "enclosing" the captured external variable, is generally called a closure and it is the way in which you can step-by-step transform a function to be a Curried function.

Normally the best optimizations I have done have been when a function was making a really expensive call in a loop. Then just handling it to only make the call once instead

Nobody tell this guy about HTML

Booger Aids: aids booger

Where is your next video !!!

I like the cleanup shown, easy to follow. I wonder if it would be possible to have a: "2lvls == 2deep"