Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Good refactoring vs. bad refactoring

builder.io

Post reply on HN
Print view View original

31–40 of 154 posts

Re: Good refactoring vs. bad refactoring

#31

Post by vasco »

The_Colonel wrote: post #23
vasco wrote: post #20

Earlier quoted context omitted.

Your second part is how I think and how I think most people think. That's exactly what I meant.

So when you arrange the visit with your friend two weeks in advance, you first think about sitting in the car, driving out of the garage, getting on the highway, turning on the radio, parking the car, ringing the bell and this other myriad of actions, and the actual talking with the friend is just one of the actions, with no prominence over the others? I certainly don't think like that. My main goal is to visit a fri…

You're the one that added all those conditions about exactness, about needing to replay every step (even this is a problem because steps are fractal), or not being able to change the plan. I can think imperatively and still do those :)

Re: Good refactoring vs. bad refactoring

#32

Post by dominicrose »

vips7L wrote: post #16

That OO refactor isn’t actual OO. The tell tale sign is that it is named by what it does rather than what it is (verb vs noun) and the -or ending in the name [0]. It’s just a function masquerading as a class. The better refactor to introduce OO concepts would have been to introduce an isAdult function on the user class and maybe a formatted function. This + the functional refactor probably would have made for the bes…

What about a pure function that can take anything that has an age as input? Well obviously that wouldn't work for a cat but it's just an example. It requires typescript and I'm not sure how to name the file it would go in, but I think it's interesting to consider this duck-typing style.

    function isAdult({age}: {age: int}) {
        return age >= 18
    }
ps: I replaced const by function because I don't like the IDE saying I can't use something before it is defined. It's not a bug it's an early feature of javascript to be able to use a function before it is defined. Code is just easier to read when putting the caller above the callee.

Re: Good refactoring vs. bad refactoring

#33

Post by whilenot-dev »

vasco wrote: post #13
zahlman wrote: post #11

Earlier quoted context omitted.

> I am under the impression that people start programming, by and large, with imperative for/if style => so the imperative style is readable by more people. IMO, this is a simple consequence of technology moving faster than society. There are still instructors out there who learned to program in an environment where the go-to options for imperative programming were C and FORTRAN; the go-to options for other paradigms…

People think imperatively though. If I think of visiting my friend, grabbing gas on the way back, the way I'll visualize the steps is not functional.

I disagree. People are sometimes just forced to think imperatively when dealing with computers, but I usually think declarative when I design my programs.

Say if I want to filter a sequence of users and omit users below the age of 18, I'll construct my predicate (a "what"), and want to apply that predicate to create a new sequence of user (another "what").

I really don't want to tell a computer how to process a list every single time. I don't care about creating an index first and checking the length of my list in order to keep track that I process each user in my list sequentially, and don't forget that important "i++". All I want at that moment is to think in streams, and this stream processing can happen in parallel just as well for all I care.

But I also do think Python, Haskell etc. are the most expressive here with list comprehensions. It can't get more concise than this IMHO:

  users_adult = [
    user
    for user in users
    if user.age >= 18
  ]

Re: Good refactoring vs. bad refactoring

#34

Post by mariopt »

Words can not express my hate for this kind of articles.

Imagine working on a legacy codebase where the PM holds the dogma of refactoring being a bad thing and expecting you to do it wrong, even micro managing your PRs.

Most often than not, I do see projects suffering and coders actually resigning due to a lack of internal discussing about best practices, having space/time to test potential solutions, having Lead devs who resemble dictators quite well.

Let me guess, some PM wrote this article and they just want you to push the product asap by applying pressure and not allowing you ever to refactor. This is just a casual day in software development. I'm not surprised anymore when most web apps have silly bugs for years because it's gonna be a Jira ticket and a big discussion about..... one evil thing called refactor.

Several years ago I rewrote a full SaaS in about 3 months, it took another team 12 months with 5 devs. Guess which version made the investors happy, mine.

Bad refactoring is just a product of poor engineering culture.

Re: Good refactoring vs. bad refactoring

#35

Post by yxhuvud »

vasco wrote: post #13
zahlman wrote: post #11

Earlier quoted context omitted.

