26

Esto fue algo originalmente discutido durante una presentación dada por Charles Brian Quinn del Big Nerd Ranch al acts_as_conference. Hablaba de lo que había aprendido al impartir un Ruby on Rails Bootcamp a mucha gente nueva en programación y nueva en Rails.Para foo bar, o no para foo bar: esa es la pregunta

Una diapositiva particular que se destacó fue a lo largo de las líneas de nunca utilizando foo y barra como ejemplos cuando se intenta enseñar a alguien a programar. Su razonamiento fue muy simple.

¿Qué es más fácil de entender?

baz = foo + bar 

o

answer = first_number + second_number 

Ha sucedido muchas veces a mí mismo cuando explica algo y de inmediato salta a la marcha a foo marcadores de posición de la barra, pero luego darse cuenta de mi error y hacer que el ejemplo tiene mucho más sentido mediante el uso de un escenario del mundo real.

Esto es especialmente aplicable cuando se trata de enseñar a alguien que no ha tenido exposición de programación y termina necesitando explicar foo y barra antes de explicar lo que realmente está tratando de enseñar.

Sin embargo, usar foo y barra para programadores experimentados parece estar bien, aunque personalmente creo, junto con Charles, que es algo que debe cambiar.

Una búsqueda rápida de SO para "foo" devuelve más de 20 páginas de resultados con foo que se usa de más formas que puedo comprender. Y en algunos casos, cuando estoy leyendo una pregunta en un idioma en particular, lo hago para ayudar a entender mejor ese idioma. Si se usan nombres de variable aplicables en lugar de foo y bar, es mucho más fácil comprender e interpretar el problema. Entonces, para los desarrolladores experimentados, la construcción parece un poco defectuosa también.

¿Es este un hábito que alguna vez podrá ser pateado? ¿Por qué eliges foo bar o no foo bar?

+3

Gran pregunta. (+1) –

+1

Intenta enseñarle a la gente a utilizar buenos nombres de variables y lo primero que hace es lanzarles "foo and bar". Puedo decir que esto es más frustrante para los que no hablan inglés ya que se confunden y no entienden lo que es foo y bar, y pueden pensar que foo y bar son construcciones de lenguaje. –

Respuesta

35

Depende estrictamente de lo que intente enseñar. A veces, al mostrar un ejemplo de programación, debe declarar algunas cosas solo para que el fragmento sea "completo", y esas pocas cosas no son el núcleo de lo que está mostrando.

Por ejemplo, si desea mostrar cómo lanzar una excepción, creo que está bien para presentar un fragmento como

public void foo() { 

    // Do some things 

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

} 

Desde el punto en que está mostrando excepciones, no hay ningún punto en el cuidado sobre el nombre del método, entonces foo es "legal" en este contexto, o al menos para mí.

Lo que yo no aceptaría (en este mismo ejemplo) sería

public void foo() { 

    // Do some things 

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

} 

ya que oscurece lo que está tratando de enseñar.

15

Puedo ver el punto cuando hablo con no programadores, pero cuando estás en una pizarra discutiendo un problema con algunos miembros del equipo ... extrañaría mis foos y mis bares. Creo que la prevalencia de foo/bar es un ejemplo de la capacidad de la mayoría de los programadores para pensar de forma abstracta.

Probablemente más un problema si estás en el campo de entrenamiento.

+0

Excelente punto para pensar abstractamente. Eso es algo que nunca consideré. – mwilliams

7

Los uso a veces. Pero solo si un nombre "real" no es relevante.

1

Elijo no engañar y prohibir siempre que mi público esté lo suficientemente familiarizado con el concepto en cuestión, que sería perjudicial para su comprensión.

La única vez que se debe utilizar Foo and Bar es cuando se trata de algo tan abstracto que agregar un contexto requeriría una discusión adicional. Entonces, Foo y Bar son mucho más legibles y crean código que es más seguido que las alternativas, como x, y y z.

3

Los uso cuando demuestro que cualquier valor de 'foo' y 'bar' será suficiente, como "puede obtener el tamaño de un objeto con sizeof (foo)". Es útil para lograr que las personas comprendan el concepto general y no solo los detalles. Por ejemplo, si dijera "puedes obtener el tamaño de un objeto con algo como sizeof (int)", entonces casi está garantizado que alguien pregunte si eso también funciona para flotadores.

0

Soy nuevo en la programación, y más o menos autodidacta. Leí mucho código de ejemplo en línea y al principio me encontré reemplazando foo y barra & c. con nombres más relevantes, como los ejemplos firstnumber y secondnumber anteriores.

Ahora prefiero x, y, z, i ... porque foo y bar parecen despertar impulsos lingüísticos en mi mente y pueden distraerme de la rutina, y he desarrollado, de alguna manera, la capacidad de sostener una todo un montón de diferentes variables en mi cabeza y recordar lo que son. Pero definitivamente recomendaría usar nombres relevantes cuando enseñe a otra persona, especialmente cuando explique el código a alguien que no programa pero necesita entender cómo funciona el programa.

1

Creo que es debido a la naturaleza sarcástica de muchos programadores, o tal vez no tan suavemente. Mientras que muchas personas han tratado de poner diferentes significados en foo/bar la mayoría, o al menos muchos, de nosotros pensamos en "FUBAR", F ** K Up Beyond All Recognition. Es una forma para que la gente "con experiencia" haga un comentario sarcástico sobre los demás.

Debido a esto, nunca lo uso para no programadores y rara vez lo uso, incluso con programadores experimentados. Si lo uso, puede apostar que estoy haciendo una referencia velada al tema en cuestión.

+0

Nadie podría convencerme de que 'foo' y' bar' significan algo diferente y no me gusta su uso. El código de muestra debe usar etiquetas con significado como "aguja" y "pajar" – TecBrat

+0

Vi una excelente alternativa en los enlaces de "preguntas relacionadas": 'spam',' eggs' y 'spam_and_eggs'. Pero incluso estos solo deberían usarse cuando más etiquetas específicas de contexto detraen la comprensión. – TecBrat

1

Además de evitar palabras sin sentido como la barra foo &, he descubierto que es mucho más importante proporcionar ejemplos de código para escenarios del mundo real que tienen las mismas relaciones. Esto realmente ayuda al alumno a comprender un tema adecuadamente y evita malentendidos. Por ejemplo, si enseño sobre Inyección de dependencia y muestro código de ejemplo donde se inyecta una instancia de la clase Car en la clase Driver, nadie se confundirá y pensará "¿Entonces eso significa que el coche controla el controlador?".

2

Para el programador totalmente nuevo, tengo que decir que los términos foo y bar pueden no conocerse. Pensé que eran algo específico del lenguaje (es decir, C), pero después de hacer clic en Wikipedia ahora sé que son portadores de lugares abstractos. Entonces, si su público está formado por personas que no conocen sus significados, algo más es mucho más claro. También first_number y así dice que esos son números como sea que se presenten y no algo más.

1

Creo que hay otra razón importante para usar foo y bar en ejemplos. Estos nombres dejan en claro que no está invocando ninguna palabra clave mágica.Cada vez que leo algunos documentos o ejemplos de código, me gusta que las partes arbitrarias del ejemplo se distingan claramente de las partes necesarias.

Si sustituyó la palabra sin sentido por lo que genéricamente representa en el código de ejemplo, podría terminar con algunos nombres que se parecen mucho a las palabras clave, clases o métodos que intenta explicar. El prefijo "mi", como en myNumber, myFunction, es un buen compromiso que hace que los nombres se destaquen como arbitrarios.

Cuestiones relacionadas