Refactoring: Improving the Design of Existing Code 99
| Refactoring: Improving the Design of Existing Code | |
| author | Martin Fowler with Kent Beck, John Brant, William Opdyke, |
| pages | 431 |
| publisher | Addison-Wesley |
| rating | 9/10 |
| reviewer | SEGV |
| ISBN | |
| summary | Just what the working programmer ordered: a catalogue of practical refactorings with solid advice on when and how to apply them. |
Overview
This book could very well do for refactoring what the "Gang of Four" book did for design patterns. In fact, with the number of contributing authors, this might well become known as the "Gang of Five" book. (They contributed content to chapters 3 and 12 through 15.)
Organization
Refactoring leaps in feet first with an extended example. I found this to be a surprisingly effective opener: it didn't overwhelm me, and left me hungry for more. The first chapter follows a sample program through several incremental refactorings, and the reader gets the idea via osmosis.
To illustrate the technique of refactoring, the first chapter presents the original code on the left page, and the resulting code on the right, with changes in bold. This presentation, coupled with explanatory text, makes it easy to see what's going on and focus on what's happening. It's as if you're looking over the author's shoulder as he edits, compiles, and tests code in his development environment.
What is Refactoring?
Now that you've done a refactoring, you might be curious to know more about what refactoring is. The next few chapters provide the relevant background.
Refactoring is what the book's subtitle suggests: changing code in in ways that preserve behaviour, but improve the way that behaviour is generated. This could be as trivial as renaming a method, or as tricky as separating domain and presentation classes.
Why go through this trouble? In the end, the code is different but it acts the same; there has been no new functionality added. Why? You do this to place yourself in a better position to add new functionality to the software. If you don't, you eventually end up with spaghetti code that is unmaintainable and will not support new functionality at all.
I think anyone who has worked on real code can appreciate the need for refactoring. In fact, most good programmers already do it, although perhaps only on a subconscious level. What this book aims to do is to raise that ad-hoc activity to a higher level of applied technique. Just as there are principles and practices in GUI design (as opposed to merely throwing widgets together randomly), there are principles and practices in refactoring activity: this book catalogues them.
Catalogue
Sandwiched between introductory and summary chapters is the meat of the book: a catalogue of over seventy refactorings. This catalogue follows in the footsteps of the highly successful Design Patterns format: Pattern Name and Classification, Intent, Also Known As, Motivation, Applicability, Structure, Participants, Collaborations, Implementation, Sample Code, Known Uses, and Related Patterns. Since the individual refactorings are less complex than patterns, this catalogue uses the format: Name, Summary, Motivation, Mechanics, and Examples.
The idea is the same. The name and summary provide a definitive vocabulary and a reference-card example. The motivation explains the relevance of the refactoring. The mechanics cover the step-by-step details of how the refactoring is executed. Then a series of examples demonstrate the variations.
Applicability
I like the catalogue. Although some refactorings seem deceptively trivial, it is useful to have them laid out in step-by-step detail. You never know when you will make a mistake, and when you absolutely positively must fix a bug or add a feature by the next day, and need to refactor to do it, slow and steady wins the race.
Further, other refactorings are not so trivial and familiar, and it is certainly useful to have their traps and pitfalls exposed. Frequently, they rely on the smaller refactorings themselves.
I can see this book becoming well-used in a shop with plenty of production code.
Supplementary Material
The non-catalogue chapters are informative as well. I especially appreciate the metaphor of bad smells in the code: the "if it stinks, change it" philosophy is the perfect counter-point to the oft-cited "if it ain't broke, don't fix it" mentality.
The chapter on refactoring tools discusses the possibility of automating much of the mechanical work of refactoring. Although there is a Refactoring Browser for Smalltalk, I suspect that Java and C++ versions are a little ways off. I'd wager that, as with the UML, tool support will lag industry practice for some time.
Style
As always, the author's writing style is down-to-earth and easy to read. Martin tells you straight up what he's found useful and what he hasn't. He tells you where he's made mistakes, and where the risk is less pronounced.
I like the way he goes through an example, then goes through it again under different conditions, thereby revealing the many-splendoured variations. Frequently he continues examples that were left off from other refactorings.
Plenty of further reading is suggested; I always like that.
Flaws
The book has a Java focus, and that is the language used for the examples. There is some mention of Smalltalk and C++, but not much; far less than Design Patterns, for example. Still, the book is quite understandable to anyone with object-oriented development experience.
The book references design patterns; some refactorings even apply and manipulate patterns. However, I wish there were more direct references to the Design Patterns book. That would especially help those new to both refactorings and design patterns.
There are a few minor typos (nothing major), so check the author's web site for errata and try to get a recent printing if you can.
Recommendation
It's no secret that I think this is a book whose time has come. I'm hoping it will codify my approach to refactoring, to help me be more efficient in my development.
I recommend this book as both a practical catalogue, and as a general work on the theory and practice of refactoring. I think that the refactoring community will grow much as the patterns community before it, and that we will see more published on the subject.
Until then, this book is a good start.
Purchase this at Amazon.
TABLE OF CONTENTS
Foreword
Preface
1. Refactoring, a First Example
2. Principles in Refactoring
3. Bad Smells in Code
4. Building Tests
5. Toward a Catalog of Refactorings
6. Composing Methods
7. Moving Features Between Objects
8. Organizing Data
9. Simplifying Conditional Expressions
10. Making Method Calls Simpler
11. Dealing with Generalization
12. Big Refactorings
13. Refactoring, Reuse, and Reality
14. Refactoring Tools
15. Putting It All Together
References
List of Soundbites
Index
Important... (Score:1)
Refactoring and Extreme Programming (Score:2)
Good book (Score:3)
How original is this idea? (Score:1)
For design patterns, read reusability. Some languages, eg. Haskell, support a high degree of reusability in the way they work, and so one can implement the idea-in-itself once and for all, but in most languages you will find yourself reimplementing the same idea again and again.
Similarly with the current book, for refactoring read refinement. If we have programs M and N, and N terminates on the all of the inputs M does, and with the same observables, then N refines M.
Both of these ideas are important, and fraught with hazards in practice, so they are well deserving of a book length treatment. What irritates me is the contention that until now these ideas are ones we were only subconsciously aware of. Absurd: they are old ideas, and ones good sofware engineers are very conscious of.
Finally, Software Editing Arrives... (Score:3)
No amount of programming methology... (Score:2)
...can replace good, solid comments. Comments lines are soooo understated in schools, but are sooo conforting in the real world.
At University of Toronto, examples in first year had 2 line of comments for each line of code. I try to stick with that ratio at work. (I said TRY
Re:No amount of programming methology... (Score:2)
Additionally, if you're spending twice as much time writing comments as you are writing code, then only one third of your time is being immediately productive. I appreciate the long-term value of well-documented code, but also tend to believe that brevity is the soul of clarity. And with that in mind, I'll shut up now.
Simes.
--
Re:No amount of programming methology... (Score:1)
No amount of programming methology...can replace good, solid comments. Comments lines are soooo understated in schools, but are sooo conforting in the real world.
No amount of comments will help with poorly structured code with badly chosen variable and function names. Code should be written such that it needs very little comments (admittedly, this is a subjective matter).
--
Re:No amount of programming methology... (Score:1)
Well, I guess that means that there is no good C++ or Java code (duck & cover)
Just another AC.
Re:'Well' architectured systems suck (Score:1)
comments should be about *WHY*..not *WHAT* (Score:3)
Too many comments can be as bad as too few, and trying to get the right mix is somewhat of an art that I still haven't quite mastered. But I think using them as reminders has come in very handy.
SPR? (Score:1)
Re:SPR? (Score:2)
Anti-Patterns (Score:1)
Re:No amount of programming methology... (Score:1)
I think it is much more important to have comments outside a function, method or class, explaining what it is and how to use it, than inside the code itself. This is for two reasons: firstly, if the comment is outside (say, just before the function definition), it doesn't clutter the code. But more importantly, somebody who wants to use a function shouldn't have to read the code to see what it does. You should put a comment at the top explaining the interface and what the code does, and any 'gotchas' in using it. Below that, you can optionally comment on how it does it, for the benefit of those trying to debug or improve the implementation.
Of course, having comments doesn't excuse you from choosing meaningful method names, variable names, and so on. But in most cases, a name like get_user() isn't sufficiently descriptive in itself.
Re:No amount of programming methology... (Score:1)
Too much code, and you're spending too much time reading TWO languages. But how many programmers usually over-comment?
Aside, does anyone have a list of the "must-have" software development books?
i.e. "Computer Graphics" by Foley and van Dam and the Graphic Gems series are the "bibles" of graphics.
I have "Code Complete" and "Rapid Development" both by Steve McConnel along with Design Patterns, which I find are great. Anyone have any others that every developer should have?
Re:How original is this idea? Doesn't matter (Score:1)
> subconsciously aware of.
I think the main reason to be for books like this and Design Patterns are to
a) provide a common vocabulary so everyone knows what we're talking about - for example I 'discovered' the Command pattern and called had a load of classes derived from command. But I talked about compounds rather than composites. I frequently use template methods but until I read Design Patterns I had no concise way of refering to them - I had to explain it everytime. Refactoring is the same.
b) show you more then you already knew, or cast new insight on something you're already familiar with.
This second reason is probably why Design Patterns is so popular and why I think Refactoring will also be. You already be using more than half of what the book describes, but the book(s) show you more then you knew. Because you're already in agreement with the authors (because some of the stuff is already familiar) the new stuff goes in easy.
It doesn't have to be *original*... (Score:1)
Good software engineers may already be aware of this sort of thing; I know as I read that book review I see things I've done and things I've wanted to do but not had the time and things I'm perfectly well aware of.
But that's not the primary value of a book like this. If the ideas were brand new and untested, they would be less valuable to have written down. The thing is that there are at least N+1 ways, for any given value of N, to re-engineer or refine or redesign a piece of code, and ideally you want to consider as many as possible before choosing which one to do. A book listing lots of them gives you a massive boost because it reduces the chance that you might overlook the one strategy that could be the biggest win. Think of it as a checklist: you may know, if you look in the fridge, that you have no milk, and as you walk around the house you may see any one of forty things you need to buy and they're all obvious to you, but you still make a shopping list when you go out because otherwise there's a good chance you'll forget at least one of them.
In addition, writing these down might help turn bad software engineers or learning software engineers into good software engineers. I think learning software engineers, if they're going to be good ones, probably are already subconsciously aware of these ideas and benefit from having them brought up into the conscious level and carefully reviewed.
Re:No amount of programming methology... (Score:1)
(And yes, I'm a profession programmer who likes C/C++/Java.)
Re:'Well' architectured systems suck (Score:1)
On the other hand, if you're doing more of a RAD style, the best advice I've ever heard is for each development mini-cycle, to "do the simplest thing that works, then refactor". Unfortunately, people love the first half of the advice but rarely remember to do the second half... :(
--
"Anyone have any others that every developer "... (Score:1)
..." should have?"
All of the Dilbert books.
Just to maintain your sanity.
But refactoring applies to small programs too (Score:2)
I'd also agree architecture is of critical importance in large multi-programmer projects, especially any that must be expanded and grow over time. Many open source projects qualify nicely of course.
But refactoring really rings a bell, even with small assembly programs. Typically I develop a simulation in C, test it, translate to assembly, verify equivalence of output, then refactor it until it's time optimal. Don't know if this book would suggest methods useful to me, but rewriting code while preserving its function is something I do a lot of.
Re:Finally, Software Editing Arrives... (Score:2)
1) social: if programmers feel the need to protect their code from their coworkers, you do not have a team development. Your whole application, being put together by modules from each programmer, will only be as good as your weakest team member.
2) testability: if you cannot easily test (parts of) your application code, refactoring will not work. No one, other than the original designer, will dare to do any changes. Especially if it is spaghetti.
3) concurrent version control: using something like cvs, clearcase or such is vital. For doing refactoring you need your own sandbox to be able to play in.
If you have all three items working in your project, you will get, in my experience, the best results. Everybody can learn from everyone else.
The worst experience was in a department where everyone worked isolated. Being new there, I got a piece of code to extend with some minor function. Peeking into the main header file I found:
#define TRUE (-10)
#define FALSE (-11)
The guy who had written this had left the company. Showing this piece of marvel around and asking, if this was common practise, I was told not to do such thing. Someone could feel embarrassed by it. "Well, someone should", I thought, went back to my desk and refactored heavily...
Re:No amount of programming methology... (Score:3)
Comments the just restate what the code says, like
foocnt++; /* increment foocnt */
are absolutely useless, and those who put them in code need to be taken out and beaten. But comments like
foocnt++; /* yes, this situation counts as a foo */
(ok, a bit of a contrived example) are more useful. Function and module headers that explain design and interface are very useful, and should be required on all sizeable projects, IMHO.
Inside the code itself, perhaps the best way to comment is to write down what a section of code is going to do before you write it. Thus, you write the comment
before you write the code that loops over the array . (Assuming that the code is more complex than for (i=0;i) Then, when you're going back over the code, and you see something that makes you pause for a second - or even a quarter of a second - and say "why are we doing this?", comment it. Trust me, the guy who inherits your code will love you for it.
(I have a calligraphic button that says "Code as if whoever maintains your code is a violent psychopath who knows where you live." Great advice. Anyone know the original source?)
Anyway, I'm glad that I know have a term for refactoring. I've been doing it for years, but it was sometimes difficult to explain to management what had to be done and why. I shall add this tome to my purchase queue.
Re:No amount of programming methology... (Score:1)
Interesting...
Most comments I do are for the sanity of my future self/others, who are not perfect and are not experts at coding. (eg 6months of simple programming from college)
Another reason why comments are needed is to get around limitations of development environment. I'm not talking about GNU C + vi. I'm talking about full environments like Developer 2000 or Uniface. Developer 2K doesn't even have an effective global search (fixed in next version).
>if you're spending twice as much time writing comments as you are writing code, then only one third of your time is being immediately productive
I disagree with you on this. Comments can save you/other people/you company lots of time/money when you come back 1 year later when you have forgotten what everything does and its limitataions. Also makes you look better in front of customers when you can fix things quickly. This is more important than any academic elegance of code.
>I'll shut up now
I should take your advice.
Re:No amount of programming methology... (Score:1)
Re:No amount of programming methology... (Score:1)
Refactoring & Extreme Programming (Score:1)
I bought this book as soon as I saw Martin Fowler's name on it, and it hasn't disappointed me. On some level, it's design patterns in practice, but it deals with the niggling deals of loose code far more effectively than DP. I liked it.
The testing framework methodology really interests me, but I found I was spending more time writing the tests than actually writing the code. YMMV.
Re:No amount of programming methology... (Score:1)
Comments also often contain bugs, or are out of date.
When code is properly designed and implemented, it's intent is usually pretty clear. Code that requires explanation can nearly always be rewritten so that it's intent is clear even without comments.
C++ maybe..but Java? (Score:1)
Foo.getBar()
or
Sun.addAnotherJavaFeature()
Maybe Perl or Python would be better examples :)
I am stealing this! (Score:1)
>"Code as if whoever maintains your code is a violent psychopath who knows where you live."
I HAVE A NEW SIG.
Actually, I try to include the business rules/concepts in my comments also.
eg
/* Since each box contains a max of 28 packages and each shelf has 4 rows of 8 boxes.*/
Important when the business rules change. And they will
Also, your post is formated enough to get the idea.
Re:How original is this idea? (Score:1)
Coding in Java for my job is beginning to rot my brain. I have to write Haskell programs no one will ever use to keep my sanity. Every time I write a type-cast I want to cry. My wrists hurt at the end of the day from the amount of typing required to implement the simplest concepts. Worst of all I look at my own code and I'm not sure whether it's right -- and it hurts because I know that if it were written in ML, or Haskell, or one of a dozen other civilized languages, I would be able to look at it and know that it was right.
Is there any escape?
Whoops. (Score:1)
>/* Since each box contains a max of 28 packages and each shelf has 4 rows of 8 boxes.*/
Business rules that could change assumptions you made, there are now a new type of box, the rows are now different depending on which warehouse it is in, a box can now contain packages or containers or some of each.
Business rules suck. They get in the way of my beautiful code.
...or *what* - not *how*... (Score:1)
If You think about it...
Thoroughly Agree (Score:1)
Analysis Paralysis (Score:3)
The most important thing about all of this is that software development goes in cycles. First you make it work, then you make it right, then you make it fast. Leaving out any of these steps is very bad.
Another very bad thing is when you have the whole system planned out in excruciating detail before you write line one of code. Inevitably, one of your assumptions will turn out to be totally unworkable, and if it's already set in stone, that will probably break everything else. Generally you have to sketch the broad strokes, fill in the major code, find out what works and what doesn't, throw away what you've done so far, and start for real. That's just the way it is, and if you don't plan to throw away your first try, you'll just end up being overbudget and late when you have to throw it away anyway.
----
We all take pink lemonade for granted.
Re:Finally, Software Editing Arrives... (Score:1)
From a business perspective it's even worse. Do you spend $X to hire Alice to write some code, or many times that to have Alice review the code that Bob wrote? Depending on the problem, you could literally have Bob take a week to write code that Alice could write in a few hours (e.g., because Alice realizes that it's a perfect example of when you should use bison/flex), then she would have to spend some time explaining what tools she used to reduce a big hairy problem to a little one.
(coyote-san unlogged in)
Commenting style should be based on language. (Score:1)
That aside, I would offer my opinions for the following languages:
Stack Assemblies: Comment anything tricky, and include a stack status comment on every line! This is necessary to make sure the stack never underflows or overflows due to not knowing what to expect in it after unconditional branching.
Other Assemlies: Commenting most line is still likely a good idea. That way it's possible to see what's being moved and so forth.
Higher Level Languages: Inline comments are usually a waste. In fact they can reduce the clarity of the code. Assume that the reader of your code knows the language. Save inline comments for tricky algorithms, highly mathematical content, or maybe obscure functions in a large language like Perl or Ada. Block comments have a great deal of use though. I'd probably recommend a block comment to describe each function.
...just my 2 cents; it's saved me a heck of a lot of time.
Re:Refactoring and Extreme Programming (links?) (Score:1)
- Mike
Old Ideas; Newly Codified (Score:1)
What is new, is the codification of these ideas into a more textbook form. This is a step along the way from art to science. You can open a textbook now, and discover the steps of a proven method to get from software point A to B, when to do so, and when not to.
This makes it more akin to engineering. These are proven recipes for engineering software, and now they are codified in books.
Re:Finally, Software Editing Arrives... (Score:2)
C++ and elegance (Score:1)
Then Stroustrup's "The C++ Programming Language (Third Edition" to understand the language as it now is. If you can see past the support for casting and operator overloading, you will discover that Stroustrup has as much to say on large scale software design as Booch or Lakos.
There are whole chapters on expressing architecture in C++. Of course, you have to understand the syntax and semantics of the language to achieve that goal. But C++ is about more than obfuscation and C compatibility. Lurking in there is a language that combines the best of Simula, C, and other languages, into a successful language that supports large scale programming.
Don't forget: Stroustrup's background is heading a research centre for large scale programming at ATT. He doesn't just work with toy problems.
Comments and/or dependencies... (Score:1)
struct mystruct
/* This calls functions "function1" and "function2" and needs a FILE*
foo(int bar, int baz, FILE *fnord)
*that points to the comma-delimited data that gets updated in function "blorf".
*/
That's saved me a few hassles. ("Why is this not working right?" "Hold on, I tweaked foo... looks like function blorf needs an update too; I'll get right on it.") Does CVS do something like this automatically? I ask because I have never used CVS; it seems like overkill for the essentially one-person project I'm working on. Besides, the users always let me know semi-immediately whenever anything breaks.
Re:C++ maybe..but Java? (Score:1)
Now
Re:Finally, Software Editing Arrives... (Score:3)
Re:Refactoring and Extreme Programming (links?) (Score:1)
XProgramming.com
Re:'Well' architectured systems suck (Score:1)
Re:C++ and elegance (Score:2)
C++ doesn't HAVE a semantics. C++ has a tangled, elephantine heap of ambiguities. ML has a semantics (Milner et al, The definition of Standard ML, second edition).
As for syntax ... I read a story once about someone (I forget who) who was trying to write a yacc grammar for C++, and every time he ran across an ambiguous case and ran it through cfront (the defining implementation at the time) to check its parsing, cfront dumped core. But that doesn't even matter; any language could have its syntax reduced to Lisp's and it would be fine with me.
Type checking? After working in a language with a really powerful static type system (such as ML or Haskell), trying to express concepts as types in C++ feels like moving a sand dune with tweezers. Parametric polymorphism and algebraic sum types are just the beginning of what I miss.
In short, individual language features (casts, overloading, whatever -- see Haskell to understand what overloading should be about) aren't what bother me. What bothers me is the whole philosophy of clumsy thinking at too low a level of abstraction. It astonishes me that people can and do write large programs in C++ and Java. I can respect that after a fashion, but just because the wall is bloody from everyone else banging their head against it doesn't mean I should do the same.
I apologize for the strong language in this post, but I feel very strongly that the use of insufficiently abstract languages (principally C++ and Java these days) in production software is a major reason why said software is so frequently so bad; and that there is no excuse for the failure to use more advanced language technology to improve our design of and reasoning about programs.
Good idea, but what about politics... (Score:2)
Perhaps the book addresses this (I haven't read it). Anyone actually work anywhere where management signed on to refactoring?
The problem with abstraction... (Score:1)
I used to do a lot of development in APL -- now there's a language with a lot of high level abstraction, but it's oriented in a particular direction that is not necessarily a good fit for some of the things I've seen it applied to (email!? business management!?).
It may well be that the applications you're working on could in fact be better developed in ML or Haskell (I'm not familiar with either of those), but in the commercial world that's only one consideration. Other considerations are: who supports the develpment tools, and how big is the available pool of talent to support what gets built. I've beaten my head against that wall, too (I was an early adopter of C++ back in the 'cfront 1.0' days because the OO approach was a much better fit for some of the applications we were developing -- this in a UNIX/C shop that had just barely finished migrating some of their developers from VMS/FORTRAN. C++ has gone downhill since then, in my opinion.)
Re:C++ and elegance (Score:1)
Those who really, really want "a better language" are going to stick with something like Haskell, or Eiffel, etc. But the majority of people are going to accept C++'s warts (yes it has a few, I believe all languages do) because of its other advantages.
So, more people use C++. Granted? Not everyone is a good programmer. Probably there are worse programmers using C++ (sheer numbers argument here) than Haskell.
It's not surprising you see bad C++ code. Again, sheer number of users.
You haven't seen my C++ code. Do I sound like the kind of person who would tolerate inelegance? I've used quite a few languages (although admittedly not Haskell, I'll take your word that it's nice). I understand C++ seems inelegant in places, but I believe that's more of a surface impression.
C++ is currently the best, prevalent, language we have for software architecture. Java lacks language features (particularly const, and stack-allocation for user-defined types) and performance. C lacks higher-order features (such as classes). Smalltalk/Lisp/etc. lack performance and static type checking. Eiffel/Haskell/etc. lack prevalence.
As long as C coders use C++, we will be stuck with programmers who don't understand the difference between initialization and assignment. The language can't help that.
I feel your pain (Score:1)
Re:I am stealing this! (Score:1)
If I have constants defined like this, then I can't imagine ever needing to write a comment like that:
public interface BusinessRuleConstants {
public static final int MaxPackagesPerBox = 28;
public static final int BoxesPerRow = 8;
public static final int RowsPerShelf = 4;
}
Also, I wouldn't call the statement in your comment a business rule. A business rule in my experience is more like, "If the number of packages in a box is less than 5, order more packages." And that rule could easily be expressed as a language construct, with no comment needed, if the data structures and constants have been given clear, correct names. And if they haven't, maybe you can refactor so they have.
Re:No amount of programming methology... (Score:2)
Not a complement.
Doing it over (Score:1)
Programs are no different--whenever you write a function or module, consider it a draft, and don't worry about throwing it away and writing it again. Too often I see people spending hours and hours trying to get acceptable behaviour out of their fundamentally flawed "first draft", when it would have been much simpler and easier to just toss the code and rewrite it, now that the problem is better understood. That way, when you're done, you have an elegant, easy-to-understand, simple program, instead of an inscrutable mess that "seems to work okay" (as far as your testing shows, anyway!)
D'Oh! (Score:2)
Re:No amount of programming methology... (Score:1)
;-)
The book covers this (Score:1)
It's a hard topic, especially since many of the best technical people are not the best politicians. How do we cope?
At one point, Fowler addresses the question of "What if your manager won't let you refactor?" His controversial advice is "Don't tell the manager you're refactoring." His justification is, you are a professional, you know what it takes to do your job, and if refactoring here and there is the right thing to do, just do it. When your development improves because the code improves, your manager won't complain.
I do "un-glowing" reviews (Score:1)
Re:I am stealing this! (Score:1)
>That's exactly the kind of comment that should never be written.
I would agree with you with this.
But what happens when you are working with a language and business requirement which really pushes the boundaries. (I asked a consultant if I could do what I wanted to do. Reply:"Why would you want to do this?" And then we proceded to spend 2 hours on how to do it without making it crash. I am forced to use this language because the customer requested it.)
It kinda hard to explain but the example is not what I did. It was a difference between comment/program like this _or_ risk running into a known issue in the programming language.
Some languages are not as nice as C. I would love it if I could have used C.
I think I'll shut up now before I get in trouble.
I do respect Waterloo grads. (Score:1)
>comments are not necessarily.
It was a first year course and it was mostly to explain to students what was going on. But coming from high-school it was quite abit of comments.
>why Waterloo produces better and more sought-after developers than UofT.
I know and worked with quite a few Waterloo grads and I must admit they are _all_ very nice people and good programmers. Considering that the university is in the middle of nowhere.
AntiPatterns (Score:1)
Another good book on this subject is AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (ISBN: 0471197130).
Re: C++ and elegance (Score:2)
the time is worth it in my opinion; laziness provides a powerful heuristic for attacking difficult optimisation problems efficiently: an application of haskell is in providing effiecnt dynamic prgramming solutions to NP hard optimisation problems, and then step-by-step transforming these into industrial strength `C' code. This strategy has produced some of the best solutions to the problem, because laziness captures a fruitful intuition about how to minimise resources in such problems.
If you are not enthusiastic about putting the time in, it is worth having a look at Objective CAML (`ocaml'), a language that combines an excellent marriage of objective and functional programming with one of the best development suites in functional programming. References to both can be found at the FAQ for comp.lang.functional [nott.ac.uk].
Of course both languages lack `prevalence', though that may change, since Simon Peyton-Jones, one of the chief architects of Haskell, has taken a post at Microsoft...
Re:The book covers this (Score:1)
Also, you won't achieve much if you are the only one doing it. If you're part of a 5 person team, and only your 20% of the code is refactored, you're not going to accomplish much.
My pessimistic view is that this just requires too long a view -- especially when most companies are only looking ahead a few months.
Re:'Well' architectured systems suck (Score:1)
The hard part is maintaining it.. (Score:1)
Once the documentation is not reliable, people will stop reading it, and it will grow obsolete at an ever increasing rate.
So I'm doubtful about this mechanical approach.
But any documentation that is in the code itself is always 10 times better than the one that is on it's own in a binder or web site somehwere. That stuff never gets either read or updated, and is just a pure waste of effort.
Re:Good book (Score:1)
When refactoring, you run unit tests. To finalize a refactoring, you must run a full test suite on the entire product.
This is all part of ExtremeProgramming.
Re:No amount of programming methology... (Score:1)
Sample:
foo++;
turns into
numSpecialFoo++;
Respect the Wiki! (Score:1)
Re:No amount of programming methology... (Score:1)
> not experts at coding. (eg 6months of simple programming from college)
I'm not advocating having no comments at all, which seems to be the way everyone's reading what I said. I'm simply saying that if you find you need to write two lines of comments per line of code something is definitely wrong. I used to write code like this, and it was a living nightmare to update later on.
Code sensibly; choose sensible variable and function names, comment at the beginning of function definitions explaining the purpose of the function and at the beginning of each logical block - a for loop, for example. If there are a couple of lines which need additional explanation, a comment there. I find that this works, and code I have written in this way is still actively in use and maintainable by others some six years on.
Again, the closer your code is to being self-documenting the easier it will be to maintain, irrespective of how many comments are in it. There is little worse, in my opinion, than finding code like:
a = a + b;
A well-commented line, to be sure. But what additional information does the comment pass on? If you're writing two comment lines per line of code, I can't see how you're avoiding stuff like this.
Simes.
--
Functional Languages (Score:1)
I have a background in computer science, and have studied dynamic programming, functional programming, etc.
You should check out C++'s standard valarray templated class. It is designed for optimum performance. Implementations typically use proxy objects for intermediate access and operations. This, in effect, means lazy evaluation. However, it's partly done at compile time, which effectively means performance.
Re:Old Ideas; Newly Codified (Score:1)
See my web page (Score:1)
http://www.cgocable.net/~mlepage/library.html
Of course not all are "must haves" but I did buy them all.
Comments are Like Newspaper Headlines (Score:1)
Good comments are like newspaper headlines -- they give you a quick summary of a section of code without having to read article (code) in detail.
Even though the article may be well-written, it still takes more time than the headline if all you want is the gist. Sometimes you are simply hunting for something and need a way to filter out the unlikely code "paths" faster.
Also, giving a "hint" before the actual code may make it's purpose jump out faster because you were prepared with the general idea.
Good commenting is art form, (just like programming itself.)
favorite computer books (Score:1)
I bought the book---it's worth it! (Score:1)
After reading this review I went to The Bookpool [bookpool.com] (where Refactoring is available for $28; sorry, Amazon) and ordered it. I've now had it a few days, sampled a number of sections, and started seriously on reading from cover to cover.
Maybe SEGV's seen something I haven't, but I'm tempted to give it at least 9.5/10, and thinking about more.
Yes, as many posters above note, I too have been refactoring for much of my career, to save my sanity if for no other reason. But I called it ``cleaning up the code'', and often couldn't articulate to my peers or bosses why it was the right thing to do. I was abstracting the form of the code, changing it to make it easier to understand. Fowler has abstracted the form of the changes, to make them easier to recognize and execute correctly. This higher level of abstraction is what makes the book worthwhile.
In addition, he's labelled and codified abstractions I haven't thought of, but which will be useful now that they've been brought to my attention.
It's also nice that he's given ``guest authors'' chapters to themselves, so we get different views of the subject. Fowler's upfront about what he owes to others in developing the concepts; he says they should have written the book, but since he's the one to get around to it, he's at least roped them in for their expertise.
All in all, if you ever have to touch sub-standard code, get and apply this book. I would have killed for this at my last job.