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.
@@ВикторЛюбезный-ч2ы 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.
@@ВикторЛюбезный-ч2ы 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.
Meide die Eierlegende Wollmilchsau wie den Teufel. Schreib lieber fünf einfache, aber richtig angeordnete IF...ELSE-Abfragen als eine dreifachverschachtelte, deren Sinn nach 30 Jahren der dann zuständige Mensch nicht herausfindet. Ein Programm wird nur einmal geschrieben, muß aber von ANDEREN oft gelesen und verstanden werden, wenn der ursprüngliche Programmierer längst zu den Ahnen gegangen ist. Avoid the egg-laying wool-milk sow like the devil. It is better to write five simple but correctly arranged IF...ELSE queries than one triple-nested one, the meaning of which the person responsible will not be able to figure out after 30 years. A programme is only written once, but has to be read and understood many times by OTHERS when the original programmer has long since gone to the ancestors.
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
Yes exactly, I disagree with pretty much every point in this video. Don't start with abstraction, let it come naturally. Start WET (write every time) then encapsulate from there. Stop telling programmers to be lazy! They need to be disciplined. Blindly following a rule does not improve the industry.
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.
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.
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.
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)
@@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.
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.
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..
We can use constructor in class which are just where we give unique properties to the objects in our class, then use it in other functions within the class
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.
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 RU-vid for something like "problems with object oriented programming"
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
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
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.
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...
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
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 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.
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
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)
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.
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.
I also prefer to name variables in a way i know exactly what each function is doing and what the variables mean, i avoid "x and y", and instead write like " damage" or " health"
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.
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
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
debatable sometimes going DRY from the start can make a wreck of large code bases, it's rather a situational thing it should specifically be used for parts that are actually repeated not just dividing any function cuz we can.
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 ..
Things that change together should be grouped together. You should trade a bit of repetition for a bit of coupling if there’s a chance that you’ll have to change one spot but not the other.
The example he gives has what I sometimes call “mountain range” code smell. If you glance at a page of code and see a repeating pattern in the shape of the lines, check and see if you can separate the data from the functionality. In this example, those x and y parameters are data, and can be extracted, keeping the common functionality in its own DRY method.
On the contrary, dry code can lead to very bad maintainability if done incorrectly. Specifically in systems where decoupling is something you want. Also, one of the main promises of dry code is "change it once and you're done", but if the code is used in enough places, a basic change introduces the need to retest the entire application. I don't mean to say that everyone should run out copying and pasting the same code, I just want people to put a bit of thought and reason into whether or not DRYing a specific piece of code really makes sense and not follow the principle blindly.
DRY is way, way overstated. What's important is having a single source of truth, not being lazy. You need to be ready to express subtle differences by replicating different parts of code, not just obsessing over commonalities.
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.
Overall this is a good tip, but some people take it too far and too early. You can allow some duplication, because over time you might see that repetition was temporary and with more requirements things start to drift apart. Same with simple things repeating once or twice, it doesn't make it any harder to read code or maintain it, so there's no need to deduplicate it (sometimes). Overall be lazy but think about what you do. But don't overthink it, go for good enough at first and then refine 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
Real world developer tip! There exist still scenarios where you absolutely have to do things repeatedly, for various reasons. In such cases, you can also choose to go for code generation, either by using code generators or by scripting such a thing yourself. So DRY here means to not actually write the repeated code by hand.
I have some skepticism over this approach over the factor of speed... When you take a repeated string of code and make it a function. you have it so that instead of running just that code, you have to perform a jump to that place in memory in order to execute what you want. If you are gonna make it a function, you should probably just inline it though the compiler may not agree with you...
don't go overboard though, functions should really only be used when you actually have repeating code. don't be intimidated by long functions. separating a function that has pieces that aren't used anywhere else into separate functions is hell to debug
Software engineer here. Please don't do this in actual unit tests with complicated inputs. Unit tests are not meant to be efficient. It's meant for anyone to just come in and see what problems there are at that moment ASAP. Especially considering there might some small variant in a unit test; this is especially true for unit test on functions that create large csv files. Edge cases will require you to repeat yourself -quite a bit. Make generic builder functions for unit tests but please repeat yourself for unit tests. Able to pinpoint immediately on individual unit tests is extremely important.
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.
A correlation to this would be building physical modules of a vehicle that clip together, each responsible for it's own task. Like a wheel hub that steers, absorbs shock and provides drive.
I can always tell the difference between beginners and experienced programmers, and this is almost always it. Copied and pasted blocks of code in every direction you look, and single simple changes taking hours to implement because it involves fifty literals across thousands of lines instead of fifty references to one global variable right at the top with the rest of the “just make this one little tweak real quick for me” stuff. Remember kiddos, it’s not about how fast you code, it’s about how well you code fast
i dont follow "dry" or "clean". i just follow what looks good. one thing ive found to be consistently true instead is if i need more than 3 levels of nesting, my code is bad and needs to be fixed. but your thing of adding an __init__ is still the correct thing to do because it increases readability and maintainability. your improved version also removes the confusing bit of why x, y were even parameters when you weren't even using them. dont be dry or clean, just be lazy. long functions can always be broken up later down the track anyways if you need to reuse components of them, and repeating yourself sometimes isnt always bad.
DRY isn't always the best way to go **when testing**. Tests should be as independent as possible and repeating is Ok. Doesn't apply for regular production code.
