Limpieza del código generado: ¿Refactorizador o mapa?

Contexto:

Recientemente tuve que lidiar con un archivo de clase generado por XSD.exe. Tenía 3500 líneas de largo con nombres de clase / variable ridículamente verbosos (piense someRidiculouslyLongPrefixThenMaybeOneThingUniqueAtTheEnd, difícil de comparar de un vistazo someRidiculouslyLongPrefixThenMaybeOneOtherThingChanged) y anotaciones por todas partes. En pocas palabras, me llevó años averiguar qué demonios estaba pasando. Lo leí y pensé que nunca pondría mi nombre al lado de algo así que ... No limpio.

Pregunta:

1) ¿Es una mala práctica meterse con el código generado (es decir, limpiarlo)?

2) ¿Sería una mejor práctica escribir un mapeador para mapear las clases generadas a mis propias clases bonitas y limpias (con las que podría trabajar, muy feliz)?

EDITAR:

Gracias por todos los comentarios.

Si realmente iba a hacer algo interesante con él (es decir, si hubiera objetos de dominio que fueran cualquier cosa menos objetos de transporte), entonces creo que los asignaría a clases 'más limpias', lo que tendría que hacer de todos modos para obtener cualquier tipo de funcionalidad fuera de ellos. En este caso, las clases son efectivamente DTO, por lo que quizás tenga sentido que el nombre coincida con los elementos correspondientes. Como se indicó, no necesito tocarlo, solo para llamar a los accesores / mutadores antes de pasar los datos a otra capa para su procesamiento.

Por ahora, creo que los dejaré bien en paz.

El peligro de refactorizar el código generado para limpiar y ordenar es que si la herramienta la regenera usted u otro desarrollador, los cambios se perderían.

Su equipo podría ubicarse en una posición en la que estaría generando el código en otro archivo y copiándolo en la versión limpia y refactorizando para aplicar cambios que solo requieren tiempo y recursos. (He estado allí con la versión original de Entity Framework).

Si no puede vivir con los nombres generados, cambie la fuente que genera o haga lo que sugiere en el n. ° 2.

Como regla general, nunca toque el código generado, porque hacerlo significa prometer que nunca lo volverá a generar, o tendrá que rehacer todos los cambios que haya realizado. Si desea que el código generado se vea mejor, debe automatizar tanto la generación del código como la limpieza; por ejemplo, si genera un archivo XML en algún lugar, es posible que desee ejecutarlo xmlindentcomo parte de su proceso de compilación.

Por razones similares, el código generado no pertenece al control de origen. Pones los datos y las reglas bajo control de origen y dejas que tu script de compilación maneje la generación del código.

Cualquier cambio en el código generado tiene que pasar por el generador de código, es decir, si desea que el código generado se vea diferente, cambie las entradas del generador de código, el generador de código en sí mismo o aplique un procesamiento posterior programable. Pero no edite a mano.

Una excepción son los generadores de código de estilo 'andamio', donde ejecuta el generador una vez para darle un esqueleto a partir del cual construye más. Con ellos, nunca volverá a ejecutar el generador para el mismo archivo, por lo que simplemente trata el archivo generado como un archivo fuente normal y olvida que proviene de un generador.

Estoy totalmente de acuerdo con la respuesta de @NikolaiDante (+1).

En dotnet / c # tiene el concepto de "clases parciales": el código fuente de la "clase a usar" consiste en 2 archivos separados, una parte generada y una parte añadida / editada manualmente. Sus api-beautifications van en el archivo "manual" que el generador de códigos no sobrescribirá.

En el mundo java / hybris usan la herencia para el código no generado:

Tiene, por ejemplo, un Cliente de clase con sus "api-beautifications" que hereda de "GeneratedCustomer".