@user-sl6gn1ss8p
You know, it's always Uncle Bob asking me to avoid others - Booleans never asked me yo avoid Uncle Bob, for example. I think I'm starting to see who is the toxic one here.
@MrKrtek00
can we have a little more dramatic music?
@ivantatarchuk697
Don't write code! The best code is that you have never written.
@yrds96
- Raises a problem - Doesn't come up with a solution. - Leaves Classic Uncle Bob
@Zocress
My function names after this talk be like: copy_files_but_do_not_overwrite_older_files_but_do_override_if_file_is_smaller EDIT: Guys, it's a fucking joke. The people in the replies trying to explain how this is a bad practice are why programmers have a bad rep for our social skills. Jesus Christ.
@MsBukke
The thing i like about boolean parameters is that some languages allow optional values that have a default value and in that case you have a default behavior and an edge case
@adambickford8720
People are missing the point, of course you're just moving the boolean, that's the point! There's an old saying "push 'if' up and 'for' down". Your function should either be doing work, or coordinating work, not both. Code that only coordinates other code is usually higher level and more 'volatile' as it changes w/the business. The lower-level code should be as 'context free' as possible as context is the problem the calling code is solving.
@sealsharp
Yes, the if(...) inside a function can be avoided by having two functions. Which leads to the follow up question: Will there be an if(...) outside of the functions? Because if yes, you would just move the additional code to some other place. It would not reduce the complexity or the amount of code. It's just someone else's problem. If the boolean argument is usually a constant, make it two functions. If the boolean argument is usually not constant, keep it as a parameter.
@MTAG
Just write the code that works Boolean parameters or not, single function function or not. Don't worry about that until it becomes a problem, chances are it never will. It is guaranteed 100% you will refactor your code anyway, for some other reason. Premature optimization and overdesigned patterns are a waste of your time.
@jakobpederpettersen2179
Dropping the boolian argument and splitting the function in two is a good idea if the called function branches right away. However, in many cases the function follows mostly the same logic (and code) for the two values, the boolian option is there for a slight variation. Splitting such a function into two would double the amount of code and make it less maintainable. Alternatively you could try to use the same code for two different functions by applying metaprogramming, but such solutions can quickly become ugly, especially when done with C macros. From a performance perspective, I have experienced that the compiler often will optimize out the boolean variable and effectively call two different functions depending on the value. This is very useful when the branch is written within a tight loop. Therefore: Strive to write the code for the humans, and let the compiler help write the code for the machine.
@byrey3
Of course, why would I want to have 1 function with 3 booleans along, when I could have 8 functions!!! And the moment I wanted to change 1 aspect of it, now I would change it 8 times on the infinitely long library
@meanmole3212
Thanks, this vital insight helped me to code Quake 1 rendering engine, in fact it would have been impossible without this magnificent knowledge.
@Valerius123
In C due to the lack of features it is more streamlined to use the last argument as the output and the return value returning a state value or success/failure. The issue is usually you want both something from the function AND whether the function succeeded or failed. It is quite ugly to bundle this all up in a struct to return or something.
@VictorMartins239
so the reason is because he doesn't like it
@victorbaxan7436
Depending on who's reading the same piece of code, you'll have bored, surprised, amused, disappointed, defeated, angry etc, etc people.
@DannoHung
What Bob's actually arguing against is allowing default named values to be filled by unnamed positional parameters.
In the code example provided, the issue becomes a complete-non issue if the default is named in the call-site:
printName('Olga', 'Puchmajerova')
printName('Olga', 'Puchmajerova', reverse=True)
Parameterizing behavioral changes is a far more compositionally friendly approach than creating parallel implementations as well.
Bob has mischaracterized a language design issue as a coding hygiene issue.
Similarly, output parameters are a similar symptom in most cases of not having one of tuples or variants in the language.
@noctuss86
If your entire function is a if statement around a boolean argument, then yes, it makes sense to remove that boolean argument, but there are plenty other places where boolean arguments totally make sense (eg. a verbose argument)
@abderrahmanemya6602
i feel bad for all the people who had their time wasted for attending this. unless it was advertised as a pure comedy show
@MrMoralesOrlando
Today him say this tomorrow "Avoid to many functions" after that " make your code shorter" after that "express more your code, the problem with those guys is that they have so many things in their head that they ended with a" mess of good ideas " the best code is the code that works properly and do it simple !
@matheusaugustodasilvasanto3171
About the boolean arguments, other comments seem to be focusing too much on the control flow aspect of the problem ("don't you just end up making the decision somewhere else?"), and not enough on the software design aspects (except myPrzeslaw, he seems to get it). Here's my take. IN TERMS OF SOFTWARE DESIGN, I can see the following benefits to what Robert C. Martin is suggesting. Extracting distinct branches into separate functions. f(..., bool b) { if (b) { f_true(...) } else { f_false(...) } } Symbolic names. "Never" write function names like this. Reusability. You may want to re-use the behavior for a specific branch elsewhere, in a place where perhaps the other condition cannot occur. Extract the function allows for code reuse, without tangling the caller with an unnecessary dependency for both cases. Configurability. "Bubbling up" the interesting decisions for a program is an excellent way to make code easier to understand, maintain and extend. Centralizing a point where program behavior is decided, and segregating it from where the actual actions occur, is a general principle which brings many benefits. See also CQRS, Functional Core + Imperative Shell, Strategy Pattern, ... Using Enums (not a recommendation by Martin in this video, but a general pattern to avoid boolean arguments) Understandability. As he said, boolean arguments can be very cryptic reading from the outside. createEmployee("John", 27, true) is fundamentally less understandable than createEmployee("John", 27, Status.EMPLOYED); this is mitigated in languages like Python with keyword arguments. create_employee('John', age=27, is_employed=True) Extensibility. Perhaps in the future the code might have to deal with more than two cases. Booleans are an inherently restrict data type, with only two valid states (discounting unfortunate languages with null-like values for it). They are perfect for some situations, but not for others. For a more flexible design, Enums are the way. Extra point for backward compatibility when adding Enum states. Some type systems offer ever better extensibility and safety (Rust comes to mind). General software engineering disclaimers: * details for a specific situation matter; do not presume everything here is applicable to all cases * there are still downsides to the suggestions here presented; everything is a trade-off