你遵循原程序員的命名約定嗎？

Question

如果你從某人手中接過一個項目來做簡單的更新，你是否遵循他們的命名約定？我剛剛收到一個項目，其中前任程序員到處使用匈牙利符號。我們的核心產品有一個命名標準，但我們有很多人在過去幾年中進行自定義報告並做他們想做的事情。

我沒有時間去更改代碼中已經存在的所有變量名。

我傾向於readablity只是爲了繼續他們的命名約定。

Answer 1

是的，我喜歡。它使得後面繼承它的人更容易遵循。如果真的很難理解，我會盡量清理代碼，使其更具可讀性。

Answer 2

通常情況下，製作一個代碼庫批發變化正好與風格指南，以符合只是一個介紹由於缺乏高附加值新的錯誤方式。

這意味着要麼你應該：

1. 更新你的工作代碼爲你進行這項工作符合準則。

2. 使用代碼中的約定來幫助將來的維護工作。

我推薦2.，但匈牙利符號使我的眼睛流血：頁。

Answer 3

一般來說，是的，在這種情況下，我會遵循常規和標準的可讀性。沒有人喜歡這個答案，但是爲了保持代碼的長期可維護性是正確的。

當一個好的程序員的閱讀代碼，他應該能夠解析變量名和跟蹤多個在他的頭上 - 只要他們保持一致，至少在源文件中。但是，如果你打破了這種一致性，這可能會迫使程序員閱讀代碼，使其遭受一些認知上的不和諧，而這會使它難以跟蹤。這不是一個殺手 - 好的程序員會通過它，但他們會詛咒你的名字，並可能會在TheDailyWTF上發佈你。

Answer 4

如果您維護的代碼別人寫的，其他人會照顧你保持，你應該爲每個人都參與不作無償的變化。當他們進入源代碼控制系統以查看更改的內容時，他們應該看到解決您正在處理的問題的必要條件，而不是百萬差異，因爲您執行了一系列全局搜索並將代碼替換或重新格式化爲適合你最喜歡的大括號匹配慣例

當然，如果原始代碼真的很糟糕，所有投注都關閉。

Answer 5

我當然會繼續使用相同的命名約定，因爲它會保持一致的代碼（哪怕是一貫醜陋），比混合變量命名約定更具可讀性。人類大腦在模式識別方面似乎相當擅長，並且您並不是真的想通過無故打破所述模式而將大腦拋出弧形球。

這就是說，我只是一些匈牙利符號，但如果這就是你一直在... ...

Answer 6

就我個人而言，每當我接管一個具有不同變量命名方案的項目時，我傾向於保持前一個程序員正在使用的方案。我做的唯一不同的是我添加的任何新變量，我在變量名前面加下劃線。這樣我就可以快速查看我的變量和代碼，而無需進入源代碼歷史記錄和比較版本。但是當談到我繼承簡單的無法讀取的代碼或評論時，我通常會通過它們並在不重寫所有內容的情況下儘可能清理它們（它已經到了）。組織是擁有可擴展代碼的關鍵！

Answer 7

，如果我可以閱讀代碼，我（試行）採取同樣的約定 如果它不是可讀反正我需要重構，從而改變它（取決於它像什麼）相當

Answer 8

依賴。如果我正在構建一個新應用程序並從具有垃圾變量命名的傳統應用程序中竊取代碼，那麼只要將其添加到我的應用程序中，我就會重構。

Answer 9

如果您沒有將所有現有的代碼更改爲您的標準，那麼只要您更改這些文件，我就會堅持原始約定。在同一個文件中混合使用兩種代碼會破壞一致代碼風格所帶來的好處，而下一個人將不得不自問「誰寫了這個函數，它叫什麼--FooBar（）或fooBar（ ）？」

當您導入第三方庫時，這種事情變得更加棘手 - 您不想重寫它們，但是它們的代碼風格可能與您的代碼風格不匹配。所以最終你會得到幾種不同的命名約定，最好在「我們的代碼」和「他們的代碼」之間劃清界限。

Answer 10

