2008-09-22 53 views

回答

8

如果代碼生成器在沒有正確的論證的情況下被廣泛使用,那麼代碼就不那麼容易理解,並且降低了可維護性(與動態SQL相同)。就我個人而言,我將它與一些ORM工具一起使用,因爲它們在這裏的用法大多很明顯,有時用於像搜索器 - 解析器算法和語法分析器這樣的事情,這些算法和語法分析器最近不是「手動」維護的。乾杯。

7

我們使用代碼生成器來生成數據實體類,數據庫對象(如觸發器,存儲過程),服務代理等等。任何地方你都會看到很多複製代碼遵循一個模式並涉及很多手動工作,所以代碼生成器可以提供幫助。但是,你不應該使用它太多,可維護性是一個痛苦。如果您想重新生成它們,也會出現一些問題。

像Visual Studio,Codesmith這樣的工具對於大多數常見任務都有自己的模板,並且使這個過程更容易。但是,您可以輕鬆地自行推出。

10

在硬件設計中,在'堆棧'的幾個層次上執行此操作是相當普遍的做法。例如,我寫了一個代碼生成器來發出各種寬度,拓撲結構和DMA引擎和交叉開關結構的Verilog,因爲表達這種參數化所需的結構在合成和仿真工具流程中尚不成熟。

將邏輯模型一直髮布到佈局數據,這對於可以用算法表示和生成的非常規的東西(如SRAM,高速緩存和寄存器文件結構)來說也是常規操作。

我也花了一段時間編寫本質上的代碼生成器,它將採用片上系統上所有寄存器的XML描述,併發布HTML(是的,是的,我知道XSLT,我只是發現它在編程上更具時間效率),Verilog,SystemVerilog,C,Assembly等等,爲不同團隊(前端和後端ASIC設計,固件,文檔等)提供了這些數據的「視圖」使用(並通過這個單一的XML「代碼庫」保持它們的一致性)。這算不算?

人們還喜歡爲例如編寫代碼生成器。對有限狀態機等常見事物進行簡潔的描述,並機械地輸出更詳細的命令式語言代碼來有效地實現它們(例如轉換表和遍歷代碼)。

+4

您不是第一個說過編寫代碼比使用XSLT更容易的人。 – 2009-07-08 21:40:49

1

可能會有很多的代碼生成在那裏,但我總是創造我自己的,使代碼更易於理解和適應的框架和準則,我們正在使用

0

是我不得不保持幾個。 CORBA或者其他一些對象通信風格的界面可能是我首先想到的一般東西。你有對象定義,這些對象定義是通過你要交談的接口提供給你的,但你仍然需要用代碼構建這些對象。構建和運行代碼生成器是一種相當常規的方式。爲了支持一些傳統的通信渠道,這可能會變得相當冗長,而且由於圍繞CORBA的包裝使其變得更簡單,所以事情變得更糟。一般來說,如果您有大量結構,或者只是需要使用快速變化的結構,但無法通過元數據處理構建對象的性能問題,那麼您就需要編寫代碼生成器。

1

我們對所有新代碼使用生成器來幫助確保遵循編碼標準。

我們最近用CodeSmith取代了我們的內部C++生成器。我們仍然需要爲該工具創建模板,但似乎不需要自己維護工具。

1

我最近需要一個生成器,它是一個從硬件讀取數據並最終將其發佈到「儀表板」UI的項目。中間是幾個數據點的模型,屬性,演示者,事件,接口,標誌等。我研究了幾個數據點的框架,直到我滿意地接受設計。然後,在一些精心設計的評論的幫助下,我把「代」放在一個視覺工作室的宏中,調整並清理宏,將數據點添加到宏中的一個函數中以調用這一代 - 並且節省了幾個繁瑣的時間?) 到底。

不要小看宏 :)


我現在還想把我的頭周圍CodeRush定製功能,以幫助我做一些更多的本地發電需求的力量。如果您在生成代碼塊時需要進行實時決策,那裏有強大的功能。

+0

是的,emacs和on-the-fly-lisp代碼非常適合推出重複性內容。 – Chris 2008-09-22 05:50:54

+0

同意。當我有嚴肅的重複代碼重寫的時候,沒有什麼能比得上可靠的舊Epsilon宏。 – 2009-01-26 14:06:33

2

