Видео

these videos are so good. already knew it but damn. i wish i was a noob watching these

0:04 1. fmtr should be allocated after check for empty string, because it is a rudimentary allocation if empty is true; 2. it is not necessary to allocate validator to check string length; 3. there should be check for error before return from db.fetchData or for empty return; 4. formattedName is unnecessary allocation, since fmtr.formatName call can be passed within db.fetchData call.

Your style of editing is so good...

some people write code that only them can read... and they don't care and keep doing because in the event boss is thinking in firing you or hiring another dev he will be the one that know how to maintain it making him more valuable.

Kantan, didn't you make the same video last 2 weeks?

woow i love this kind of coding video !! what do you use for the filmmaking of the code part ?

2:48 ok i have to disagree with the extraction approach there, you are just trading readability for more abstraction which is even worse, i believe a priece of code should only be extracted into its own thing if its would be used in several places, many times, not this one piece, that likely only happens there

This is probably the most useful information for me as someone who has just started to learn Python. I was taught a little bit of programming by my father in the 80s (DOS Basic, and then later GFA Basic and Laser C when we got an Atari ST), but unfortunately I never got very far. In the late 90s I started working for a large PC manufacturer and ended up in database management, but I was relying mostly on visual editors and editing existing SQL. I did write quite a lot of Access and Excel VBA (and some VBscript for outlook forms), and I was playing around with Visual Basic at home. But without knowing about things like style guides, good coding practices and basic algorithms, everything that I wrote ended up as a giant, deeply nested hairball that no-one else would have been able to decypher! 😂

Sorry that's a no a Go fir me. Roger that?

Usually it's better to sacrifice performance for readibility. This is where CS programs set up their students for failure when they get to the real world. The thing you really need to optimize for is Mental RAM. Engineering time is expensive. Writting code that's easy to understand and refactor and is tested will save engineering time in the long run.

*So...:* - Try to not nest. - Function spam. - bool UseElementNamesThatAnyLaymanCanDecipherInOrderToKeepYourCodeReadable = True

Great video helped me understand the concept, thanks much ❤

+

thanks!

1. KISS, avoid nested code. 2. DRY, have a single source of truth / point of failure. 3. WHY, use names and comments to describe why the code is there.

One other thing you can do is maintain objects so you can use the 'if' statements wherever you want, to check for the current status of the block of code you are running. Sometimes it won't work but most of the times it will work.

I call it "The indian arrow." Once our externist (guess from where) gave us a 10x (I kid you not) nested code. Truly amazing.

Unit tests help void somethibg liek segfaults. However in my experience (embedded) there are far more functional bugs that sometimes only get noticed in field tests.

best explanations on go concurrency i found on RUclips

The first two laws of code reduction. Third law is give meaning full descriptions to your variables.

❤❤❤

very nice and simple explanation on channels..

10 seconds in, already parroting propaganda. Experienced dev don't have issues "reasonning" over such code, inexperienced devs do. Train yourself to read code or your career will be miserable.

There are a few critical bits: First, this is on the Go Programming language. Any other programming language probably works different, I can at least confirm that for a couple. Second, the rules of the presented programming language behaviour are still unclear/dubious. Better practice is making a class giftcard with an attribute int amount and a function deposit(int). And after all, any hardware-near implementation of the closure will expose this fact, because you need a function pointer (as depicted) with a state (as is what a class object with attribute instantiation is).

What font do you use in your code examples? It's beautiful.

Very useful

In my Software class, we learned the following principles: Don’t repeat yourself (DRY) Comment where needed Fail fast (code should reveal its bugs as early as possible) Avoid magic numbers One purpose for each variable Use good names Use whitespace and punctuation to help the reader Don’t use global variables Functions should return results, not print them Avoid special-case code I think this video summarizes many of them!

Great brief explanation. As someone once said, bad coders know what to write, whereas good coders know what not to write.

Back here to refresh and strengthen foundational knowledge. Thank you for putting these together!

So far, your explanation is the best one 👍🏻 Now I understand how to implement Interface for Polymorphism 🎉 thanks mate !

I appreciate the effort you put into this video. On behalf of all noobs, I want to thank you for the complete explanation you have provided. GO is an interesting departure from c++. Some packages need some time to digest. This is a fantastic video. You should have more subscribers, like me, who are happy to have found this channel.

Beautifully animated video, great explanation and delivery, thank you!

yeah and on the extraction rule of thumb: 3 to 5 actions, which produce 1 action when combined. e.g. function is "cook potatoes" actions would be "peel potatoes", "chop them", "choose a way to cook them", "cook them the way you chosen to". if you can split an action into more or equal amount of actions you should do so. e.g. ",cook potatoes the way you chosen to" can split into "get the chosen cooking method", "prepare for cooking" and "do the cooking". you can split actions into more actions into more actions. they only need to result in one concrete thing and be semantically similar. like e.g. when we cook we will do things related to cooking. we will not focus on arbitrary actions like "take the knife in your hand" if it isnt obvious how we will relate that action in the context of splitting another one ("take the knife in your hand" and "make a chicken stock" arent obviously related, imagine if we dont have to chop anything why did we take the knife then?)

ive had cases where second law doesnt apply. like when same methods are in different modules, they both are depended on, need to be incapsulated strictly in their modules and moving them around requires moving a large chunk of code along with them potentially breaking everything and bringing a disaster upon oneself often called "integration hell". yeh that sucks a bit but hey if i just copy my code once you have to read it only once, i dont break anything and its okay

So helpful

1) Modular and maintable code (use functions) 2) write Unit tests 3) Write regression Test

NASA programming follows all of these (and then some), mostly to avoid stack-heap-collisions and use less memory+energy.

i agree 100 % but i have also worked two projects where "integration test" was the unit tests, and that ... was a flipping nightmare.

Law #4: never right negative properties. The name of your property should be something such that knowing what the default is is very obvious and straightforward. If you find you are putting the word not in your property names then you have it backwards. Example: DontProcessX. In this example in order to process x you would need to pass false. You're much better off with a property called ProcessX

Law #4: never right negative properties. The name of your property should be something such that knowing what the default is is very obvious and straightforward. If you find you are putting the word not in your property names then you have it backwards. Example: DontProcessX. In this example in order to process x you would need to pass false. You're much better off with a property called ProcessX

OMG. I love how your refactoring of code actually changes the logic and you somehow breeze right over that as if that's not kind of important??!! I think I need to make a video about rookie developers doing RUclips videos. 🤣😂🤣😂

I've had to work behind senior programmers who like to use single letter names for pretty much everything. They get good evaluations and promotions because of how fast they can code this way. No fun trying to understand what they did though.

that's 100% true , consistency is key

I fully disagree with 2:46 because if you have a bug or the code needs to change, the developer who reads the code will be like "what does is valid user mean?" then he needs to open that function, read it and keep it in his mind, if that function exists of other functions, he needs to do the same... this is kinda the same problem as too many indentations, but worse, it just looks neat, but it's totally impractical

STOP TURNING YOUR SIMPLE COMPARISONS INTO FUNCTIONS A simple comparison is much more obvious and clear to read than a random function call

is that htop showing processes in the monitor in background.

So, i'd disagree with the extraction bit. It might be easy to skim code when you do this, but it actuslly degrades from the READability. Most programs I've seen have everything as a small little function instead of just writing it where it's needed. When looking through people's source, it's difficult to scroll to the function and back and scroll to the function and back... Though, I do use this for more mathematical functions and, of course, when I have code that is duplicated

Good advice!! I would summarize the video at the end just like the thumbnail, learning is based on repetition after all :D