EzDevInfo.com

How do you stop yourself from refactoring working-but-awful code? [closed]

I have this problem. I can't stop myself from refactoring existing code that works but is, in my opinion (and perhaps objectively), badly designed or contains other "code smells". This can have a significant negative effect on my immediate productivity. But ultimately will be a big maintenance boon.

If you also suffer from this "affliction", how do you restrain yourself? Or at least manage the refactoring to avoid having to alter large chunks of existing code in order to make it maintainable for the long term.

Unit testing for C++ code - Tools and methodology

I'm working on a large c++ system that is has been in development for a few years now. As part of an effort to improve the quality of the existing code we engaged on a large long-term refactoring project.

Do you know a good tool that can help me write unit tests in C++? Maybe something similar to Junit or Nunit?

Can anyone give some good advice on the methodology of writing unit tests for modules that were written without unit testing in mind?

Find and replace Android studio

Is there a way to find and replace all occurrences of a word in an entire project( not just a single class using refactor -> rename) and also maintain case, either in android studio or using a command line script?

For example, Supplier has to go to Merchant, supplier -> merchant, SUPPLIER -> MERCHANT. My boss wants me to change all instances of supplier with merchant for a project im working on. Ive been doing it for about an hour and i know im wasting my time. Let me know of any time saving suggestions. Thanks in advance!

C/C++: Detecting superfluous #includes?

I often find that the headers section of a file get larger and larger all the time but it never gets smaller. Throughout the life of a source file classes may have moved and been refactored and it's very possible that there are quite a few #includes that don't need to be there and anymore. Leaving them there only prolong the compile time and adds unnecessary compilation dependencies. Trying to figure out which are still needed can be quite tedious.

Is there some kind of tool that can detect superfluous #include directives and suggest which ones I can safely remove?
Does lint do this maybe?

Is it OK to have a class with just properties for refactoring purposes?

I have a method that takes 30 parameters. I took the parameters and put them into one class, so that I could just pass one parameter (the class) into the method. Is it perfectly fine in the case of refactoring to pass in an object that encapsulates all the parameters even if that is all it contains.

Method can be made static, but should it?

Resharper likes to point out multiple functions per asp.net page that could be made static. Does it help me if I do make them static? Should I make them static and move them to a utility class?

Find unused classes in a Java Eclipse project

I have a large Eclipse project in which there exist several classes which, although they ceased to be used anywhere, were never marked @Deprecated.

How can I easily find all of these?

Find unused code [closed]

I have to refactor a large C# application, and I found a lot of functions that are never used. How can I check for unused code, so I can remove all the unused functions?

When is it good (if ever) to scrap production code and start over? [closed]

I was asked to do a code review and report on the feasibility of adding a new feature to one of our new products, one that I haven't personally worked on until now. I know it's easy to nitpick someone else's code, but I'd say it's in bad shape (while trying to be as objective as possible). Some highlights from my code review:

• Abuse of threads: QueueUserWorkItem and threads in general are used a lot, and Thread-pool delegates have uninformative names such as PoolStart and PoolStart2. There is also a lack of proper synchronization between threads, in particular accessing UI objects on threads other than the UI thread.

• Magic numbers and magic strings: Some Const's and Enum's are defined in the code, but much of the code relies on literal values.

• Global variables: Many variables are declared global and may or may not be initialized depending on what code paths get followed and what order things occur in. This gets very confusing when the code is also jumping around between threads.

• Compiler warnings: The main solution file contains 500+ warnings, and the total number is unknown to me. I got a warning from Visual Studio that it couldn't display any more warnings.

• Half-finished classes: The code was worked on and added to here and there, and I think this led to people forgetting what they had done before, so there are a few seemingly half-finished classes and empty stubs.

• Not Invented Here: The product duplicates functionality that already exists in common libraries used by other products, such as data access helpers, error logging helpers, and user interface helpers.

• Separation of concerns: I think someone was holding the book upside down when they read about the typical "UI -> business layer -> data access layer" 3-tier architecture. In this codebase, the UI layer directly accesses the database, because the business layer is partially implemented but mostly ignored due to not being fleshed out fully enough, and the data access layer controls the UI layer. Most of the low-level database and network methods operate on a global reference to the main form, and directly show, hide, and modify the form. Where the rather thin business layer is actually used, it also tends to control the UI directly. Most of this lower-level code also uses MessageBox.Show to display error messages when an exception occurs, and most swallow the original exception. This of course makes it a bit more complicated to start writing units tests to verify the functionality of the program before attempting to refactor it.