如果文件或項目已使用一致的樣式編寫，那麼即使它與您現有的樣式衝突/矛盾，您也應該嘗試遵循該樣式。代碼風格的一個主要目標是一致性，所以如果您向代碼中引入了不同的風格（已經是一致的）（本身內部），則會失去一致性。

如果代碼寫得不好，需要一定程度的清理才能理解它，那麼清理樣式就成爲一個更相關的選項，但是隻有在絕對必要時才應該這樣做（特別是如果沒有單元測試的話）當你運行引入意想不到的改變的可能性。

Answer 11

絕對，是的。我不相信最好遵循原始程序員的命名約定的一種情況是，原始程序員（或從那時起修改代碼的後來的開發者）未能遵循任何一致的命名約定。

Answer 12

是的.. 有一點讓人更加沮喪，然後走進一個具有兩種截然不同風格的應用程序。我一直在努力的一個項目有兩種不同的操縱文件的方式，兩種不同的方式來實現屏幕，兩種不同的基本結構。第二個編碼器甚至讓新功能成爲從主代碼調用的dll的一部分。當我在一節中，我正在與正確的工作一起工作時，維護是噩夢，我必須學習範式和希望。

Answer 13

當在羅馬做羅馬人做的。

（除了索引變量的名稱，例如「iArrayIndex ++」。停止縱容該白癡）

Answer 14

我想使一個錯誤修復作爲外科手術過程的。進入，儘可能少打擾，修理它，走出去，留下儘可能少的痕跡。

Answer 15

我同意建議將作爲作者的代碼留在代碼中，只要代碼內部保持一致，就可以使用。如果代碼由於不一致而難以遵循，那麼對未來的維護者（可能是您）有責任使其更加清晰。

如果花費40個小時來確定函數做了什麼，因爲它使用命名不當的變量等，則應爲重構/重命名以清晰/添加註釋/做適合情況的任何操作。也就是說，如果唯一的問題是作者使用的大多數一致風格與公司標準或您習慣的風格不同，我認爲您正在浪費時間重命名所有內容。另外，如果原作者仍然有問題，您可能會失去專業知識，因爲他不會再識別代碼。

Answer 16

我這樣做，但不幸的是，在那裏有幾個開發者沒有遵守這個規則，所以我有幾個命名約定可供選擇。

但是有時候我們有時間把事情調整到最後，它會很好，很乾淨。

Answer 17

如果代碼已經有一致的風格，包括命名，我會試着按照它。如果以前的程序員不一致，那麼我可以自由地應用公司標準，或者如果沒有任何公司標準，我可以使用我的個人標準。

在任何一種情況下，我都會嘗試通過評論來標記所做的更改。我知道今天的CVS系統通常沒有這樣做，但我仍然喜歡這樣做。

Answer 18

不幸的是，大多數時候答案是肯定的。大多數情況下，代碼並不遵循良好的慣例，因此很難遵循先例。但爲了可讀性，有時需要遵循流程。

但是，如果它足夠小，我可以重構很多現有代碼以更好地「聞」，那麼我會這樣做。或者，如果這是一個更大的重寫的一部分，我也將開始編碼當前的編碼標準。但通常情況並非如此。

Answer 19

是的。我實際上是在標準文檔中寫下來的。我在當前公司創建了：

現有代碼取代所有其他標準和實踐（無論它們是行業標準還是本文檔中的標準）。在大多數情況下，你應該變色龍你的代碼在同一個文件是否符合現有的代碼，原因有二：

1. 爲了避免單個模塊/文件中的多個截然不同的風格/模式（相抵觸的目的標準和妨礙可維護性）。
2. 重構現有代碼的努力很容易導致不必要的成本更高（耗時且有助於引入新的錯誤）。

Answer 20

如果在現有的應用程序中有一個標準，我認爲最好遵循它。如果沒有標準（製表符和空格混合，無處不在......大括號），那麼我會做我覺得最好的事情，並通常通過格式化工具（如Vim）運行現有的代碼。如果存在一致的風格，我將始終保持現有代碼的大小寫風格等。

我的一個例外是，我不會用匈牙利命名法，除非有人用槍指着我的頭。我不會花時間重新命名現有的東西，但是我添加的任何東西都不會有任何匈牙利疣。