As someone who reads much more code than they write, this seems spot on. That for loop for printing empty desks is so much nicer to read than jumping about in a repo to find methods etc. Clarity & verbosity >>> cleanness every time
I generally agree, my rule of thumb is that I only make things classes/structs if they have a reason to hold data, otherwise they're just utility functions, I only separate things into multiple functions if I find myself reusing code a lot (aside from boilerplate, which is just unavoidable in some languages), and I comment at the top of the function with a short description of what it does and how to use it if it's not already obvious
Love the calm video style, intertwined with guitar playing and a calm vibe. Looking forward to more videos :) re bad code: I don't like how many programmers talk in absolutes. "the best / worst" etc. it's the same thing with many areas of life. there's often a use case for many things and often it takes a knowledgable person in that domain to help you realize where it is. these days people talk about if React is better than Svelte, etc. you can create great production apps with both, and they have their own trade-offs. the question "which is better" is predicated on a false assumption that one is definitively better which isn't true. it's really what is better for the current goal. if you need to move fast, which lets you move faster? which one do you have more experience with already? which option has pros that matter more to you and your business? etc. same thing with bad code, it depends. I agree both ways definitely have their time and place, but I generally side on "self-documenting" code over comments as I have had experiences at jobs where I was bitten by outdated comments. I agree with your point that function names can go out of date too, but I feel developers respect the function name more than the surrounding comment - I feel it's more common for comments to go out of date than for function names. Also, it's easier to see the function name from another developer and code based on it, because it's consistently present at the signature and every callsite. The comment is typically only in one place, which may not be the code you're touching, and you may miss that comment. a great point you brought up, however, is that functions for things that are only called once can be a smell. if the function is long and complex, then I can understand why you'd do it. but for certain small things, I agree it is often an anti-pattern that leads to unnecessary complexity.
I've been programming 35 years now. That doesn't mean I'm great at it or an expert or such. The most interesting thing about programming for so long is seeing how "best practices" have changed so dramatically over the decades. It basically went from "do the most efficient thing no matter how it reads", when hardware was the limiting factor. (It's still that way in places where hardware is truly the limiting factor.) Then it moved to "everything should be as readable as possible", where you make single-use, self-describing functions and depend on the optimizer to inline them for you, but there was little effort put into making sure code could be easily refactored. This was in the time of "build it and ship it" types of projects that didn't really evolve much over time. These days, with everything being a "service" or having "DLC" or other ways of continuously updating after launch, best practices are largely about optimizing for living code while working with others, which means a combination of "easy to understand" and "easy to extend/refactor". I'm super curious what the next phase will be.
Hey Robin. 35 years is much longer than my ~5 years experience. There is so much historical context that is hard to understand when learning to code these days. Learning Go (as I've done) without knowing C puts me at a disadvantage because of a lot of idioms are foreign to me. A developer starting their first job in Rails won't realize for years that Ruby borrowed in part form Perl. I wish there was a good book or course that explained how we got to where we are in 2022.
I feel like there should have been a lot more mentions of code testability which is very much related to how understandable your code is. You can understand what a piece of code does almost instantly if it has a clear, behaviour focused test attached to it, especially in go where this is all so easy to do.
I agree. Tests can make the intention of code clear. But the challenge is still what do you test? Is it better to have several functions each with their own tests, or can we have a longer, messier function that has its own tests instead. I truly think it's case by case and there are definitely times when things need to be broken apart.
Great video. Mostly experience bad readability of "good" code while developing in Typescript and have to visit 20 NPM packages with a one line of code in each.
Good points. This is why long method chains, and in many (not all) cases a more functional programming style can often reduce clarity of the code. (Sometimes not. Choose the right tool for the task, and all that.) It looks pretty on the page, but you don't know what it's doing - which becomes a problem when you run into this-does-not-work-how-you-think-it-works. Also, in compiled languages, clunky code can sometimes result in much faster binaries. Modern compilers can aggressively optimize clunky idoms they recognize. If you're working with others, try to write code that less experienced developers can read.
I always kinda smile a bit at the fact that what usually gets brought up as examples of bad code is pretty much how the stuff I make looks. Cuz I'll wholly agree to any programmer that'll tell me my scripts are trash, but there just hasn't been any reason where making my code "better" has done anything to help me better. Programming is not really something I plan to pursue professionally, I just like learning it cuz it helps me automate tasks I do frequently. So a lot of the more intermediate level stuff about coding I see on youtube feels like bizarre software alchemy to an outsider like me rather than "this thing does x,y,z steps to do task A" which is just how I tend to think about it. Personally my coding approach has just been to get things working as crudely as I can get away with. So, functions only when I do a lot of a thing, separating stuff into functions only if it's less unwieldy, classes barely ever, and comments mostly if I'm doing something "clever". The only rule I've pretty much held myself to as a constant is to properly name variables and functions so that their purpose is clear. That, and frequent saves and backups. Otherwise, screw the rules cuz there isn't really anybody looking over my shoulder to tell me what I'm doing is wrong anyways. :D I am fully aware that there are perfectly valid reasons for common practice and conventions are the way they are. Though it's prolly reasonable to say those reasons need not apply to every single situation. At the end of the day, I feel like what matters over doing things a certain way is the awareness of what makes that specific approach helpful and the flexibility to not rely on it when it's not necessary. So yeah idk, this video just kinda brought up a lot of thoughts in me and hey these are those thoughts. Either way, regardless of what you think about them, I wish a nice day!
Have a comment to this desks.empty().print() "empty" function makes me think I'm "empting" something in "desks" instance. Having a context I would suggest that it empties all the desks. However your point that it should retrieve empty desks. The problem here that functions should mean some action and action is always the verb. For me desks.getEmpty().print() would be much better. Also in c# for example there are properties which are language features. So, in c# it would look like desks.Empty.Print() where "Empty" would be a getter property. What's good about properties as part of language is they allow to replace get/set verbs for namings and they should always be used as nouns in context.
I agree, the name `empty` isn't good. `desks.getEmpty().print()` would be easier to understand, and in certain paradigms it would be the clearest way to write the code.
"[...] it's a lot scarier, becoming someone, who can't change their mind" 4:09 .Wow, that sentence blew my mind. I am someone, who loves clean code, and I really wanted to watch this and be against it. But you actually made a point. Programming is a lot about "working together", and if I am not open to the views of my colleagues (and they like long, expressive functions), then I can not develop myself; I am in fact separating myself from my team. Thank you. I guess there is more to "readability" than clean, short functions. Sure, the functions add meaning, and are like plain english to read. But it feels over-engineered for that small function. You really make me look different on the KISS principle. Maybe, it turns around, when functions get more complex and bigger. What are your thoughts about that?
Regarding `printDesks(desks)` vs `desks.print()`: I think the former example works better because the name "desks" isn't really a conceptual "object". It's just a collection of `desk` (conceptually speaking). I think a method would work better if its type was a conceptual unit/"object". If you had named `desks` `classroom` instead, then I think the latter style (using a method) would be more appropriate for a reader.
I think the `desks.empty().print()` example could be better if you had instead used a filter like `desks.filter(desk -> isEmpty(desk)).print()` or `desks.filter(isEmpty).print()` (not valid go syntax but you get the idea). The for loop example it's weighed against is more go-like and therefore better, as adherence to the go style is important for the language. For other languages I'd recommend the `filter` example I used above as it's obvious (the name `empty` is ambiguous, whereas a filter with a predicate is not) and abstracts away the underlying for loop, making it easier to read and potentially enabling compiler optimizations in more complex examples as well.
I'm a data engineer and the code I write is for a very specific purpose. There is rarely any code in a pipeline I build that is used more than once in a given process. So my code does not use very many functions, and I add a lot of comments to make it self documenting. I think I'm really bad at coding, but I like my code because when I revisit it a year later it's not difficult to parse what's going on.
I think "can I QUICKLY understand this code later" is far more important than a lot of other things. It's certainly more important than the worst versions of DRY.
I enjoyed that, if you like bad code, you would love mine. I have a couple of scripts I wrote that are just a bunch of functions and then some that are messy looking, I kind of prefer the messy, but both ways have their appeal I guess.
As someone who reads much more code than they write, this seems spot on. That for loop for printing empty desks is so much nicer to read than jumping about in a repo to find methods etc. Clarity & verbosity >>> cleanness every time
This is the most aesthetically pleasing “powerpoint” presentation I’ve ever seen
Thanks Daniel.
It took a while for me to get it looking how I wanted. Glad it turned out ok!
I generally agree, my rule of thumb is that I only make things classes/structs if they have a reason to hold data, otherwise they're just utility functions, I only separate things into multiple functions if I find myself reusing code a lot (aside from boilerplate, which is just unavoidable in some languages), and I comment at the top of the function with a short description of what it does and how to use it if it's not already obvious
This is where I've landed too. Especially the comments at the top of the functions.
Yes! Abstraction is a double-edged sword. Not many people realize this. Thanks.
it's good to hear from you Tom!
Love the calm video style, intertwined with guitar playing and a calm vibe. Looking forward to more videos :)
re bad code: I don't like how many programmers talk in absolutes. "the best / worst" etc. it's the same thing with many areas of life. there's often a use case for many things and often it takes a knowledgable person in that domain to help you realize where it is. these days people talk about if React is better than Svelte, etc. you can create great production apps with both, and they have their own trade-offs. the question "which is better" is predicated on a false assumption that one is definitively better which isn't true. it's really what is better for the current goal. if you need to move fast, which lets you move faster? which one do you have more experience with already? which option has pros that matter more to you and your business? etc.
same thing with bad code, it depends. I agree both ways definitely have their time and place, but I generally side on "self-documenting" code over comments as I have had experiences at jobs where I was bitten by outdated comments. I agree with your point that function names can go out of date too, but I feel developers respect the function name more than the surrounding comment - I feel it's more common for comments to go out of date than for function names. Also, it's easier to see the function name from another developer and code based on it, because it's consistently present at the signature and every callsite. The comment is typically only in one place, which may not be the code you're touching, and you may miss that comment.
a great point you brought up, however, is that functions for things that are only called once can be a smell. if the function is long and complex, then I can understand why you'd do it. but for certain small things, I agree it is often an anti-pattern that leads to unnecessary complexity.
I've been programming 35 years now. That doesn't mean I'm great at it or an expert or such. The most interesting thing about programming for so long is seeing how "best practices" have changed so dramatically over the decades.
It basically went from "do the most efficient thing no matter how it reads", when hardware was the limiting factor. (It's still that way in places where hardware is truly the limiting factor.) Then it moved to "everything should be as readable as possible", where you make single-use, self-describing functions and depend on the optimizer to inline them for you, but there was little effort put into making sure code could be easily refactored. This was in the time of "build it and ship it" types of projects that didn't really evolve much over time. These days, with everything being a "service" or having "DLC" or other ways of continuously updating after launch, best practices are largely about optimizing for living code while working with others, which means a combination of "easy to understand" and "easy to extend/refactor".
I'm super curious what the next phase will be.
Hey Robin.
35 years is much longer than my ~5 years experience.
There is so much historical context that is hard to understand when learning to code these days. Learning Go (as I've done) without knowing C puts me at a disadvantage because of a lot of idioms are foreign to me. A developer starting their first job in Rails won't realize for years that Ruby borrowed in part form Perl.
I wish there was a good book or course that explained how we got to where we are in 2022.
I feel like there should have been a lot more mentions of code testability which is very much related to how understandable your code is. You can understand what a piece of code does almost instantly if it has a clear, behaviour focused test attached to it, especially in go where this is all so easy to do.
I agree. Tests can make the intention of code clear. But the challenge is still what do you test? Is it better to have several functions each with their own tests, or can we have a longer, messier function that has its own tests instead.
I truly think it's case by case and there are definitely times when things need to be broken apart.
@@tomontheinternet absolutely! that's a whole other can of worms that maybe you should open in another video
Great video. Mostly experience bad readability of "good" code while developing in Typescript and have to visit 20 NPM packages with a one line of code in each.
Good points. This is why long method chains, and in many (not all) cases a more functional programming style can often reduce clarity of the code. (Sometimes not. Choose the right tool for the task, and all that.) It looks pretty on the page, but you don't know what it's doing - which becomes a problem when you run into this-does-not-work-how-you-think-it-works. Also, in compiled languages, clunky code can sometimes result in much faster binaries. Modern compilers can aggressively optimize clunky idoms they recognize. If you're working with others, try to write code that less experienced developers can read.
I always kinda smile a bit at the fact that what usually gets brought up as examples of bad code is pretty much how the stuff I make looks. Cuz I'll wholly agree to any programmer that'll tell me my scripts are trash, but there just hasn't been any reason where making my code "better" has done anything to help me better.
Programming is not really something I plan to pursue professionally, I just like learning it cuz it helps me automate tasks I do frequently. So a lot of the more intermediate level stuff about coding I see on youtube feels like bizarre software alchemy to an outsider like me rather than "this thing does x,y,z steps to do task A" which is just how I tend to think about it.
Personally my coding approach has just been to get things working as crudely as I can get away with. So, functions only when I do a lot of a thing, separating stuff into functions only if it's less unwieldy, classes barely ever, and comments mostly if I'm doing something "clever". The only rule I've pretty much held myself to as a constant is to properly name variables and functions so that their purpose is clear. That, and frequent saves and backups. Otherwise, screw the rules cuz there isn't really anybody looking over my shoulder to tell me what I'm doing is wrong anyways. :D
I am fully aware that there are perfectly valid reasons for common practice and conventions are the way they are. Though it's prolly reasonable to say those reasons need not apply to every single situation. At the end of the day, I feel like what matters over doing things a certain way is the awareness of what makes that specific approach helpful and the flexibility to not rely on it when it's not necessary. So yeah idk, this video just kinda brought up a lot of thoughts in me and hey these are those thoughts. Either way, regardless of what you think about them, I wish a nice day!
Have a comment to this desks.empty().print()
"empty" function makes me think I'm "empting" something in "desks" instance. Having a context I would suggest that it empties all the desks. However your point that it should retrieve empty desks. The problem here that functions should mean some action and action is always the verb.
For me desks.getEmpty().print() would be much better. Also in c# for example there are properties which are language features. So, in c# it would look like desks.Empty.Print() where "Empty" would be a getter property. What's good about properties as part of language is they allow to replace get/set verbs for namings and they should always be used as nouns in context.
I agree, the name `empty` isn't good.
`desks.getEmpty().print()` would be easier to understand, and in certain paradigms it would be the clearest way to write the code.
"[...] it's a lot scarier, becoming someone, who can't change their mind" 4:09 .Wow, that sentence blew my mind.
I am someone, who loves clean code, and I really wanted to watch this and be against it. But you actually made a point. Programming is a lot about "working together", and if I am not open to the views of my colleagues (and they like long, expressive functions), then I can not develop myself; I am in fact separating myself from my team. Thank you. I guess there is more to "readability" than clean, short functions. Sure, the functions add meaning, and are like plain english to read. But it feels over-engineered for that small function. You really make me look different on the KISS principle.
Maybe, it turns around, when functions get more complex and bigger. What are your thoughts about that?
Regarding `printDesks(desks)` vs `desks.print()`: I think the former example works better because the name "desks" isn't really a conceptual "object". It's just a collection of `desk` (conceptually speaking). I think a method would work better if its type was a conceptual unit/"object". If you had named `desks` `classroom` instead, then I think the latter style (using a method) would be more appropriate for a reader.
fizzbuzz enterprise is a great example of what can happen to your codebase if you follow some so called "best practices"
I think the `desks.empty().print()` example could be better if you had instead used a filter like `desks.filter(desk -> isEmpty(desk)).print()` or `desks.filter(isEmpty).print()` (not valid go syntax but you get the idea). The for loop example it's weighed against is more go-like and therefore better, as adherence to the go style is important for the language. For other languages I'd recommend the `filter` example I used above as it's obvious (the name `empty` is ambiguous, whereas a filter with a predicate is not) and abstracts away the underlying for loop, making it easier to read and potentially enabling compiler optimizations in more complex examples as well.
I'm a data engineer and the code I write is for a very specific purpose. There is rarely any code in a pipeline I build that is used more than once in a given process. So my code does not use very many functions, and I add a lot of comments to make it self documenting. I think I'm really bad at coding, but I like my code because when I revisit it a year later it's not difficult to parse what's going on.
I think "can I QUICKLY understand this code later" is far more important than a lot of other things. It's certainly more important than the worst versions of DRY.
Amen. Also love the "thought the wrong thoughts" line :)
Your idea is great, but it comes at the cost of hardly testable code 😅
I enjoyed that, if you like bad code, you would love mine. I have a couple of scripts I wrote that are just a bunch of functions and then some that are messy looking, I kind of prefer the messy, but both ways have their appeal I guess.
K.I.S.S. is always better
You shouldn’t have ❤