I'm just scratching the surface here, but my question is simple enough: Would it make more sense to take the time to refactor the existing codebase, focusing on one issue at a time, or would you consider rewriting the entire thing from scratch?

EDIT: To clarify a bit, we do have the original requirements for the project, which is why starting over could be an option. Another way to phrase my question is: Can code ever reach a point where the cost of maintaining it would become greater than the cost of dumping it and starting over?

Coupling, Cohesion and the Law of Demeter

The Law of Demeter indicates that you should only speak to objects that you know about directly. That is, do not perform method chaining to talk to other objects. When you do so, you are establishing improper linkages with the intermediary objects, inappropriately coupling your code to other code.

That's bad.

The solution would be for the class you do know about to essentially expose simple wrappers that delegate the responsibility to the object it has the relationship with.

That's good.

But, that seems to result in the class having low cohesion. No longer is it simply responsible for precisely what it does, but it also has the delegates that in a sense, making the code less cohesive by duplicating portions of the interface of its related object.

That's bad.

Does it really result in lowering cohesion? Is it the lesser of two evils?

Is this one of those gray areas of development, where you can debate where the line is, or are there strong, principled ways of making a decision of where to draw the line and what criteria you can use to make that decision?

is f(void) deprecated in modern C and C++

I'm currently refactoring/tidying up some old C code used in a C++ project, and regularly see functions such as:

int f(void)

which I would tend to write as:

int f()

Is there any reason not to replace (void) with () throughout the codebase in order to improve consistency, or is there a subtle difference between the two that I am unaware of? More specifically, if a virtual member function in C++ is described as:

virtual int f(void)

and a derived class includes a member function:

int f()

is this a valid override? Additionally, am I likely to encounter any linker problems based on almost identical signatures?

Changing Variable Names in Vim

I am trying to read a lot of c/perl code through vim which contain many single letter variable names.

It would be nice to have some command which could help me change the name of a variable to something more meaningful while I'm in the process of reading the code so that I could read the rest of it faster.
Is there some command in vim which could let me quickly do this.

I dont think regexes would work cos
1) the same single letter name might have different purposes in different scoping blocks
2) the same combination of letters could part of another larger var name, or in a string or comment .. would not want to modify those

Any known solutions??

If I use C-Style casts in my C++ project, is it worth refactoring to C++ casts?

I use C-style casts in my 15K LOC C++ project, 90% of the times for casts between child and base classes.

Even when I read that it is bad to use them, and that they can result in severe errors, as they are not type safe as the C++ casts, I still feel perfectly fine and comfortable with using them.

I have not experienced a single bug in my project so far that was caused by, for example, an accidentally mistyped C-Style cast - really.

There are two main reasons I have not been using them:

• I didn't know enough about them yet
• I didn't like their syntax, they are more verbose and harder to read for me

My questions:

• (Why) Should I refactor my project to use C++-style casts?
• Why should I use C++-style casts for my future projects?

I use as good as all other advantages C++ offers me, from OOP including virtual and abstract base classes, namespaces, the STL, and so on, just not the new type casting syntax. The argument "Why aren't you just using C then?" doesn't work for me.

How many constructor arguments is too many?

Let's say you have a class called Customer, which contains the following fields:

• UserName
• Email
• First Name
• Last Name

Let's also say that according to your business logic, all Customer objects must have these four properties defined.

Now, we can do this pretty easily by forcing the constructor to specify each of these properties. But it's pretty easy to see how this can spiral out of control when you are forced to add more required fields to the Customer object.

I've seen classes that take in 20+ arguments into their constructor and it's just a pain to use them. But, alternatively, if you don't require these fields you run into the risk of having undefined information, or worse, object referencing errors if you rely on the calling code to specify these properties.

Are there any alternatives to this or do you you just have to decide whether X amount of constructor arguments is too many for you to live with?

How to make Databinding type safe and support refactoring

When I wish to bind a control to a property of my object, I have to provide the name of the property as a string. This is not very good because:

1. If the property is removed or renamed, I don’t get a compiler warning.
2. If a rename the property with a refactoring tool, it is likely the data binding will not be updated.
3. I don’t get an error until runtime if the type of the property is wrong, e.g. binding an integer to a date chooser.

Is there a design-pattern that gets round this, but still has the ease of use of data-binding?

(This is a problem in WinForm, Asp.net and WPF and most likely lots of other systems)

I have now found "workarounds for nameof() operator in C#: typesafe databinding" that also has a good starting point for a solution.

If you are willing to use a post processor after compiling your code, notifypropertyweaver is well worth looking at.

Anyone knows of a good solution for WPF when the bindings are done in XML rather then C#?