"A", "an" y "the" en nombres de métodos y funciones: ¿Cuál es su opinión? [cerrado]

16

Cerrada . Esta pregunta está basada en la opinión . Actualmente no está aceptando respuestas.

¿Quieres mejorar esta pregunta? Actualice la pregunta para que pueda ser respondida con hechos y citas editando esta publicación .

Cerrado hace 5 años .

Estoy seguro de que muchos de nosotros hemos visto nombres de métodos como este en un momento u otro:

UploadTheFileToTheServerPlease
CreateATemporaryFile
WriteTheRecordToTheDatabase
ResetTheSystemClock

Es decir, nombres de métodos que también son oraciones gramaticalmente correctas en inglés e incluyen palabras adicionales únicamente para que se lean como prosa. Personalmente, no soy un gran admirador de tales nombres de métodos "literales", y prefiero ser breve, sin dejar de ser lo más claro posible. Para mí, las palabras como "a", "an" y "the" simplemente se ven incómodas en los nombres de los métodos, y hace que los nombres de los métodos sean innecesariamente largos sin agregar realmente nada útil. Preferiría los siguientes nombres de métodos para los ejemplos anteriores:

UploadFileToServer
CreateTemporaryFile
WriteOutRecord
ResetSystemClock

En mi experiencia, esto es mucho más común que el otro enfoque de escribir los nombres más largos, pero he visto ambos estilos y tenía curiosidad por ver qué pensaban los demás sobre estos dos enfoques.

Entonces, ¿estás en el campo de "nombres de métodos que se leen como prosa" o en los "nombres de métodos que dicen lo que quiero decir pero leen en voz alta como un campo de mala traducción del idioma extranjero al inglés"?

coding-style naming

— Mike Spross
fuente

77

Nunca he visto métodos con nombres como WriteTheRecordToTheDatabase. Si alguien lo registrara, tendrían una conversación seria.

— Tim Robinson,

13

" Please"? Wow

— configurador

3

Solo me gustaría agregar que Wordpress tiene funciones auxiliares de plantilla como "the_contents ()", "get_the_post ()", etc. Me molesta muchísimo.

— Carson Myers

1

@Carson Myers Hah, ese es un ejemplo perfecto de esto en el mundo real. Debo haber suprimido los recuerdos de la última vez que miré el código de WordPress :-)

— Mike Spross

21

Estoy de acuerdo en que los métodos en prosa apestan con una excepción:

Casos de prueba unitaria

Generalmente, estos nunca se invocan en su código y se muestran en los informes de prueba. Como tal, es útil tener lecturas con un poco más de prosa:

AddingACustomerOrderFailWhenCustomersIdIsInvalid: Failed
OutOfBoundsPriceReturnsAnError: Aprobado
CanDeleteAnEventFromASeason: Pasado

Incluso esto debe hacerse con moderación, pero puedo verlo como al menos un caso en el que las adiciones gramaticales pueden hacer que sea un poco más fácil expresar lo que pasó y lo que falló. Esto es, por supuesto, a menos que su lenguaje / marco proporcione un buen mecanismo para las descripciones de prueba en la lectura de la prueba que no sean los nombres de los métodos, en cuyo caso ignore este también.

— Fishtoaster
fuente

1

+1 para un buen ejemplo de dónde los nombres de métodos en prosa pueden ser realmente beneficiosos. Es divertido, porque ahora que lo mencionas, lo he hecho específicamente al escribir los nombres de las pruebas unitarias, y específicamente para saber qué diablos estaba haciendo la prueba cuando las ejecuté más tarde.

— Mike Spross

Eso es útil y se ajusta a la MethodUnderTest_Condition_ExpectedBehaviour convención de nomenclatura de prueba unitaria sugerida de Roy Osherove . por ejemplo AddOrder_WithInvalidCustomerId_Fails, CreateItem_WithOutOfBoundsPrice_ReturnsErroryDeleteEvent_EventExistsInSeason_Succeeds

— StuperUser

@StuperUser para el comportamiento esperado, realmente ha puesto el resultado esperado de la prueba y, por lo tanto, no tengo idea de qué se supone que devolverá el método.

— ediblecode

