Write cleaner code by doing less. The S in SOLID.

There are five principles the help you write better code, known as SOLID.
In this video, we look at the first of these principles, known as the Single Responsibility Principle, which dictates that modules should only be responsible for one thing and to do that one thing well.
#coding #solid #architecture
Code: github.com/dreamsofcode-io/si...
My socials:
Twitter: / dreamsofcode_io
Discord Server: / discord
Please consider supporting me as well!
Patreon: / dreamsofcode

[@egor.okhterov]

One thing I would add is that what we should apply is called "need based approach" (YAGNI). Every code that you write is good enough as long as it is correct. The primary goal for you as you start implementing the feature is to produce a working solution with as little code as possible. In the beginning you don't even know what logic and classes will survive and the changes you make in the beginning are quite drastic: functions and files appear and disappear out of existence. Eventually the code base for the feature stabilizes. After a month you notice that it became hard to make a certain change and that becomes your "need". Now you try to understand how code should look like in order to facilitate the change that you want to introduce (not more than that) and do a preparation refactoring. Once you have prepared the code base using some of the software engineering principles and patterns as your guide, you introduce the feature change that fits in nicely and naturally. Don't do refactoring for the sake of refactoring. Apply need based approach. Less is more.

[@olafbaeyens8955]

"Good enough" be careful with that. Do not commit code that you do not 100% feel that it is correct because months, years from now that good enough code will hit you smack in the face. Write the code in such a way so that no one has a need to fix your code in the future because someone is confused in your code. And it is a misconception that software engineering principles and patterns will save you from design flaws or bad code. In a "perfect virtual world" code according to these principles should work but in reality your code will run on buggy physical machines combined with other developers code that will be buggy or mess with your code. Software engineering principles and patterns should only be regarded as guide never as an ultimate rule!

[@spr3ez]

YAGNI is great, but I don't agree with you saying that, every code you write was good enough as long as it was correct. I think you shouldn't quick and dirty code to finish just to get the job done. To have a great architectural design behind your code base is very important especially when the project grows/is planned to be big.

[@randall.chamberlain]

I understood your point perfectly well, unlike I think the previous commenters. The idea is to never over engineer up front, but of course a well established architecture introduces constraints and that's fine too. More interestingly, the previous comments expose an even deeper problem within our industry. We're a bunch of smart people who always assume we know better and rarely try to listen or understand other comments or arguments. Like I said, your comment is straight forward and it's sentiment easy to understand yet other posters felt compelled to correct you. This is, for me, the single most annoying trait in software dev. Too many experts who preach before listening. With all due respect of course. This insistence in correcting others without listening is what drives agile teams insane and it adds only social behavioral burden with no palpable tech gain to our daily chores

[@henriquemarques6196]

Solid makes so much sense, specially if you're working in a bigger code base with a lot of other developers. Being able do debug a code that follows SRP is almost a pleasure to do. I've only discovered the importance of SRP when I landed my first job in a multinational company, they had a huge codebase and I was only able to understand because they were following a variety of good practices such as SOLID. Thanks for the video!

[@coderized]

Nice video! It's a hard topic to explain to people at the small scale because they see it as "excessive", but the real power comes as the project grows. Without it, it would be like trying to run a successful business where all the employees share all responsibilities without any clearly defined roles (HR, Coding, Marketing, Accounts, Sales, etc) - maybe you can get away with that in a Startup but at the Enterprise level it would soon implode.

[@dreamsofcode]

Agreed! I probably could have done more to explain some of the other problems it solves as the code scales, but that's my irrational fear of longer than 10 minute videos coming in to play. I'll probably need to start biting the bullet and doing longer videos again! Love your channel btw!

[@coderized]

@@dreamsofcode Thanks, really enjoying yours too! Best of luck with everything!

[@iamrafiqulislam]

