Difference between revisions of "Programming/Quotes"
Line 1: | Line 1: | ||
=Martin Fowler= | |||
<blockquote> | |||
I'm not a great programmer; I'm just a good programmer with great habits. | |||
</blockquote> | |||
<p style="text-align:right;">—Martin Fowler. ''Refactoring: Improving the Design of Existing Code.''</p> | |||
<blockquote> | |||
Whenever I have to think to understand what the code is doing, I ask myself if I can refactor the code to make that understanding more immediately apparent. | |||
</blockquote> | |||
<p style="text-align:right;">—Martin Fowler. ''Refactoring: Improving the Design of Existing Code.''</p> | |||
<blockquote> | |||
If you can get today's work done today, but you do it in such a way that you can't possibly get tomorrow's work done tomorrow, then you lose. | |||
</blockquote> | |||
<p style="text-align:right;">—Martin Fowler. ''Refactoring: Improving the Design of Existing Code.''</p> | |||
<blockquote> | |||
A heuristic we follow is that whenever we feel the need to comment something, we write a method instead. | |||
</blockquote> | |||
<p style="text-align:right;">—Martin Fowler. ''Refactoring: Improving the Design of Existing Code.''</p> | |||
<blockquote> | |||
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. | |||
</blockquote> | |||
<p style="text-align:right;">—Martin Fowler. ''Refactoring: Improving the Design of Existing Code.''</p> | |||
<blockquote> | |||
Other than when you are very close to a deadline, however, you should not put off refactoring because you haven't got time. Experience with several projects has shown that a bout of refactoring results in increased productivity. Not having enough time usually is a sign that you need to do some refactoring. | |||
</blockquote> | |||
<p style="text-align:right;">—Martin Fowler. ''Refactoring: Improving the Design of Existing Code.''</p> | |||
<blockquote> | |||
I've found that refactoring helps me write fast software. It slows the software in the short term while I'm refactoring, but it makes the software easier to tune during optimization. I end up well ahead. | |||
</blockquote> | |||
<p style="text-align:right;">—Martin Fowler. ''Refactoring: Improving the Design of Existing Code.''</p> | |||
<blockquote> | |||
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 Obsfuscatis; 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. | |||
</blockquote> | |||
<p style="text-align:right;">—Martin Fowler. ''Refactoring: Improving the Design of Existing Code.''</p> | |||
<blockquote> | |||
Most programmers, even experienced ones, are poor judges of how code actually performs. | |||
</blockquote> | |||
<p style="text-align:right;">—Martin Fowler. ''Refactoring: Improving the Design of Existing Code.''</p> | |||
=Donald Knuth= | =Donald Knuth= | ||
Revision as of 09:44, 17 July 2021
Martin Fowler
I'm not a great programmer; I'm just a good programmer with great habits.
—Martin Fowler. Refactoring: Improving the Design of Existing Code.
Whenever I have to think to understand what the code is doing, I ask myself if I can refactor the code to make that understanding more immediately apparent.
—Martin Fowler. Refactoring: Improving the Design of Existing Code.
If you can get today's work done today, but you do it in such a way that you can't possibly get tomorrow's work done tomorrow, then you lose.
—Martin Fowler. Refactoring: Improving the Design of Existing Code.
A heuristic we follow is that whenever we feel the need to comment something, we write a method instead.
—Martin Fowler. Refactoring: Improving the Design of Existing Code.
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.
Other than when you are very close to a deadline, however, you should not put off refactoring because you haven't got time. Experience with several projects has shown that a bout of refactoring results in increased productivity. Not having enough time usually is a sign that you need to do some refactoring.
—Martin Fowler. Refactoring: Improving the Design of Existing Code.
I've found that refactoring helps me write fast software. It slows the software in the short term while I'm refactoring, but it makes the software easier to tune during optimization. I end up well ahead.
—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 Obsfuscatis; 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.
Most programmers, even experienced ones, are poor judges of how code actually performs.
—Martin Fowler. Refactoring: Improving the Design of Existing Code.
Donald Knuth
In this sense, we should continually be striving to transform every art into a science: in the process, we advance the art.
—Donald Knuth. 1974 Turing Aware Lecture. Communications of the ACM 17 (12), (December 1974), p. 668.
The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.
—Donald Knuth. 1974 Turing Aware Lecture. Communications of the ACM 17 (12), (December 1974), p. 671.
A good technical writer, trying not to be obvious about it, but says everything twice: formally and informally. Or maybe three times.
—Donald Knuth. Algorithms, Complexity, Life, and The Art of Computer Programming. AI Podcast (December 30, 2019).
Bjarne Stroustrup
Within C++, there is a much smaller and cleaner language struggling to get out.
—Bjarne Stroustrup. The Design and Evolution of C++, p. 207.