tag paleta online example combinaciones colores code code-generation

code-generation - online - paleta de colores combinaciones



¿Creas tus propios generadores de código? (26)

A menudo es útil crear un generador de código que genere código a partir de una especificación, generalmente una que tiene reglas tabulares regulares. Reduce la posibilidad de introducir un error a través de un error tipográfico u omisión.

El programador pragmático aboga por el uso de generadores de código. ¿Creas generadores de código en tus proyectos? Si es así, ¿para qué los usa?


En el diseño de hardware, es una práctica bastante común hacer esto en varios niveles de la ''pila''. Por ejemplo, escribí un generador de código para emitir Verilog para diversos anchos, topologías y estructuras de motores DMA e interruptores de barras cruzadas, porque las construcciones necesarias para expresar esta parametrización aún no estaban maduras en los flujos de herramientas de síntesis y simulación.

También es rutinario emitir modelos lógicos hasta los datos de diseño para elementos muy regulares que pueden expresarse y generarse algorítmicamente, como SRAM, caché y estructuras de archivos de registro.

También dediqué bastante tiempo a escribir, esencialmente, un generador de código que tomaría una descripción XML de todos los registros en un sistema en chip y emitiría HTML (sí, sí, sé acerca de XSLT, acabo de encontrar emisores programáticamente para ser más eficaz en el tiempo), Verilog, SystemVerilog, C, Assembly, etc. "vistas" de esa información para diferentes equipos (diseño ASIC frontal y final, firmware, documentación, etc.) para usar (y mantenerlos consistentes en virtud de esta única "base de código" XML). ¿Eso cuenta?

A la gente también le gusta escribir generadores de código para, por ejemplo, tomar descripciones breves de cosas muy comunes, como máquinas de estado finito, y generar mecánicamente un código de lenguaje imperativo más detallado para implementarlas de manera eficiente (por ejemplo, tablas de transición y código de cruce).


Los generadores de código, si se usan ampliamente sin una argumentación correcta, hacen que el código sea menos comprensible y reducen la capacidad de mantenimiento (lo mismo con el SQL dinámico, por cierto). Personalmente lo estoy usando con algunas de las herramientas ORM, porque su uso aquí es obvio y algunas veces para cosas como algoritmos de búsqueda y análisis sintáctico y analizadores gramaticales que no están diseñados para mantenerse "a mano" últimamente. Aclamaciones.


Mi necesidad más reciente de un generador era un proyecto que leía datos del hardware y finalmente los publicaba en una interfaz de usuario del ''tablero''. En el medio se encontraron modelos, propiedades, presentadores, eventos, interfaces, banderas, etc. para varios puntos de datos. Trabajé en el marco para un par de puntos de datos hasta que estuve satisfecho de poder vivir con el diseño. Luego, con la ayuda de algunos comentarios cuidadosamente colocados, puse la "generación" en una macro de estudio visual, pellizqué y limpié la macro, agregué los puntos de datos a una función en la macro para llamar a la generación y guardé varias horas tediosas (días ?) en el final.

No subestimes el poder de las macros :)

Ahora también estoy tratando de entender las capacidades de personalización de CodeRush para ayudarme con algunos requisitos de generación más locales. Hay cosas poderosas allí si necesita tomar decisiones sobre la marcha al generar un bloque de código.


No puedo pensar en ningún proyecto en el que necesitemos crear nuestros propios generadores de código desde cero, pero hay varios en los que usamos generadores preexistentes. (He utilizado Antlr y Eclipse Modeling Framework para construir analizadores y modelos en java para software empresarial.) La belleza de usar un generador de código que alguien más ha escrito es que los autores tienden a ser expertos en esa área y han resuelto problemas que ni siquiera sabía que existía todavía. Esto me ahorra tiempo y frustración.

Así que, aunque podría escribir código que resuelva el problema, puedo generar el código mucho más rápido y hay muchas posibilidades de que sea menos problemático que cualquier cosa que escriba.


