Refactoring Quotes

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
― Martin Fowler

“When you find you have to add a feature to a program, and the program's code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“Life being what it is, you won't get your names right the first time. In this situation you may well be tempted to leave it—after all it's only a name. That is the work of the evil demon Obfuscatis; don't listen to him. If you see a badly named method, it is imperative that you change it. Remember your code is for a human first and a computer second. Humans need good names.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“It's more than a little ironic that many of us preach safety first to our children, nieces, and nephews but in our roles as programmers scream for freedom, a hybrid of the Wild West gunslinger and teenage driver. Give us freedom, give us the resources, and watch us fly.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“If you have to spend effort looking at a fragment of code and figuring out what it's doing, then you should extract it into a function and name the function after the "what".”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“People sometimes ask me what length I look for in a method. To me length is not the issue. The key is the semantic distance between the method name and the method body. If extracting improves clarity, do it, even if the name is longer than the code you have extracted.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“Code that communicates its purpose is very important. I often refactor just when I'm reading some code. That way as I gain understanding about the program, I embed that understanding into the code for later so I don't forget what I learned.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“Notice how I'm playing the part of an enemy to code. I'm actively thinking about how I can break it. I find that state of mind to be both productive and fun. It indulges the mean-spirited part of my psyche. When you are doing tests, don't forget to check that expected errors occur properly.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“Repetition is the root of all software evil”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“Leaving nots in a conditional like that twists my mind around at a painful angle”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“An intuitive definition is that a safe refactoring is one that doesn't break a program. Because a refactoring is intended to restructure a program without changing its behavior, a program should perform the same way after a refactoring as it does before.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“If oy have to spend effort looking at a fragment of code and figuring out what it's doing, then you should extract it into a function and name the function after the "what".”
― Martin Fowler, Refactoring: Improving the Design of Existing Code