@danRhul Punto justo, no estaba lo suficientemente claro; .._AdditionFailsy .._DeletionSucceedsdebería ser mejor Puse el resultado del método, pero como usted señala, podrían confundirse con la prueba de la terminología de aprobación / falla.

— StuperUser

10

Parafraseando a Lawrence desde Office Space ...

No, no, hombre, creo que si alguien con el que trabajé por aquí nombrara una función 'UploadTheFileToTheServerPlease', le patearían, hombre.

— Gran maestro B
fuente

10

Tales nombres "largos" no suenan a prosa . Cuando están solos, tal vez, pero acompañados con el resto del código, simplemente hacen más desastre. Echale un vistazo:

bool ResultOfTheUpload
      = UploadTheFileToTheServerPlease(TheNameOfTheFile, TheServersAddress);

Yuuuuk! ..

Este no es un texto válido en inglés, y en ningún lenguaje de programación se verá como uno. Entonces no tiene sentido gastar bytes en artículos.

— P Shved
fuente

1

¡Un buen ejemplo de por qué no me gusta tanto este enfoque! Cuando escribí la pregunta, solo me enfocaba en que los nombres de los métodos por sí mismos sonaran en prosa, pero estoy de acuerdo con usted: es bastante difícil hacer que el código de llamada se lea realmente en prosa, por lo que no tiene sentido hacer que los nombres de funciones individuales suenen como escritos Inglés.

— Mike Spross

3

Sugierobool ResultOfTheGentlyUploadOfTheFileToTheServer

— Wizard79

He trabajado con una persona que creó los estándares de la compañía en los que 'theVariable' y 'aMethod' tuvieron que seguirse. A esta misma persona también le gustaba que todas las líneas de código se alinearan verticalmente.

— Chris

7

Desde la perspectiva de los programadores, "UploadFileToServer" tiene más sentido y es más fácil de leer y comprender que "UploadTheFileToTheServerPlease".

¡Más que la gramática inglesa, la legibilidad y la comprensión son más importantes en la programación!

— Gopi
fuente

Totalmente de acuerdo ... si leo el código escrito en primer estilo durante unos días, estoy seguro de que me volverá loco ...

— Naveen

@Naveen: he trabajado con un código como este, y la primera vez que tuve la oportunidad cambié el nombre de todos esos métodos. Y no estoy seguro de si fue solo el desarrollador o no, pero creo que hay una tendencia a hacer que las funciones hagan múltiples cosas cuando las escribes como oraciones, es decir UploadTheFileAndProcessItAndEmailTheOrdersToTheCustomers, aunque espero que nada sea tan malo en la vida real.

— Mike Spross

@ Mike Entonces refactorizaría el método a 2 métodos diferentes;)

— Gopi

2

Dado cuántos errores tipográficos presenta mi vida, terminaría con

* UploadTehFileToTehServerPleaz
* WriteTehRecordToTehDatabase
* ResetTehSystemClock
* ICanHazTehCheezburger

En serio, incluso miraría cuál era el nombre de mi clase también. Si mi clase se llamara "Archivo", probablemente solo iría con

*UploadToServer
*DownloadFromServer

Entonces sería

   File file = new file;
   file.UploadtoServer(ServerAddress);

Solo un ejemplo trivial, pero espero que sea lo suficientemente ilustrativo.

— desaparecido en combate
fuente

Jeje. De hecho, he visto "Teh" arrastrarse a los nombres de métodos siguiendo el patrón de nomenclatura "similar al inglés". En cuanto a su segundo punto: estoy completamente de acuerdo, la redundancia en los nombres de los métodos es otro motivo favorito mío ( File.UploadFileToServer... ugh).

— Mike Spross

0

Personalmente no me importa. Los he visto y no me molestan. Ni siquiera pensé en ellos hasta que otro programador habló sobre ellos. Me pareció sorprendente que alguien se preocupara tanto por algo que importa tan poco. Quiero decir que en realidad estaba enojado por eso. Pero eso fue al principio de mi carrera, hace unos 11 años, y desde entonces he descubierto que los desarrolladores enojados por cosas menores es bastante común. Es por eso que a los gerentes de desarrolladores se les paga tan bien. Tienen que tratar con los desarrolladores a diario.

Y prefiero ver eso que "UL_FlToSrv".

— ElGringoGrande
fuente