Sí, he tenido que mantener algunas. CORBA o algún otro estilo de interfaz de comunicación de objeto es probablemente lo general en lo que pienso primero. Tiene definiciones de objeto que le proporciona la interfaz de la que va a hablar, pero aún tiene que construir esos objetos en el código. Construir y ejecutar un generador de código es una forma bastante rutinaria de hacerlo. Esto puede convertirse en una compilación bastante larga solo para admitir algún canal de comunicación heredado, y dado que hay una gran tendencia a poner envoltorios alrededor de CORBA para hacerlo más simple, las cosas simplemente empeoran.

En general, si tiene una gran cantidad de estructuras o solo estructuras que cambian rápidamente que necesita usar, pero no puede manejar el impacto de rendimiento de construir objetos a través de metadatos, escriba un generador de códigos.


Si no va a escribir el código, ¿se sentirá cómodo con el código generado de otra persona?

¿Es más barato en tiempo y $$$ a largo plazo escribir su propio código o generador de código?

Escribí un generador de código que construiría cientos de clases (java) que generarían datos XML desde la base de datos en forma de DTD o esquema. La generación de código generalmente era una cosa de una sola vez y el código sería mejorado con varias reglas de negocios, etc. La salida era para un banco bastante pedante.


Tengo mi propio generador de código que ejecuto contra tablas SQL. Genera los procedimientos de SQL para acceder a los datos, la capa de acceso a los datos y la lógica de negocios. Ha hecho maravillas al estandarizar mi código y las convenciones de nombres. Debido a que espera ciertos campos en las tablas de la base de datos (como una columna de Id. Y una columna de fecha y hora actualizada), también ha ayudado a estandarizar mi diseño de datos.


Usamos generadores de código para generar clases de entidades de datos, objetos de base de datos (como desencadenadores, procesos almacenados), proxies de servicio, etc. En cualquier lugar donde vea gran cantidad de código de repitición siguiendo un patrón y mucho trabajo manual, los generadores de códigos pueden ayudar. Pero, no debe usarlo demasiado en la medida en que el mantenimiento sea un problema. También surgen algunos problemas si quieres regenerarlos.

Herramientas como Visual Studio, Codesmith tienen sus propias plantillas para la mayoría de las tareas comunes y hacen que este proceso sea más fácil. Pero, es fácil de implementar por su cuenta.


Usamos un generador para todo el código nuevo para ayudar a garantizar que se sigan los estándares de codificación.

Recientemente reemplazamos nuestro generador de C ++ interno con CodeSmith . Todavía tenemos que crear las plantillas para la herramienta, pero parece ideal no tener que mantener la herramienta nosotros mismos.


en mi opinión, un buen lenguaje de programación no necesitaría generadores de código porque la introspección y la generación de código de tiempo de ejecución serían parte del lenguaje, por ejemplo, en las metaclases de Python y el nuevo módulo, etc.


los generadores de código generalmente generan más código inmanejable en el uso a largo plazo.

sin embargo, si es absolutamente imperativo usar un generador de código (eclipse VE para el desarrollo de swing es lo que utilizo a veces), entonces asegúrese de saber qué código se está generando. Créanme, no querrían código en su aplicación con el que no estén familiarizados.


puede haber muchos generadores de código, sin embargo, siempre creo el mío para que el código sea más comprensible y se adapte a los marcos y las pautas que estamos usando


¿Cuántos estás buscando? Creé dos más importantes y numerosos menores. El primero de los más importantes me permitió generar programas de 1500 líneas (dar o recibir) que tenían un gran parecido familiar, pero que estaban en sintonía con las diferentes tablas en una base de datos, y que lo hacen de forma rápida y confiable.

La desventaja de un generador de código es que si hay un error en el código generado (porque la plantilla contiene un error), entonces hay mucho que arreglar.

