variables - significa - Para foo bar, o no para foo bar: esa es la pregunta
foo bar baz (10)
Además de evitar palabras sin sentido como foo & bar, 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 Coche en la clase de Conductor, nadie se va a confundir y pensar "¿Entonces eso significa que el Automóvil controla el Conductor entonces?".
Esto fue algo originalmente discutido durante una presentación dada por Charles Brian Quinn de Big Nerd Ranch en 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.
Una diapositiva particular que se destacó fue la de nunca utilizar foo y bar como ejemplos cuando se trata de enseñar a alguien a programar . Su razonamiento fue muy simple.
¿Cuál es más fácil de entender?
baz = foo + bar
o
answer = first_number + second_number
Muchas veces me ha sucedido a mí mismo al explicar algo y de inmediato salgo a la barra de foo, pero luego me doy cuenta de mi error y hago que el ejemplo tenga más sentido al usar un escenario del mundo real.
Esto es especialmente aplicable cuando se trata de enseñar a alguien que no ha tenido exposición en programación y termina necesitando explicar foo y bar antes de explicar lo que en realidad 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 maneras que puedo comprender. Y en algunos casos, cuando estoy leyendo una pregunta en un idioma en particular, lo hago para ayudar a comprender 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?
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.
Creo que se debe a la naturaleza sarcástica de muchos programadores. 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.
Depende estrictamente de qué estás tratando de 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 presentar un fragmento como
public void foo() {
// Do some things
if (errorCondition) {
throw new Exception("Error message");
}
}
Dado que el punto muestra excepciones, no tiene sentido preocuparse por el nombre del método, por lo que foo es "legal" en este contexto, o al menos para mí.
Lo que no aceptaría (en este mismo ejemplo) sería
public void foo() {
// Do some things
if (bar) {
throw new Exception(baz);
}
}
ya que está oscureciendo lo que estás tratando de enseñar.
Elijo no burlarme y excluirme cada vez 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 usar Foo y Bar es cuando se habla 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.
Los uso a veces Pero solo si un nombre "real" no es relevante.
Los uso cuando demuestro que cualquier valor de ''foo'' y ''bar'' será suficiente, como "puedes 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.
Para un programador totalmente nuevo, debo decir que los términos foo y bar pueden no ser conocidos. 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.
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 sea un problema mayor si estás en el campo de entrenamiento.
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 bar & 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 mantener 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.