101–110 of 154 posts
Earlier quoted context omitted.
Certainly so! The first example is needlessly contrived. But instead of for (const i=0; i you can write const new_data = old_data.map((x) => x.toUpperCase()); I think it's both more clear and less error-prone.
The second code does not compile and introduces a new dependency.
https://www.typescriptlang.org/play/?#code/MYewdgzgLgBCA2ATA...
The easiest way to accomplish a real goal like fix a bug, or add a feature, may very well be to first refactor the code. And yes maybe you want to merge that in as its own commit because of the risk of conflicts over time. But just having the code look nice (to who exactly?) isn't valuable, and it encourages the addition of useless abstractions. It may even make later real-work harder. Never refactor outside the context of real-work.
The cartoon with the PM also gets at a ridiculous pattern: engineers negotiating when to do various parts of their job with non-technical people who have no idea how do any part of their job. The PM doesn't know what a refactor is, the EM probably doesn't either. It doesn't make the organization function any better to tell these people about something they don't understand, and then ask them when it should be done. Budget it as part of the estimate for real-work.
I’ve found almost always that less is best.
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.
I'm going to disagree and see what other people say. I don't think that reduction of size is of any relevance. I admit my own refractors tend to make things smaller but it's only a tendency. Most definitely some increase the size overall. I'm currently refactoring a code base – for each item there used to be one class. Each object was examined after creation then a runtime flag was set: Rejected or Accepted. As the c…
This article just reminds me why I hate JavaScript so much. I know you frontend engineers can’t avoid it, but I wish we could come up with something better.
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.
I'm going to disagree and see what other people say. I don't think that reduction of size is of any relevance. I admit my own refractors tend to make things smaller but it's only a tendency. Most definitely some increase the size overall. I'm currently refactoring a code base – for each item there used to be one class. Each object was examined after creation then a runtime flag was set: Rejected or Accepted. As the c…
This code is unreadable chaos, before and after. This article just reminds me why I hate JavaScript so much. I know you frontend engineers can’t avoid it, but I wish we could come up with something better.
Earlier quoted context omitted.
I'm going to disagree and see what other people say. I don't think that reduction of size is of any relevance. I admit my own refractors tend to make things smaller but it's only a tendency. Most definitely some increase the size overall. I'm currently refactoring a code base – for each item there used to be one class. Each object was examined after creation then a runtime flag was set: Rejected or Accepted. As the c…
Other goals can be performance, testability
Earlier quoted context omitted.
I'm going to disagree and see what other people say. I don't think that reduction of size is of any relevance. I admit my own refractors tend to make things smaller but it's only a tendency. Most definitely some increase the size overall. I'm currently refactoring a code base – for each item there used to be one class. Each object was examined after creation then a runtime flag was set: Rejected or Accepted. As the c…
Sure, comprehensibility is the terminal goal—but size reduction is relevant because it’s an easily measured, decently predictive proxy for that. No, code-golfing 3 lines down to one doesn’t help, but the bigger size differences are always of the “composition over XYZ” variety that change the entire complexity class of how much code you need to write (like React letting people write O(states) rendering code instead of…
Maybe you're right. I've had a drink, I'll think over it in the morning, thanks.
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…