Is it a bad idea to automatically versize classes with Jibx?

Asked

Viewed 65 times

4

Where work we have a project (very old) that uses Jibx to generate some classes from schemas. These classes are generated in build logo os source do not exist in the project.

Someone gave the brilliant idea to take these source generated and put (CTRL+V) within the project, so it would no longer be necessary to generate them and only when we have some change in the schema.

This does not seem like a good idea, since the generated classes are very bad and this would open up room for someone to change them, generating a version that may be incompatible with the schemas.

What arguments can I use to convince the team that this is not a good idea (if it really isn’t)?

  • 1
    1. Define good practice; 2. Simply explain to them why this is not a good idea, if you don’t know, it’s probably a good idea.
  • 1

    "bad practice" was a bad choice

  • 1

    @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.

2 answers

4

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.

3


I personally see some reason to consider this nay is a good idea:

  • The less code, the better. Frameworks exist exactly so we don’t have to create code and more code if someone (or something) can do it for us :P

  • From the moment you assume the creation of a code, well, the code becomes yours. In other words, you are 100% responsible for ensuring that it is functional and bug-free.

  • CTRL+C and CTRL+V? Really? Normally code generated by frameworks/libs is "ugly" code. If you really want to put inside the folder src at least make an original/better implementation, right?

  • The less code you keep, the smaller the size of your repository

  • The less code you keep the less test you need to have/run

  • If you use any static code analysis tool (the Sonar, for example), you can disregard the codes generated by lib, since in fact they are not from your team.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.