As usual, very comprehensive Nine and Half minutes. Thank you! Again another request for a topic, please - I try to grasp Hexagonal Arch (Ports and Adapter), but I mess up with true implementation and I am bit lazy to write testcases :(. I am trying to learn and understand Rust with you (I am still at the first step 'a' on Rust), so Hexagonal Arch implementation both in Go and Rust would be a nice help. And again, thanks in advace and sorry to request for videos on each video!

[@TheOnlyEpsilonAlpha]

I've build a project exactly like that without known that principal. Because it simply make sense to do it like that

[@dreamsofcode]

Just like putting a name to a face.

[@parlor3115]

I think you overlooked the most important problem here which is that the code is written in GO. This breaks the D in SOLID which stands for "Please don't write GO code" and the O too which stands for "Oh no"

[@dreamsofcode]

😂😂😂😂 This made me laugh a lot. Thank you for that!

[@AzerAnimations]

Nothing wrong with Go. Gets the job done, does it reasonably well, and still has nice fast compiled binaries.

[@rj7250a]

@@AzerAnimations It is because some developers like "concise code", even if that means making the code 10x more difficult to maintain. Since Go does not have fancy features to make 1 liners, thus some people hate it. With normal Go code, you write 4 lines of code and 1 line of comment, with the "consice code" of "clever" developers, you need 4 lines of comments to understand 1 line of code. Modern C++ is plagued with this, devs use every shiny new feature, even if it does not makes sense. I like Rust and some functional features of it, but i try to only use the most common functions, i do not use obscure features that only 5% of devs are going to understand, just to remove 2 lines of code.

[@IBelieveInCode]

@@rj7250a "Modern C++ is plagued with this" C++ is plague 🙂

[@jeffreyhymas6803]

Maybe I need to give Go a go (sorry, couldn't help myself). I'm currently learning Rust and while there are things I like about it, I really can't stand all the extra features. I don't need 5 ways to do a thing. I'm also not totally sold on the functional aspects. I often see implementations using iterators, maps, and filters, but I'm not completely convinced that's better then a loop with a little logic. The flow of the code isn't nearly as obvious, and how one piece feeds the next gets lost. All of that is to say it sounds like I might appreciate the simplicity of Go.

[@VeryCreative481]

I was rewatching this video a few days ago and I just want to say: I would love if you could explain the rest of SOLID to us. And maybe even other programming paradigms such as the 12 factor principle, or different design patterns. Sure: most things are known at this point already. But man you just have such a good way of explaining things.

[@dreamsofcode]

Thank you! I've got a few on my backlog to explain and will definitely bump them up due to this comment 🙂

[@VeryCreative481]

@@dreamsofcode oh boi I can't wait! 💜

[@KingJellyfishII]

In my opinion, SRP shouldn't be used universally. for example, imagine some hypothetical code for the game Minecraft: you need to represent a lot of different blocks with different behaviours represented by classes. The SRP would dictate that you have a module for rendering, a module for (de)serialisation etc. The alternative is to have each class be responsible for its own rendering, (de) serialisation, updating, etc. If you need to add a new block, it's as simple as creating a new class and implementing the required methods, whereas the more abstracted code would require you to modify many modules to add the functionality in different places.

[@dreamsofcode]

You could also apply the SRP to this, however. One way would be to have a renderer module that accepts an Renderable interface. The block itself could then be responsible for defining it's coordinates, and the renderer accepts the block and draws it's geometry. Each block you wish to draw just needs to conform to the interface and provide it's coordinates. That way, you can use the block more as a data model, rather than having to implement render on each block type. SRP isn't an exact definition, and is a little ambiguous on purpose. It's typically up to the developer/team to determine what level of granularity a single responsibility is. Of course, that definition could be that a block is responsible for everything to do with being a block.

[@KingJellyfishII]

@@dreamsofcode Thanks for the reply. I hadn't thought of doing it that way before but that makes a lot of sense. I am guessing you could also make a Renderable able to provide some code to do nonstandard stuff too.

[@dreamsofcode]

@@KingJellyfishII Yeah, exactly! Same with collision and other attributes. I had a friend at university that built a game entirely using what he called "components" for his thesis, so it was very much composition vs inheritance. It was pretty awesome because at the time OOP was pretty much the standard for building games.

[@wlockuz4467]

Awesome video! kudos for acknowledging that SOLID is not exclusive to OOP, Its just good practice in general. Hope you also cover the other letters as well!

[@dreamsofcode]

Thank you! I have videos planned for each of them. I was going to do just one video on the LSP but decided it would be good to do a series on the 5 of them! It's interesting how negatively perceived they are however, even though they're just good practices imho.

[@yates_]

Thanks for yet another fantastic video! What is the thing though that reduces the function body to a single line as in the initial shot?

[@dreamsofcode]

Thank you! That is code folding in vim! It should come as part of the base installation. Really neat when you want to keep things concise!

[@yates_]

@@dreamsofcode Thanks, turns out it's just two lines of Lua to get this folded nicely!

[@wWvwvV]

I do it exactly as described here, except I also put the DB-funtionality in a separate package. The data/domain-package, in this case the user-package, should have only functions to operate on itself, like searching for a user in a list. No other dependencies should be allowed, except necessary data-processing-libs. I name related packages similar to put them next to each other in between other packages. As the code base gets bigger and more complex, I now think a better approach is to group related packages intuitively under the domain-package, when there is more than one domain-package in the module. But don't "abstract" names of sub-packages. Don't call a sub-package "repo". There must be a "user"- and a "user_repo"-Package (I would label it "userrepo" or "userdb").

[@navaneeth6157]

awesome videos man. how do you get such good ideas

[@dreamsofcode]

Thank you! I've been working as an engineer for over 10 years so just pulling from things that have always interested me!

[@adoreyourpain]

Would you ever consider going over your Arch setup? It might be one of the prettiest I’ve ever seen!

[@dreamsofcode]

Absolutely! Although it's mostly just alacritty, tmux and catppuccin themes!

[@arun_kannan]

Would love it if you can cover other 4 in SOLID as well

[@dreamsofcode]

I have a plan to do so!

[@AungBaw]

Play list please

[@AvastarBin]

What's the point of the handler package? I didn't get that part

[@blankRiot96]

Really cool video mate, I think my interest in writing clean code is slowly getting ignited again

[@dreamsofcode]

I really like clean code and architecture. One of my colleagues and I nerd out on it a lot. For us, it's all about making code as readable and concise as possible, rather than dogmatic practices. Code is for people at the end of the day!

[@Rbmukthegreat]

Hello, is there any way you could do a linux setup? I love your backgrounds / graphics!

[@dreamsofcode]

I can do, but most of it is video editing or using backgrounds from freepik though! I'll def go over my setup however.

[@menahem-mendelg]

I haven’t realized the srp till I started to write services using kratos framework. Now I don’t need to remember what each function is doing and can write tests more easily without hours of debugging. Thank you for the video

[@dreamsofcode]

Thank you for the feedback! I need to take a look at the Kratos framework.

[@sorvex9]

Lol this example was eerily relevant for the project I am sitting and refactoring right now.

[@dreamsofcode]

Haha. I chose it because it's a very common example across many a codebase. At least in my experience.

[@asdqwe4427]

I dont know, people tend to spend tones of time adding abstractions around a database that they are never going to replace anyway. To me, scattering logic in different files doesnt make code that much easier to read.

[@dreamsofcode]

The abstraction is more for testing and reusability. A Save function in a data model is an instant code smell, and the inability to test how the code handles errors is also a nightmare. Otherwise, I agree. Heavy abstractions are often a bad thing. I typically dislike ORMs because of that reason

[@RodyDavis]

I also have switched from SQLite to firestore with relative ease thanks to the abstraction. I used to never do abstract/interface driving projects, but now I can’t build one without it!

[@worgenzwithm14z]

Yeah I too think that copy and pasting the same code that accesses the db across every struct in my code base is a good idea

[@lel7531]

Great video ! Crystal clear as always. I do find that code modularity and reusability is a big deal and for debugging it really does make a difference.

[@dreamsofcode]

For me, testable code is the most important thing, especially when working in a continuous delivery environment! We ship code multiple times a day (at most was 50 deployments!) and having code that is well tested is the only way to do this.

[@sarves_boreddy]

Hey, will u do a video on how to setup golang in nvim using NVChad?

[@dreamsofcode]

I'm working on one right now! Should be out this weekend or Monday.

[@sarves_boreddy]

@@dreamsofcode thanks 😊 🙏

[@RayfuzuLearning]

Great video. Beautiful explanation.

[@dreamsofcode]

Thank you! I appreciate that

[@TheSast]

Great stuff as always!

[@dreamsofcode]

Thank you!

[@Hidarikikino]

Good video. Do you have a plan to make a videos for others letters of solid? btw: cool octopus wallpaper is it free or paid?

[@dreamsofcode]

Thank you! I certainly am planning to, I have a couple of the thumbnails drafted up. The octopus background is on freepik! I believe it might be licensed or attribution (I have a paid account though)/

[@goa213]

Very nice video, easy to follow 👍

[@dreamsofcode]

Thank you!

[@detaaditya6237]

That's a solid video! (pun intended) Will there be another videos covering other SOLID principles? I want to see your explanation on Open-Closed and Liskov Substitution 😁

[@dreamsofcode]

Thank you! I'm planning on doing a video for each one of the principles, so we'll definitely cover those two 😁

[@moeruishi]

I’ve been learning the SOLID principles recently along side other design patterns. So I have some questions. After moving the logic of the hashing function to its own module, doesn’t it still break the Single responsibility principle since it defines and stores both the type and the actual hashing function? And down the line say you want to add a way to compare hashes, I believe that would exist inside the hashing module too, wont that also break the principle? Or would the comparison be moved into its own module? Is it really possible to always have a i.e function have a single responsibility, if so would that mean modules allover the place? AWESOME EXPLANATION AND VIDEO BY THE WAY🎉

[@dreamsofcode]

Thank you for the feedback and great question! As always in software dev: It depends. I like to start with the definition of "responsibility" typically. There's certainly a risk of going too granular and having individual modules for every action, which, in my opinion, is too much. I tend to think a little more higher level with the single responsibility, i.e. the hasher struct/module, is responsible for anything to do with hashing, which includes generating the hash and comparing it. As I showed, you could add File hashing here as well, as it still conforms to that single responsibility. Another example is with the Mailer's interface. It's responsible for sending emails. You could have a number of functions in the mailer class for sending different email templates that are preset, but it still keeps core to it's single responsibility. Does that answer make sense?

[@moeruishi]

@@dreamsofcode This is really makes sense. Just like you said “higher level”. So, abstract an idea/functionality to its own module and other components of that idea/functionality like with hashing and comparing (which would both live in the same module). Thank you. This response cleared my confusion. Looking forward to videos on other principles.

[@dreamsofcode]

@@moeruishi You got it! I probably should have done a better job explaining what a module is in my video. Something I'll try to do better with next time!

[@principleshipcoleoid8095]

Some of these functions could be just functions without classes. Also SRP might make Bevy ESC things a lot more convoluded. I want my Plugins to set up many systems, resources ect.

[@dreamsofcode]

That's true, I could have scoped them into module level for this video!

[@Davidlavieri]

specially in Go, i use interfaces for abstraction, interfaces for the win! Also this reminded me of FunFunFunction channel and it's video about inheritance vs composition

[@dreamsofcode]

Interfaces in Go are perhaps one of the most powerful implementations I've seen. The implicit conformance is something I really value in Go, and I feel the pain of not having it whenever I work in another language.

[@anon-fz2bo]

I love Go 💙

[@dreamsofcode]

It's a really simple language. I was deciding which language to use for this video and Go was the perfect fit.

[@anon-fz2bo]

@@dreamsofcode yeah, when I code in more complex languages I find myself missing gos simplicity, it's beautiful

[@TechBuddy_]

Please don't over abstract things. I mostly will never replace my db but moving the db logic into it's own module is good but splitting other things across multiple files that will most likely not be reused is not the best. As far as testability goes make seperate functions in the same module ( package in this case ). Password hasher will not be reused for anything other than for user model putting them together makes it better and less complex. Adding abstractions for things that don't change is a very good thing but most software keeps evolving and we can't know what needs to be reused. Put things together until some piece of code needs to be reused. Everything need not be a class / struct ( unless you are using an "OOP" language and don't have any other option ). Functions can exist independently. I am not against SOLID infact I would like people to use it but please don't add complexity unless you absolutely have to. They are just guidelines to make the code cleaner and not rules you should absolutely follow.

[@dreamsofcode]

I disagree that this is over abstraction. Good separation of concerns is important and a User model should never interact with an unhashed password.

[@TechBuddy_]

@@dreamsofcode nooo! What I mean is we don't need a hasher package that will not be reused put them in the same package

[@dreamsofcode]

@@TechBuddy_ I understand what you're saying. I still think it's risky to keep them together, especially as you'll likely want to add other functionality (such as password checking) to the hasher module. Keeping the unhashed password as far away from the user model is generally safer and the ability to mock the hasher when it comes to testing is something you may want as well. However, taking the code in isolation and not considering how you'd build on it, I can see your point.

[@TechBuddy_]

@@dreamsofcode uhm this is going nowhere 😆. I get the point but I don't like the example

[@dreamsofcode]

@@TechBuddy_ I guess we agree to disagree! Thank you for sharing your thoughts.

[@harmonicseries6582]

Why is it creating a connection per request? That’s way worse than responsibility

[@principleshipcoleoid8095]

Clean code can cause terrible performance. How terrible depends on the language (and sometimes on the compiler/interpriter too). Things like dynamic trait variables are honestly more expensive than a solution using enums or generic function several times.

[@dreamsofcode]

I don't think enums or generic functions are excluded from "clean code". I always prefer code that is well architected and readable over code that is "performant". (Provided it's following correct O notations and concurrency where feasible). The compiler is the true optimizer IMHO.

[@principleshipcoleoid8095]

@@dreamsofcode compiler cannot optimise away using clone or infinite recursion. And it also can't optimise away trait objects. And some functions just make little sense to split up and could be better just with maintained doc comments. The best way is to be performant aware and optimise critical parts. Pessimising all of your code to dogmatically follow some set of rules that was not even proven to help would be sad. So yea, function over form is an important part there. Just in case: I'm not accusing you of anything nor saying all of my code is highly optimised.

[@dreamsofcode]

@@principleshipcoleoid8095 Oh, I'm enjoying this conversation! I don't feel accused or anything. Good vibes here, friend :). I agree on your points regarding the compiler not optimizing eerything. But clone or infinite recursion isn't anything to do with "clean code" imho. I just think the performance argument for why not to do clean code is flawed. Ultimately code is for humans and for me that's the most important part about writing good code. This is anecdotal, but I've seen firsthand the performance of teams working with well architected code, observable and tested code vs code that has none of those things, and it's night and day.

[@isnimshchikov]

This is noncence, you are not creating a new hashing method. You are already using an existing library for hashing. This code is most likely will be used only once in your project so why bother with this nightmare

[@dreamsofcode]

What is nightmarish for you?

[@cherkim]

Wow! You are very knowledgeable! Great video. Where did you learn all of this? Best coding KZbinr by far!

[@dreamsofcode]

Thank you! I've been working as an engineer for over 10 years now and have been obsessed with writing code the whole time.

[@Lorkin32]

1 million subs within 1 year, if you keep this up. Another excellent video! This channel is a backend goldmine

[@dreamsofcode]

Thank you! Hopefully I'll keep producing some nuggets!

[@olafbaeyens8955]

All these design principles in the end will fail. It fails because the people that invent these principles are more academic in nature ("Hello world level") and not grounded in real programming. You are so focused on design principles that you create one giant bloated mess if you get it back in 2-3 years from when you designed it. Focusing on design principles prevents you to find other solutions that works better for the project you are writing in. You brain never gets trained to find different solutions you only are trained follow the paint by numbers painting. It is not normal that modern day software needs 10-1000's developers for simple things we did 5+ years ago as one developer.

[@dreamsofcode]

SOLID has been around for 20 years though and is still widely accepted as a design principle that works. Although I am learning there's a lot of baggage associated!

[@olafbaeyens8955]

@@dreamsofcode The fact that is has been around for so long does not mean that the projects succeed. By starting with SOLID or other design patters, you set up your project to become unnatural. You prevent the project to follow a natural flow because you lock it into some abstract mess. When you start with design principles then everything is a hammer and a nail. Yes your code looks nice, yes you code appears to be perfect but hidden under that shines are design flaws that no one can solve because the code gives the illusion that it works perfect. Start with a blank code file and start writing, don't restrict your code creativity by limiting factors as design rules, principles. Code that is good will automatically evolve to some kind of pattern, but it will be different that the "academic" patterns created by people that have no real developers experience.

[@dreamsofcode]

@@olafbaeyens8955 Really glad to hear your thoughts! I've seen code that has naturally developed become incredibly hard to maintain. This usually happens when multiple developers work on it and just aim to get their change added, rather than thinking about how to effectively structure the project for scale. Perhaps I've just been unlucky, but I know since we adopted more thought into our structure, we've seen a huge increase in team level productivity.

[@olafbaeyens8955]

@@dreamsofcode Every time your code becomes hard to maintain then you evolve the code 🙂 So it stabilizes again to a better natural form. My code is incredible easy to maintain. even by other developers with no experience :-) I understand your reasoning, but my point is that with SOLID you restrict your developers ability to become even better programmers over time. They never train their brain to think out of the box and find newer solutions. Your project stays "average" at best never becomes incredibly useful for the people that uses it. Note: The discussion is not intended to be negative.

