-
Notifications
You must be signed in to change notification settings - Fork 154
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
[#2076] Refactor RepoConfiguration to simplify constructor complexity #2078
[#2076] Refactor RepoConfiguration to simplify constructor complexity #2078
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@asdfghjkxd kudos for taking on a relatively meaty first issue - changes are looking good and I see no significant issues so far!
for a start, let's keep the documentation changes within this PR for completion, although i suspect there isn't too much to update.
@gok99 I have gone back and reviewed the user/developer guides and didn't find any part that needs modification. I believe the only documentation left would be the JavaDocs within the code itself, but all public methods and some private methods should have their JavaDocs already furnished! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@asdfghjkxd Great work on this! I was really impressed that you tackled this as your first issue. I think you did a very good job refactoring it into the new builder pattern and making sure to capture all the logic carefully.
I've added some comments as minor nitpicks. Additionally, it would be good if you could address some of these new lines that Codecov flagged as not covered by tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For lines 38 - 39, new ArrayList<>()
Initializer for ignoreGlobList
and ignoredAuthorsList
is now redundant
/** | ||
* Updates the {@code fileTypeManager} for {@code RepoConfiguration}. | ||
* | ||
* @param fileTypeManager List of file types and groupings permitted. | ||
* @return This builder object. | ||
*/ | ||
public RepoBuilder fileTypeManager(FileTypeManager fileTypeManager) { | ||
this.fileTypeManager = fileTypeManager; | ||
return this; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider accepting a List<FileType>
directly in the builder and internally creating the FileTypeManager
, for simplicity and maintainability. This way, we encapsulate FileTypeManager
creation and make the API easier for users, keeping the builder's usage clean and hiding unnecessary complexity.
public RepoBuilder formats(List<FileType> formats) {
this.fileTypeManager = new FileTypeManager(formats);
return this;
}
@MarcusTXK Sure thing, I will work on it and add a new commit here once I'm done fixing the code and creating new test cases! |
I have also made some changes to the way the I believe that this was an oversight on my part and I had failed to implement checks and allow This behaviour should be fixed now in the new commit! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry about the review delays! have left some suggestions and discussion points - feel free to comment :)
*/ | ||
private void processNames(RepoBuilder repoBuilder) { | ||
String repoName = this.location.getRepoName(); | ||
this.displayName = repoBuilder.displayName == null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would an Optional
be a good idea for these? we probably should be using more Optional
s in RepoSense to enforce a check, but that's a separate discussion...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, Optional
would eliminate the == null
checks, making the code a lot more understandable and readable! Will look into usingOptional
here!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we look into creating an issue for these separately?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MarcusTXK I agree, most of the issues we had discussed above are rather complicated (parameter verification, duplication of RepoConfiguration
, etc.) and seem to warrant the creation of separate issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think we can focus on improving the RepoConfiguration
incrementally, as @gok99 has brought up alot of good points.
I'm reverting the changes back to before the refactor, it seems like something has caused all the system test cases to break. EDIT: After looking through the code, it seems that there was some mistake in how |
07c7506
to
a50e488
Compare
…ub.com/asdfghjkxd/RepoSense into enhancement-repoconfig-builder-pattern
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for the work!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, great job with this PR!
The following links are for previewing this pull request:
|
Part of #2076
Proposed commit message
Other information
Apologies if this PR seems rather rough, as this is my first time contributing to an OSS, especially one at this scale!
I labelled this as a partial fix as documentation for the changes has not been made yet, and I'm not sure if that is within the scope of this issue; if required, I am happy to work on the updated documentation, before opening another pull request that seeks to address that, otherwise, I am also happy to upgrade this PR from a partial fix to a full fix.