Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Visual Studio Refactoring: Seamless Method Relocation #72936

Open
vsfeedback opened this issue Apr 8, 2024 · 0 comments
Open

Visual Studio Refactoring: Seamless Method Relocation #72936

vsfeedback opened this issue Apr 8, 2024 · 0 comments
Labels
Area-IDE Feature Request untriaged Issues and PRs which have not yet been triaged by a lead

Comments

@vsfeedback
Copy link

This issue has been moved from a ticket on Developer Community.


I propose a new refactoring feature for Visual Studio aimed at seamlessly relocating methods along with any associated code to either a new or existing class. Allow me to illustrate the scenario:

Currently, I have a class dedicated to benchmarking code. However, this class has grown so extensive that it takes BenchmarkDotNet over three hours to generate the reports. My proposed solution involves moving one or more of these benchmarking methods to a new benchmarking class. Yet, simply relocating the method isn't sufficient; I also require all related methods and fields to be transferred to the new class. This automation would significantly alleviate manual efforts and streamline the refactoring process. While I've long desired this functionality, the urgency to address this issue is now paramount.

To provide a concrete example, consider the benchmark method below that I aim to relocate:

[Benchmark(Description = "foreach(): MemoryExtensions.AsSpan List<ref>")]
public void ForEach_MemoryExtension_AsSpan_Ref()
{
    var collection = MemoryExtensions.AsSpan(this._personRefList.ToArray());
    foreach (var person in collection)
    {
        base. Update(person);
    }
}

The method in question utilizes the _personRefList field, which must also be moved along with it. Moreover, it's worth noting that the collection within this field is instantiated within the method itself. Thus, it's imperative that both the method and the field, along with its instantiation, are relocated together.

public override void Setup()
{
    base. Setup();
    this._personRecordList = [.. this. GetPersonRecordCollection()];
    this._personRefList = [.. this. GetPersonRefCollection()];
    this._personValList = [.. this. GetPersonValCollection()];
}

In addition to moving the specified method and field, it's essential to relocate or create the Setup() method in the new class. This includes transferring the call to base. Setup() and the line responsible for populating the _personRefList field with data. The new Setup() method should look like this:

public override void Setup()
{
    base. Setup();
    this._personRefList = [.. this. GetPersonRefCollection()];
}

Considering that this benchmark class inherits LargeCollectionBenchmark, the new class should inherit it as well, along with any necessary using statements.

Furthermore, the capability to select multiple methods for relocation should be incorporated. For instance, all three of these methods and their associated code should be movable:

Picture2.png

Furthermore, if these three methods constitute the sole users of the fields mentioned earlier, any relevant fields or associated code within the original class should be removed. However, if these moved methods are referenced elsewhere within the solution, it's imperative to refactor the respective code to reference the new class appropriately. This ensures seamless integration and maintains the integrity of the solution.

Implementing this refactoring feature would significantly expedite the process of relocating code to different classes, offering substantial benefits to software engineers. By automating the transfer of methods along with related fields and code, developers can streamline their workflow, reduce manual effort, and enhance productivity. This feature would undoubtedly find utility among a wide range of software engineers, helping them efficiently organize and maintain their codebases.


Original Comments

Feedback Bot on 4/7/2024, 00:15 AM:

(private comment, text removed)

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead labels Apr 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-IDE Feature Request untriaged Issues and PRs which have not yet been triaged by a lead
Projects
None yet
Development

No branches or pull requests

2 participants