OpenAPITools / OpenAPITools/openapi-generator
[REQ][CORE] Clean up and refactor DefaultCodegen
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 26.8k
- Forks
- 7.7k
- PR merge metrics
- PR metrics pending
Description
Problem
On trying to add support for multiple return models in PR https://github.com/OpenAPITools/openapi-generator/pull/4063 I get lost pretty fast in DefaultCodegen and all the property classes. Part of that is the (sorry) spaghetti nature of DefaultCodegen with over 5000 lines of code without code documentation and a not so trivial naming scheme.
For the pull request I have to copy a lot of code since the defaultCodegen and all the codegen properties are incompatible on handling multiple model types. which results in duplicating everything the tree down from the method DefaultCodegen.fromOperation
Request
I would like to start refactoring this class. The first step would be to extract all getters, setters and properties into a superclass so that DefaultCodegen should only contain logic after that step.
The second step is to extract some logic into well named functions which should be easy ti test which can be extracted into static or singleton classes.
The goal is that the code in DefaultCodegen is easy to understand even for people who never developed java and do not want to since those have to understand DefaultCodegen to write their own generator.
Best case Szenario
Since DefaultCodegen is a kind of read-only-class (if every feature is supported the user want to use)I would like to refactor this class to Kotlin since kotlin has a lot less overhead and mess by itself which results in enhancing the readability and with better readability also code safety. Another major feature is null safety without overhead or failing on readability.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading DefaultCodegen, especially DefaultCodegen.fromOperation, and inventory its getters, setters, properties, and interactions with the property classes. Define extraction boundaries before changing the class; done means the properties and logic are separated as requested and the resulting code is easier to understand and test.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, kotlin
- Domain
- tooling
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100