实用程序员提倡使用代码生成器。
我们是否在项目上创建代码生成器？如果是，我们将它们用于什么用途？

解决方案

如果不使用正确的论点而广泛使用代码生成器，则会使代码难以理解并降低可维护性(顺便说一下，与动态SQL相同)。我个人将它与一些ORM工具一起使用，因为它们在这里的用法通常很明显，有时用于诸如搜索器解析器算法和语法分析器之类的东西，这些东西最近都不是"手动"维护的。干杯。

我们使用代码生成器来生成数据实体类，数据库对象(如触发器，存储的proc)，服务代理等。在遵循某种模式和大量手动工作的情况下，看到大量重复性代码的任何地方，代码生成器都可以提供帮助。但是，我们不应过多地使用它，以至于可维护性是一种痛苦。如果要重新生成它们，也会出现一些问题。

诸如Visual Studio和Codesmith之类的工具都有它们自己的模板，可以执行大多数常见任务，并使此过程更加容易。但是，很容易自行部署。

在硬件设计中，在"堆栈"的多个级别执行此操作是相当普遍的做法。例如，我编写了一个代码生成器以针对DMA引擎和交叉开关的各种宽度，拓扑和结构发出Verilog，因为表达这种参数化所需的构造在综合和仿真工具流程中尚未成熟。

从逻辑上讲，一直到逻辑数据的布局都是常规的事情，这些事情可以通过算法表达和生成，例如SRAM，缓存和寄存器文件结构。

我还花了相当多的时间来编写代码生成器，该代码生成器将对片上系统上的所有寄存器进行XML描述并发出HTML(是的，是的，我知道XSLT，我刚刚发现了它可以通过编程来提高时间效率)，Verilog，SystemVerilog，C，Assembly等。供不同团队(前端和后端ASIC设计，固件，文档等)使用的数据"视图"借助单个XML"代码库"使它们保持一致)。这算吗？

人们还喜欢为对有限状态机之类的非常普通的事物进行简短描述，并机械地输出更详细的命令式语言代码以有效地实现它们(例如，过渡表和遍历代码)。

那里可能有很多代码生成器，但是我总是创建自己的代码生成器，以使代码更易于理解，并适合我们使用的框架和准则

是的，我不得不维持一些。我首先想到的是CORBA或者其他接口的对象通信样式。我们将要通过要讨论的界面提供对象定义，但是仍然必须在代码中构建这些对象。构建和运行代码生成器是一种相当常规的方式。仅为了支持某些旧版通信通道，这可能会成为一个相当漫长的编译过程，并且由于存在一种将CORBA封装起来以使其更简单的趋势，因此情况只会变得更糟。

通常，如果我们有大量的结构，或者只是需要快速使用的结构，但是我们无法通过元数据处理构建对象的性能问题，那么我们就需要编写代码生成器。

我们为所有新代码使用生成器，以帮助确保遵循编码标准。

最近，我们用CodeSmith替换了内部C ++生成器。我们仍然必须为该工具创建模板，但是似乎不必自己维护该工具似乎很理想。

我最近对生成器的需求是一个从硬件读取数据并将其最终发布到"仪表板" UI的项目。中间是几个数据点的模型，属性，演示者，事件，接口，标志等。我为几个数据点设计了框架，直到对我可以接受该设计感到满意为止。然后，在一些经过仔细放置的注释的帮助下，我将"世代"放入Visual Studio宏中，进行了调整和清理，将数据点添加到了宏中的函数中以调用世代，并节省了一些繁琐的时间(几天？ ) 到底。

不要低估宏的功能：)

我现在也想尽我所能来了解CodeRush定制功能，以帮助我满足更多本地生成要求。如果我们需要在生成代码块时进行即时决策，则其中包含强大的功能。

在我看来，一种好的编程语言不需要代码生成器，因为自省和运行时代码生成将是语言的一部分，例如在python元类和新模块等中

我有针对SQL表运行的自己的代码生成器。它生成用于访问数据，数据访问层和业务逻辑的SQL过程。它在标准化我的代码和命名约定方面产生了奇迹。因为它期望数据库表中的某些字段(例如id列和更新的datetime列)，所以也有助于标准化我的数据设计。

我想不出需要从头开始创建自己的代码生成器的任何项目，但是有几个项目使用了预先存在的生成器。 (我曾使用Antlr和Eclipse Modeling Framework在Java中为企业软件构建解析器和模型。)使用他人编写的代码生成器的好处在于，作者往往是该领域的专家，并且已经解决了问题我什至不知道的存在。这节省了我的时间和沮丧。

因此，即使我能够编写解决当前问题的代码，我也可以更快地生成代码，而且很有可能比我编写的任何东西都不会出错。

在长期使用中，代码生成器通常会生成更多难以管理的代码。

但是，如果绝对需要使用代码生成器(有时我会使用Eclipse VE开发秋千)，那么请确保我们知道正在生成的代码。相信我，我们不会想要我们不熟悉的应用程序中的代码。