在我看來,一個好的編程語言不需要代碼生成器,因爲自省和運行時代碼生成是語言的一部分,例如在python元類和新模塊等

1

我有我自己的代碼生成器,我對SQL表運行。它生成SQL過程來訪問數據,數據訪問層和業務邏輯。它在標準化我的代碼和命名約定方面做得很好。因爲它期望數據庫表中的某些字段(如id列和更新的datetime列),它也有助於標準化我的數據設計。

0

我想不出任何項目,我們需要從頭開始創建自己的代碼生成器,但有幾個地方我們使用了先前存在的生成器。 (我已經使用Antlr和Eclipse建模框架在Java中爲企業軟件構建解析器和模型。)使用其他人編寫的代碼生成器的美妙之處在於作者傾向於成爲該領域的專家並解決了問題我甚至不知道它是否存在。這爲我節省了時間和挫折。

所以,儘管我可能能夠編寫解決手頭問題的代碼,但我可以更快地生成代碼,並且很有可能它會比我寫的任何東西都少。

2

代碼生成器通常會在長期使用中生成更多難以管理的代碼。然而,如果絕對必須使用代碼生成器(eclipse VE for swing開發是我有時使用的),那麼請確保您知道正在生成的代碼。相信我,你不希望你的應用程序中的代碼不熟悉。

6

創建一個從規範生成代碼的代碼生成器通常很有用 - 通常是一個具有常規表格規則的代碼生成器。它減少了通過輸入錯誤或遺漏引入錯誤的機會。

0

如果你不打算編寫代碼,你會對其他人生成的代碼感到滿意嗎?

從長遠來看,它是否在時間和$$$方面都比較便宜以編寫自己的代碼或代碼生成器?

我在DTD或模式合規的方式寫了一個代碼生成器,將建立的類(JAVA)100的是將輸出XML數據從數據庫中。代碼生成通常是一次性的,然後代碼將隨着各種商業規則而變得更加智能化。輸出是針對一個相當迂腐的銀行。

20

在「語用程序員」亨特和托馬斯區分被動和主動代碼生成器。

無源發電機運行一次,然後編輯結果。

主動發生器任意經常地運行,因爲它會被替換,你永遠不應該修改的結果。

IMO,後者是更有價值,因爲他們的做法DRY(不 - 重複自己動手)的原則。 (A)(如元數據或DSL)以及每次程序運行時不同的部分(B)((A))(如元數據或DSL)更改的部分可分爲兩部分實時輸入),您可以編寫一個只需要A作爲輸入的生成器程序,並寫出一個僅以B作爲輸入的特設程序。 (另一個名字是部分評估)

生成器程序比較簡單,因爲它只需要通過輸入A而不是A和B進行操作。而且,它不必經常運行,因爲它並不經常運行,而且它不必關心內存泄漏。

的特設項目是更快,因爲它沒有通過輸入幾乎是始終不變的(A)涉水。這很簡單,因爲它只需要對輸入B做出決定,而不是A和B.

對於生成的臨時程序來說這是一個好主意,因此您可以更輕鬆地找到任何錯誤。一旦你從發生器中刪除錯誤,它們就會永遠消失。

在一個項目中我的工作,一個團隊設計出來,設計規範兩英寸厚和冗長的實施時間表,充滿了對性能的擔憂複雜的數據庫應用程序。通過編寫一個代碼生成器,兩個人在三個月內完成了這項工作,而源代碼清單(C)的厚度大約是半英寸,並且生成的代碼非常快以至於不成問題。特設計劃每週重新生成,成本微不足道。

所以有源代碼生成,時,你可以用它,是一個雙贏。而且,我認爲這正是編譯器所做的並不是偶然的。

0

代碼生成器可解決編程語言限制。我個人更喜歡反射而不是代碼生成器,但我同意代碼生成器更靈活,並且運行時的代碼明顯更快。我希望,未來的C#版本將包含某種DSL環境。

0

你在找幾個?我創造了兩個主要的和許多次要的。第一個主要的項目允許我生成程序1500個線程程序(給與或不帶),這些程序具有強烈的家族相似性,但與數據庫中的不同表格匹配 - 並且可以快速,可靠地執行。

代碼生成器的缺點是,如果有一個在生成的代碼中的錯誤(因爲模板包含一個bug),然後有很多固定要做的。但是,對於需要完成大量近乎重複的編碼的語言或系統來說,一個好的(足夠的)代碼生成器是一個好處(並且更多的是一個好處,而不是'doggle')。