Sin embargo, para lenguajes o sistemas donde hay una gran cantidad de codificación casi repetitiva, un buen (suficiente) generador de código es una bendición (y más una bendición que un ''doggle'').


En "Programador pragmático", Hunt y Thomas distinguen entre generadores de código pasivo y activo.

Los generadores pasivos se ejecutan una vez, después de lo cual se edita el resultado.

Los generadores activos se ejecutan con la frecuencia que se desee y nunca se debe editar el resultado porque se reemplazará.

IMO, estos últimos son mucho más valiosos porque abordan el principio DRY (no repetir).

Si la información de entrada a su programa se puede dividir en dos partes, la parte que cambia raramente (A) (como metadatos o DSL) y la parte que es diferente cada vez que se ejecuta el programa (B) (la entrada en vivo) , puede escribir un programa generador que solo toma A como entrada, y escribe un programa ad-hoc que solo toma B como entrada. (Otro nombre para esto es evaluación parcial).

El programa del generador es más simple porque solo tiene que pasar a través de la entrada A, no de A y B. Además, no tiene que ser rápido porque no se ejecuta con frecuencia, y no tiene que preocuparse por las pérdidas de memoria.

El programa ad-hoc es más rápido porque no tiene que pasar por una entrada que casi siempre es la misma (A). Es más simple porque solo tiene que tomar decisiones sobre la entrada B, no sobre A y B.

Es una buena idea que el programa ad-hoc generado sea bastante legible, para que pueda encontrar más fácilmente cualquier error en él. Una vez que elimina los errores del generador, desaparecen para siempre.

En un proyecto en el que trabajé, un equipo diseñó una aplicación de base de datos compleja con una especificación de diseño de dos pulgadas de grosor y un extenso calendario de implementación, plagado de preocupaciones sobre el rendimiento. Al escribir un generador de códigos, dos personas hicieron el trabajo en tres meses, y las listas de códigos fuente (en C) tenían aproximadamente media pulgada de grosor, y el código generado fue tan rápido que no fue un problema. El programa ad-hoc se regeneró semanalmente, a un costo trivial.

Así que la generación activa de código, cuando puede usarlo , es una situación en la que todos ganan . Y, creo que no es accidental que esto sea exactamente lo que hacen los compiladores.


Los únicos generadores de código que uso son analizadores de servicios web. Personalmente, me mantengo alejado de los generadores de código debido a los problemas de mantenimiento para los nuevos empleados o un equipo separado después de la entrega.


Los generadores de código son una solución para las limitaciones del lenguaje de programación. Personalmente prefiero la reflexión en lugar de los generadores de código, pero estoy de acuerdo en que los generadores de código son más flexibles y el código resultante obviamente más rápido durante el tiempo de ejecución. Espero que las futuras versiones de C # incluyan algún tipo de entorno DSL.


Escribo mis propios generadores de código, principalmente en T-SQL, que se llaman durante el proceso de compilación.

Con base en los datos del metamodelo, generan desencadenantes, registros, declaraciones de C # const, instrucciones INSERT / UPDATE, información del modelo de datos para verificar si la aplicación se está ejecutando en el esquema de base de datos esperado.

Todavía necesito escribir un generador de formularios para una mayor productividad, más especificaciones y menos codificación;)


He creado algunos generadores de código. Tenía un generador de código pasivo para procedimientos SQL almacenados que usaban plantillas. Esto generó el 90% de nuestros procedimientos almacenados.

Desde que hicimos el cambio a Entity Framework, creé un generador de código activo usando T4 ( Text Template Transformation Toolkit ) dentro de Visual Studio. Lo he usado para crear clases parciales básicas de repositorio para nuestras entidades. Funciona muy bien y ahorra una gran cantidad de codificación. También uso T4 para decorar las clases de entidades con ciertos Atributos.


Los generadores de código son realmente útiles en muchos casos, especialmente al mapear de un formato a otro. He hecho generadores de código para IDL a C ++, tablas de base de datos a tipos OO y código de clasificación solo por nombrar algunos.

