One of worst videos so far Throw a bunch of statements from 20 years old book, and opinionately state these as 'good', and all other ways are bad Code comments show this most beautifully
Hey! Thanks for the feedback! Even if we like it or not, Clean Code is popular and widely discussed in the dev world. In this video I tried to sum up what I found most useful in the book. I think it was published back in 2008, which makes it la 15 years old, but I don't think the software scene changed that much in the past 15 years to call it deprecated. I learned during the years that "good" software is actually really subjective. You'll see comments in this video mentioning that Exceptions are the worst, and Go error values are the way to go. If you watch my previous Golang video, you'll see that the first thing people complain in the comments are the error values and Go's verbose error handling. So I think you can see how difficult is to write a book on good software since the opinions are so divergent even for some of the most basic tasks. I don't believe there are clear rule of thumbs when it coms to writing "good" software because this is dictated by the people maintaining the software, their experience and preferences. When it comes to code comments what I stated was that "comments do not make up for bad code". In other words, if your actual code sucks, it has logical flaws and is overall not following the best practices, having good comments doesn't really make things better. As I stated in the video "if a method has more comments than lines of code, that's a code smell".
No you did a good job with this video because you put things in perspective and were not dogmatic about it. Some rules are there to be broken but you need to at least know them.
I would say that comments should not be explaining WHAT is the code doing but WHY. The what should be visible from the code, but it is not often clear why. Explaining why is it there should prevent people from deleting it "because it doesn't even seem necessary" - when it's actually a super important hack that prevents the whole thing to crumble (on some of the supported platforms or under some crazy non-obvious conditions). What I also like is to put some traceability into the code, as in "This function fulfils the requirement REQ-001". It's not always nice but very handy when someone needs to verify that all requirements were implemented and how.
I think its more like so someone else can find things easily. Cause you usually know where everything is in your room even if its very messy, until you go on vacation.
Good video, but I disagree that “good code doesn’t need comments”. Some code is complex by default and also if your working on code in which developers over many years are writing then having useful comments can be good. Imagine a codebase over 100,000 lines of code with no comments! You will pray it has some internal docs but it probably wont if you wont even comment the code! Also there are librarys to use code comments to generate a web version of the docs.
Good point! I should have word it better. The point I was trying to make is that comments should not be your “fix” for any code that looks complex. Sometimes, refactoring and code clean up are the smart choice.
I thought the same when I was watching, I think the best thing you can do for very complex code is try to make many tests for it and explain what you are doing in the tests, big libraries/frameworks like React do that
I was agreeing until the "use exceptions". errors as values are so much nicer wdym?? so much more explicit and clear where errors can happen, and forces you to handle all errors.
I think the counter argument here is that errors as values are tightly coupling your error management to the actual business logic. I can see it go both ways. To your point, Go has errors as values, and you can see in one of my recent videos that a lot of people are complaining because of the exact thing you like. (Video - ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-TGz4Osgk7AQ.html) That's the thing about coding best practices and principles - it is extremely difficult to make everybody happy 😅
@@awesome-coding Keeping the error handling logic close to its source makes for an easier debugging session and also makes for code that is easier to understand. There's nothing inherently wrong with coupling error management and business logic, I'd even argue that if you want to gracefully handle your errors, you must think of them as part of your business logic. People complain about errors as values because they are used to exceptions but it goes the other way, once you get used to errors as values, you don't want to go back to throwing exceptions around. I think you might like Carson Gross' essay about "Locality of Behaviour". Cheers and thanks for the video!
@@zyriab5797 Totally agree, people tend to try to find cookie cutter examples to make them feel good, this is not how software works, some code will be inevitably hard to understand no matter how nice you named a function... Locality of Behaviour is one of the few things that actually helps. also overusing OOP will lead to bad code 100%, it only appears clean code if you look one file at a time...
Here's a thing I learned about testing best-practices: Test higher-level requirements, not implementation details. I've seen some developers test nitty gritty details of their implementation, which doesn't really matter. And the result is code that is hard to refactor, and by extension hard to maintain, because despite requirements remaining the same during a refactor, tests fail and you have to adapt them to the refactor. Adapting tests is a necessary thing, but only when the actual requirements of the SUT changes. This obviously relates to the point you made about not over testing, but this is my attempt to explain what that actually means.
Yep, the problem is that "Unit Testing" has always been extremely fuzzy in *what* you're testing - I spent years making every damned function public so that I could test it because of this. You test your public interfaces to the code written, private code should not be directly tested, but exercised through the calls to your public interfaces. Most of your code should not be public. When you think in that way, you *stop tightly coupling your tests to your implementation*, code becomes easily refactorable without "we made the change but 300 tests stopped working, so we disabled them" happening. It also makes you start thinking about your interface designs, and how your code is modularised behind them. It's almost like it's all a virtuous cycle... :)
3:59 Be careful Boy Scout! You might violate another important guideline! 1. "Don't make unnecessary changes" or "Avoid making changes for the sake of making changes" 2. "Keep your change small and focused"
One thing you forgot to mention is to split a big complex function in pure functions and impure functions, because with the pure functions you can do unit tests and they usually has the logic of your app
I agree 99% of this, this is really good!! 🙏 The only thing I disagree with is that you should avoid duplication at all costs. Sometimes it is better to write WET code when code becomes hard to understand. Don't make it so DRY that it becomes a desert 😎 I guess comments in moderation are also not bad.
Commenting code is important when you are authoring a library; imagine the horrors that might unfold without JSDoc comments when you need to use a JavaScript library!
I don't agree with comments being code smell. It could be very helpful understanding the business logic behind the code or why something was implemented in a specific way.
Having more lines of comments than actual lines of implementation is a code smell. That's what I was trying to imply in the video, but probably my wording was wrong.
I disagree with all this throwing exceptions, exceptions are not free and in some languages don't have stacktrace and makes so much difficult to debug, assert over throw always. Like Tsoding once said you can put any adjective in front of code and write a book about it, Sad Code.
It’s not that functions must be small, but functions should only do one thing (single responsibility principle). If you write long functions, you probably are failing this principle.
@oumardicko5593 I agree as well. This is why I mentioned that arbitrary rules lile 20 lines long functions don’t really work in the real world, but you should still try to follow the principle
Clean code is just a myth. Its hardly feasible in a real environment where management wants everything done as fast as possible, they don't want to sink time and money into something that has no direct business value. The only exception being massive companies which can afford to spend money and time on quality code because their reputation depends on it. Take your own example for instance, that placeOrder function never improved because of the mentality of "if it works, let's not spend anymore time on it"
@@awesome-coding what defines "good code" is usually dependent on what the project is, if you have a project where performance is priority, "good code" might be code that has good performance, and clean code doesn't always have that, so it might not be considered good in that scenario
I found the wording in the video "when forced to write tests" a bit odd. I often write the test first because it crystalizes what I expect the code to do, and forces me to think a little about edge cases and boundaries. Then the test allows me to refactor fearlessly. Lately I have even started using tests to make ai code-gen smarter. Sometimes I can write the test and then only a small part of the code that should pass the test, then hand it over to an ai loop that runs the code, examines the output and errors, then rewrites the code until the test passes. Not as good as my own handwritten code, and I usually have to make a few adjustments even after the test passes, but still at least 10x faster. I love test code.
writing good code is doable in c++ and rust writing good code on a frontend project with reactive framework, props, components, tailwind etc is practically impossible, its a complete mess
0:54 c’mon! Everything is fundamentally agile! Everything has to adapt or die. E.g large companies are constantly trying to adjust course based on changing markets and environments… only the most agile of those companies survive. It’s as true for the largest groups of people as it is for the smallest groups of people. Adapt or die. More generally though, everything we do is based on assumptions about the current state of the environment around us. From those assumptions we build hypotheses and a strategy. If we don’t validate our assumptions and the derived hypotheses often, we won’t be doing the right thing. The longer we take to work out we’re wrong, the longer it takes to do the right thing and more time is spent doing the wrong thing. That equates to wasted effort and gives your competitors time to catch up and move ahead.
I fully agree with you. However, in software development Agile is kind of linked to SCRUM these days, which is just a waste of time and resources these days. At least this is my experience with it.
@@awesome-coding sure, if you consider scrum to be agile, which it probably isn’t lol. I’m a big Agile development advocate. It’s a big problem that people associate it with Scum and that scrum has such a bad wrap. It always pushes people into an even more waterfall style of development… which is actually the opposite of what they really want. People also seem to think Agile means no plan or no planning. Which is also wrong. I think Dave Farley describes Agile the best.
If you do OOP or even function/constructor which have some preconditions(invariants) using it wrongly is exception/error so throwing is acceptable. Elaborating some convoluted way to return exceptional situation as a result (like constructor returing null) is worse and maybe dangerous. Imagine function calculating total weight of plane cargo, wich is given some shit data (negative unit mass for example), what it should return ?
But if I'm using a source control manager like Git I would be able to see what commit added a method / change in the code base. That commit has usually a message linking the commit to some sort of Jira / Asana task, so it would be very easy for me to jump from the code to the actual Jira issues defining in detail the business logic requirements. Why would I duplicate that in the code?
It’s okay to have some duplicate code, so my tip would be to not take “avoid duplication” or the DRY principle too literally. Premature abstraction is an easy way to waste your time!
I think we should actually define what code duplication is. If the implementations are somewhat alike, but it would take a couple of minutes to match them in a single implementation, I'm ok with postponing that. If you are copying a function and only change a parameter / adding an if statement just because you are lazy you should be ashamed of yourself 😅
Comments for edge cases are very very important, especially when doing more complex backends tasks. Documenting flags, magic offsets and other such items is pretty dang handy.
If it's an algorithm that's based on an obscure mathematical formula, then each function under it should at least be strictly single responsibility and have a clear expressive name. But if it's just business logic or utility logic, then it should definitely not require much explanation aside from what the top function does.
The best tip I read in his book is to write one assert per test. At first glance, I thought it was a stupid rule. I tried it anyway and discovered that my tests became much cleaner. This resulted in quicker test writing, easier code, more test cases that I wrote on average and with that more code coverage. Overall, it made writing tests a whole lot easier while also improving the quality of my code.