创建一个代码生成器通常很有用，该代码生成器根据通常具有常规表格规则的规范生成代码。它减少了通过错别字或者遗漏引入错误的机会。

如果我们不打算编写代码，那么我们是否会对别人生成的代码感到满意？

从长远来看，编写自己的代码或者代码生成器便宜吗？

我编写了一个代码生成器，该代码生成器将构建100多个类(java)，这些类将以DTD或者架构兼容的方式从数据库输出XML数据。代码生成通常是一次性的事情，然后可以使用各种业务规则等对代码进行智能化。输出的结果是针对一家颇有学问的银行。

在"实用程序程序员"中，Hunt和Thomas区分了被动代码生成器和主动代码生成器。

被动生成器是一次性运行的，之后我们可以编辑结果。

活动生成器会根据需要运行，并且永远不要编辑结果，因为它将被替换。

IMO，后者更具价值，因为它们遵循DRY(请勿重复自己)原则。

如果程序的输入信息可以分为两部分，则很少更改的部分(A)(例如元数据或者DSL)，以及每次运行程序时都不同的部分(B)(实时输入) ，我们可以编写仅将A作为输入的生成器程序，并编写仅将B作为输入的即席程序。
(这的另一个名称是部分评估。)

生成器程序更简单，因为它只需要遍历输入A，而不必遍历输入A和B。而且，它不必很快，因为它不经常运行，也不必关心内存泄漏。

临时程序速度更快，因为它不必遍历几乎总是相同的输入(A)。这比较简单，因为它只需要对输入B做出决定，而不必对A和B做出决定。

生成的即席程序具有很好的可读性是一个好主意，因此我们可以更轻松地发现其中的任何错误。一旦我们从生成器中消除了错误，这些错误就会永远消失。

在我从事的一个项目中，一个团队设计了一个复杂的数据库应用程序，该应用程序的设计规范厚2英寸，执行时间表冗长，充满了对性能的担忧。通过编写代码生成器，两个人在三个月内完成了工作，源代码清单(用C语言表示)厚约半英寸，生成的代码是如此之快以至于不成问题。临时计划每周产生一次，费用微不足道。

因此，在可以使用主动代码生成的情况下，这是双赢的。而且，我认为这正是编译器所做的事情并非偶然。

代码生成器是解决编程语言限制的方法。我个人更喜欢反射而不是代码生成器，但是我同意代码生成器更加灵活，并且在运行时生成的代码明显更快。我希望，将来的Cwill版本将包含某种DSL环境。

我们要找几个？我创建了两个主要的和许多次要的。第一个主要的程序使我能够生成1500个行式程序(给定或者接受)，这些程序具有很强的家族相似性，但被调整到数据库中的不同表，并且可以快速，可靠地执行该程序。

代码生成器的缺点是，如果生成的代码中存在错误(因为模板包含错误)，则需要进行很多修复。

但是，对于要进行大量接近重复的编码的语言或者系统，一个好的(足够多的)代码生成器是一个恩惠(比"狗狗"还多了一个恩惠)。

我使用的唯一代码生成器是webservice解析器。由于交接后新员工或者单独团队的维护问题，我本人远离代码生成器。

我编写自己的代码生成器，主要使用T-SQL，在生成过程中将其调用。

它们基于元模型数据生成触发器，日志记录，Cconst声明，INSERT / UPDATE语句，数据模型信息，以检查应用程序是否在预期的数据库架构上运行。

我仍然需要编写一个表单生成器以提高生产率，增加规格并减少编码;)

我创建了一些代码生成器。我有一个用于模板的SQL存储过程的被动代码生成器。这生成了90％的存储过程。

自从切换到实体框架以来，我已经在Visual Studio中使用T4(文本模板转换工具包)创建了一个活动的代码生成器。我已使用它为我们的实体创建基本的存储库部分类。效果很好，并节省了大量代码。我还使用T4来用某些属性装饰实体类。

是的 ，
我为AAA协议直径(RFC 3588)开发了自己的代码生成器。
它可以生成用于描述直径应用程序语法的XML文件中的直径消息的结构和Api。

这大大减少了开发完整直径接口(如SH / CX / RO等)的时间。

我使用EMF Eclipse建模框架提供的代码生成功能。

在许多情况下，代码生成器确实非常有用，尤其是在从一种格式映射到另一种格式时。我已经完成了IDL到C ++的代码生成器，数据库表到OO类型的代码生成器，以及编组代码的功能。

我认为作者试图提出的观点是，如果我们是开发人员，则应该能够使计算机为我们工作。生成代码只是自动化的一项显而易见的任务。

我曾经和一个坚持要他手动完成我们的IDL到C ++映射的人一起工作。在项目开始之初，他就能够跟上进展，因为我们其他人都在试图弄清楚该怎么做，但最终他成为了瓶颈。我在Perl中做了一个代码生成器，然后我们可以在几分钟内完成他的"工作"。