I spent 6 months building some macros / scripts / automation in AHK for my day job (a little bit each day, 100% outside the scope of my actual job's duties) but damn does it make me faster than everyone else who does my job, and with way less typing/repetitive actions. Not to mention others come to me for bulk order entries since our outdated scheduling system makes doing those rather painful.
Agree. When using a double code with the different data, including possibly incorrect, you can see, which line of your script throws an exception, and understand easier, where is the problem. Other case is when the count of the parameters may be extended for the single case. If the code is in the function with parameters as arguments, then you need to add a function argument and, when impossible to set the default argument value, set this value to all of the function calls.
@@user-jt9yd6vr8b Many languages allow optional parameters, and those that don't will allow you to pass JSON objects with as many parameters as you like. In reality, the times you don't want to write reusable code for everything would be when you create a function for one thing, then extend it for another case, then keep extending it until the function becomes too complicated and difficult to maintain.
@@user-jt9yd6vr8b Oh and you can also create optional parameters in the Java sense, which doesnt have optional parameters but you can create haave multiple headers for a function doSomething(int x){ doSomething(x, -1); } doSomething(int x, int y){ .... }
@@GldnClaw The example given, could be made even simply by passing the math operators as an argument to an all-purpose binary operation function: def binaryCalc(x, op, y): Only thing is I'm not sure if this programming language (Python I presume?) allows for passing operators as arguments. Maybe the operator could be passed as a string and you could use a decision structure to handled the 4 different operator cases. I think one function that decides between 4 different versions of an argument is drier than 4 different functions for each operator.
My professor always says: " start where others reached", that's why I used my classmates' graduation project's code to build my own, it was a php website and he had all the oop stuff ready so why spend time and effort writing it when they already did.
That's the thing,.. that's what business corps learned to do quick & my college HOD pushed us to do IEEE projects(which was done by professors & phd students which i can't afford the project requirements) still those projects meant to cash in by corps than we actually ddo something for us(personal use) and/or to start our business from it.. Still that's the thing.. why go from beginning to just make it different at the end.. get a done project,real world application,try to change few things little by Little,eventually we learn much & quick(that's how Engineering & reverse enginnering works) At the end every little change we made often,make it really different,unique & really usable than the original 😃 just go for it 😃 As one legend says "if you're good at something,don't do it for free" (joker ofcourse)😇 since you can sell any of your work in Computer Programming,just go for it than stayed at one 😃 Its about how much we can do program our own ideas anytime & make it worth,build your career,happiness & life out of it.. i am putting this here,to anyone who has ideas to do something,just go for it,build it,sell it,a same product differs tto each one,its your style & usability counts.. see y'all success,happy days ahead in our life 😃🌟✨🙌 24.08.2022 03:12 pm ist
@@victorbitencourt9481 yes because we didn't have better technology available back in 2000s but now it's not an excuse to not use newer tech which is just better overall in terms of development, security, versatility, and performance.
Yep, don't use DRY in cases where you have code duplication but you're not entirely sure if those pieces of code absolutely need to be the same, because maybe they're just coincidentally the same at the moment. If you find yourself abstracting your code into a function then adding a boolean flag to change how it behaves, you just created a crappy abstraction
@@Daniel_WR_HartAn easy example of this in game dev is player variables. Walk speed might coincidentally be the same as jump velocity. You wouldn't merge those two into one variable, because you might need to change them independently of each other later on.
@@pixels_per_minute For sure, like if you decide to add running, powerups that only effect speed or jump height, upside-down gravity in some areas, or muddy ground that affects speed a bit more than height. It could even be as simple as having the controls feel just a bit nicer when walk speed is 90-95% of jump speed depending on the level layout
No. There's a great talk by Casey Muratori on his channel explaining how he rewrote a navmesh generating function so that instead of taking half a minute each time it ran, it was possible to run it in realtime, at 30 FPS. How did he achieve such an incredible optimization? By not reusing functions that did what he needed to be done, but they did it in a way horribly unsuitable for the task, since their primary use was for different tasks. My point is, there's no universal "every programmer should always do this". Following even the most obviously-sounding "principles" religiously, without thinking what is their purpose, and how does that purpose align with the purpose of what you're currently doing, is a surefire way to end up in horrible places. DRY is a suggestion suitable for most programmers, and many situations, but not for everyone, nor everywhere. Same as all the other "good code practices". They're suggestions to consider and use if suitable for the specific thing you're doing.
Absolutely, while you definitely want to keep your code organized and improve readability it's important not to overdo it, especially in intensive applications where performance is key, adding a bunch of function calls will introduce overhead so it's something to keep in mind. Every situation will be different and needs to be properly studied/considered.
@@TR_Arial Depending on the requirements if there is user input the user can decide which function is chosen. That deletes all extras and consolidates that down to one function. So choose this, case statement based off what was chosen then the function variables x and y.
It was a terrible example, the tests didn't assert anything and you want to use fixure values over hard coded values but even if you did use hard coded values you should be keeping them within the test.
In my experience DRY leads to premature refactorization. Instead I rather use the rule of three - 2 instances of similar code are OK, but when doing a 3 instance it should be refactored.
I thought the wisdom on testing specifically was Do Repeat Yourself A Little Bit, so you don't break all tests by reusing code that wasn't supposed to change in the first place...
You are right. You also should only consider repetition of intent not just repetition of code itself. If the same code is used for separate intents, we tend to add boolean parameter to the function, instead of just splitting that multiple-intent function into multiple smaller functions that call shared lower-level constructs.
Agreed, example in the video is not the best since you’re asserting for different constant values in the end. And if you change values in the init, you need to go and change all the tests, which you most likely do not want to do..
There was once a science survey, which proved if u have a task which u want simplified or reduce the time of effort required, just hand it over to a lazy person, he'll automatically create the most efficient and time energy saving way to do that work, Some say even the tv remotes were made that way cuz some lazy person didn't want to stand up and walk to tv to change channels and instead wanted to change it while lying leisurely on sofa...
I started coding seriously pretty recently and had this concept in mind, I didn't know people called it this way lol, it's like creating lego pieces you can combine in different ways to obtain completely new things
It's more commonly known as object oriented programming, and it was definitely a big upgrade in the 90's. But there are a lot of problems with strictly adhering to this, I would recommend searching CZcams for something like "problems with object oriented programming"
Like most rules there are situations in which it's perfectly okay to break them. Sometimes ctrl-c ctrl-v really is preferable to wasting time on some generic solution.
That might lead to a bug if you reuse the SE test object for all tests. Now you have to make sure that your test runner kills the object before next test so you may need another test for that
In this case, you don't even need to do anything with classes (though you should). You could just use variables in the intended way, and if x and y will always be the same, just initialize them outside the scope, and add them within those functions.
if you dont want to use objects in this case, you can pass a function to a wrapper function that does the setup def wrapper(operation): x = 10 y = 10 return operation(x, y) def add(a, b) return a + b and use like this: wrapper(add)
I think it is okay to start with a mess long line of code and then think to re-write it with a shorter one. I remember while creating neural network I write every single weights and outputs cuz I wanna know how it works, after it works I re-write with a shorter line of code.
right. "Don't repeat yourself if you know exactly what you are doing", which is after you have come to the conclusion that you know what you are doing, which should be almost never, lol.
You’re right. Making it work comes first because you never know what you’re going to have to add later that might not fit your current modular design. They say that premature optimization is the root of all evil.
And then you get a framework that requires you to write 200 instances of the exact same boilerplate for 200 different dialog boxes but now it's not considered bad practice because it's no longer business logic, it's just boilerplate and you'll never need to refactor it except in a week when the framework announces API change.
Lol, totally agree dry doesn't usually work specially in UI when you eventually have to write each case code inside the common function .. The only principle i follow is to not have any principles .. and that from people who have to make videos regularly ..
When writing tests, be careful not to confuse code that looks the same but is testing different things as repetition that should be abstracted. Too much abstraction can create dependencies where your tests aren't completely isolated from each other and which can lead to problems.
This is good advice for code you know you're gokng to use again. Sometimes you just have bulk operations that need to get done in a specific way that doesn't pertain to another scenario.
Sometimes it makes more sense to spend 5 hours repeating yourself than spending 5 hours setting up a function to do what you need in a reusable way, then only using it once
learning design principles is one of the most productive things you can do as a new programmer when you feel like theres not much else you need to learn in terms of syntax in your preferred language. Learn things like SOLID, KISS, DRY, YAGNI, and others. theyre all very easy concepts and will take your code to the next level
I just learned the lazy bit last night. I over complicated my code and have been struggling to get it to work. So I took out some extra bits and it works
Sometimes identical code snippets exist for different purposes. I advise AGAINST de-duping these ones or you'll make it hard to modify one snippet without modifying the other. It's very hard to know when this applies or not, but you will encounter these situations when you overapply DRY principle
I thought that was the point of the editing process. You design the logic ahead of time then go back in and do alterations to modulate it and make it better. It’s just like writing an essay, you wouldn’t turn it in without an editing process, would you?
I spend a considerable portion of my day conducting code reviews and continually emphasizing points such as this. If developers would just take a step back to really grasp fundamental design principles; specifically: encapsulation, single responsibility, separation of concerns, principle of least knowledge, and DRY, they would significantly expedite their domain of expertise and that knowledge will always carry across any language or platform.
very context dependent, but sometimes the cost of repeating yourself doesnt outweigh the cost of refactoring to be DRY. Again, also very context dependent but you can risk tighter coupling by trying to be too DRY
Using C#, I have made a static class called “Conventions” that holds all of the most common functions I use everywhere. Similarly, I have a static class for extensions that also holds more type specific functions that I also use all the time, but as class extensions
I like to think in my head I came up with this idea first which is one of the reasons I don't take advice from programmers on the internet. But look for the answers myself on their coding. And I think I would find it fascinating how people solve different problems.
in compsci classes in university we actually got MAJOR points off for not following DRY. I thought it was a pain in the butt but now that I'm working as a SWE I'm super thankful for having this drilled into me
This principle is overutilized, not under-. There are valid cases to duplicate code. Especially if it's about 2 distinct business rules that may change independently from each other and are just accidentally relying on the same logic right now.
It's kinda true but a lot of times you make your code literally unreadable, and scalable as you're locked with one design, I'd suggest looking into SOLID principles as they clearly express when you need to write more code and when less.
@@doktoracula7017 single responsibility principle is one of the most important thing to do when you're writing reusable code. I don't know about you but I've made tons of projects and I've seen them go crazy I'd rather stick with a few design patterns than starting another project.
@@thatsalot3577 It's single RESPONSIBILITY principle. And every single person defines responsibility differently. I made a ton of commercial projects too and I'd prefer one that doesn't stick to any design patterns over one where people stick to them religiously. People take S from SOLID too far and divide things that should be one function into 3-4 functions and then you get a ton of one use functions with bad naming that make future changes hell. It's far easier to divide a 1000 line function and clean it up than to collect 100 one to few use functions together and clean it up.
And yeah i get that but when you're new and Don't have much experience about how to structure your code the SOLID principles act as a beacon I like following those principles because I often reuse my code and not to mention how easy it becomes to debug the code, make commits in git I've been using them for a year now and I owe it the projects I've made so far despite being small or big.
The object isn’t bad, but it’s still more typing than I like. I prefer to create a test(a,b,callback) and inside just call my various functions, seeing as they all take the same parameters. In my main() I’ll just have a few calls like so: function test(a,b,callback) return callback(a,b) //could also just be this: // const test = (a,b,callback) => callback(a,b) const a = 10; const b = 10; const add_val = test(a,b,test_add); console.log(add_val); OR in python: test = lambda a, b, callback : callback(a,b) # could also be this: # def test(a,b,callback): # return callback(a,b) a, b = 10, 10 add_val = test(a,b,test_add) print(add_val)
True, to be honest I end up finding ways to make my program more dry. For instance I would have 2 different outcomes that need to do different things, and when I look back on it I can see that most of the code within them are technically the same in some way. so I would try and put it all into a function and then once I do that, I can add many different outcomes I just need to pass in all the needed stuff to the function. Made my code much cleaner and no repeats
If you want to be very strict in this principle, you should also factor out the `x y` pattern. In reality, there is quite the grey area between what counts as a code clone and what doesn't.
Also, stuff the setup for your unit tests inside of a fixture. Don't repeat fixtures, use inheritance. Don't invent your own homebrew testing framework, use an existing one.
"you gotta think lazy" is the best description ever of programmers and is the most true 😂
work smart not hard 😏
Think smart, not hard.
Not lazy, effectively.
That's a good slogan for a programmer. Maybe I should use it 😅🤣
@@cerulity32k yes
"You gotta think lazy"
Me: coding for hours to automate 5 minutes tasks.
Proceeds to use the automated program for 5days and does all the work while people do half the work in 10days
@@MightyAnik In grad school one of my friends said: "if you do it twice you'll do it 10 times, just automate it"
@@MightyAnik definitely worth it!
I spent 6 months building some macros / scripts / automation in AHK for my day job (a little bit each day, 100% outside the scope of my actual job's duties) but damn does it make me faster than everyone else who does my job, and with way less typing/repetitive actions. Not to mention others come to me for bulk order entries since our outdated scheduling system makes doing those rather painful.
hah no kidding
Be DRY don't be WET ( We Enjoy Typing)
Write Everything Twice
@@rhoynarr You mean Thrice?
"Waste everyone's time"
@@shivangrathore T Times
@@shivangrathore this doesn't exist
Oh don't you worry, im lazy alright, too lazy to even start coding
The best code is NO code at all
@@CodingWithLewis Truer words were never spoken
@@CodingWithLewis isn't it that why we are Building A.Is
@@CodingWithLewis 🤣🤣🤣🥲
@@CodingWithLewis lmao
"Don't repeat yourself is aimed at encouraging programmers to not repeat themselves"
Wiser words never have been spoken
The American way of thinking, exemplified.
Also:
"Use DRY in order to avoid having to refactor
How to use DRY instead: you simply refactor the code"
Underrated.
People die if they are killed
Profile picture checks out
Well, sometimes readability takes precedence over DRY. :)
Agree. When using a double code with the different data, including possibly incorrect, you can see, which line of your script throws an exception, and understand easier, where is the problem. Other case is when the count of the parameters may be extended for the single case. If the code is in the function with parameters as arguments, then you need to add a function argument and, when impossible to set the default argument value, set this value to all of the function calls.
@@user-jt9yd6vr8b Many languages allow optional parameters, and those that don't will allow you to pass JSON objects with as many parameters as you like.
In reality, the times you don't want to write reusable code for everything would be when you create a function for one thing, then extend it for another case, then keep extending it until the function becomes too complicated and difficult to maintain.
@@user-jt9yd6vr8b Oh and you can also create optional parameters in the Java sense, which doesnt have optional parameters but you can create haave multiple headers for a function
doSomething(int x){ doSomething(x, -1); }
doSomething(int x, int y){ .... }
Is there an efficient way where you can have it display everything it refers back to without repeating? (I know nothing about coding)
@@GldnClaw The example given, could be made even simply by passing the math operators as an argument to an all-purpose binary operation function: def binaryCalc(x, op, y): Only thing is I'm not sure if this programming language (Python I presume?) allows for passing operators as arguments. Maybe the operator could be passed as a string and you could use a decision structure to handled the 4 different operator cases. I think one function that decides between 4 different versions of an argument is drier than 4 different functions for each operator.
There is no “DRY” npm package. Am I supposed to do this by thinking?
It’s a way of thinking :)
I can make one 😂
But what should I put in it?
@@shadowplay1211
x = 10
y = 10
-- WARN
-- WARN
Downloaded 7 audit files
Sry if that's a little inaccurate I'm a noob at web dev right now
Ask stackoverflow
"You gotta think lazy"
Me: goes to stack overflow then copy-paste
ChatGpt entered the chat
Now that's more like it
Just Chat GPT - and hope whatever it created never breaks - at least while your around.
@@AppleYoJo nah bro i prefer google bard, more updated data
@@i_zoru FR? I’ve seen some reddit posts about Bard a few months ago and its answers were often rubbish, did it get better?
My professor always says: " start where others reached", that's why I used my classmates' graduation project's code to build my own, it was a php website and he had all the oop stuff ready so why spend time and effort writing it when they already did.
That's the thing,..
that's what business corps learned to do quick & my college HOD pushed us to do IEEE projects(which was done by professors & phd students which i can't afford the project requirements) still those projects meant to cash in by corps than we actually ddo something for us(personal use) and/or to start our business from it..
Still that's the thing.. why go from beginning to just make it different at the end.. get a done project,real world application,try to change few things little by Little,eventually we learn much & quick(that's how Engineering & reverse enginnering works)
At the end every little change we made often,make it really different,unique & really usable than the original 😃
just go for it 😃
As one legend says "if you're good at something,don't do it for free" (joker ofcourse)😇 since you can sell any of your work in Computer Programming,just go for it than stayed at one 😃
Its about how much we can do program our own ideas anytime & make it worth,build your career,happiness & life out of it.. i am putting this here,to anyone who has ideas to do something,just go for it,build it,sell it,a same product differs tto each one,its your style & usability counts..
see y'all success,happy days ahead in our life 😃🌟✨🙌
24.08.2022 03:12 pm ist
Php in 2022? Lol
@@SahilP2648 I was about to say the same thing 😂
@@SahilP2648 php is still prevalent all over the web
@@victorbitencourt9481 yes because we didn't have better technology available back in 2000s but now it's not an excuse to not use newer tech which is just better overall in terms of development, security, versatility, and performance.
The level beyond this is knowing when to break this rule, understanding the trade-off.
Like learning writing rules.
Yep, don't use DRY in cases where you have code duplication but you're not entirely sure if those pieces of code absolutely need to be the same, because maybe they're just coincidentally the same at the moment. If you find yourself abstracting your code into a function then adding a boolean flag to change how it behaves, you just created a crappy abstraction
@@Daniel_WR_HartAn easy example of this in game dev is player variables.
Walk speed might coincidentally be the same as jump velocity. You wouldn't merge those two into one variable, because you might need to change them independently of each other later on.
@@pixels_per_minute For sure, like if you decide to add running, powerups that only effect speed or jump height, upside-down gravity in some areas, or muddy ground that affects speed a bit more than height.
It could even be as simple as having the controls feel just a bit nicer when walk speed is 90-95% of jump speed depending on the level layout
It took me almost a decade to get this idea removed from my head
No you should just know when not to use it.
No.
There's a great talk by Casey Muratori on his channel explaining how he rewrote a navmesh generating function so that instead of taking half a minute each time it ran, it was possible to run it in realtime, at 30 FPS.
How did he achieve such an incredible optimization?
By not reusing functions that did what he needed to be done, but they did it in a way horribly unsuitable for the task, since their primary use was for different tasks.
My point is, there's no universal "every programmer should always do this". Following even the most obviously-sounding "principles" religiously, without thinking what is their purpose, and how does that purpose align with the purpose of what you're currently doing, is a surefire way to end up in horrible places.
DRY is a suggestion suitable for most programmers, and many situations, but not for everyone, nor everywhere.
Same as all the other "good code practices".
They're suggestions to consider and use if suitable for the specific thing you're doing.
Absolutely, while you definitely want to keep your code organized and improve readability it's important not to overdo it, especially in intensive applications where performance is key, adding a bunch of function calls will introduce overhead so it's something to keep in mind. Every situation will be different and needs to be properly studied/considered.
Then just use functions that are suited for the task. Break it down into smaller functions.
100%. This DRY thing sounds more like an religion.
My principle is "If it doesn't look good, it's not good"
Fitting with the example of the class init
Love that! I think the same way and it's just our instinct telling us that our code sucks!
@@godnyx117same
There’s nuance here:
«Prefer repetition over the wrong abstraction.»
«Avoid hasty abstractions»
See the talk by Sandy Metz.
“Gotta think lazy”… that’s what I’m doing when I repeat myself. It’s out of laziness… efficiency is hard.
Did he really repeat the functions in order to not repeat the function?
If he ever needs to change x and y values, he only needs to change it once rather than in every function
@@TR_Arial Depending on the requirements if there is user input the user can decide which function is chosen. That deletes all extras and consolidates that down to one function. So choose this, case statement based off what was chosen then the function variables x and y.
Exactly what I was thinking
@@TR_Arial but why does the function has 2 arguments x and y? Just remove the overwriting part and done
It was a terrible example, the tests didn't assert anything and you want to use fixure values over hard coded values but even if you did use hard coded values you should be keeping them within the test.
"Don't repeat yourself is a software development principle aimed at reducing repeating yourself."
*ah yes, the floor is made out of floor here*
"You're a programmer, you gotta think lazy" man this line will stick with me for the rest of my life.
In my experience DRY leads to premature refactorization. Instead I rather use the rule of three - 2 instances of similar code are OK, but when doing a 3 instance it should be refactored.
3 strikes and you're turned into a function
Learned this the hard way. Not a fan of the 'always do X' or 'always do Y' crowd. Almost every decision requires at least some nuance and thought.
@@sabientje65 yeah buy then you have to think your thoughts more than once each, and thats not DRY.
"I'm a programmer, I'm too lazy to think lazy"
😂
"you gotta think lazy"
the one guy who overengineers simple code to save on doing the task multiple times: 👁️👄👁️
this.
Make sure not to use DRY programming in test cases, they are meant to be repetitive otherwise you will need to write tests for your tests.
Ca you make video explaining SOLID principles? Your explaining skill is great
"You gotta think lazy"
So true, I'd rather waste 5 hours failing to automate a simple task rather than taking 5 minutes to do it manually.
I thought the wisdom on testing specifically was Do Repeat Yourself A Little Bit, so you don't break all tests by reusing code that wasn't supposed to change in the first place...
You are right. You also should only consider repetition of intent not just repetition of code itself. If the same code is used for separate intents, we tend to add boolean parameter to the function, instead of just splitting that multiple-intent function into multiple smaller functions that call shared lower-level constructs.
Agreed, example in the video is not the best since you’re asserting for different constant values in the end. And if you change values in the init, you need to go and change all the tests, which you most likely do not want to do..
There was once a science survey, which proved if u have a task which u want simplified or reduce the time of effort required, just hand it over to a lazy person, he'll automatically create the most efficient and time energy saving way to do that work,
Some say even the tv remotes were made that way cuz some lazy person didn't want to stand up and walk to tv to change channels and instead wanted to change it while lying leisurely on sofa...
DRY, aka: "If you reuse it, encapsulate it in a function"
Functions are also really good for making your code look clean
I started coding seriously pretty recently and had this concept in mind, I didn't know people called it this way lol, it's like creating lego pieces you can combine in different ways to obtain completely new things
It's more commonly known as object oriented programming, and it was definitely a big upgrade in the 90's. But there are a lot of problems with strictly adhering to this, I would recommend searching CZcams for something like "problems with object oriented programming"
I prefer wet ( write everything twice). The third time you have different use cases and can create a better abstraction.
Code Monkey teaches this in his course. It's helping me a lot.
Like most rules there are situations in which it's perfectly okay to break them. Sometimes ctrl-c ctrl-v really is preferable to wasting time on some generic solution.
That might lead to a bug if you reuse the SE test object for all tests. Now you have to make sure that your test runner kills the object before next test so you may need another test for that
I don't get the impression that this video is for professional developers. I was thinking the same thing lol
In this case, you don't even need to do anything with classes (though you should). You could just use variables in the intended way, and if x and y will always be the same, just initialize them outside the scope, and add them within those functions.
Yea i dont know why hes asking for inputs if hes just redefining them
"don't repeat yourself is a way to stop repeating yourself"
Wow
if you dont want to use objects in this case, you can pass a function to a wrapper function that does the setup
def wrapper(operation):
x = 10
y = 10
return operation(x, y)
def add(a, b)
return a + b
and use like this: wrapper(add)
And vice versa
Don't follow WET
We Enjoy Typing
I think it is okay to start with a mess long line of code and then think to re-write it with a shorter one. I remember while creating neural network I write every single weights and outputs cuz I wanna know how it works, after it works I re-write with a shorter line of code.
right. "Don't repeat yourself if you know exactly what you are doing", which is after you have come to the conclusion that you know what you are doing, which should be almost never, lol.
“You gotta think lazy” bro resumed my whole life in 4 words 💀
"we gotta think lazy"
yeah, perfectly describes me writing 15 lines of code for 3 hours
What programming principle do you follow? 🤔
DRY and KISS mostly
@@leshtiz440 What is it?
@@leshtiz440 So what you saying is, if I ever encountered a bug, I should leave it for later?
@UCk45TyHC6P97yuqKHSP6DoA Lol thank you for the explanation, kind stranger.
Uh the tag broke lol.
yeah I gotta do this with my code at some point - but I also think make it work, then tidy it up
You’re right. Making it work comes first because you never know what you’re going to have to add later that might not fit your current modular design. They say that premature optimization is the root of all evil.
And then you get a framework that requires you to write 200 instances of the exact same boilerplate for 200 different dialog boxes but now it's not considered bad practice because it's no longer business logic, it's just boilerplate and you'll never need to refactor it except in a week when the framework announces API change.
Lol, totally agree dry doesn't usually work specially in UI when you eventually have to write each case code inside the common function ..
The only principle i follow is to not have any principles .. and that from people who have to make videos regularly ..
That's what first got me using lists. I'm someone who gets bored writing and typing the same thing multiple times. Glad to know I'm on the right track
“Don’t repeat yourself is a software development principle aimed at reducing repeating yourself”
It’s the dry humor for me 😂
You are really inspiring 10/10
🥺🥺🥺
"You gotta think lazy" is probably the best quote to sum being a programmer up. Somebody put that on a shirt.
When writing tests, be careful not to confuse code that looks the same but is testing different things as repetition that should be abstracted. Too much abstraction can create dependencies where your tests aren't completely isolated from each other and which can lead to problems.
Copy paste seems pretty lazy to to me
Often safer too
This is good advice for code you know you're gokng to use again. Sometimes you just have bulk operations that need to get done in a specific way that doesn't pertain to another scenario.
"Laughs and then cries in VHDL and Assembly"
"Don't Repeat Yourself is a software principle aimed at reducing repeating yourself"
Nice
I can't be DRY cuz im too WET (Write Everything Twice) 🤡💀
I am subbing "we are programmers you gotta think lazy" this is so true it feels targeted ☠️🤣
As someone who just started c# this help a lot. Thx!
You’re right. From now on all my code will only contain the word „if“ a single time and i refuse to repeat it.
Sometimes it makes more sense to spend 5 hours repeating yourself than spending 5 hours setting up a function to do what you need in a reusable way, then only using it once
learning design principles is one of the most productive things you can do as a new programmer when you feel like theres not much else you need to learn in terms of syntax in your preferred language. Learn things like SOLID, KISS, DRY, YAGNI, and others. theyre all very easy concepts and will take your code to the next level
**starts replacing repeating stuff with different but also repeating stuff**
*unrolls every loop in his program so that the running program never jumps back to the same place twice*
DRRRYYYY
DRY is good for the beginning but later you need to understand also separation of concerns. It tells you when it is good to repeat your code :)
it is called modular coding. we put a multiple used code in a module that we can call by a variable
"Don't repeat yourself"
-> proceed to repeat himself
"You gotta think lazy" nice 😂♥️♥️♥️♥️
I just learned the lazy bit last night. I over complicated my code and have been struggling to get it to work. So I took out some extra bits and it works
Sometimes identical code snippets exist for different purposes. I advise AGAINST de-duping these ones or you'll make it hard to modify one snippet without modifying the other. It's very hard to know when this applies or not, but you will encounter these situations when you overapply DRY principle
Refactoring and abstracting is not “thinking lazy” - quite the contrary, as saving time long term takes a lot of effort up front.
Thinking lazy is what brought me to development
"Don't repeat yourself" → make a short that literally repeats itself indefinitely :D
😅
I am learning how to use magic methods now. this short helped me to understand the use a bit more. thankyou!
A lot of times following this could make some code unecessarily diffucult to read, so it depends on the context.
I like the irony of a DRY explanation on an auto loop.
I thought that was the point of the editing process. You design the logic ahead of time then go back in and do alterations to modulate it and make it better. It’s just like writing an essay, you wouldn’t turn it in without an editing process, would you?
I spend a considerable portion of my day conducting code reviews and continually emphasizing points such as this. If developers would just take a step back to really grasp fundamental design principles; specifically: encapsulation, single responsibility, separation of concerns, principle of least knowledge, and DRY, they would significantly expedite their domain of expertise and that knowledge will always carry across any language or platform.
"assumed at avoiding repeating yourself" bro yes I'm dead 😁
very context dependent, but sometimes the cost of repeating yourself doesnt outweigh the cost of refactoring to be DRY. Again, also very context dependent but you can risk tighter coupling by trying to be too DRY
this have been my motto for lyfe
'minimum effort, maximal result' 😂
I garuntee I have seen this 16 - 20 times
welcome to step one in Machine Learning.
Good tip for someone that is just starting.
Using C#, I have made a static class called “Conventions” that holds all of the most common functions I use everywhere. Similarly, I have a static class for extensions that also holds more type specific functions that I also use all the time, but as class extensions
I like to think in my head I came up with this idea first which is one of the reasons I don't take advice from programmers on the internet. But look for the answers myself on their coding.
And I think I would find it fascinating how people solve different problems.
An another way is declare x and y as global variables
And use it on all functions
Damn u know what's funny is I actually like the idea of splitting any things up in factory games so this is very accurate
"You have to be lazy" Wisest phrase ever
in compsci classes in university we actually got MAJOR points off for not following DRY. I thought it was a pain in the butt but now that I'm working as a SWE I'm super thankful for having this drilled into me
This principle is overutilized, not under-.
There are valid cases to duplicate code. Especially if it's about 2 distinct business rules that may change independently from each other and are just accidentally relying on the same logic right now.
"you gotta think lazy"
I am MADE for this
It's kinda true but a lot of times you make your code literally unreadable, and scalable as you're locked with one design, I'd suggest looking into SOLID principles as they clearly express when you need to write more code and when less.
SOLID is as far away from clear as it's possible. S - the single thing is not defined
@@doktoracula7017 single responsibility principle is one of the most important thing to do when you're writing reusable code. I don't know about you but I've made tons of projects and I've seen them go crazy I'd rather stick with a few design patterns than starting another project.
@@thatsalot3577 It's single RESPONSIBILITY principle. And every single person defines responsibility differently.
I made a ton of commercial projects too and I'd prefer one that doesn't stick to any design patterns over one where people stick to them religiously.
People take S from SOLID too far and divide things that should be one function into 3-4 functions and then you get a ton of one use functions with bad naming that make future changes hell.
It's far easier to divide a 1000 line function and clean it up than to collect 100 one to few use functions together and clean it up.
@@doktoracula7017 that was a typo 💀
And yeah i get that but when you're new and Don't have much experience about how to structure your code the SOLID principles act as a beacon
I like following those principles because I often reuse my code and not to mention how easy it becomes to debug the code, make commits in git I've been using them for a year now and I owe it the projects I've made so far despite being small or big.
DRY is good for code which is meant to coexist together, it is HELL for code which must be kept separate.
One of the first lesson in any good programming class.
Yet professionals seems to forget it
The object isn’t bad, but it’s still more typing than I like. I prefer to create a test(a,b,callback) and inside just call my various functions, seeing as they all take the same parameters. In my main() I’ll just have a few calls like so:
function test(a,b,callback)
return callback(a,b)
//could also just be this:
// const test = (a,b,callback) => callback(a,b)
const a = 10;
const b = 10;
const add_val = test(a,b,test_add);
console.log(add_val);
OR in python:
test = lambda a, b, callback : callback(a,b)
# could also be this:
# def test(a,b,callback):
# return callback(a,b)
a, b = 10, 10
add_val = test(a,b,test_add)
print(add_val)
Keep posting man. You rock
True, to be honest I end up finding ways to make my program more dry. For instance I would have 2 different outcomes that need to do different things, and when I look back on it I can see that most of the code within them are technically the same in some way. so I would try and put it all into a function and then once I do that, I can add many different outcomes I just need to pass in all the needed stuff to the function. Made my code much cleaner and no repeats
If you want to be very strict in this principle, you should also factor out the `x y` pattern. In reality, there is quite the grey area between what counts as a code clone and what doesn't.
"you are a programmer, you gotta think lazy"..... I was like: Hey is he talking to me???😂
I learnt about this last week.
And that's exactly how my code always ends being a ravioli.
This is a solid advice for almost all cases, but sometimes you need to sacrifice DRY for clarity
Also, stuff the setup for your unit tests inside of a fixture. Don't repeat fixtures, use inheritance. Don't invent your own homebrew testing framework, use an existing one.
Don't repeat yourself long as it doesn't drive you nuts. I got too ocd into don't repeat yourself that it actually made things worse at one point.
I see this immediately after a video saying don't be afraid to repeat yourself. It was in regards to inheritance, but still :P