[@dreamsofcode]

@@olafbaeyens8955 I'm enjoying the discussion! Def not seeing it as negative. Thank you for having it with me.

[@yuyu-zs6jb]

Quality as usual

[@dreamsofcode]

Thank you!

[@typecraft_dev]

this is great. easier to read, easier to test, easier to extend and maintain

[@dreamsofcode]

Thank you!

[@saniancreations]

You just turned a very easy to read easy to understand piece of code into 4 separate harder to read pieces of code spread across multiple files/folders. One of the structs you create doesn't even have any member variables, meaning that you could just as well have made a stand-alone function to perform that task, because the function you associate with that struct evidently doesn't even need the struct in order to work. By religiously applying this principle you are actually introducing complexity, not taking it away. This line of thinking is exactly how you end up with codebases made completely unworkable because everything is powered by EnterpriseServiceFactoryBuilderProviders

[@dreamsofcode]

Show me how you can effectively test failure states on the original code.

[@saniancreations]

Look at the error values returned from the functions? I don't think your code changes any of that. Look, the original code isn't without flaw, but it is at the very least consise and easy to read. Pulling out the database connection is fine, but making a struct to wrap the db connection struct that is already provided to you isn't necessary. Whilst you remove one flaw you introduce another, that being that you spread out your logic into unnecessary abstractions when simple functions were enough. You don't need a "hasher" object when all you need is a hash function. You don't need a "user_repo" when all it does is wrap another struct for no reason.

