Live data from Hacker News

Good refactoring vs. bad refactoring

builder.io

71–80 of 154 posts

Re: Good refactoring vs. bad refactoring

#71

Earlier quoted context omitted.

Making analogies like this doesn't prove anything, they're just suggestive. All I'm getting out of this is that you think for loops are old-fashioned.

That's because they are. Functional code is more readable. And if you look back, basically all advances in programming languages have been about "making stuff more readable". Thus, for loops (for this usage) are "old".

You say it’s more readable and I disagree with that!

Is this just fashion? Is there a way to settle it other than “I like it better?”

Re: Good refactoring vs. bad refactoring

#72
post #5

Earlier quoted context omitted.

(Raises hand.) I prefer the for loop. Pushing items to an array is idiomatic Javascript for creating an array. An if statement is an idiomatic way to do it conditionally. It's also easier to debug. The map and filter methods are nice too, but they're for one-liners.

I will say in 2024 i feel like for/of or forEach would at least let you avoid the boilerplate of an index.

Yes, I agree.

Re: Good refactoring vs. bad refactoring

#73

Earlier quoted context omitted.

Making analogies like this doesn't prove anything, they're just suggestive. All I'm getting out of this is that you think for loops are old-fashioned.

That's because they are. Functional code is more readable. And if you look back, basically all advances in programming languages have been about "making stuff more readable". Thus, for loops (for this usage) are "old".

> Functional code is more readable.

There is no way that

    name: R.pipe(R.prop('name'), R.toUpper),
    age: R.prop('age'),
    isAdult: R.always(true)
is more readable than

    name: user.name.toUpperCase(),
    age: user.age,
    isAdult: true

Re: Good refactoring vs. bad refactoring

#74
post #70
post #66

Earlier quoted context omitted.

> u.isAdult() Being adult is not a property of the user but of the jurisdiction that the user is in. In some places or some purposes it is 18 but it could be, e.g., 21 for other purposes. If you software is not going to just run on the USA it is not a good idea to implement isAdult in the user but in a separated entity that contains data about purpose and location.

