-
Notifications
You must be signed in to change notification settings - Fork 870
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
fix-#1199/refactor-implementation-smells #1200
base: master
Are you sure you want to change the base?
fix-#1199/refactor-implementation-smells #1200
Conversation
/** | ||
* Get formatted block comment, either as parameter comment or regular block comment | ||
*/ | ||
private String getFormattedBlockComment(Tok tok, List<String> lines, int column0) { |
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 my taste, the methods are too fragmented. It’s hard to keep track of all the small subroutines in my head. Isn’t there a middle ground between being too small and too complex?
} | ||
|
||
/** | ||
* Get formatted block comment, either as parameter comment or regular block comment |
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.
Who is supposed to read this JavaDoc comment? By default, JavaDoc for private methods is not published. You can only see it in the IDE by hovering over the method name and waiting, or by jumping to the method’s implementation. The method signature is already well chosen.
Even I don’t understand what the comment means. How am I supposed to choose between a parameter comment and a regular block comment?
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.
The refactored code looks much better. However, I still get headaches when I see the parameter i
.
I understand the approach with ImportAndIndex
to make the side effects clearer.
At the moment, I also don't know how to improve it further.
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.
Very good!
Refactor Multiple Components for Improved Maintainability
Description
This PR addresses several implementation smells in the codebase to enhance maintainability, readability, and testability. The refactoring process ensures no functional changes are introduced, maintaining backward compatibility while improving code quality metrics.
Changes Made
1. Refactored Complex Method in
ImportOrderer
2. Eliminated Magic Numbers in
CommandLineOptionsParser
3. Simplified Long Statement in
JavaCommentsHelper
Benefits
Testing
Impact
Related Issues
Labels
refactoring
code-quality
enhancement
implementation-smells