[@dreamsofcode]

@@saniancreations I disagree. You require the ability to mock in order to test error states, otherwise it's incredibly high effort and complexity to get a database to fail when you want it to for testing. Sure, you could make an argument for function vs struct vs discrete file, but you're focusing on semantics at this point.

[@dreamsofcode]

@@saniancreations That's fair. The video isn't about mocking and I only touched on testing, although I didn't want to overload this video with too much information. I'll agree it's hard to look through that lens when I didn't touch upon it. I think the argument about empty struct vs function is a semantic issue, which could be argued ad infinitum. In reality, there's very little difference beyond having to inject a function or a struct into the handler for hashing. Personally, having the User struct responsible for more than just representing the data model is poor code, IMHO. But my opinion is just an opinion, although I tend to think SOLID is a pretty decent set of principles for writing code. Either way, I appreciate hearing your opinion!

[@saniancreations]

@@dreamsofcode Cool. I'm personally not big on OOP as a whole, including SOLID. I'm biased in that regard, but I do always try to at least reason about why I have that opinion. I generally enjoy you vids, this example just irked me a little. Side-note (you don't have to read this DoC, it's a rehash of my previous comment): For anyone confused as to why there's 2 replies from DoC, it seems my previous comment got voided after I tried to edit it, unfortunately. I had another comment in between those where I talked about how the video wasn't about mocking but writing good code in general. That from the 4 points, Readability, Maintainability, Reusability and Testability, readability and maintainability actually went downhill imo. That it only talked about testing in isolation (not mocking), which is still possible even if you have a struct with methods with different responsibilities, because those methods do not interfere with each other simply by being on the same struct.

