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

Clearly mark code that is designed for a Developer to change #254

Open
gedw99 opened this issue Aug 23, 2024 · 6 comments
Open

Clearly mark code that is designed for a Developer to change #254

gedw99 opened this issue Aug 23, 2024 · 6 comments

Comments

@gedw99
Copy link

gedw99 commented Aug 23, 2024

Hey @lerenn

2 things I want to ask for help with:

  1. Easily seeing what code i can expect to be stomped on by the code generator.

When I look at https://github.com/lerenn/asyncapi-codegen/tree/main/examples/helloworld/v3

All the going code has generators, and so you cant easily tell which code is your code and which is generated code.

A big and clear comment at the top of the files that are designed for a User to change that the generator will stomp on is the solution I think.

  1. Merge generated code with Developers own code.

https://github.com/lerenn/asyncapi-codegen?tab=readme-ov-file#with-async-api-generated-code explains the notion of User Code versus Generated code.

Also you can design in special comments into code files that are generated BUT also designed for Developers to add code to that same file , by using comment delineators. When the code generator is re-run alter, you can use there start and stop delineator to merge the generated code with the user code.
An early way to do this is to:

a. First gen run is just normal, and generates any code files designed to have users code changes with the special comments.
b. Next phase is to parse of all the code for files with these special comments, and copy each file in place from, for example, "file.go" to file". It's in the same directory, and so makes it easy.
c. Then parse all the code again looking for a match of "file.go" and "file.go.tmp", and then do the merge based on the special comments.
d. Delete "file.go.tmp"

The advantage of this approach is that the current generator is NOT affected. In stead we are just adding a 2nd phase. So this approach works fine with golang templates etc.

I used this technique for a very large Enterprise company that has a team for 500 developers. It was a total hit, and the developers liked it, because it solves an everyday problem and make it much easier to work with the code also. We were generating off a custom schema and we would generate the DB and Middle tier. The merging strategy did work well.

Please let me know if this is helpful ?

@gedw99 gedw99 changed the title mark code that is designed for a Developer to change clearly Clearly mark code that is designed for a Developer to change Aug 23, 2024
@lerenn
Copy link
Owner

lerenn commented Aug 23, 2024

Hello @gedw99 ! Thanks for the tips and critics, it's really appreciated !

I'm currently on vacation so I won't be able to make the change now, but I'll take a look when I'll get back :)

@gedw99
Copy link
Author

gedw99 commented Aug 24, 2024

no rush - just an idea that I got working on some other golang cod gen stuff.

@gedw99
Copy link
Author

gedw99 commented Aug 25, 2024

@lerenn span above... might want to delete these...

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

No branches or pull requests

4 participants
@lerenn @gedw99 and others