Creo que lo que intentan hacer los autores es que, si eres un desarrollador, deberías poder hacer que la computadora trabaje para ti. Generar código es solo una tarea obvia para automatizar.

Una vez trabajé con un chico que insistía en que haría manualmente nuestro mapeo de IDL a C ++. Al comienzo del proyecto, pudo mantenerse al día, porque el resto de nosotros estábamos tratando de descubrir qué hacer, pero finalmente se convirtió en un cuello de botella. Hice un generador de código en Perl y luego pudimos hacer su "trabajo" en pocos minutos.


Sí, desarrollé mi propio generador de código para el diámetro del protocolo AAA (RFC 3588). Podría generar estructuras y Api para mensajes de diámetro que se leen a partir de un archivo XML que describe la gramática de la aplicación de diámetro.

Eso redujo en gran medida el tiempo para desarrollar una interfaz de diámetro completo (como SH / CX / RO, etc.).



Vea nuestro generador de código "universal" basado en transformaciones de programa.

Soy el arquitecto y un implementador clave. Vale la pena señalar que una fracción significativa de este generador se genera utilizando este generador.


En los sistemas integrados, a veces se necesita un gran bloque de datos binarios en el flash. Por ejemplo, tengo uno que toma un archivo de texto que contiene glifos de fuentes de mapa de bits y lo convierte en un par de archivos .cc / .h declarando constantes interesantes (como primer carácter, último carácter, ancho y alto del carácter) y luego los datos reales como una gran static const uint8_t[] .

Tratar de hacer algo así en C ++, para que los datos de la fuente se autogeneren en la compilación sin un primer pase, sería un dolor y probablemente ilegible. Escribir un archivo .o a mano está fuera de discusión. Lo mismo ocurre con el papel milimetrado, la codificación manual en binario y el tipeo de todo eso.

En mi humilde opinión, este tipo de cosas es para qué son los generadores de código. Nunca olvide que la computadora funciona para usted, no al revés.

Por cierto, si usas un generador, siempre siempre siempre incluye algunas líneas como esta al inicio y al final de cada archivo generado:

// This code was automatically generated from Font_foo.txt. DO NOT EDIT THIS FILE. // If there''s a bug, fix the font text file or the generator program, not this file.


Usamos el generador de códigos de Telosys Tools en nuestros proyectos: https://sites.google.com/site/telosystools/

Lo hemos creado para reducir la duración del desarrollo en tareas recurrentes como pantallas CRUD, documentación, etc.

Para nosotros, lo más importante es poder personalizar las plantillas del generador, para crear objetivos de nueva generación si es necesario y personalizar las plantillas existentes. Es por eso que también hemos creado un editor de plantillas (para archivos Velocity .vm). Funciona bien para el generador de código Java / Spring / AngularJS y se puede adaptar para otros objetivos (PHP, C #, Python, etc.)


Escribir un generador propio para un proyecto no es eficiente. En su lugar, use un generador como T4, CodeSmith y Zontroy.

T4 es más complejo y necesita conocer un lenguaje de programación .Net. Debe escribir su plantilla línea por línea y debe completar operaciones relacionales de datos por su cuenta. Puedes usarlo en Visual Studio.

CodeSmith es una herramienta funcional y hay muchas plantillas listas para usar. Se basa en T4 y escribir tu propio temlate toma demasiado tiempo como lo está en T4. Hay una prueba y una versión comercial.

Zontroy es una nueva herramienta con una interfaz de usuario fácil de usar. Tiene su propio lenguaje de plantilla y es fácil de aprender. Hay un mercado de plantillas en línea y está en desarrollo. Incluso puede entregar plantillas y venderlas en línea sobre el mercado. Tiene una versión gratuita y comercial. Incluso la versión gratuita es suficiente para completar un proyecto de mediana escala.