[@TECHN01200]

This sounds good and all, but none of these lines are well defined. How big is a "module", how much is a "Single Responsibility", etc. These are the kinds of issues that people like Casey Muratori take with SOLID. I'd also add, given how vague these terms can be, does this extend to the program? A program could be classified as a "module". What happens if I use multiple functions with single, but disperate, responsibilities in another function that is also meant to have a "single responsibility"? Is it no longer singularly responsible? I am sick of random bs platitudes that sound great on the surface, but when you dig into them, they begin to fall apart.

[@dreamsofcode]

It's a good point, even a microservices itself could be considered a singularly responsible module. I still consider it a worthwhile practice to consider, and when designing new functionality, we'll often consider if this breaks the single responsibility of the given module. If it does, we'll put it elsewhere, rather than having a dumping ground of functionality, which makes maintainence a nightmare. There's no hard and fast rule, except for what you and your peers derm is correct. You could have everything in a single main function if you like, but you'll probably piss off a bunch of engineers who join later. There doesn't need to be a concrete definition in my opinion, mainly because code is about people, not about computers.

[@AcidiFy574]

Is there any place for a viewer with no programming experience on your channel ?😅

[@dreamsofcode]

I need to do a better job for those viewers. It may be that I start another channel which talks about more fundamentals and beginner areas. Is there anything you'd personally like to see more of?

