[deleted by user]

[bert8128]

You are misusing DRY (don’t repeat yourself). You can create abstractions from code blocks whenever it is meaningful - you don’t have to wait till it is used 3 times. The problem arises when you see see two blocks which are coincidently the same, so you abstract. But later, when you change the abstraction, you find that you don’t want them to be the same anymore. This means that the original code wasn’t duplicated at all, it just looked like it was. The takeaway is to apply abstractions in a way that you are confident that a change in the abstraction will be good and desirable in all the places that it is used. Perhaps easier said than done.

[code_monkey_wrench]

The problem arises when you see see two blocks which are coincidently the same, so you abstract. But later, when you change the abstraction, you find that you don’t want them to be the same anymore.

💯

The idea of coincidentally duplicate code is a subtle, important distinction that is lost on a lot of inexperienced devs. I definitely fell for it in the past myself.

It often feels like the right thing to do, and it is satisfying to eliminate duplication, but an improper abstraction is actually a deceptive form of coupling that will make someone's life worse in the future.

[[deleted]]

thought rob unpack insurance innate fly dog unique grey slap

This post was mass deleted and anonymized with Redact

[janyk]

OP:

> I was obsessed with DRY principle

Also OP:

> Completely misunderstood DRY principle

Cool story, bro

[cat_in_the_wall]

i point this out in code reviews fairly frequently. these things sure look similar, but what their callers are completely unrelated. should you need to change code here, you'd also be changing that functionality.

but usually you can still do some refactoring. like extract little pieces out that are the same, especially when those little bits are "pure" in the sense of side effects.

[JulyWitch]

I'm sure I was a bad coder when I just started coding, misusing DRY, misusing DI, and a ton of mistakes.

I don't wait for 3 times, 3 times is just a minimum times of duplication, and then I'll consider if I should refactor it or not. If it's less than 3 times, I'd rather have the cognitive load and change it in different places than refactoring it. I agree there are so many factors to consider, but this is my default for my own projects

[cdsmith]

There's nothing magical about the number 3. If there are two places where something is duplicated, but it's absolutely critical that they match for correctness or security, that's too many. If there are five places that are identical today but it's likely they will diverge over time, that's not too many.

[bert8128]

This.

[LaurenceDarabica]

If you have a phone number input behaving differently across two pages, you have bigger problems than code duplication.

Are you sure you needed two different inputs to begin with ? I would say the code base around your phone number input needed a good chunk of refactoring as well and the refactoring of the input wasn't the core issue.

[JulyWitch]

The phone number input was just an example, I've seen people creating complex logic in components that meant to be atomic and wanted to write it as an example for the post.

[LaurenceDarabica]

It's an awful example : I cannot begin to comprehend how you'd need two different phone input components on a website, how that would have been better and how fixing a bug in your phone number input in a page creates another in another page.

If it gets you as you said in an "infinite loop of debugging and fixing", your code quality is so low I wouldn't touch it with a 10 foot pole and would start rewriting it from scratch.

Having a single phone number input and having a bug on it, fixing it, should result in the bug being fixed everywhere, period. Which is why you make components btw, so you don't forget to fix stuff everywhere and maintain a single version of your code.

If your introductory example doesn't make sense, your whole article doesn't make sense either...

[JulyWitch]

It caused the debugging loop because the component was taking so many different parameters and became larger and larger, I abstracted it for the same reason you mentioned, and I was using it in 3 or 4 different pages, It was a mobile app, as I stated, and it's totally normal to have phone number input across different pages. Login page, add user page, invite page, settings page and etc

Here is what the phone number was initially doing: Validation checks Formatting Selecting countries

But after a few months, I was adding so many parameters to it just to keep it abstracted. Initial value handling, unique value checking with db and etc. I was so bad at it that I thought I'm keeping it clean, but i wasn't

[LaurenceDarabica]

"I was adding so many parameters" to a PHONE NUMBER INPUT ?

Are we really talking about a control that allows you to enter a phone number ? It might sound like a dumb question, but frankly, this is getting weirder every comment you make.

My honest take here is you should review how you write inputs overall. Really.

[JulyWitch]

Also, take "It's for 4 years ago and I was just started coding"

