Time to make some changes to CloudNet's codebase
See original GitHub issueSo, I “analyzed” CloudNet’s code and oh boy, a lot of work needs to be done. By work I mean actual code and performance optimization, debugging etc.
Most things can probably be done using IntelliJ’s advanced refactoring tools, like searching for something and replacing it, but there’s also stuff on the list which needs to be done by hand.
Pending:
- [approved] Use builders where applicable
- [approved] Create data classes where applicable
- [wip] Replace pure string concats
abc += "def"
with StringBuilder appends - [approved] Replace
java.io
classes withjava.nio
classes where applicable, might require@Deprecated
declarations - [approved] Some abstract classes and interfaces are waayyy too fat. Requires separation. Might require
@Deprecated
declarations - [approved] Return
Collection<?>
types instead ofList<?>
,Set<?>
or any other extending interface or class ofCollection
. Might require@Deprecated
declarations - [approved] Use lazy type initialization. (Let a field be initialized by a getter or setter, if the field is null. A lot of stuff in CloudNet might not be needed by anyone or anything)
Work in progress:
- Replace inline statements with block statements
- Calls to functions located in own class should use the
this.
accessor - Calls to functions located in super class should use the
super.
accessor ONLY IF the function is not overridden by the child class - Try catch blocks shouldn’t silently dispose any exceptions/throwables. (Re-)Throw, print or log them
- Parameter validations shouldn’t silently dispose any exceptions. (Re-)Throw, print or log them
- Re-arrange fields correctly
- Re-arrange functions correctly
- Separate chained field declarations
- Validate the state of parameters (Is the int negative?, is the string blank even though it shouldn’t be?, is the passed varargs array empty?)
- Validate the parameter for null
- Use Guava’s Preconditions instead of own validation class
Done:
- Lombok should not be used in such complex application. The only thing Lombok could be used for is generating
#equals()
,#hashCode()
and#toString()
. Using@Getter
,@Setter
and any other Lombok annotations is highly discouraged blurs a class’ logic
More to come
Issue Analytics
- State:
- Created 4 years ago
- Comments:25 (12 by maintainers)
Top Results From Across the Web
How to Refactor a Monolithic Codebase Over Time - CloudBees
If not, then get it under version control straightaway! The last thing you want to do is to make any changes and not...
Read more >Commit Changes to Your Codebase the Right Way - SitePoint
Commit changes to your codebase the right way with this guide. Lucero del Alba outlines best practices for the ideal version control commit....
Read more >Old Ruby Codebase - When to Update, What to Consider ...
Ok, We'll Update. What Are The Options? What if my codebase is already out of date? If I don't have time, what should...
Read more >5 ways to make your codebase withstand the test of time
Split your code based on domain concepts, not tech concepts. One of the first questions you may have when starting a new project...
Read more >Use the Mikado Method to do safe changes in a complex ...
Use the Mikado Method to do safe changes in a complex codebase. Are you struggling with Legacy Code and not enough time to...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Issue-Label Bot is automatically applying the label
feature_request
to this issue, with a confidence of 0.95. Please mark this comment with 👍 or 👎 to give our bot feedback!Links: app homepage, dashboard and code for this bot.
Not using Guava would mean, that we’d have to maintain our own commons. Technically speaking, we’re maintaining something which Google’s maintaining for us, in their own library and probably more efficient. Re-inventing the wheel isn’t the best imho.
Ima change the status of
Use Guava's Preconditions instead of own validation class
toapproved