Hacker News Reader

Comment by analog31 | Hacker News Reader

I believe that of all the lessons to come from contemporary software development, constant refactoring may be the most valuable.

The spaghetti monster looms large when you're in the heat of battle. But we've all got some idle time for whatever reason. I spend some time every week doing a couple of things: 1) Reading about good techniques. 2) Working through old code and cleaning it up.

Because changing your code could always break it, refactoring also reinforces the habit of writing code that can be readily tested -- also a good thing.

View on HN

That was my exact thought reading this.

I used to write some crazy spaghetti code as an untrained student working in a lab. Coding would go really quickly at first, but as I kept adding on to accommodate new requirements it became a huge kludgy mess.

Recently (after quite a few years of software engineering experience) I helped a researcher friend to build some software. He was following along with my commits and asked why I kept changing the organization and naming of the code, pulling things out into classes, deleting stuff that he thought might be needed later, etc. He spends only a small part of his time writing code, so he's never realized how much time it actually saves to keep things organized and well-factored.

Makes you wonder why most languages don't come with good refactoring tools.

Safe automatic refactoring requires the ability to do static analysis of the code. Many refactorings are harder in loosely-typed languages.

Refactoring tools were invented in Smalltalk and worked just fine.

Smalltalk is dynamically typed, but I wouldn't call it loosely typed. It's closer to Ruby's "duck typing". I was thinking more of Javascript and PHP. Weak and loose.

This has always surprised me, since I learned it.

What are the features of Smalltalk that allowed this to happen? Conversely, what is stopping this from existing in more modern dynamic languages?

Smalltalk has simple and strong reflective features. Moreover, it does not make a difference between the developed program and IDE. This means that doing things like that are very natural and well established in the Smalltalk cultural background.

Indeed. Having the whole system in front of you, and knowing how patterns like MVC or Thing-Model-View-Editor encapsulate parts of it, makes it very easy to "reason about" wholesale changes to the system.

I should have added that I am probably abusing the term refactoring if it has a precise definition. What I'm talking about is working on improving the readability of my code, but also improving its structure. Today, "spaghetti" probably doesn't refer to a tangled mess of code sequences because we've gotten rid of the GOTO, but tangled interactions between modules, many of which are vestigial.

A lot of my code interacts with hardware configurations that will cease to exist when a project is done, but I mainly look at the stuff that's potentially reusable, and making it worth re-using.

I'm using Python, and there are a lot of tools for enforcing coding styles and flagging potential errors. I try to remove all of the red and yellow before closing any program file. I don't trust myself with too much automation! "Walk before you run."

I don't think refactoring tools are that useful for refactoring, most of the time you are doing non-obvious refactoring tools can't help with anyways. Depends what we call "refactoring", tools are mostly useful for what I would call "housekeeping".

Well, every refactoring can be seen as a series of correctness-preserving housekeeping operations.

At least in the languages I work primarily in (JS and Java), I find my IDE to be pretty good at analyzing a lot of it.

Refactoring is kind of subjective, because there is rarely One Right Way to solve a problem, and you need context, so I could see why it’s not something that languages themselves take strong opinions on.

Reply on news.ycombinator.com