Comment by hinkley | Hacker News Reader

Comment by hinkley | Hacker News Reader

Parent Full thread

I was quite comfortable with refactoring for a very long time before I started doing tests, and I think that colors my approach to the problem space. I write code until it misbehaves the first time, and then I start writing tests, comfortable in the knowledge that in another half hour this code will be unit testable and look better than what everyone else is turning in, and that I'll spend 20 minutes at the end cleaning it up even more.

But I am not everybody, and trying to set team policy on my comfort levels is quite likely a bit dangerous.

I've paired with a few smart people this month and was horrified by how they refactor. Most trust their hands more than the tools. They do a LOT of transcription instead of copy and paste, and don't use the IDE's refactoring tools at all. That's not just inviting human error to the table, that's giving it the seat of honor.

For most processes there are ways to do it that are worse than nothing at all, and unfortunately many of us seem drawn to them almost instinctively. I try not to think about it because it just makes me angry that the distance between what we collectively know and what we individually do is so wide.

> They do a LOT of transcription instead of copy and paste

Transcription makes you think about what you're typing in and avoids the whole class of errors that arise from copy-and-paste. Transcribing code rather than pasting it is not a red flag.

Transcription can lead to the same conditional in two blocks of similar code instead of the two intended. It can lead to fencepost errors due to changing or inverting an inequality. And in some languages it can lead to code that looks up data that doesn't exist (misspell a property name outside the happy path).

The big problem is that you're chewing up short term memory slots that used to hold the next thing you planned to do. For me I generally use only a couple slots for a single refactor because it's all muscle memory.

Additionally, it just takes a hell of a long time, which means you go from virtually no chance of interruption to a measurable one.

When I was young I had an exceptional short term memory and could pull off some crazy big refactor without introducing errors. But now it's normal at best, and also I rely far less on those sorts of feats, in part because I put a higher value on commit history readability.

> Transcription can lead to the same conditional in two blocks of similar code instead of the two intended. It can lead to fencepost errors due to changing or inverting an inequality. And in some languages it can lead to code that looks up data that doesn't exist (misspell a property name outside the happy path).

Funnily enough, all of those are also problems with copy-and-paste. But they're much more likely to occur through copy-and-paste, because it's easy to do that without reviewing the code.

You're saying you should do extract method or rename variable by typing the code out again long form instead of cut and paste or using the IDE?

Author here...

I have the same issue you have. I luckily work in a language with great refactoring tools, but it's like pulling teeth to get people to use them rather than cut and paste.

What language?

In this case a bunch of former Java devs touching Java for the first time in a while. There could be something to that.

Could be they've forgotten how, but this isn't the first experience like this. I am doing fine with the tools even though they don't do everything when the language is not statically typed).

I'm afraid it is common.

Java isn't perfect and when people also treat their IDE as a glorified text editor I think it is no wonder they dislike it.

(If you go with Java, embrace it. This is probably the thing I disliked most about the way programming was taught in school: they used Java, but without the tooling that makes it awesome. Supposedly so we should learn it well.

If anyone here teaches Java: by all mean have your students use javac in the first assignmemt but teach them maven the very next thing you do. Learn them to use an IDE - it's not harmful as long as you don't accept autogenerated code.)

What is wrong with autogenerated code?

Nothing. There is nothing wrong with code generation in a production setting with "grown up" engineers who uses version control and knows the pitfalls.

The part in parenthesis is just a rant about education and how teachers use notepad and javac to teach Java.

So my point is the only thing students shouldn't use in an IDE is code generation.

But going from javac to Maven in CS1 would be insanely difficult; there are many prerequisites before one can use Maven. It may only work in top-tier schools.

I'd say quite the contrary:

If I had been given a zip with a basic pom file and the correct main and test directories I think I'd had a much simpler start.

C#. Resharper is a really, really good tool, and I also use NCrunch (a continuous test runner) when I do TDD.

I too fell in love with NCrunch during my few months with .Net.

It's possibly the single tool[0] I'll miss from the .Net world when I program in Java.

(For anyone who might be wondering why not Resharper that is because that functionality is provided out-of-the-box with all major Java IDEs. On .Net however, Resharper seems to be almost a must-have for many.)

[0]: I'll be missing Asp.Net MVC, parts of Entity Framework and parts of the C# language too.

Reply on news.ycombinator.com