[@AcidiFy574]

@@dreamsofcode I guess the fundamentals & self-learning tricks I've always imagined if you learn go, you are pretty much set in terms of web-development (kinda) & if you learn rust, you are pretty much set in terms of native development (also kinda) Of course it's not entirely true But on a different note, I DO want to see you try out EMACS 😂 Seriously there's almost no content on it

[@dreamsofcode]

@@AcidiFy574 Thank you for the feedback and ideas! I'll definitely do some more content geared towards fundamentals, either on another channel or this one. Haha, it's going to be painful seeing me learn or master emacs. It's got to be done though. I believe there's untapped potential there.

[@echobucket]

The problem with explaining this in a video with a simple example is that this makes it seem like you are making thing more complicated by breaking them out into pieces. But that's because the original code is too simple to do this with. In the real world, all the various edge cases and features added over time will make the first example grow into a hard to maintain mess, while the one that is broken out will still be complex, but won't be quite as much of a mess.

[@dreamsofcode]

Yeah, you're 100% spot on. This one could have probably done with a section on expanding the original code and how it would eventually become a mess to maintain, so I can understand why at face value some people take issue. (Although I maintain the original code is unable to be tested effectively). Something for me to work on!

[@rathewm.6107]

The best part of SOLID is that if you do not follow these rules, you are a better programmer. Newcomers can avoid learning this and save themselves 2 years of unlearning terrible habits down the line. I would also like to add, why does it make sense to follow the rules which are made up by people who do not even work as programmers, most of the big names, who authored the most popular books (Clean Code, Design Patterns, etc.) from which such rules emerge, do little to no programming and haven't done much in their entire careers. If these are your role models as a programmer then you are looking in the wrong place. If you do not do something, you do not understand how to do that, and are also not qualified to give advice on how to do that. Furthermore, if you only ever consider 1 approach, then you cannot validate if this approach is any good. Everything is relative. Most people who are applying SOLID / OOP principles to their code have NEVER tried any other approach, because this is usually the "one true way" they teach at college. I always see the same thing, student fresh out of school suggesting that this way of working is better than XYZ, and then you ask them: how much work did you do with XYZ? Answer is always the same - none. This is an engineering discipline, you are not supposed to believe, you are supposed to measure, verify and know.