> I am under the impression that people start programming, by and large, with imperative for/if style => so the imperative style is readable by more people. IMO, this is a simple consequence of technology moving faster than society. There are still instructors out there who learned to program in an environment where the go-to options for imperative programming were C and FORTRAN; the go-to options for other paradigms…

People think imperatively though. If I think of visiting my friend, grabbing gas on the way back, the way I'll visualize the steps is not functional.

While I think of things in a defined order, I also think in sets. If I grab a bunch of peanuts, I don't visualize grabbing every single peanut one by one, I visualize getting a bunch at the same time.

Re: Good refactoring vs. bad refactoring

#36

Post by vasco »

yxhuvud wrote: post #35
vasco wrote: post #13

Earlier quoted context omitted.

People think imperatively though. If I think of visiting my friend, grabbing gas on the way back, the way I'll visualize the steps is not functional.

While I think of things in a defined order, I also think in sets. If I grab a bunch of peanuts, I don't visualize grabbing every single peanut one by one, I visualize getting a bunch at the same time.

If you grab a bunch of peanuts you're probably thinking in "hand fulls", but the fact that the world and actions we take are fractal in the way we can analyze them doesn't prove one or the other.

Re: Good refactoring vs. bad refactoring

#37

Post by knallfrosch »

azangru wrote: post #30

The first example of a good refactor is a meh refactor at best, and possibly a bad refactor. Array methods such as map or filter are not "more conventional" in javascript; they are "as conventional" as for-loops, and arguably less "conventional", given how for-loops have been around since the introduction of the language. They are also inevitably more expensive than for-loops (every cycle creates an anonymous functio…

Disagree on this. filter and map are much more readable and especially extensible than result-arrays. Plus it eliminates out-of-bonds indexing.

See the variable name. It's forced to be 'result' so that it's consistent with the result-array style. Therefore it lacks a descriptive name.

For the functional methods, you can easily assign the filter(age > 18) result to an intermediate variable like adultUsers to make the code even more descriptive. Useful when you have more steps. With the result-array approach, you'd have to repeat the looping code or bury the description deep in the loop itself and so you usually avoid that.

Re: Good refactoring vs. bad refactoring

#38

Post by vips7L »

dominicrose wrote: post #32
vips7L wrote: post #16

That OO refactor isn’t actual OO. The tell tale sign is that it is named by what it does rather than what it is (verb vs noun) and the -or ending in the name [0]. It’s just a function masquerading as a class. The better refactor to introduce OO concepts would have been to introduce an isAdult function on the user class and maybe a formatted function. This + the functional refactor probably would have made for the bes…

What about a pure function that can take anything that has an age as input? Well obviously that wouldn't work for a cat but it's just an example. It requires typescript and I'm not sure how to name the file it would go in, but I think it's interesting to consider this duck-typing style. function isAdult({age}: {age: int}) { return age >= 18 } ps: I replaced const by function because I don't like the IDE saying I can'…

That wouldn’t be object oriented. In OO you tend to want to ask an object about itself, Yegor talks a bit about this in his book Elegant Objects.

What you are proposing is just functions or data-oriented programming; which is fine if that’s your thing, but I’d be weary because of the reasons you outline above. Can a book be an adult? What about a tv show? Or recipe from the 9th century? isAdult really only applies to users and really belongs on that object.

Re: Good refactoring vs. bad refactoring

#39

Post by Jean-Papoulos »

I feel this article is honestly disingenuous. One of the "common pitfalls of refactoring" mentioned is "Not understanding the code before refactoring". Well yeah ? The same would apply to doing anything with the code. The following one is "Understand the business context" (note that the author has already departed from the pattern of listing "common pitfalls" to just write whatever he feels like. Or he just published his first draft).

Not a very qualitative article.

Re: Good refactoring vs. bad refactoring

#40

Post by Jean-Papoulos »

skybrian wrote: post #18
nine_k wrote: post #9

Earlier quoted context omitted.

Writing assembly was the idiomatic way of programming before Fortran and human-readable languages came. Writing with goto was the idiomatic way before Algol and structural programming came. Having only a handful of scalar types was the idiomatic way until structural data types came (and later objects). Writing programs as fragments of text that get glued together somehow at build time was the idiomatic way until modu…

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".
Post reply on HN