創意術語

Question

我似乎經常使用諸如node ， property ， children （等）之類的乏味單詞，而且我擔心其他人僅僅因為這些部分的名稱是含糊的通用單詞而難以理解我的代碼。

您如何找到類和組件的創意名稱，以使其更令人難忘？

對於那些沒有真正描述的通用工具，除了它們的通用功能目的之外，我尤其感到麻煩。 我想知道其他人是否找到了創造性的方式來命名事物，而不是僅僅通過其實用程序來命名它們，例如AnonymousFunctionWrapperCallerExecutorFactory 。

Answer 1

很難回答。 我發現它們僅僅是因為它們看起來“合適”。

但是，我確實知道，除非發現正確的名稱，否則我基本上無法繼續編寫代碼，而且感覺“不錯”。 如果命名不正確，我會發現它很難使用，並且代碼通常令人困惑。

我不太擔心“難忘”的事情，而只是“准確”的事情。

眾所周知，我經常坐在外面大聲思考要命名的東西。 花點時間，並確保您對這個名稱感到非常滿意。 不要害怕使用常見/簡單的單詞。

Answer 2

使用“隱喻”是敏捷（和模式）文學中的常見主題。

“孩子”（在您的問題中）是一個被廣泛使用且有充分理由的比喻的例子。

因此，我鼓勵使用隱喻，只要它們是適用的，而不是想象力的延伸。

隱喻在計算中無處不在。 從文件到錯誤，再到流的指針……您無法避免。

Answer 3

我真的沒有答案，但是您需要考慮三件事。

1. 已故的菲爾·卡爾頓（Phil Karlton）曾有句著名的話：“計算機科學中只有兩個難題：緩存失效和命名事物。” 因此，您很難拿出好名字這一事實是完全正常的，甚至可以預料的。
2. OTOH，在命名時遇到麻煩也可能是不良設計的標志。 （是的，我非常清楚，＃1和＃2相互矛盾。或者也許人們應該更像是相互平衡。）例如，如果一件事情承擔太多責任，那就幾乎不可能實現取個好名字 （見證所有不良OO設計中的“ Service”，“ Util”，“ Model”和“ Manager”類。下面是Google代碼搜索“ ManagerFactoryFactory”的示例。）
3. 另外，您的姓名應映射到主題專家使用的領域術語。 如果找不到主題專家，則表明您目前正在擔心自己不應該擔心的代碼。 （基本上，應該很好地實現和設計實現您核心業務領域的代碼，應該這樣來實現和設計輔助領域中的代碼，並且根本不應該實現或設計所有其他代碼，而應該從供應商那里購買您所購買的是他們的核心業務領域。[請自由地解釋“購買”和“供應商”。社區開發的免費軟件就可以了。]）

關於上面的＃3，您在另一條評論中提到您當前正在實現樹數據結構。 除非您的公司從事銷售樹數據結構的業務，否則這不是您的核心域的一部分。 找不到好名字的原因可能是您在核心領域之外工作。 現在，“銷售樹形數據結構”聽起來可能很愚蠢，但是實際上有一些公司這樣做。 例如，Microsoft開發人員部門內的BCL團隊：他們實際上銷售（無論如何，對於“銷售”的某些定義來說）.NET框架的基類庫，其中包括樹數據結構。 但是請注意，例如Microsoft的C ++編譯器團隊實際上（從字面上）是從第三方供應商那里購買其 STL –他們認為其核心領域是編寫編譯器，而將庫的編寫工作留給了一家公司，而該公司考慮將STL編寫為其核心領域。 。 （實際上，對於AFAIK而言，該公司除了編寫和銷售STL實現外什么都不做。這是他們的唯一產品。）

但是，如果出售樹型數據結構是您的核心領域，那么列出的名稱就可以了。 它們是主題專家（在這種情況下為程序員）在談論樹數據結構域時使用的名稱。

Answer 4

我認為，出於標准化和交流的目的，最好使用通用的vocab，就像在相同情況下用於設計模式一樣。 我遇到一個程序員，他一直在“發明”自己的術語，但在理解他時遇到了麻煩。 （他一直使用“事件編排”一詞，而不是“腳本”或“ FCFS過程”。盡管如此，創造力還是值得贊揚的！）

這些常見的詞匯描述了我們習慣的東西。 節點是點，在圖形中的某處，在一棵樹中或諸如此類。 一種方法是特定於域。 如果我們正在處理映射問題，則可以使用“位置”代替“節點”。 從某種意義上說，這至少對我有幫助。 因此，我發現需要兼顧與其他程序員進行通信的能力，同時保持足夠具體的描述符以幫助我記住它的作用。

Answer 5

我認為節點，子級和屬性都是好名字。 我已經可以通過它們的“平淡”名稱來猜測有關您的班級的以下內容：

• 節點-此類是對象圖的一部分
• children-此變量保存屬於該包含節點的節點列表。

我認為“節點”既不模糊也不常見，如果您正在編碼通用數據結構，則可以使用通用名稱！ （話雖如此，如果您正在編寫一棵樹，則可以使用諸如TreeNode之類的東西來強調該節點是樹的一部分。）一種使使用API​​的開發人員的生活更輕松的方法是遵循平台內置庫的命名約定。 如果每個人都將節點稱為節點，將迭代器稱為迭代器，則生活變得輕松。

Answer 6

反映類，方法或屬性目的的名稱比具有創造力的名稱更容易記住。 現代化的IDE使得使用更長的名稱變得更加容易，因此需要付出一定的描述費用。 變得有創意並不能像獲得准確一樣多。

Answer 7

我建議從特定的應用程序領域中選擇名詞。 例如，如果您將汽車放在樹上，則調用節點類Car-它也是一個節點的事實應該從API中明顯看出。 另外，不要在實現中嘗試過於通用-不要將汽車的所有屬性放入名為屬性的哈希表中，而應為品牌，顏色等創建單獨的屬性。

Answer 8

許多語言和編碼風格都喜歡使用各種描述性前綴。 在PHP中沒有明確的類型，因此這可能會很有幫助。 而不是做

$isAvailable = true;

嘗試

$bool_isAvailable = true;

公認這是一種痛苦，但通常值得花時間。

我也喜歡使用長名稱來描述事物。 它可能看起來很奇怪，但是通常更容易記住，尤其是當我回去重構代碼時

$leftNode->properties < $leftTreeNode->arrayOfNodeProperties;

如果其他所有方法都失敗了。 為什么不退回到堅實的星球大戰主題節目。

$luke->lightsaber($darth[$ewoks]);

最后，在大學里，我以老師的名字給班級命名，然后我的班級將所有我想做的事情都當作方法來處理。

$Kube->canEat($myShorts, $withKetchup);