[@lel7531]

Asking a student how much work they did on XYZ kinda sounds like a gottem to make everything they said before invalid. It is true that it is an engineering discipline, and that you should verify and know, but if you don't explore what's been told to you how can you validate it and know if it was the right thing to do ? And your assumptions on being better isn't based on anything tangible so how could you know ? Seems more of a reaction based of of emotions rather than facts and logic. Also, learning is part of the process, there's no skipping it or avoiding it.

[@dreamsofcode]

The OPs take is interesting to me. Personally, I'd hate to be working at a place with developers dismissing SOLID or other patterns because they "know better". This would be like not using Dijkstra's algorithm because a computer scientist / mathematician invented it.

[@rathewm.6107]

@@lel7531 No. I wasn't implying that opinion of less experienced programmer is invalid. I was just making a point of how there aren't many SOLID proponents that actually have experience with other ways of writing software. No. It's quite simple. You can measure everything, time spent: writing, maintaining, running, etc. SOLID principles are entirely subjective. You cannot prove that any of these principles objectively improves quality of your code. It's simply not possible. Because whichever code you find "clean" and "well structured" is the same code someone else finds "ugly" and "impossible to comprehend" - and this is always the case, no matter which slogan you parade. On the other hand, I can guarantee that code written in this style will waste a ton of my machine cycles on nothing. Because it encourages you increase number of layers between the "working code" and "API", furthermore it encourages you think of everything as if it is self contained, aka. Your memory is in shambles, CPU is throwing mountains of data in and out just to process a cupcake worth of it. On top of that because noise to signal ratio is so bad, you are writing a lot more code to accomplish the same task, so I know for a fact it will also take you longer to maintain it too. You gain nothing but day 1 legacy code, when you write it in this style. I encourage you to find 1 example, of relatively complex project that follows these principles and result of which is not a giant pile of duct tape. Even at smaller scale - website CMS, or a smaller game engine, this style falls apart so fast. On the other hand, examples of good procedural code are countless. Many of them bedrocks of our entire industry, unmatched complexity, maintained successfully to this day, yet written in a style that is complete opposite to what ideas like SOLID propose. As I said, it's an engineering discipline, you can measure meaningful information, subjective things like favorite IDE color scheme you cannot measure beyond of your own personal space and you certainly cannot suggest that your IDE color scheme is the best. Imagine if people who built bridges decided to place supports at distances which are increment of their favorite number instead of a distance which can actually allow it to distribute weight evenly and not cause a horrible accident in the future.

