Hearted Youtube comments on Kantan Coding (@kantancoding) channel.

  1. The reason math is poorly understandable is not its inherent complexity, but the fact that mathematicians for some reason are all using single letter meaningless variable names
    3200
  2. In my opinion avoiding duplicate code is often taken too far. You avoid duplicate code if the code has the same reason to change, not just to make it look prettier. If you try to extract every inch of shared logic you’ll end up with high coupling and your code will be even harder to maintain
    2200
  3. And remember: "Potential readers of your code" is more than likely going to be YOU in the future.
    2100
  4. Imagine someone writing a program that converted well-written code to badly-written, by nesting, duplicating, and renaming.
    827
  5. 1. don't deeply nested code and not using inversion; avoid deep nesting by inverting conditionals, merging related if statements, and extracting complex logic into separate methods or functions 2. organize code; prevent code duplication by extracting shared logic into its own functions. 3. don't use naming that only you understand; use clear and descriptive naming conventions to make the code self-explanatory and easier for others to understand.
    625
  6. Coming from a math background I actually find having to using explicit variable names makes it hard to calculate more than using Greek letters. There's a topic about this on Math Stack Exchange.
    531
  7. Hey Kantan, I believe this video is for your coworker who does not write unit tests lol
    305
  8. 2:46 I feel like the if statement that checks if it is a valid user does not need to be in its own method, as it is literally two lines of code. I get that making it into its own method would allow whoever is reading the code to instantly understand what the if statements are for, but another part of clean readable code is conciseness and being succint. If we are adding another two lines of code that doesn't actually much affect the readability of the code, then it isn't very necessary.
    281
  9. I'm leading a project which consist of migrating old PHP code. I found up to six levels of nesting, functions with bodies of more than 3000 lines (yes, three thousand), copy-paste engineering galore and many, many other issues. They blame PHP, but I blame the programmers, who even today still write very sub-standard code
    277
  10. E-nooom 💖😭
    268
  11. All of them are done by a junior developer using chatgpt, just changing the prompt.
    218
  12. The simplest one is the senior one. A senior dev prioritieses readability over fancy nonsense. They know this because they're sick and tired of explaining the code to the billionth junior and mid level dev.
    217
  13. It’s worth noting that the first example refactor changes the program behavior- they are not equivalent. It needs additional return statements in the guards .
    166
  14. Saying that without abstraction you have to duplicate the greet logic "over and over again" is a complete disservice to other paradigms. Your right absolutely noone in they're right mind would do that... But functions exist for a reason. Inheritance isn't the only solution to these problems and videos like this, imo, do a bad job at demonstrating the options, new programmers will see this and agree with what's being said (which isn't wrong) but they'll take away that abstraction is the mechanism to solve this problem. When In A lot of cases alternatives are better suited.
    162
  15. The background music is annoying.
    147
  16. Basically, just make sure your interfaces make sense, and document them well, so no one has to look for the actual implementation just to understand the intent. And know when it's not worth the hassle to do all that
    146
  17. Python's "f" strings are amazing
    127
  18. as a lead dev, I can only say that you never want to debug such code, which contains 10 small functions, because someone decided to split everything. It is a huge pain to debug such code, because you have to switch context a lot. You have to switch between function, classes, files. Sometimes it is much better just to have one bigger method instead of 5-10 small. Sometimes it is always better to not create an abstraction for every single potential change, because many of them will never happen. For example, it doesn't make sense to create an abstraction for delimiter, because delimiter may never change. But sometimes it makes sense to create such abstraction, haha...that's the hardest part of programming - to find a good balance and write readable not overcomplex code. It is not hard to create overcomplicated code with many abstractions, but the real problem is to create easy readable code for complex solutions.
    114
  19. all this work and you're still saving untrimmed name to the database lol
    111
  20. Maybe the only way to write code with no bugs is writing no code at all. Writing tests help to mitigate what we know that could go wrong, but we can't be 100% sure that our code runs perfectly 100% of the time, because we can't know in advance all the contexts of use of each piece of software that we build and we use.
    108
  21. I've never really understood the "don't use comments to explain how something works only why it's in the code" argument, but if the example in this video of explaining "how" is what that rule is supposed to stop, then I totally get it now.
    99
  22. I can't read the code with all this movement :( have a good day.
    93
  23. I was in a project where pieces of code where repeated frequently, so I created a function that took the generic parts allowing to reduce a considerable amount of code everywhere. Turns out that instead of using the function, it was used as a paperclip and other team members copy-pasted the code inside of the function whenever it was needed... The conclusion is... I don't know, that was really weird to experience
    73
  24. for anyone worried that using const variables will be worse for performance since you need to create variables for values now. First of all most compilers will substitute const variables for a set value anyways and is used exactly as if you just typed the number instead. Its a win win. Secondly, you should not do premature optimization anyways since it will make your code way harder to read, maintain, refactor and change later down. Only optimize when needed, prioritize more readable code before that.
    72
  25. To those who are confused about how log works, it's basically like splitting a log. All it's asking is how many times do you have to split the big number by the small number to get down to 1. for example log base 2 of 4 basically means that you have to split 4 by 2 two times to get to 1. another example would be log base 4 of 64, you have to split 64 by 4 three times to get down to 1 single wood log piece.
    71
  26. Holding a computer on your lap is very unergonomic. You will be in pain in the future.
    69
  27. Oh my days. I've been stuck on this for so long, and I finally figured it out. So in a binary search, each pass halves the data set. BECAUSE THE BASE IS 2!!! Thank you so much.
    68
  28. For the last example, I would use keyword arguments (python) instead. Like createUser(name="Alice", age=30, ...). Less bloated and just as clear, and on top of that the order of the arguments doesn't matter.
    67
  29. 1:35 You've got the example wrong. We're not `grep`ing the output of the program for the error message (splitting up the error message in the source code isn't going to cause it to be printed any differently anyways): we're `grep`ing the source code for where that error message is, so we can see under what circumstances it gets printed.
    67
  30. Fantastic. It is extremely rare to come across this level of concise and easy to follow explanation.
    66
  31. I've just got that "oh" moment, it all clicked! thanks!
    65
  32. What does the fox say?
    64
  33. I’m not inexperienced but I stayed for your animations
    58
  34.  @kantancoding  Good to know! I’m clearly not familiar with Go 😅 So for a more general refactor recipe one would basically make the (implicit) returns in the "leaves" of the control flow tree explicit before applying inversion and remove redundant ones afterwards.
    58
  35. You know what's even better than tests? Type checking.
    55
  36. One of the best I've seen. You are the rare type that can take complex concepts and explain them so well. I hope you continue to make this kind of great content!
    53
  37. Kind of ironic that a video about readability flashes words onto the screen instead of displaying the full text and animating it... ;P
    50
  38. I was on your side until you talked about the functions. Don't get me wrong, functions are useful, however, functions which only have 1 return line or less than 5 lines altogether, are unnecessary and using those would require the reader to potentially jump around in different files to find what the main code is doing.
    48
  39. Great explanation, but you gotta get rid of the hand. It's extremely distracting and adds nothing to the video
    47
  40.  @guruware8612  I prefer Rust's "panic!" :) I guess "fatal" implies that the program cannot recover, so it makes sense. But the problem is that in many logging libraries, "fatal" is just a log level like any other, and won't exit the app automatically. As for calling exit() on error, I think it depends more on the type of application than on the language. If it is a command line app that only does one thing (which this example kind of is), then it makes sense. But if it is something like a GUI, you probably want to display a message to the user and let them try again or something.
    47
  41. My takeaway is that stampeding buffalo are just saying hello.
    47
  42. You should know that your channel is soon going to grow crazy. Loved the content. Especially the graphic part and the tools used makes the concept so much more clear. More power to you.
    46
  43. comment for the algorithm
    45
  44. I really dislike the common wisdom about "self-documenting code" as it is proven again and again by examples that are the simplest of simple code. I think it all starts somewhere different. And that's the distribution of logic into multiple methods when it does not need to be that way. When ever something gets so big that you might add in a comment, someone will say "just split it into descriptive methods", and yes, in the spirit of uncle bob you can split that 30 lines method into 10 simple methods. And instead of reading the code from lines 30 to line 60, the dev now has to scroll around trying to memorize 10 methods and what they do and build a mental model of how they are called. And after splitting one method into 10 methods, it's suddenly too much work to put a doc header of them, so we don't do it because we don't like tying shit after we just split that shit up for no reason. Three steps back. Lets not split up code if there's no reusing of the methods. Let's keep the code local, in context. Complex code exists, because complicated tasks exist. So you got complex code. Your coworker asks "what dos that do?" What do say? Do you go line by line saying things like "so this line checks if the first parameter is null" and so on? Of course not. Your coworker can read. Human language can is great to explain the concept of something. You will probably be able to formulate one sentence that can explain a complex block of code. Well, if you understand that code you should. And that's a good comment. Because three years later, someone will search for a bug and will find that block of code and ONE GOOD LINE may explain it better than anything else. "So what if the comments lie?" Comments are written with the assumption that code does what it is meant to do. Comments may "lie" when the code does not what it is meant to do, but in that case, the bug is the discrepancy between intended and actual behavior. You got two versions now, one telling you what it does, and one what it is supposed to do. You can now check if the assumptions where wrong from the beginning or if it's an implementation error and the fix is going to make the code do what the comment tells. That's my experience in working with complicated code.
    44
  45. Bad programmers waste hours refactoring code duplication, good programmers copy and paste because: 1. Makes their job easier 2. There will NEVER be a case where two objects will use the same code forever, you can try to prove me wrong I'll wait
    44
  46. When I read the legacy code , developers always give bad long name to the magic numbers, making the code more difficult to read.
    44
  47.  @guruware8612  it's a standard library function dude. Combination of being pedantic and clear unfamiliarity with the language.
    44
  48. that func saveFormatted is a bad idea it doesn't do any formatting and just saves the raw input, so if your API consumer doesn't format first you now have incorrect data in your db. should've called it saveUnsanitized if that's what you really need, or just call it saveFormatted and implement as db.save(format(name)) that way the format function is still testable but any data inserted into the db using your api is also formatted
    41
  49. Wow!! This tutorial is so underrated. You deserve more recognition!
    40
  50. Missing doc strings... I get that you don't want too many comments, but I shouldn't have to read the code to know what a function's effects, return types, or exceptions are.
    39