Tag Info

Hot answers tagged

36

Refactoring is cleaning up a piece of code (e.g. improving the style, design, or algorithms), without changing (externally visible) behavior. You write tests not to make sure that the code before and after refactoring is the same, instead you write tests as an indicator that your application before and after refactoring behaves the same: The new code is ...


9

Not really, because if there are 0 items, the setup of the foreach loop will find that out anyway and simply not execute the body of the loop. It's theoretically possible, in a very tight loop in which it's common for your collection to be empty, and in which finding the count is a very inexpensive operation, for there to be a noticeable performance benefit ...


9

Maybe try the builder pattern? (note: fairly random Google result :) var document = new DocumentBuilder() .FirstPageBlank() .Name("doc1final(2).doc") .MinimumNumberOfPages(4) .Build(); I cannot give a full rundown of why I prefer builder over the options you give, but you have ...


6

Ah, maintaining legacy systems. Ideally your tests treat the class only through its interface with the rest of the code base, other systems, and/or user interface. Interfaces. You can't refactor the interface without affecting those upstream or downstream components. If it's all one tightly coupled mess then you might as well consider the effort a ...


5

You're right when you tell that you may use the first approach before refactoring. While personally, I disagree with this approach, that's the rule of three from Refactoring by Martin Fowler (page 58): Here's a guideline Don Roberts gave me: The first time you do something, you just do it. The second time you do something similar, you wince at the ...


5

Refactoring just means making changes that improve readability but don't change the functionality of code. IDEs like eclipse will help you do it, but it doesn't have to be done automatically. Where refactoring comes into play in understanding other people's code, is when that code is very poorly written. Say you have a 1000 line function with a lot of ...


5

Some ideas; Clear, well understood, code structure. So that there's an 'obvious' place to put certain code, by folder location or namespaces; if it's a shared extension method for example, then you might find those in a Company.Common.Extensions location. Or set patterns for encapsulation, so that methods should be found inside a relevant type, not ...


4

My own answer/realization: From fixing various errors while refactoring I am realizing that I wouldn't have done the code moves as easily without having tests. Tests alert me of behavioral/functional "diffs" that I introduce by changing my code. You don't have to be hyper aware when you have good tests in place. You can edit your code in a more relaxed ...


4

I think the answer lies in between the two of you. Changes are to be expected as software evolves. No matter how competent you are, you can't predict the future with 100% accuracy. And even if you could, it may not match your customer's predictions or taste. Since he's the one who pays he (most unfortunately :) ) has a say in it. So unless it's dead simple, ...


3

@jwenting is right that the number of lines should not be the primary reason for refactoring methods. Nevertheless it is a often an indicator for a "code smell". And when the situation is so clear as in your logging example, where the SRP is clearly violated, the method should be refactored. So your main criteria for "when to refactor" should be the SRP ...


3

The only scenario I can think of where checking Count first would help performance is with a collection having a resource-hungry IEnumerable.MoveNext() implementation and yet an highly efficient ICollection.Count implementation. While it's technically possible, it's very unlikely that it would ever happen. In fact, on some scenarios, checking Count() first ...


3

Ultimately, the best answer is to actually test it. Make a method which loops over an empty array with and without checking the length first, call each 100,000 times and see which has a faster runtime. public void withCheck(Integer[] array) { for (int i = 0; i < 100000; i++) { if (array.length > 0) { for (Integer i : array) { ...


3

Refactoring is not limited to using IDE commands (although they help a lot in refactoring). This is the technical definition: "Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior." ([Wikipedia)1 Refactoring to understand code is when and while you are reading code, you ...


3

Use your tests to drive your code as you do it. In the of legacy code this means writing tests for the code you are going to change. That way they are not a separate artifact. Tests should be about what the code needs to achieve and not about the inner guts of how it does it. Generally you want to add tests on code that has none) for code you are going ...


2

You should test sufficiently to provide adequate code coverage. Sufficiently (and adequate) vary on the risk associated with an undetected problem in your code. The cost to fix a problem after development (assuming a classic SDLC) is significantly higher then the cost to fix during development, but the risk may be minimal. So, really that is another way of ...


2

Looking at the source code of System.Collections.Generic.List<T> we see that MoveNext() is implemented like this: public bool MoveNext() { List<T> localList = list; if (version == localList._version && ((uint)index < (uint)localList._size)) { current = ...


2

Embrace refactoring. Embrace the fact that you can create code that works, and you have tests that make it work, and then you can change the internals having confidence that you are not breaking anything. And as you mention, KISS. About the view of not having written/designed correctly from the start, for me the answer is that I have not worked in a project ...


2

I generally write enough tests to give me confidence that my implementation is correct, but no more than that. How many tests this is depends on the problem at hand. If you're feeling very unsure about the correct implementation of the behaviour, you'll probably end up writing a full set of tests for each endpoint and refactoring at the end: going from ...


1

My guiding principle here would be that test code has to meet the same level of quality as implementation code. If your test code can't reach that level, then something is wrong with the implementation design. In the specific context of a method that is now common to two classes, I would try to refactor that into a common class that both Class1 and Class2 ...


1

A method is too long that does more than it needs to do. Any blanket statement that "any method longer than XXX lines/statements is too long" is bogus, shows only that the author of the statement is a mindless acedemic with no experience writing actually productive software. It's all nice and dandy to claim that "anything that can be must be removed into ...


1

The benefit comes in the form of flexibility, but it has no performance benefit. When a foreach runs over an ICollection with count of 0, the enumerator will register as having already traversed the whole set. Functionally, it's similar to the following for loop: for(int i = 0; i > -1; i++) foo(); Now, if there is some other business rule that ...


1

It all come down to who writes better code relative to the amount of time. Your company/team should define what "better" means. Customers have something to say about this as well. Make sure you have a solid definition of Refactoring. It sounds like you do, but you mention it along with code behavioral changes very close together in your question. Be ...


1

Using a parameter object is a good way to avoid (excessive) overloading of methods: it cleans up the code seperates the data from the functionality makes the code more maintainable I would, however, not go too far with it. Having an overload here and there is not a bad thing. It is supported by the programming language, so use it to your advantage. I ...


1

The best thing I am aware of is communication. It contains some points: Almost all classes or functions I reused from other programmers inside a project, came to my awareness, because I was talking with them about some issue and therefore knew that they had written something for it. Code reviews and pair programming can reinforce this. Also the code has to ...


1

As asked in the title, you are probably looking for the Data Access Object pattern, that is also discussed in this StackOverflow question. The point is using software layers to separate the program logic from database structure, because this way you could change your database schema, the names of the tables, and modify a small and isolated part of your ...


1

What is the goal of refactoring in your specific case? Presume for the purposes of putting up with my answer that we all believe (to some degree) in TDD (Test-Driven Development). If the purpose of your refactoring is to clean up existing code without changing existing behavior, then writing tests before refactoring is how you ensure that you have not ...



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