Hacker News Reader

Comment by moron4hire | Hacker News Reader

This article, when I originally read it 5 years ago, was hugely influential to me. It completely convinced me of the superiority of refactoring existing systems to an ideal over rewriting. It doesn't take anywhere near as much time to fix cruft as it is to create a system from scratch and try to avoid your own cruft. But it's scary and it's an unknown. But if you approach it with courage, it falls quite easily.

EDIT: refactoring large systems has also convinced me of the superiority of statically typed programming languages for large projects. When I break code, I want it to break as hard as possible. I want to see absolutely everywhere function XYZ is called, and one way to do that is to rename XYZ to XYZ___ and see where all of the compiler errors show up.

View on HN

The article and Fowler's Refactoring book had a similar effect on me as well. Your point about statically typed programming languages is one that I've been feeling the brunt of, though I'm not convinced yet.

I've been 100% python for the last few years, after a career mostly in Java and I definitely miss the sweeping refactoring abilities and hard-breaks during those kinds of refactorings. It does lend courage for sure. I'm just SO MUCH MORE productive in python for most of what I do that I'm not willing to throw out the baby with the bathwater yet. Instead I've been trying to focus on leveling up test coverage, and experimenting with Rope for refactorings ( http://rope.sourceforge.net/ ). I'm also slowly learning patterns for coding to make refactorings easier moving forward.. choosing code and data structures that are more easily affect-able later, or even things as simple as naming things for grep-ability.

Modern statically typed languages (cough cough not Java cough) generally have static type inference, which removes a lot of redundancy from the code. Being able to do

val object = MyObject(someOtherObject(12, "hello")) // Scala

instead of:

MyObject object = new MyObject(new someOtherObject(12, "hello")); // Java

saves a lot of time and it just looks nicer. All the while retaining the advantages that static, strong typing have (great potential for refactoring, a lot of errors can't happen at all). Of course, there are some things that will still take up more space than they do in Python or Ruby but it's a great improvement. Languages like Rust, Scala or C# also have a good variety of functional programming tools that can make your life a lot easier.

Interestingly, this (narrow) case is supported by C++ (auto) now.

Even C, kind of:

#define AUTO_TYPE(X,Y) __typeof(Y) X = Y

... though I'm not sure I'd recommend it.

Type inference in full generality can give you a bunch more, as I just went into over here: https://news.ycombinator.com/item?id=6327327

Java 8 will have static type inference, and some other goodies too.

I find C# extremely productive, if you don't try to do like most C# developers seem to want to do and treat it like Java, with interfaces out the ass. An interface can be handy, but generics fill the role more often. However, there are some others like Boo and Nemerle are still statically typed but much, much closer to Python in terms of lack of syntax verbosity.

I used the very first version of C# and enjoyed the language. I found it an improvement (and obviously a reaction) to Java, for sure.

Just remember that you can hint types in Python, and statically enforce those hints. You can create a type system as powerfull as Haskell's.

People just don't do that because it makes them less productive, but it may be a huge bonus for refactoring.

I don't know about other IDEs, but in Visual Studio I'm able to just right-click on a method and hit "Find All References" to see a list of everywhere something is called.

I work on a large piece of C++ software (millions of lines) and unfortunately this feature does not work well enough to be worth using. The first problem is that it takes far too long, much longer than the rename method and waiting to recompile. The other pretty serious problem is that it sometimes misses references so I just can't trust it.

In my vim setup, ctrl-\ <Tab> drops a search for the word my cursor is sitting on (with word boundaries) in my quickfix buffer, for easy stepping through. More or less the same thing.

Could you paste your config for doing this? I'd like to give it a try.

The actual vim config is terribly simple:

    nmap <silent> <Leader><Tab> :make search PATTERN='\<^R^W\>'<Cr>

Where ^R and ^W are literal ctrl-R and ctrl-W (typed with a leading ctrl-v).

Then my Makefile contains:

    search:
        git grep -n "$$PATTERN"

plus some project-specific bits to prune out portions of the tree which should be skipped.

The following are also nice:

    clip:           
        xclip -o        
                    
    todo:           
        PATTERN=TO''DO make search | sed -n 's/\([^ \t]*\)\(.*TO''DO \(([0-9]*)\)\):\?\(.*\)/\1 \3 \2\4/p' | sort -k 2

I've also found it useful to make sure my unit tests output some relevant file:line: info and run those from my makefile.

Relatedly, I have:

    nmap <silent> <Tab> :cnext<Cr>
    nmap <silent> <S-Tab> :cprev<Cr>

to make it easy to jump between quick-fix items.

While that is true, and I do use it frequently (so much so that I prefer the keyboard shortcut CTRL+K, CTRL+R), it's not available everywhere. Also, I tend to still use the "break-it" pattern in Visual Studio because the errors serve as a good TODO list to clean up all of the references.

Though, it gets a little more complicated when dealing with overloaded methods. In that case, Find All References really is a lot better.

Reply on news.ycombinator.com