[@rathewm.6107]

​@@dreamsofcode The moment you step away from "enterprise" web software development you will find 0 SOLID code. It's only the companies who can afford the development and server costs of such heavy code that actually practice it. I mean, to compare Dijkstra with Uncle Bob or similar is just offensive. Uncle Bob is essentially financial guru of software industry, "Here in my garage ..." Even so, if actually competent programmer like John Carmack wrote a book about how Monokai is the best IDE theme and everyone who is a serious programmer should use it. It would still be equally easy to dismiss this idea, because it's subjective, there's no ground truth there. Just like there's 0 proof that ANY of the SOLID principles improve code quality or readability or whatever. You find SOLID code perfectly reasonable. I find SOLID code horribly ugly, most of it is noise, pouring from one glass to another, for no reason. You cannot have any 2 people ever agree on style, so suggesting that there is such a thing as set of principles that will always result in best style is just silly. What you can do however, is measure time spent writing such code, maintaining it and then also running it. Then you will find that non-constant subjective gain is not worth the cost.

[@dreamsofcode]

@@rathewm.6107 🤷 I've worked at many startups and larger companies that have followed patterns, and some that have not. The ones that didn't think about code structure always had the worst code to deal with, and were usually saddled with tech debt. If you're arguing about cpu cycles for code organization, you're forgetting code is ultimately for humans, otherwise you should advocate for working in assembly... Leave optimization to either big O notion or the compiler. Microservices are an extension of the SRP but for structuring distributed systems for autonomous teams...