0

我使用的唯一代碼生成器是webservice解析器。我個人遠離代碼生成器,因爲新員工或單獨的團隊在維護後出現問題。

0

我編寫自己的代碼生成器,主要是在構建過程中調用的T-SQL中。

基於元數據模型,它們所產生的觸發器,日誌記錄,C#const聲明,INSERT/UPDATE語句,數據模型信息,檢查應用程序是否在預期的數據庫架構上運行。

我仍然需要編寫提高生產力,更規範,少一個編碼形式產生;)

0

我已經創建了一些代碼生成器。我有一個使用模板的SQL存儲過程的被動代碼生成器。這產生了90%的存儲過程。

由於我們切換到了實體框架我創建使用T4(Text Template Transformation Toolkit)在Visual Studio中的積極codegenerator。我用它爲我們的實體創建基本的存儲庫部分類。工作非常好,並節省了一堆編碼。我也使用T4來裝飾具有特定屬性的實體類。

3

是的,我 開發的AAA協議的直徑(RFC 3588)我自己的代碼生成器。 它可以從描述直徑應用程序語法的XML文件中讀取直徑消息的結構和Api。

這大大縮短了開發全徑接口(如SH/CX/RO等)的時間。

0

代碼生成器在許多情況下非常有用,特別是從一種格式映射到另一種格式時。我已經完成了IDL到C++的代碼生成器,數據庫表到OO類型,以及編組代碼等等。

我認爲作者們試圖讓一點是,如果你是一個開發人員,你應該能夠使計算機爲您工作。生成代碼只是一個明顯的自動化任務。

我曾經和一個堅持要手動做我們的IDL到C++映射的人一起工作。在項目開始的時候,他能夠跟上,因爲我們其他人試圖弄清楚該怎麼做,但最終他成了一個瓶頸。我在Perl中做了一個代碼生成器,然後幾分鐘後我們幾乎可以完成他的「工作」。

0

請參閱我們的"universal" code generator基於程序轉換。

我是架構師和關鍵實施者。 值得注意的是,這個發生器的很大一部分是使用這個發生器產生的。

0

在嵌入式系統中,有時需要在閃存中有大塊的二進制數據。例如,我有一個需要包含位圖字體符號的文本文件,並將其轉換爲一個.cc/.h文件對,聲明有趣的常量(如第一個字符,最後一個字符,字符寬度和高度),然後將實際數據作爲一個大的static const uint8_t[]

試圖在C++本身做這樣的事情,所以字體數據會自動生成編譯沒有第一遍,將是一個痛苦,很可能難以辨認。手寫一個.o文件是不可能的。因此,打破方格紙,手編碼爲二進制,並打字所有英寸

恕我直言,這種事情是什麼代碼生成器的。 永遠不要忘記,電腦適合你,而不是相反。

順便說一句,如果你使用一臺發電機,永遠永遠永遠包括一些線路如這個在每個生成的文件的開頭和結尾都:

// 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. 
0

我們使用Telosys工具代碼生成器在我們的項目中:https://sites.google.com/site/telosystools/

我們已經創建它來減少像CRUD屏幕,文檔等經常性任務的開發時間...

對我們來說,最重要的是能夠自定義生成器的模板,以便在必要時創建新生成目標並定製現有模板。這就是爲什麼我們還創建了一個模板編輯器(用於Velocity .vm文件)。 它適用於Java/Spring/AngularJS代碼生成器,可以適應其他目標(PHP,C#,Python等)

1

爲項目編寫自己的生成器效率不高。相反,請使用T4,CodeSmith和Zontroy等生成器。

T4更復雜,你需要知道.Net編程語言。您必須逐行編寫模板,並且必須自行完成數據關係操作。您可以通過Visual Studio使用它。

CodeSmith是一個功能性的工具,並有大量的模板可供使用。它基於T4,編寫自己的temlate需要花費太多的時間,因爲它在T4中。有一個試用版和一個商業版。

Zontroy是一個新的工具,具有用戶友好的用戶界面。它有自己的模板語言,很容易學習。有一個在線模板市場,它正在發展。即使您可以提供模板並通過市場在線銷售它們。 它有一個免費和商業版本。即使免費版本也足以完成一箇中等規模的項目。

相關問題