Study: Refactoring Doesn't Improve Code Quality 247
itwbennett writes: A team of researchers in Sri Lanka set out to test whether common refactoring techniques resulted in measurable improvements in software quality, both externally (e.g., Is the code more maintainable?) and internally (e.g., Number of lines of code). Here's the short version of their findings: Refactoring doesn't make code easier to analyze or change (PDF); it doesn't make code run faster; and it doesn't result in lower resource utilization. But it may make code more maintainable.
Maintainable... (Score:5, Insightful)
Re: (Score:3)
and creating code which can be easily refactored is, itself, the key to maintainable code.
Re:Maintainable... (Score:5, Insightful)
The study sounds like nonsense (at least as presented in this post).
Refactoring doesn't make code easier to analyze or change.... But it may make code more maintainable.
What is code maintenance, if not analyzing and changing the code??!?!
Does code in Sri Lanka need to have its oil changed and tires rotated?!
Re: (Score:2)
on *average* (Score:2)
Re:on *average* (Score:5, Insightful)
It needs a lot more qualifiers than that.
For a start, as with an unfortunate number of academic studies, it appears that the sample population consisted of undergraduates and recent graduates. That alone completely invalidates any conclusions as they might apply to experienced professionals with better judgement about when and how to use refactoring techniques.
Even without that, there seem to be a number of fundamental concerns about the data.
One obvious example is that they consider lines of code to be a metric that tells you anything useful beyond the width you need to allow for the line number margin in your text editor. I doubt most experienced programmers would agree that a LOC count in isolation tells us anything useful about maintainability or that the mere fact that LOC went up or down after a change necessarily meant the code had become better or worse in any useful sense.
Another concern is that they talk about "analysability", but this seems to be measured only by reference to a brief examination of a small code base in one of two versions, unrefactored and refactored. I'd like to know what the actual code looked like before I read anything at all into that data -- what refactoring was performed, what was the motivation for each change, and how do they know those two small code bases were representative of either refactoring in general or the effectiveness of refactoring on larger code bases or code bases that developers have more time to study and work with?
I'm all for empirical data -- goodness knows, we need more objective information about what really works in an industry as hype-driven and accepting of poor quality as ours -- but I'm afraid this particular study seems to be so flawed that it really tells us very little of value.
Re: (Score:3)
I read a bit of it looking for actual meaningful numbers, but it was clear to me that none of the people involved or focused worked on multi-million line projects. I am almost choking on my tongue thinking "Imagine the code quality of a web browser if the code wasn't regularly refactored to reduce the number of possible bugs?
Every
Re: (Score:2)
Re: (Score:2)
The framing strongly suggests that it is a simple issue.
It is a simple issue - "this 'study' is crap."
Re:Maintainable... (Score:5, Insightful)
For most software projects maintainability is THE most important thing for TCO (over 90% as per the article) and thus the MOST important thing. Also I find it hard to believe for your average "REAL" project (i.e. far more than 4.5k of code) changeability and maintainability are not intertwined. Any study arguing otherwise needs it methodology closely inspected.
Technical Debt is real, obvious and accumulates exponentially with the amount of code involved over time. This is what we are talking about here when we talking about being able to change it and maintain it. There is lots of research on this and any experienced enterprise developer will have seen this in action.
MAJOR problems with this study:
- They used Students. If you don't know why this is bad there is no hope for you.
- 4500 is barely a code base at in the real world.
- Debt accumulation is worst over long periods of time and many iterations/changes. This is not commented on at all when describing the example. (NB: From my speed read)
So take this all with a grain of salt. This is a very limited academic paper and not at all definitive or real world applicable in of itself...
Re:Maintainable... (Score:5, Interesting)
The biggest problem with the study is it seems to miss the whole point of refactoring code http://en.wikipedia.org/wiki/C... [wikipedia.org]. It is not about one project, it is all about a coding company and the code it produces over the life time of it's existence, about all of it's projects, past present and future. Is refactoring a technical waste for one project, depends upon the qualities of the initial code produced. Is refactoring a waste over 100 different projects over ten years, of course not and often because far less refactoring effort will be required for latter projects than earlier projects and those latter projects will be far more efficient.
It is much like the principles of TQM http://en.wikipedia.org/wiki/T... [wikipedia.org]. Does Total Quality management work for one project, rarely the administrative costs will readily out weigh the benefits because there is little or no opportunity to apply the improvements provided by TQM. Will TQM provide benefits for hundred projects over ten years, of course because. As there is plenty of opportunity to apply the benefits gained from the administrative efforts expended on TQM.
Re: (Score:2)
Re:Not true (Score:4, Interesting)
Re:Maintainable... (Score:4, Insightful)
...is pretty important, and you should refactor when needed if only just for that. It'll spread all over rest of the code in many ways, in good ways.
Exactly, and that good way is reliability which is something I observe the study doesn't measure so whilst it's good to challenge the current wisdom, there seems to be a few holes here.
First up I don't think 4500 lines of code is a good was to asses the interaction complexity of applications where the codebase exceeds 10 or 20 times that number. Second I may write a functional prototype of code knowing full well that I or someone else will refactor later when we have a better idea of how things are functioning.
Unexpected failure modes are going to exist in the software. The whole point of doing things the 'Agile' way is to provide incremental improvement so things get better. The paper talks of XP but what if you are using DSDM instead of programming pairs, in that case you are *expecting* to refactor often as you explain the domain or new concepts are introduced. That's not scope creep, it's being honest and admitting you don't know everything.
In my experiences the most powerful concept is the vocabulary you build as you begin to understand the domain better. I've found refactoring is the opportunity to 'put things in the right place' to define the vocabulary which makes things easier on myself and my colleagues a year or two later when someone asks if they can have this extra feature. Sure we should be using certain design patterns when implementing code from the beginning however I'm certain I'm not alone in confronting a codebase and wondering why certain methods are implemented in the controller instead of an information expert and spending the next week refactoring to avoid peoples heads exploding when methods are duplicated...but they don't work the same.
that's my 2 cents...
Re: (Score:2)
It's important, and it's always been the main reason to re-factor. It's also strange to say that Maintainability is improved, but changing the code is not, since code maintenance isn't really maintenance, it's just changing the code. It's not like code wears out over time through too much use.
Re: (Score:2)
Refactoring done right happens as you go (Score:3)
Refactoring for the sake of refactoring is often wasted time for the original author for there is ways of understanding code past just nice variable names and indentation. Sometimes even badly formatted code stands out and reminds you what it did to remind you of how it works. But when you code in a group, this doesn't hold true and a refactor can help.
Re: (Score:3, Insightful)
I'm not sure I can trust the coding advice from a person who thinks all the predictions in the bible have been, or will be proven to be 100% true (meanwhile claiming all other belief systems have been proven to be fakes). There are a lot of "religious" programmers out their who are sure that their preferred language, design pattern, or style is the only good one, and all others are terrible, even without bringing in actual religion.
If a scientist were to tell me he is 100% sure that the planes that crashed
Re: (Score:2)
I'm not sure I can trust the coding advice from a person who thinks all the predictions in the bible have been, or will be proven to be 100% true
One of the smartest men to ever live (Isaac Newton) was deeply religious, believed in scientific studying of the Bible, alchemy, and plenty of other ridiculous things. I'm as atheist as they come, but I still understand that very smart people can still have very ridiculous beliefs. Being religious in no way means you cannot refactor code properly.
Re: (Score:2)
WTF does this have to do with the bible? There are SO MANY things wrong with this that you could attack, but you chose prior posts?
Go fuck yourself with a sideways with a rusty rake.
Re: (Score:2)
You are not using logic. You only think you are
I am expressing an opinion.
In actuality, you are cherry-picking to discredit him to fulfill your own bias.
I'm not sure what "fulfilling one's bias" means, but at no point did I claim to be unbiased. In fact I think it was pretty clear that I was presenting my bias openly.
If you actually gave a shit about him, you'd read through his other posts, not just a simple click of his signature.
It's not just his signature. It's also his username and his domain name. It seems pretty clear that he wants to be identified with the statement on his website.
In short, using someone's religion or other personal choices to detract from their words is the act of a petty, scared individual, incapable of debating in professional terms.
I wasn't using his religion detract from his words. I am using his words to detract from his credibility as a person with good analytical ability.
You might as well be deriding a programmer for being gay, or a woman. Rewrite your post using one of them, and you clearly come off as a bigot.
That's ir
Re: (Score:2)
Re: (Score:2)
What do you mean by "memory architecture"? I am willing to suspend my disbelief that someone who believes they have directly communicated with a metaphysical entity couldn't give me advice concerning programming.
From the context, I gather that maybe what he meant to say was "data structures"?
Re: (Score:2)
Hence the title of Wirth's book, Algorithms + Data Structures = Programs. I think it was my second semester CS text (nigh on nearly forty years ago).
Re: (Score:3)
"Memory architecture" -- you mean data structures?
As the title of my old intro CS text put it, "Algorithms + Data Structures = Programs". Yep, one is clearly going to influence the other, and sometimes a minor tweak in one will vastly simplify (or complicate, if you do it wrong) the other.
Refactoring isn't merely reformatting -- a prettyprinter can do that -- but it can help give you insight into the code. After getting the code right I like to refactor to see how much code or useless variables I can ge
Re: (Score:2)
When you code, the most important thing to do is get your memory architecture built right, then methods just write themselves. Come back later and want to make a better method, you can use your old code as a partial refactor. It is an agile sort of run and gun approach and it works. Refactoring for the sake of refactoring is often wasted time for the original author for there is ways of understanding code past just nice variable names and indentation. Sometimes even badly formatted code stands out and reminds you what it did to remind you of how it works. But when you code in a group, this doesn't hold true and a refactor can help.
But I never write badly formatted code.
Of course part of the reason is that I refactor as I write. Like battle plans never surviving contact with the enemy, software designs rarely survive contact with the code. As I'm writing the code I find holes in requirements that force a new plan. I refine method signatures to reduce dependencies. In short, I'm learn more about what I'm writing as I write it. It only makes sense refactor as I go. And sometimes I have to finish writing something before I ca
Re:Refactoring done right happens as you go (Score:5, Interesting)
Of course part of the reason is that I refactor as I write.
I'm not sure what that has to do with writing "badly formatted code", but I'd still caution against that. Some of the best advice I ever received: "There are no good writers, only good rewriters." I've found this to be true for code as well. It's amazing how much you can improve your code once you've distanced yourself from it a bit.
Easier to Analyze or Change == More Maintainable (Score:5, Insightful)
Re: (Score:2)
Isn't refactoring when you start doing the optimizations that were premature before, when you just wanted something that ran?
Re: (Score:3)
I hope not.
Re: (Score:2)
No. Refactoring is when you take the awful, unmaintainable spaghetti code you produced when you were in a deadline crunch and convert it into something maintainable. The goal is to restructure the source code without changing the functionality at all.
Re: (Score:2)
So I have a method that brute forces something, then I go back and figure out how to do it with a better big 0, and the functionality doesn't change, but that still isn't refactoring, because ... ?
Re: (Score:3)
So I have a method that brute forces something, then I go back and figure out how to do it with a better big 0, and the functionality doesn't change, but that still isn't refactoring, because ... ?
That is generally considered optimizing, not refactoring. By some definitions of refactoring I guess all optimizations are a form of refactoring, but that is almost never what someone means when they say refactoring.
Re: (Score:3)
So I have a method that brute forces something, then I go back and figure out how to do it with a better big 0, and the functionality doesn't change, but that still isn't refactoring, because ... ?
Because it violates the standard definition of "refactoring".
Refactoring is about changing the structure of the code, and not the algorithms used within the code. The goal is typically to reduce coupling, increase cohesion, and (frequently) to improve testability.
Replacing an algorithm with a better algorithm isn't "refactoring", it's "rewriting".
Taking your giant brute-force method and breaking it into smaller parts in a cohesive unit (source file, class, package, etc.) with lowered coupling (perhaps by g
Re:Easier to Analyze or Change == More Maintainabl (Score:5, Insightful)
Nope, it's when I take the awful, unmaintainable spaghetti code someone else produced when they were in a deadline crunch and convert it into something maintainable.
Sigh... I wish I could say that with a straight face.
Interestingly, in my experience, poorly structured code seems to come about often less often because of "rushed code" but instead a lack of foresight in the original structure of a system to deal with continuously evolving features (which happens in most projects), along with a lack of willingness to refactor those systems as soon as it's apparent it's starting to break down.
This is the "golden time" to refactor code, because it's just now become apparent where the structural flaws are in the architecture, but it's still early enough to refactor without causing a significant amount of pain. It's often hard to justify, because you've only got a couple of ugly special cases that complicate things here and there. However, if you procrastinate too long, you're going to start piling on more and more "ugly special cases", and the code is going to get harder and harder to read and maintain.
Re: (Score:3)
This is the "golden time" to refactor code, because it's just now become apparent where the structural flaws are in the architecture, but it's still early enough to refactor without causing a significant amount of pain.
It can also be the golden time because the original writers are still around and know why certain things were done a certain way, and know what dependencies need to be addressed.
Interestingly, in my experience, poorly structured code seems to come about often less often because of "rushed code" but instead a lack of foresight in the original structure of a system to deal with continuously evolving features...
In my opinion poorly structured code too often comes from individual developers who just don't care. They show up to do a job and get paid; they got into CS because it was a way to make money; they don't really care about doing things elegantly. Or perhaps they care about quality but just don't understand the benefits of refactori
Re: (Score:2)
Refactoring is the action of reviewing the code and re-writing it (internally only). Refactoring is in most cases done to increase readability and reusability (once again, internally only) which usually results in better maintainability. A by products of refactoring is detecting defects and optimization opportunities.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Re:Easier to Analyze or Change == More Maintainabl (Score:5, Insightful)
Yeah. The conclusions are nonsense piled on more nonsense. Plus it is plain bullshit. Imagine I only refactor by removing duplicated code across functions or different compilation units. Will the compiled code size become smaller? Yep. Will be easier to read (less LOC to read)? Yep. Will it be more maintainable? Of course you have less code to bother with.
Re:Easier to Analyze or Change == More Maintainabl (Score:5, Insightful)
My thoughts exactly. More maintainable code IS higher quality code, in my opinion.
Making code run faster has a completely different name, it's called optimization (and is frequently the root of all evil). And it often involves the exact opposite of things you do when refactoring. Eg, unrolling a loop to make it run faster is pretty much the exact opposite of refactoring for maintenance & readability.
Re: (Score:2)
who in the world ever though that refactoring would make code run faster?
Well if you were refactoring a brain dead method into something that had more smarts it is possible for the refactored code to run faster.
Re:Easier to Analyze or Change == More Maintainabl (Score:4, Interesting)
I once took over 30,000 lines of code that had been written by a subcontractor and trimmed it to around 4000 LOC. And you better believe it ran faster! Not because refactoring is magic, but because once all the mind-numbing almost-repetition was mucked out you could actually see what the code was doing and notice that a lot of it wasn't really necessary. Ever since then I have always maintained that coders should never ever copy and paste code. I've had people disagree, saying that a little bit of copying and pasting won't hurt, but I say if it's really such a little bit then you shouldn't mind re-typing it. Of course if you do that very soon you start putting more effort into devising ways to stop repeating yourself, which is exactly the point. Repeating yourself should be painful.
That's I think a reliable litmus test for whether you should refactor a piece of software. If it's an area of code that's been receiving a lot of maintenance, and you think you can reduce the size significantly (say by 1/3 or more) without loss of features or generality you should do it. If it's an area of code that's not taking up any maintenance time, or if you're adding speculative features nobody is asked for and the code will get larger or remain the same size, then you should leave it alone. It's almost common sense.
I don't see why anyone would think that refactoring for its own sake would necessarily improve anything. If an automotive engineer on a lark decided to redesign a transmission you wouldn't expect it to get magically better just because he fiddled with it. But if he had a specific and reasonable objective in the redesign that's a different situation. If you have a specific and sensible objective for reorganizing a piece of code, then it's reasonable to consider doing it.
Re: (Score:2)
Who? Quants?
That is, Quantitative Analysts. And it's kind of their job to say whether we, as coders, improve things by refactoring.
Should we bill the client those hours, or suck them up as something we were initially paid to do? Lots of arguments here, but there is a study that claims to have an answer.
How can anyone say?
Obviously, stats. How? Depends on stats.
You shut your mouth, How can you say I go about things the wrong way? I am human and I need to be loved Just like everybody else does.
New study shows taking medicine is ineffective. (Score:5, Insightful)
Whathuh? (Score:5, Insightful)
Isn't the very *definition* of making code more "maintainable" that it makes the code "easier to analyze or change"?
Re: (Score:2)
Re: (Score:2)
Or it makes the developer's intimately aware of all the different places it can break and the places you need to make changes. And since they wrote large portions of it they grok the flow from a high-level ...
That is to say, you can make the code more maintainable without changing a single line. Another example is documentation changes or environment/setup like dev instances.
Re: (Score:2)
Isn't the very *definition* of making code more "maintainable" that it makes the code "easier to analyze or change"?
No, judging from common usage, "maintainable" actually means "my favorite flavor of 'object oriented'".
It has no real world correlation with actual ease of maintenance.
Re: (Score:2)
Refactoring is more than changing names.
Re: (Score:2)
No shit (Score:2)
Re: (Score:2)
"Refactor" implies simplification, not optimization. Given all the disagreement here, maybe we should stop using such an imprecise term and just go with "rewrite".
Re: (Score:2)
Shh. Don't say "rewrite". Managers heard that was a dirty word. That's why we give them a vague, important sounding "methodology" called "refactoring".
Re: (Score:2)
I don't think refactoring implies simplification. I think ideally it would simplify something about the code (e.g. semantics, interoperability, etc), but it will likely make some parts of the code more complex (e.g. more levels of abstraction, or a more complex design patterns, etc)
Refactoring definitely doesn't imply optimization.
from wikipedia
Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior. Refactoring improves nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity to improve source code maintainability, and create a more expressive internal architecture or object model to improve extensibility.
Re: (Score:2)
^^^ Ok, here's the definition people. Mod this up so the arguments can stop over what it is.
car (Score:5, Insightful)
Car repair does not make car faster, nor more comfortable.
Re: (Score:2)
I can think of plenty of car repairs that can make your car faster and more comfortable. Fixing broken A/C would make most people more comfortable. As would fixing a bad power steering pump, fixing warped rotors, etc. And if your engine isn't running, then your car is by definition not fast, so repairing that will make your car faster.
But "repair" and "refactor" are hardly the same thing. I'm sure automotive companies refactor their car systems all the time.
Re: (Score:2)
Re: (Score:2)
Car repair does not make car faster, nor more comfortable.
Well, sometimes it can. An engine or transmission in poor condition can slow down a car's uphill performance. A broken heater will make a car less comfortable in the winter. Repairs will correct these problems.
And so it goes with software refactoring. Removing redundant calculations and data-reads (e.g., out of loops) where possible will improve performance. Changing names of variables, functions, classes, etc., to reflect their use more closely will improve readability (or "comfort" if you will.)
Good car a
Re: (Score:2)
You don't usually do car repair unless something is not working..
Re: (Score:2)
The car repair analogy isn't a good one. A better analogy would be to compare it to the engineering design process to make the car.
Refactoring is the action of reviewing the code and re-writing it (internally only). Refactoring is in most cases done to increase readability and reusability (once again, internally only) which usually results in better maintainability. A by products of refactoring is detecting defects and optimization opportunities.
Key here is that the process may reveal optimization opportuni
Re: (Score:2)
Oh my god. If I could up-vote this answer a thousand times, I would! You made my day :)
A study just to support its own hypothesis (Score:3)
May, may, may ... (Score:2)
But it may make code more maintainable.
Stating that something "may" do something, without additional qualifiers, is really no statement at all.
Procedural to Object Code (Score:5, Informative)
Re: (Score:2)
^^^ mod up. This is a good summary of what actually happened.
Re: (Score:2)
Correct. And now they have the data points to prove that. Might as well since they were testing, as recording the timings is a fairly trivial task.
Re: (Score:2)
xkcd has a good strip where zombie Feynman extolls the virtues of Mythbusters, stating that experimentation is at the core of science. And I notice in astronomy various projects are still confirming various parts of Relativity, even ones that have been proven before in different circumstances.
empirical evidence (Score:2)
If my code looks scruffy then I refactor it. When I come back to it, I can read it better. That's a
If you hire coders in Sri Lanka... (Score:2)
Re: (Score:2)
Totally meaningless paper (Score:3)
Sorry, but it has absolutely nothing to do with the real world. They're giving twenty people - ten in experiment group and ten in the control group 30 minutes to do a bit of analysis. And they measure minutes to apply a few changes, without any qualitative measure on how the code is growing. There's very little proof that the refactoring they did made any sense, the sample size is so low you'd never get reliable results and pretty much what you can conclude is that refactoring doesn't make hackjobs easier. Never thought so, that just involves finding the place something's happening and hack it. If it's a good idea, well... it works there and then.
Not significant - ignore (Score:5, Insightful)
I wouldn't call that study publish worthy.
It certainly isn't statistically significant. 4,500 lines of C# code is nothing. I work with systems that have millions of lines of code. I've seen single class files that have thousands of lines of code (and vomited when I saw it). An important question here would be whether the volume of code in a system is a significant factor in the value of refactoring.
Based on their own statistics the refactoring was poorly done. Their result was more code, more complexity, and more coupling. Certainly not the work I would expect from an experienced software developer, but certainly something I would expect to see from undergraduate students who don't fully understand what they are doing.
I think the last sentence in the actual study sums it up pretty well - "Furthermore, it would be better that the same
experimental setup can be executed in industry environment with the industry experts and with
the industry level matured source code."
Re: (Score:2)
Well, it's a first step. Industry can take it from there if they want, and adapt the experiment to their particular situations.
Re: (Score:2)
I will take well written procedural code over poorly implemented OO any day... not to mention that I can't remember a single time where I refactored and the LOC wasn't significantly reduced.
Needs a larger sample size (Score:4, Insightful)
That's hilarious, I have web apps (I'm stuck with) having individual pages larger than that, including tons of other crap. Refactoring allows following the DRY principle and removing duplicated code. It allows moving SQL statements all the heck over the place into single places where they can easily be tested and updated when bugs are found.
They're basically working with a program that's not really that awful in the first place and making it a little bit nicer. How about starting with absolute junk and making it useable? Unmaintainable code is a consequence of technical debt, refactoring pays that debt down and keeps things manageable. Sure you may not need to refactor right now, but taking the time to do it once in a while keeps things from getting out of control.
The paper is BS... (Score:2, Insightful)
There are so many problems with that study.
First, they use C#. There is no reason to think that it's not language independent.
Second, All the code was from one code base with 4500 lines! How can you extract anything statistically significant from basically 1 data point!
Third, supposedly 10 canonical re-factoring techniques were used. Could it be that these re-factoring techniques are useless? Of course, they are not discussed at all in the article. We don't know what re-factoring techniques they used (
Re: (Score:2)
"Bad smell" is a (silly, I'd agree) term of art. You know it when you look at code, wrinkle up your nose and go "eww".
I just call it ugly code.
Improving crap code (Score:5, Insightful)
I've seen the before-and-after when crap code was rewritten and refactored by hand by a good coder.
The improvement was huge.
Was it better than if the same coder wrote the code "from scratch" from the problem-description or design document? I don't know, but my point is that crap can be turned into gold by a good coder, and that refactoring can be part of the cleanup.
Refactoring does not mean superior - it depends... (Score:2)
Refactoring is something you should think of whenever you revisit your code to make changes as you are developing. Can I do this better? I don't know many programmers that write something once and it is perfect. Sure you can come back to it and make some changes that are necessary and do no thinking about anything o
Study: This Study Is BS (Score:4, Insightful)
Making a judgment about "refactoring" as a single, simplistic concept is like making a judgment about "food" or "government" without going into any further detail. Umm, it's kind of not that simple.
Refactoring in real life is a whole array of different, nuanced activities. Any of them can be wise or foolish depending on the situation. Well-written code requires less of it, but some degree of it will always be needed as we can't tell the future. Each instance is a judgment call with no concrete right answer.
Narrow Subject (Score:2)
The study was over a single application. From the article:
The researchers selected a small-scale application (about 4,500 lines of C# code) used by the academic staff at the University of Kelaniya for scheduling events and managing online documents for evaluation. 10 common refactoring techniques were applied to the code (e.g., Replace Type Code with Subclasses, Replace Conditional with Polymorphism).
Not only did they study just one application, but they limited refactoring to these 10 fancy techniques specific to object-oriented programming (from the research paper itself):
R1- Introduce Local Extension
R2- Duplicate Observed Data
R3- Replace Type Code with Subclasses
R4- Replace Type Code with State/Strategy
R5- Replace Conditional with Polymorphism
R6- Introduce Null Object
R7- Extract Subclass
R8- Extract Interface
R9- Form Template Method
R10- Push Down Method
In contrast, here are some things I do when refactoring:
- escape HTML in variables before embedding them in HTML, to seal against scripting attacks
- rewrite database queries to use parameters, instead of variables directly from user input, to seal against SQL injection
- move r
Completely misses the point (Score:3)
The #1 reason to refactor is to make code testable. The standard recipe is dependency injection with an IOC container, resulting in no live constructor calls, no dependency issues when a constructor changes, and decoupled dependencies. It's not a magic bullet but it's a big step in the right direction. Interestingly, testable code can have no tests and still be higher quality as a result.
To which I say, "duh?" (Score:3)
from my blog on this, just now:
Proponents of refactoring have never ever said otherwise (unless they themselves are confused on the matter). Code is only readable if it is either simple, or clearly follows design patterns, or is clearly commented and the comments are up to date with the current version of the code. Code is only easy to change when it is readable and when all external dependencies are well known. That last part is a key thing that metrics aren't necessarily able to capture.
A refactoring project, if not refactoring to the right design patterns to address what was wrong with the structure in the first place, is not going to improve it. One must know clearly why the current structure is making a bug-fix or a new feature difficult to implement.
And while some refactorings are 'good' in that they reduce a lot of copy-paste code, others are good because they add code, or add classes (an alternative increase in complexity). Different refactorings have different effects, and are used in different situations.
And as always, if you don't need to refactor, don't. A refactoring is to improve the design, not to rewrite for its own sake.
And there-in lies the great flaw of the whole idea of such a study: you can't measure the quality of a software design. Some things you just have to judge for yourself, based on experience and attention, and no arbitrary metrics number will ever differentiate between a good design and a rubbish heap.
Disclaimer: I hate software metrics.
Refactoring often done for understanding (Score:2)
Two birds, one stone (Score:2)
1. When you refactor, you look over your source.
Programming is like any other kind of writing. The more you proofread, the more error-free your resulting work will be. While refactoring if all you're doing is copying and pasting code around, then sure, it does no good. But if you're paying attention to the code you're working with then you're also proofreading.
2. Improved interface = improved code.
The end functionality is not all that m
Re: (Score:2)
Refactoring a good algorithm that's written in spaghetti code on the other hand...
Re:Well DUH... (Score:4, Interesting)
Re:Well DUH... (Score:4, Insightful)
The compiler is what makes the final decision on the code, not the programmer.
Just refactoring a poor algorithm will still result in a poor performance, though the code might look better.
The whole point of refactoring in most cases is to make the code look better, not to improve performance. Very rarely do people change an algorithm as part of refactoring. The goal is instead to make the code easy to understand, easy to change, and easy to debug. Creating consistent names and API patterns, re-ordering statements to group them based on the task they're performing, finding code that is the same in many different methods and moving it into its own method, reducing dependencies between classes.... these are common refactoring techniques and have almost nothing to do with performance.
Re: (Score:2)
Bingo!
Re: (Score:2)
Re: (Score:3)
Single functions with more than 4500 lines? Sounds like a good time to do some refactoring, that sounds hard to follow and probably should be broken down. We have a 100 line max standard where I am at now.
Re:This should not be on the front page (Score:5, Interesting)
10,000 line functions are shockingly common in industry. Shit grows over time, and is so poorly written that you can't safely refactor it, and management lacks the balls to let you clean it up, so it just festers and festers.
I hear PayPal had 90% of their processing business logic in a single, multi-million-line class! Thankfully, I don't know that one first hand.
Re: (Score:2)
I could believe 10 kloc (kilo lines of code) functions being created by some front-end automated code generator (like a gui builder or parser generator, etc). If anyone is hand-coding 10 kloc functions they should be taken out and shot, or at least have their fingers broken so they don't do it again.
And while a multi-million-line class certainly seems excessive, that says nothing about how it's broken down into members and methods and inner classes.
Re: (Score:3)
Tech debt is like credit card debt: the interest is a bitch. I worded for a while at one company that nearly folded because the time required for emergency bug fixes grew to, then past 100% of development time for the team. Horrible code doesn't just require more bug fixes in the first place, each change grows progressively more expensive and unsafe.
10k lines of shipped, production code is only of value if it's working bug free and without complaint. 10k lines of buggy code, that you have to add a week to
Re: (Score:2)
Re:This should not be on the front page (Score:5, Interesting)
About 5600 lines. However, because it was a glorified case statement, you were really only debugging a single case at a time, each of which was about the length of a sane function, so splitting it into functions would do little to improve readability. I like to trot out that example to terrify people, but the function itself was really quite sane and easy to maintain.
You did, however, have to fully understand the state machine as a whole, which in total was almost twenty kloc, had almost 200 instance variables in the state object, and leaned heavily on a tree object with about 30 instance variables. That's the point at which most people's heads exploded.
Either way, 4,500 lines is the size of a fairly straightforward iOS app. Most folks can dig into that and figure out enough to maintain it without spending a huge amount of time, even if the organization isn't ideal. When you hit tens of thousands of lines, that's where you have to start thinking about how you organize it and document it, because with such large projects, if you jump into the middle without a complete picture, you're likely to be hopelessly lost.
Re: (Score:3)
I'd rather have a readable and maintainable 4500-line function than an unreadable and unmaintainable 45-line function.
I remember, years ago, standard advice to students to break up code in to functions when some process got over some number of lines. Know what we got? A lot of really odd functions of similar length, as they broke things apart at seemingly random boundaries! I'm still deeply suspicious when I hear people talk about a proper length for functions.
It's time to let that one go, and teach stude