I understood that this tool, which I do not know, generates bad code, and so I should look for another solution.
There must be a reason for them to be generated in the build and not make available in the project and is rightly not let it touch. Moreover, the change is likely to occur frequently, so tampering with the code makes no sense, will lose everything or the next build, or when you need a change. These generated codes are made to not touch.
Subverting this seems rather lacking in common sense. If you don’t trust the tool, don’t use it. I am in favor of using scaffolding, but it needs to be the right tool and used in the right way.
Turn the tide. Everything that can generate an effort must be justified. Ask them to argue why they do it. If you are going to do is not a good argument. If it is to improve or customize the code, already have the opposite arguments said above. If it’s something else you need to look for a reason to counter-argue, but I think it’s those two that I said.
Good or bad practice is the argument of those who have no argument. There needs to be no bad practice, there needs to be a good reason to do something and it cannot bring about undesirable harm. It has to analyze technically. Bad practice is to avoid analysis and assume what someone else said without knowing its context.
C# has even partial classes for the code generated before the build be part of the project and at the same time be protected from changes, if everything is well structured.
– Jéf Bueno
"bad practice" was a bad choice
– Elizeu Borges
@Elizeuborges Did any of the answers solve your question? Do you think you can accept one of them? Check out the [tour] how to do this, if you haven’t already done so. You would help the community by identifying what was the best solution for you. You can accept only one of them. But you can vote on any question or answer you find useful on the entire site.
– Maniero