去foo吧，還是不去foo吧：那就是問題

這是Charles Charles Quinn在Big Nerd Ranch在acts_as_conference給出的介紹中最初討論的東西。他正在討論他從指導Ruby on Rails Bootcamp的過程中學到了什麼，這些人都是編程新手和Rails新手。去foo吧，還是不去foo吧：那就是問題

一個突出的幻燈片沿着的線條，當試圖教某人編程時從不使用foo和bar作爲示例。他的推理非常簡單。

哪一個比較容易理解？

baz = foo + bar

或

answer = first_number + second_number

這是發生很多次自己的時候解釋什麼，我立刻跳到轉到foo的酒吧佔位但後來意識到我的錯誤，讓這個例子做很多更有意義的使用一個真實世界的場景。

當你試圖教導一個沒有編程風險的人時，你最終需要解釋foo和bar，然後才能解釋你實際上想教的內容，這尤其適用。

然而，對於有經驗的程序員來說，使用foo和bar看起來還不錯，儘管我個人認爲，和Charles一樣，這是需要改變的。

快速搜索「foo」會返回超過20頁的結果，其中foo會以更多方式用於我能理解的情況。在某些情況下，我正在閱讀某個特定語言的問題，並且正在幫助我們更好地理解該語言。如果使用適用的變量名稱而不是foo和bar，則可以更容易理解和解釋問題。因此對於經驗豐富的開發人員來說，構造似乎也有點缺陷。

這是一種能夠被踢的習慣嗎？你爲什麼選擇富酒吧或不富酒吧？

來源

2008-10-24 mwilliams

偉大的問題。（+1） – 2010-10-09 15:27:29

你試着教人們使用好的變量名，你做的第一件事就是向他們扔「foo and bar」。我可以說這對非英語人士來說更令人沮喪，因爲他們感到困惑，不明白foo和bar是什麼，並且可能認爲foo和bar是語言結構。 – 2012-07-03 08:09:02

這嚴格取決於你想教什麼。有時候，在展示編程示例時，您必須聲明幾件事情，只是爲了使代碼片段「完整」，而這些少數內容不是您所展示內容的核心。

例如，如果你想展示如何拋出異常，我相信它是確定呈現片段像

public void foo() { 

    // Do some things 

    if (errorCondition) { 
     throw new Exception("Error message"); 
    } 

}

由於它的點顯示異常，有在關心毫無意義關於方法名稱，所以foo在這種情況下是「合法的」，或者至少對我而言。

我不會接受什麼（在這個同樣的例子）是

public void foo() { 

    // Do some things 

    if (bar) { 
     throw new Exception(baz); 
    } 

}

，因爲它是模糊你想教什麼。

來源

2008-10-24 17:38:11

我可以在與非程序員交談時看到這一點，但是當您在白板上討論某些團隊成員的問題時。我會想念我的foos和我的酒吧。我認爲foo/bar的流行是大多數程序員抽象思考能力的一個例子。

如果你在訓練場上，可能更像是一個問題。

來源

2008-10-24 17:36:24 Niniki

抽象地思考的優點。這是我從未考慮過的事情。 – mwilliams 2008-10-24 17:39:05

我有時會使用它們。但只有當一個「真實」的名字是不相關的。

來源

2008-10-24 17:37:33

我選擇不foo和bar每當我的觀衆是手頭的概念，這將被證明是一個損害他們的理解不夠熟悉。

Foo和Bar應使用唯一的一次是當你在談論的東西非常抽象，添加上下文需要進一步討論。然後，Foo和Bar的可讀性更高，並且創建的代碼比可選項更容易遵循，如x，y和z。

來源

2008-10-24 17:38:57

證明「富」和「酒吧」的任何值就足夠了，就像當我使用它們「你可以用的sizeof（富）獲得一個物體的大小。」讓人們瞭解總體概念而不僅僅是詳細信息很方便。例如，如果我說「你可以用sizeof（int）」來獲得對象的大小，那麼幾乎可以保證有人會問這個對象是否也適用於float。

來源

2008-10-24 17:43:36

我是新手編程，或多或少的自學。我在網上閱讀了很多示例代碼，並在開始時發現我自己更換了foo和bar & c。並提供更多相關的名稱，例如上面的第一個和第二個數字。

我現在更喜歡x，y，z，i ......因爲foo和bar似乎引發了我心中的語言衝動，並且可以分散我的注意力，並且我開發了一些能夠保持我腦袋裏有很多不同的變數，記住它們是什麼。但是，在教別人的時候，我仍然會推薦使用相關的命名方式，特別是向不編程但需要了解程序如何工作的人解釋代碼時。

來源

2009-01-06 21:25:37 user51498

我認爲這是由於溫和的，或許不是那麼婉轉，很多程序員的諷刺性質。儘管很多人都試圖在foo/bar上賦予不同的意義，但至少有很多人認爲「FUBAR」，F ** K超越了所有認可。它是讓「有經驗」的人對別人做出諷刺評論的一種方式。

因爲如此，我從來沒有使用它對於非程序員也很少使用它，即使有經驗的程序員。如果我確實使用了，你可以打賭，我正在暗中提及手頭的主題。

來源

2009-01-06 21:34:57

除了避免像foo &這樣的無意義詞語之外，我發現爲具有相同關係的實際場景提供代碼示例更爲重要。這確實有助於學習者正確理解主題並防止誤解。例如，如果我正在教授依賴注入，並展示將Car類的一個實例注入到Driver類中的示例代碼，那麼沒有人會感到困惑並思考「那意味着Car會控制Driver？」。

來源

2009-01-06 21:46:43

對於全新的程序員，我必須說，條款foo和bar可能不知道。我認爲他們是語言特定的（即C），但在維基百科之後，我現在知道他們只是抽象的佔位符。所以如果你的觀衆是由不瞭解他們意義的人組成的，那麼其他的東西就更加清晰了。 first_number也是這樣說的，那些數字是如何被呈現的，而不是別的。

來源

2009-05-14 21:52:37

我認爲這是對的例子使用foo和bar另一個重要原因。這些名稱清楚地表明您沒有調用任何魔術關鍵字。每當我閱讀一些文檔或代碼示例時，我都喜歡將示例的任意部分與必要的部分區分開來。

如果您在示例代碼中替代了一般代表的無意義單詞，那麼您最終可能會得到一些與您想要解釋的關鍵字，類或方法非常相似的名稱。「我的」前綴，如myNumber,myFunction，是一個很好的折衷方案，使得名稱突出顯示爲任意。

來源

2012-06-17 10:49:09

去foo吧，還是不去foo吧：那就是問題

回答

相關問題