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

Refactored data clumps with the help of LLMs (research project) #1962

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

compf
Copy link

@compf compf commented Jun 3, 2024

Hello maintainers,

I am conducting a master thesis project focused on enhancing code quality through automated refactoring of data clumps, assisted by Large Language Models (LLMs).

Data clump definition

A data clump exists if

  1. two methods (in the same or in different classes) have at least 3 common parameters and one of those methods does not override the other, or
  2. At least three fields in a class are common with the parameters of a method (in the same or in a different class), or
  3. Two different classes have at least three common fields

See also the following UML diagram as an example
Example data clump

I believe these refactoring can contribute to the project by reducing complexity and enhancing readability of your source code.

Pursuant to the EU AI Act, I fully disclose the use of LLMs in generating these refactorings, emphasizing that all changes have undergone human review for quality assurance.

Even if you decide not to integrate my changes to your codebase (which is perfectly fine), I ask you to fill out a feedback survey, which will be scientifically evaluated to determine the acceptance of AI-supported refactorings. You can find the feedback survey under https://campus.lamapoll.de/Data-clump-refactoring/en

Thank you for considering my contribution. I look forward to your feedback. If you have any other questions or comments, feel free to write a comment, or email me under tschoemaker@uni-osnabrueck.de .

Best regards,
Timo Schoemaker
Department of Computer Science
University of Osnabrück

Copy link
Member

@AndreasTu AndreasTu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry but I am not convinced that these type of changes make the code more readable or maintainable. So I am against integrating such a code also after addressing my findings here, because the code is not better than the original and also just removed minor code duplication by introducing new code complexity.

Also due to changing the immutable classes to mutable ones, the change functionally breaks the code for concurrent usages, see chapter Safe Publication in Concurrency in Practice for details.

private final boolean useObjenesis;
private final IMockMakerSettings mockMakerSettings;
private MockSettings mockSettings = new MockSettings(null, null, null, null, false, false);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes the object mutable due the non immutable object and non final field.

private final SpecificationAttachable mockInterceptor;

private Specification specification;
private MockSettings mockSettings = new MockSettings(null, null, null, null, false, false);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes the object mutable due the non immutable object and non final field.

Comment on lines +34 to +39
this.mockSettings.setName(name);
this.mockSettings.setType(type);
this.mockSettings.setInstance(instance);
this.mockSettings.setVerified(verified);
this.mockSettings.setGlobal(global);
this.mockSettings.setDefaultResponse(defaultResponse);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also the code change is not better readable then the other one, also the removed "code duplication" increases the overall code size => This does not make the code more maintainable.

@@ -0,0 +1,72 @@
package org.spockframework.mock.runtime;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This class does not adhere the formatting rule, code positions e.g. fields before constructor, qualified names instead of imports etc.
Nor is it Immutable, nor has a toString (for debugging purpose) + equal+ hashcode for POJO, etc.

So this new class does not make the original code more readable nor is this class maintainable.

@@ -0,0 +1,72 @@
package org.spockframework.mock.runtime;
public class MockSettings{
private java.lang.String name;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nullable annotations are missing, or null checks in the constructor/setter missing.

@compf
Copy link
Author

compf commented Jun 4, 2024

Thank you very much for the feedback. It is absolutely fine if you do not want these changes to be merged. You feedback is still very valuable and I appreciate your time

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants