Hot answers tagged

7

A longer definition can be found in Martin Fowler's Refactoring book (page xvi). Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you ...


5

This could be refactored in several ways with varying levels of elegance and intrusiveness. Do repetitive things in a loop The idea is simple: Put your values into arrays and use a loop to retrieve them. void logAnError(const std::string& message); bool hopefullyGetSomeData(const std::string& id, double& destination); bool ...


5

This is a common problem for maintainers of old/legacy code, and there is no single perfect answer. Before making the decision to replace working code, I would propose trying to answer these three questions. Is it possible? Can you devise a method whereby existing instances of the 'old way' can be reliably replaced by the 'new way' such that each change is ...


3

My question is more aimed at whether it is important to find the offending bug - and if it is, why? There are a couple of advantages to finding (not necessarily fixing) the bug. Without finding the bug, it is impossible to find the root cause. Was it a stupid typo by an overworked tired intern in an all-nighter before a looming deadline? Or was it ...


3

Well, it depends on how important it is for your company to get the authentification working again with the existing component, and if you can expect to do this significantly faster than replacing the component. If you can repair the system in two days, but exchanging the old component by the new takes you two months, you should probably consider to repair ...


2

The main advantage of doing this replacement would be the cost of bringing in new people. If you bring in a new C++ programmer, they will have to learn the particulars and vagaries of your smart pointer. Whereas if you used unique_ptr, there is a reasonable chance that they already know its peculiarities. And if they don't, then there's an entire Internet ...


2

Top Down is when you take the whole problem and break it down into smaller and smaller problems until you get to the bottom where you have lots of actual implementation details. Bottom Up is when you create lots of small, detailed building blocks that are generally useful and that can be assembled together to solve larger and larger problems. Top down is ...


2

I think top down aproach are more a re-design than a mere refactoring. From my experience refactors are usualy somehow a re-organization of the existing code. Its a low scale re-design. So you get complexe features that already meet their proposals but are not flexible enough and hardly re-usable. And you split its feature into small subprocess. The best ...


1

The typical way to simplify this sort of code is to create an "empty" resolved promise that you can use in place of the "real" promise if you don't need to get() the url. I don't use jQuery much, but I believe that would look like this: var promise = condition ? $.get('url') : $.Deferred().resolve().promise(); promise.done(function () { done(); }); ...


1

I'm just going to assume that your bisect() function is a method of the class you mentioned and that it looks similar to this: def bisect() while self.word_wrap() == False: pass As far as the word_wrap() method is concered, I would propose to break it up into smaller methods because small methods are: 1. Easier to Test Imagine writing a unit ...


1

This is a problem for many legacy systems. On one hand, this custom std::unique_ptr-like capability has been around for a long time. Bugs were wrung out long ago, and people on the project know how to use it. "It ain't broke, so don't fix it". On the other hand, it is broke in a sense. One of the biggest challenges facing older solutions to some problem is ...



Only top voted, non community-wiki answers of a minimum length are eligible