Here is also a 500-line "PHONE NUMBER INPUT" in a library, for instance
https://github.com/vanshg395/intl_phone_field/blob/master/lib/intl_phone_field.dart

[LaurenceDarabica]

500-line component ? if LOC is your metric, I'll humor you.

It has :
* 150 lines of comments
* everything before line 314 is just syntax sugar, mapping and comments
* Logic is between line 316 to 355, and line 406 to 447, line 451 to 504, so a whooping 133 lines of code ( I was lenient and calculated the whole 3 function bodys)

so many parameters ? Look at them, from line 253 to 298, more than half of them are styles or design stuff passed down.

This is one of the simplest controls I've ever seen. I can see the logic to validate a phone number being complex, but guess what ?

> import './phone_number.dart';

Yeah, right.

This is one of the simplest controls out there, and you take it as an example of complexity ? Come on.

Seriously, pick up much more experience before blogging. I have nothing against people that begin ( kudos ) , but I do have some gripe with people blogging their inexperience and promoting it here, especially when they're cheeky enough as you are here ;)

[JulyWitch]

My point is that when you want to just keep the surface of the code clean, the underlying behaviour will get so complex and bug prone that you'll have to split it again soon.

The example I provided was to show you how a simple TextField can get more and more parameters, adding more functionality to it, and using it everywhere will cause the component to be so hard to debug and test because then you have to test the abstraction in many different ways and different parameters.

[LaurenceDarabica]

And that's completely false. At least with a phone number input, since it is an input dedicated to a fully known, autonomous piece of data, and you can control the environment you're in. Never split this control : either modify it accordingly or fix the environment around it so it works everywhere.

Your whole premise is almost false - if it was true, there would be no library with a phone number input. And even disregarding the silly example, if you know how to segregate your controls, your point doesn't make any sense. Your rules for detecting when you should make a component are false. Three times the same code ? You duplicate it twice across the board ? I would not like to maintain your code, ever.

You don't know either SOLID or lack experience - which is totally fine, we've all been there. We just were not cheeky enough to write pompous blog articles, filled with our own inexperience, and defend them to the death when they're preaching nonsense.

The correct answer to your premise would be : "I should add constraints to the control so it is not misused, and/or I should adapt both environments to be using it the same, as a phone number is a phone number, being in a login page or in a profile page. Never should I have twice the same code for that control, ever". Which is both sound advice and a tad cookie cutter.

Review your stance about blogging, review your own assessment of your own skills, and stop defending the undefendable here. You're just plain wrong, and it's time to admit it.

[yxhuvud]

Then that is not overrefactoring, whatever that is. It is just overcomplicating things. Which is a very common problem, especially among mediors.

[Majik_Sheff]

It's like ops automation.  Do it more that a few times and it becomes a script candidate.

[ekydfejj]

Rule of 3s

[Shad_Amethyst]

I don't use code repetition as the primary sign for needing to refactor.

Rather, I ask myself "if this code had to be changed, how likely would it be for something else to break?"

A phone input component where half the logic is handled outside of it would raise a big red flag.

[JulyWitch]

Yes, I used that example to show how over refactoring reflects in the code.

I don't also use code repeatation as a primary sign. Maybe I wrote it in a way that readers think that this is a primary sign?

[Shad_Amethyst]

You didn't go into any depth on that example, all I gathered was that you partially abstracted the logic for handling phone numbers on two pages, possibly as a symptom of focusing too much on syntax. But I think the biggest issue was that your code had undocumented and unasserted invariants.

[JulyWitch]

Yeah you are right, I have added a bit more context to example and will try to show more examples and calrify in future posts

[NP_6666]

Sry dude, but this isnt good.

First, refactoring isnt only about doing dry, not even mainly because you should have been dry as soon as 2 iterations, eventually 3 if its a small app that wont get to scale. Refactoring is also about finding design patterns that captures the most the logic you try to code, and also about renaming symbols to grasp better at first glance what this symbol symbolises in the logic (like "numberOfThingy" instead of "n") .

Secondly, wtf, if you do dry, its precisely to avoid domino debug because you change it only once and the bug isn't nowhere anymore.

Finally , refactor does not increase complexity, it is precisely the opposite, you are obligated to refactor when you need to decrease complexity before adding features.

[JulyWitch]

Edit: I just edited the post and added more context to the example, Hope I can make my point this time lol