要foo吧,还是不要foo bar:这就是问题所在

这是最初在大型书呆子牧场的查尔斯布莱恩奎因在acts_as_conference上发表的演讲中讨论的内容.他正在讨论他从指导Ruby on Rails Bootcamp所学到的东西给许多新手编程和Rails新手的人.

突出的一个特别的幻灯片就是在尝试教别人编程时,从不使用foo和bar作为例子.他的推理非常简单.

哪个更容易理解？

baz = foo + bar

要么

answer = first_number + second_number

在解释某些内容时,我自己发生了很多次,然后我立刻跳到了foo bar占位符,然后意识到我的错误,并通过使用真实场景让这个例子变得更有意义.

这一点尤其适用于尝试教导没有编程曝光的人,并且在解释你实际上要教的内容之前最终需要解释foo和bar.

然而,对有经验的程序员使用foo和bar似乎没问题,尽管我个人认为,与Charles一起,这是需要改变的东西.

快速SO搜索"foo"会返回超过20页的结果,foo以我能理解的更多方式使用.在某些情况下,我正在阅读关于特定语言的问题,而我正在这样做以帮助更好地理解该语言.如果使用适用的变量名而不是foo和bar,则可以更容易理解和解释问题.因此对于经验丰富的开发人员来说,这个结构似乎也有点缺陷.

这是一种能够被踢的习惯吗？你为什么选择foo bar或者不选择foo bar？

它严格取决于你想要教什么.有时候,在展示一个编程示例时,你必须声明一些只是为了使代码片段"完整",而这几件事情并不是你所展示的核心内容.

例如,如果你想展示如何抛出异常,我相信可以提供一个类似的代码片段

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);
   }

}

因为它模糊了你想要教的东西.

我可以在与非程序员交谈时看到这一点,但是当你在白板上与一些团队成员讨论问题时......我会想念我的抱负和我的酒吧.我认为foo/bar的盛行是大多数程序员抽象思考的能力的一个例子.

如果您在训练场上,可能会出现更多问题.

我有时会用它们.但只有"真实"的名称不相关.