最近，我寫了與實現相關的名稱，并提供了一些示例，這些示例由于方法名稱與主體之間的緊密關系而導致方法名稱不正確。

有一會兒，我們有以下代碼：

boolean isComplexOrUnreadableWithTests() { return (complex || unreadable) && tests.exist(); }

只是為了提醒您上下文：應該確定我們是否可以進行重構：

if (code.isComplexOrUnreadableWithTests()) {doRefactoring(code); }

最近，我告訴您該名稱是錯誤的，因為它與實現有直接關系。 但是，這不是唯一的問題。 在方法名稱中使用連接詞是一個標志，表明我們找不到正確的名稱，而僅列出了我們已經完成的所有已知操作。 此列表與實現或邏輯相關都無關緊要。

關于實現還是邏輯？

如果我想將isComplexOrUnvisibleWithTests（）方法的名稱更改為：

boolean isJustifiedAndPossible() { return (complex || unreadable) && tests.exist(); }

會更好嗎？ 現在不是基于邏輯的名稱嗎？

我們有關于合理性的部分：

(complex || unreadable)

關于重構的可能性：

tests.exist()

當實現更改時，我們不需要更改名稱，對嗎？ 好吧，不完全是。 讓我解釋。

我們沒有將面向實現的名稱更改為面向邏輯的名稱。 我們只是混合了。 我們使用已知的詞（可能來自領域）將實現隱藏在這兩個術語后面。 但是，通過閱讀方法的名稱，我們仍然知道問題的答案如何。 而且我們仍然不知道最初的問題是什么。

當結果為布爾值時，我假設所問的問題類似于“是嗎？” 。 以給出的名稱，我們仍然沒有關于“某物”的任何信息。

同樣，該方法的名稱沒有我們想象的那么持久。 如果在開發過程中，我們決定從代碼中刪除tests.exist（）部分，則需要在名稱中反映此更改并將其更改為：

boolean isJustified() { return complex || unreadable; }

此外，您可能會注意到，現在該名稱可以準確告訴您問題所在。

但是，初始更改需要在方法主體內部及其名稱上進行更改。

遺失詞

除了方法本身的名稱之外，在某些情況下，我們使用已知術語來描述新事物，但不命名，可能會導致更多問題：

• 交流 -每次談論時都會解釋該術語。 您只想讓另一個人對相同上下文的理解。 用一個單獨的短語來表達“ The Something”會更好嗎？
  例如，您可能想像一下如果您不能使用設計模式的名稱，與其他開發人員的對話將是什么樣子。 這些對話肯定會更長，并且會帶來更高的誤解風險。
  缺少術語會導致完全相同的問題。
• 復制 –有人可能會問相同的問題，但是由于缺少適當的用語，他們不能百分百確定問題是否真的相同，是否有相同的意圖。 在這種情況下，他們有機會選擇一種更簡單的方法，只編寫可以給他們答案的代碼。
• 提出相同的問題 -缺少術語意味著當我們想提出相同的問題時，很難找到此代碼。 為什么？ 因為我們不知道要尋找什么。 或者我們可能知道，但是代碼本身無法表達意圖，我們正在尋找的內容與編寫的內容之間可能沒有關系。

如何發現問題？

嗯，這并不總是像給定示例中那樣容易。 但是，有兩件事可以幫助您確定名稱是好還是需要改進：

• 結合語 –我們討論了單一職責原則 ，因此在編寫代碼時應用此原則很重要。 并沒有出現不遵循SRP的征兆嗎？ 當我們使用“和”或“或”之類的詞時，我們通常談論的不止一件事。
  只要在變量，方法或類的名稱中發現連詞，就應將其視為警告。 有很大的機會需要改進。
• 正文更改會導致名稱更改 -如果代碼更改不能更改功能背后的全部原理，但仍需要更改方法/類的名稱，則表明該名稱可能未表示真實意圖。
  在這種情況下，我們應該重新考慮名稱并加以改進。

你好，我的名字是…

我知道有時候找到一個好名字要比編寫實現難得多，但這并不意味著我們不應該嘗試。 使名稱盡可能具有描述性和準確性符合我們自己的利益。 這將節省我們將來的時間。

翻譯自: https://www.javacodegeeks.com/2016/06/conjunctions-we-hate.html

總結

以上是生活随笔為你收集整理的连词我们…讨厌的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。