With proper OO you could still implement that on the user object. boolean isAdult() { return this.age >= this.location.ageOfAdulthood(); // or this.location.isAdult(this.age); pick your poison! } …anyway it’s just an example of how to introduce OO concepts. As everything in programming it depends

Just having some fun with bikeshedding here: Yeah, that could work but IMO in a big/international system the responsibility should ideally live elsewhere, since:

* You may need to determine adulthood for a different jurisdiction than where the person currently resides. Their citizenship may be elsewhere, or you may be running a report that expects "adulthood" to be by some other region's standards, etc.

* Sometimes the underlying kind of adult-need wanted is slightly different, like for consuming alcohol or voting.

* There may be a weird country or province has laws that need additional factors, like some odd place where it's a different age-cutoff for men and women.

Re: Good refactoring vs. bad refactoring

#75
post #74
post #70

Earlier quoted context omitted.

With proper OO you could still implement that on the user object. boolean isAdult() { return this.age >= this.location.ageOfAdulthood(); // or this.location.isAdult(this.age); pick your poison! } …anyway it’s just an example of how to introduce OO concepts. As everything in programming it depends

Just having some fun with bikeshedding here: Yeah, that could work but IMO in a big/international system the responsibility should ideally live elsewhere, since: * You may need to determine adulthood for a different jurisdiction than where the person currently resides. Their citizenship may be elsewhere, or you may be running a report that expects "adulthood" to be by some other region's standards, etc. * Sometimes t…

Yes this is just extreme bike-shedding at this point. But none of this is impossible with more OO principles, like interfaces:

    class User {
        // Convenience function to check if the user is an adult in their current location
        boolean isAdult() {
            return this.location.isAdult(this);
        }


        boolean isOfDrinkingAge() {
            return this.location.isOfDrinkingAge(this);
        }
    }

    interface Location {
        boolean isAdult(User u);
        boolean isOfDrinkingAge(User u);
    }

    class WeirdLawsLocation implements Location {
        boolean isAdult(User u) {
            return switch (u.gender()) {
                case MALE -> u.age() >= 16;
                case FEMALE -> u.age() >= 18;
            }     
        }

        boolean isOfDrinkingAge(User u) {
            return u.age() >= 21
        } 
    }
In the hypothetical that you want to check somewhere the user is not currently:

    class SwedenLocation implements Location {
        boolean isAdult(User u) {
            return u.age() >= 18;
        }

        boolean isOfDrinkinAge(User u) {
            return u.age() >= 18;
        }
    }
    var sweden = new SwedenLocation();
    sweden.isOfDrinkingAge(user);

Re: Good refactoring vs. bad refactoring

#76
Good refactoring should significantly reduce the size or complexity of a codebase.

These two metrics are interrelated, but as a general rule if the gzipped size of the codebase (ignoring comments) does not go down, it's probably not a good refactoring.

Re: Good refactoring vs. bad refactoring

#77
post #68

Earlier quoted context omitted.

My man, thanks for the explanation but I understand the concept I just didn't agree on definition.

Sure. Whenever you post on a forum it's half for anybody else reading, right? I just thought it was interesting to consider the underlying metaphor; maybe people don't think about it. Metaphors, connotations, etymologies -- I find these interesting.

Sure, I agree. You could even respond to me fully selfishly - treat me as a stepping stone just to form your argument, nothing wrong with that.

Re: Good refactoring vs. bad refactoring

#78
Agreed with everything except the following:

>Remember, consistency in your codebase is key. If you need to introduce a new pattern, consider refactoring the entire codebase to use this new pattern, rather than creating one-off inconsistencies.

It's often times not practical (or even allowed by management due to "time constraints") to refactor a pattern out of an entire codebase if it's large enough. New patterns can be applied to new features with large scopes. This can work especially in the cases of old code that's almost never changed.

Re: Good refactoring vs. bad refactoring

#79
post #75
post #74

Earlier quoted context omitted.

Just having some fun with bikeshedding here: Yeah, that could work but IMO in a big/international system the responsibility should ideally live elsewhere, since: * You may need to determine adulthood for a different jurisdiction than where the person currently resides. Their citizenship may be elsewhere, or you may be running a report that expects "adulthood" to be by some other region's standards, etc. * Sometimes t…

Yes this is just extreme bike-shedding at this point. But none of this is impossible with more OO principles, like interfaces: class User { // Convenience function to check if the user is an adult in their current location boolean isAdult() { return this.location.isAdult(this); } boolean isOfDrinkingAge() { return this.location.isOfDrinkingAge(this); } } interface Location { boolean isAdult(User u); boolean isOfDrink…

On a side note, this discussion really made me realize how useful concise method bodies would be in Java: https://openjdk.org/jeps/8209434

Re: Good refactoring vs. bad refactoring

#80
post #75
post #74

Earlier quoted context omitted.

Just having some fun with bikeshedding here: Yeah, that could work but IMO in a big/international system the responsibility should ideally live elsewhere, since: * You may need to determine adulthood for a different jurisdiction than where the person currently resides. Their citizenship may be elsewhere, or you may be running a report that expects "adulthood" to be by some other region's standards, etc. * Sometimes t…

Yes this is just extreme bike-shedding at this point. But none of this is impossible with more OO principles, like interfaces: class User { // Convenience function to check if the user is an adult in their current location boolean isAdult() { return this.location.isAdult(this); } boolean isOfDrinkingAge() { return this.location.isOfDrinkingAge(this); } } interface Location { boolean isAdult(User u); boolean isOfDrink…

That feels like unnecessary levels of indirection to provide a method that shouldn't be on the User anyway.

    j = Jurisdiction.fromUserLocation(user);
    j.isOfDrinkingAge(user);
Post reply on HN