Hacker News Reader

Comment by notacoward | Hacker News Reader

Sounds like you're talking about a rewrite, not a refactor. The whole idea of refactoring is to make code less repetitive or modular without changing functionality. Common patterns include replacing copy/paste code with common functions, replacing complex inline conditions and if/else cascades with helper functions returning bools/enums, etc. A true refactor is provably neutral wrt functionality, often so by simple inspection. If you're changing functionality that's a rewrite, and it's not making the code better because the original code no longer exists.

View on HN

How do you know you're not introducing a bug by replacing copy/paste code with common functions?

Most of the production code I've touched I would never dare to do something like this until I had a very good understanding of the codebase as a whole.

IMX it has often been pretty obvious by inspection. If two or more functions do "if {complex condition} then {complex action with only one variation}" any competent programmer should be able to see that a modification using a common function is equivalent. A slightly more complex case might require more review eyeballs to prove equivalence. Then there are tests. For a relatively small piece of the code you can test quite exhaustively. Most often those tests can live on as permanent unit tests. Occasionally they're so tied to the implementation that they're better thrown away after they've accomplished their purpose.

Obviously any but the most trivial refactor requires some care. Is it worth it, when (in the context of OP) you're in there to do something else? Sometimes yes, sometimes no. One rule of thumb is whether you're just rearranging code or changing the fundamental way that it works. Refactors of the first type can generally be kept low-risk and are probably worthwhile. Rewrites of the second type involve more risk and are probably better left to be projects unto themselves.

Refactoring is a form of rewriting code.

If you use a loose definition of "rewrite" then yes, obviously, but that's not a very useful definition or associated observation. It doesn't make a distinction useful for guiding behavior. If we use a stricter definition of "rewrite" to mean changing the logic as well as its expression in code then that is much more useful and precludes refactors. Also, anyone who can't see the difference between basic logic and its expression in a particular notation (code) probably shouldn't be doing either except under strict supervision of a real software engineer.

Reply on news.ycombinator.com