Ir al contenido


Foto

Falsos amigos en inglés a la hora de programar


  • Por favor identifícate para responder
13 respuestas en este tema

#1 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 29 agosto 2016 - 08:11

Buenas,

Es un hecho de que muchos de nosotros programamos en inglés, aún cuando tengamos una buena formación o no.

Mi pregunta, y que me ha estado dando curiosidad es justamente la palabra estado.

En ocasiones debemos diseñar máquinas de estado para algunas de nuestras clases.

 

El término estado posee diferentes significados dependiendo del contexto. En inglés también, pero lo hace un tanto más complejo ya que incluso tiene dos palabras que pueden confundirse: State y Status.

 

Hasta el momento yo siempre he usado State, pero anoche mi cabeza mientras programaba, me alerta de que quizá no suena bien...

 

¿Cómo es mejor?


delphi
  1. type
  2. TClassState = (csState1, csState2, ... , csStateN);
  3. TclassStatus = csStatus1, csStatus2, ... , csStatusN);

Esta duda me vino justo cuando dudaba en como nombrar una función boolean, si debía llamar StateChanged, HasStateChanged... y otras combinaciones más.

 

En cierta forma me deja un sabor intranquilo, ya que por un lado State suena más a "un organismo público" que una condición... pero creo recordar haber visto en algunos códigos Delphi usar State. Y ya no tengo seguro si estaré en sintonía con la nomeclatura. Y una de las cosas que hay que cuidar es justamente respetar una buena nomeclatura y es mejor en cuanto esta semeja y hace simbiosis con la del lenguaje (y las bibliotecas, unidades, módulos, suites, etc) que ofrezca. No vaya a ser cosa que un día pongamos funciones booleanas con Has y otras sin Has... ¡eso si es mal código!

 

Dejo abierto esta discusión para saber si estoy "tan mal" al seguir empleando State. ¿Ustedes como lo pondrían?

 

Saludos,


  • 1

#2 Agustin Ortu

Agustin Ortu

    Advanced Member

  • Moderadores
  • PipPipPip
  • 831 mensajes
  • LocationArgentina

Escrito 29 agosto 2016 - 09:57

No sos el único loco que se lo preguntó alguna vez http://stackoverflow...e-versus-status

En síntesis yo estoy de acuerdo con la primer pregunta. Me recuerda a los conceptos más básicos de POO y a algunos más avanzados como el patrón State.

State se refiere al estado actual de un objeto; sus atributos o sus variables de instancia. Si bajamos más el nivel y salimos de POO podría hablarse también del estado de un programa, un proceso, de la CPU, etc.
La cuestión es que nos referimos a cuales son los valores de un 'todo'

Status lo veo más adecuado para indicar el resultado de una operación o como parte de un atributo de un objeto.

Yo creo que los objetos se relacionan mas con la palabra State y los enumerativos con Status, aunque es una regla muy general

Al final y al cabo, la respuesta es la de siempre: depende

Editado por Agustin Ortu, 29 agosto 2016 - 10:00 .

  • 0

#3 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 29 agosto 2016 - 11:50

No sos el único loco que se lo preguntó alguna vez http://stackoverflow...e-versus-status

En síntesis yo estoy de acuerdo con la primer pregunta. Me recuerda a los conceptos más básicos de POO y a algunos más avanzados como el patrón State.

State se refiere al estado actual de un objeto; sus atributos o sus variables de instancia. Si bajamos más el nivel y salimos de POO podría hablarse también del estado de un programa, un proceso, de la CPU, etc.
La cuestión es que nos referimos a cuales son los valores de un 'todo'

Status lo veo más adecuado para indicar el resultado de una operación o como parte de un atributo de un objeto.

Yo creo que los objetos se relacionan mas con la palabra State y los enumerativos con Status, aunque es una regla muy general

Al final y al cabo, la respuesta es la de siempre: depende

 

Es cierto que existe el patrón State. Aunque yo no lo aplico. Me da la impresión de añadir clases que en ocasiones son más relleno.

Por momentos comparto tu impresión de lo que debemos entender como estado: un "resumén" (generalmente) actual de como se encuentra el objeto como un todo. Aunque a Status no lo he visto como un "resultado"

 

Pero luego sigo leyendo más abajo las respuestas que dieron en ese hilo de SO y veo esto:

 

 

IMO:

status == how are you? [good/bad]

state == what are you doing? [resting/working]

 

Y que tiene más votos positivos que todas las demás. Incluso los comentarios que dejaron debajo dan a entender que esta respuesta es mucho más clara que la elegida.

Al leer eso inmediatamente me hizo recordar a la compleja máquina de estados para la aplicación de mi tesis.

 

En resumen, ahí se expresa que Status brinda una respuesta sobre la información interna de como se encuentra el objeto; mientras que State refleja las macro-operaciones que actualmente está aplicando y que da a entender que se da un espacio de tiempo.

 

En mi Tesis, mi máquina de estados es más cercana a este principio. De hecho, los estados claramente tienen como sufijo "ing". Y si recordamos en las películas de acciones yanquis ellos usan la expresión Status para referirse a si están en peligro, sano, herido, etc. No dicen Status para referirse a "Combatiendo con granadas en la trinchera oeste", en su lugar dirían "Asediado", "Entrando", "Desactivando bombas".

 

Si bien pareciera haber cierta contradicción en los significados que dan en las respuestas, puedo notar que muchos hablan de Status como una vía de respuesta mientras que State lo mencionan como una condición que reúne o conlleva acciones, y que en parte también ofrece una descripción esperada de su situación interna... o que nos hace una aproximación de cómo se encuentra.

 

Todos coinciden en que State debe reflejar que se pasa de ciertas acciones a otras. Y ese es el objetivo del patrón: reunir las operaciones a aplicar. Status es el que trae la confusión.

 

Saludos,


  • 0

#4 escafandra

escafandra

    Advanced Member

  • Administrador
  • 4.107 mensajes
  • LocationMadrid - España

Escrito 29 agosto 2016 - 01:21

La API de Windows, en ocasiones devuelve un valor que denomina Status y que informa sobre lo que ha pasado al ejecutar la función, esto apoya la idea de que Status debe usarse para el resultado del estado de algo muy concreto y local, apoyando la opinión que vertió Agustin Ortu

 

State se refiere al estado actual de un objeto; sus atributos o sus variables de instancia. Si bajamos más el nivel y salimos de POO podría hablarse también del estado de un programa, un proceso, de la CPU, etc.
La cuestión es que nos referimos a cuales son los valores de un 'todo'

Status lo veo más adecuado para indicar el resultado de una operación o como parte de un atributo de un objeto.

 

 

Saludos.


  • 0

#5 Agustin Ortu

Agustin Ortu

    Advanced Member

  • Moderadores
  • PipPipPip
  • 831 mensajes
  • LocationArgentina

Escrito 29 agosto 2016 - 02:09

En mi cabeza:

Ejemplo de status: Error_Code_404, enabled = true, estado civil = soltero

Estado: una determinada persona con un nombre, un status civil, una edad, etx etc

El estado lo veo más ligado a una entidad o abstracción, necesita tener un 'owner' que lo identifque

El status lo veo como un posible valor

Saludos
  • 0

#6 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 14.446 mensajes
  • LocationMéxico

Escrito 29 agosto 2016 - 03:10

Lo que yo creo es que le dan muchas vueltas al asunto, la palabra es Status que es lo comunmente aceptado en programación.

 

State es para el ámbito de la vida diaria, no hay forma de que se confunda una con otra. 

 

Puede haber muchos puristas del lenguaje, pero eso no tiene la menor importancia en programación, aunque muchos quieran que así sea debe haber reglas claras, concisas y precisas y sin tanto rollo, de por si nos alucinamos con la resolución de problemas como para que también nos metamos en mas complicaciones.

 

Bueno eso pienso yo, y quien soy yo para pensar así :D :D :D

 

Saludos


  • 0

#7 Agustin Ortu

Agustin Ortu

    Advanced Member

  • Moderadores
  • PipPipPip
  • 831 mensajes
  • LocationArgentina

Escrito 29 agosto 2016 - 03:29

Discrepo amigo Elíseo. Yo soy el tipo de programador que si no sabe que nombre ponerle a una variable, método, parámetro, clase o unit me detengo y pienso; hasta no tener un nombre que me satisface no sigo codificando la solución

Lo mismo sucede para donde guardo este archivo. Es una solución genérica que debería ir a la biblioteca de clases o su uso sólo está justificado al proyecto?

Como nombramos a la unidad? Usamos namespaces? Cual/es? Tiene sentido lo que elegí? Por que?


En la gran mayoría de los casos encuentro más difícil poner el nombre que escribir la solución. De hecho muchas veces la solución ya está casi 'terminada' en la mente y sólo es cuestión de plasmarla

Lo mismo me detengo en cosas que muchos consideran menores como, especificadores de acceso, tipo de datos, tipo de parámetros..

En fin siempre le doy una vuelta de más a todas estas cuestiones. Es un 'mal hábito' del que disfruto mucho por cierto

Editado por Agustin Ortu, 29 agosto 2016 - 03:31 .

  • 0

#8 escafandra

escafandra

    Advanced Member

  • Administrador
  • 4.107 mensajes
  • LocationMadrid - España

Escrito 29 agosto 2016 - 03:38

Como dice Agustin Ortu yo también me pienso bastante los nombres de función y variables. Esos nombres dirán mucho de lo que significan, su tipo y lo que hacen. luego todo es más rodado.

 

Saludos.


  • 0

#9 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 29 agosto 2016 - 03:41

Discrepo amigo Elíseo. Yo soy el tipo de programador que si no sabe que nombre ponerle a una variable, método, parámetro, clase o unit me detengo y pienso; hasta no tener un nombre que me satisface no sigo codificando la solución

Lo mismo sucede para donde guardo este archivo. Es una solución genérica que debería ir a la biblioteca de clases o su uso sólo está justificado al proyecto?

Como nombramos a la unidad? Usamos namespaces? Cual/es? Tiene sentido lo que elegí? Por que?


En la gran mayoría de los casos encuentro más difícil poner el nombre que escribir la solución. De hecho muchas veces la solución ya está casi 'terminada' en la mente y sólo es cuestión de plasmarla

Lo mismo me detengo en cosas que muchos consideran menores como, especificadores de acceso, tipo de datos, tipo de parámetros..

En fin siempre le doy una vuelta de más a todas estas cuestiones. Es un 'mal hábito' del que disfruto mucho por cierto

 

¡Menos mal que no soy el único loco que "pierde el tiempo" en buscar el mejor nombre! :D :D :D

 

Me parece una actividad que merece su dedicación. Ayuda mucho a largo plazo. Sobre todo cuando uno vuelve para la etapa de mantenimiento.

 

Saludos,


  • 0

#10 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 29 agosto 2016 - 03:59

Creo que estos tipos de preguntas que nos hacemos son inevitables... pareciera menor el asunto como lo dice Eliseo.

Pero al menos yo he llegado a corregir muchas veces código ya hecho debido a que "no me sonaba bien lo que estaba escribiendo". Para el compilador es algo indiferente, pero para el desarrollador que tendrá la tarea de darle seguimiento desarrollar una nomeclatura y un método que elimine la ambigüedad de algunas expresiones es importante.

 

Martin Fowler dijo que el buen programador escribe programas para que una persona lo entienda. Y a mi me parece una máxima que siempre hay que conservar.

 

Yo ya tengo una media decisión tomada, me parece apropiado que un estado (State) esté en "ing". Y dejar a Status como posibles valores de respuesta o valores internos. Por ejemplo, el enumerativo que comenté en este hilo:


delphi
  1. TItemState = (isNew, isExist, isToDelete, isToModify);

No es correcto. Debería ser así:


delphi
  1. type
  2. TItemPersistentState = (ipsNothing, ipsInserting, ipsModifying, ipsDeleting);

De esta manera se ilustra realmente que operación está representando el Item Frame, que luego se traduce a una operación a nivel de base de datos.

 

Aún así, creo que debería dejarse la posibilidad a excepciones a esta regla.

 

Saludos,


  • 0

#11 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 14.446 mensajes
  • LocationMéxico

Escrito 29 agosto 2016 - 04:37

Discrepo amigo Elíseo. Yo soy el tipo de programador que si no sabe que nombre ponerle a una variable, método, parámetro, clase o unit me detengo y pienso; hasta no tener un nombre que me satisface no sigo codificando la solución

Lo mismo sucede para donde guardo este archivo. Es una solución genérica que debería ir a la biblioteca de clases o su uso sólo está justificado al proyecto?

Como nombramos a la unidad? Usamos namespaces? Cual/es? Tiene sentido lo que elegí? Por que?


En la gran mayoría de los casos encuentro más difícil poner el nombre que escribir la solución. De hecho muchas veces la solución ya está casi 'terminada' en la mente y sólo es cuestión de plasmarla

Lo mismo me detengo en cosas que muchos consideran menores como, especificadores de acceso, tipo de datos, tipo de parámetros..

En fin siempre le doy una vuelta de más a todas estas cuestiones. Es un 'mal hábito' del que disfruto mucho por cierto

 

Yo no me complico, yo uso nombres que indican que se está haciendo, lo cual me sirve incluso para documentar de primera instancia el código, me explico:

 

Si un método se encarga de agregar algo a la base de datos asi de facil,. agregaCliente(), agregaDato(), agregaFlores(), agregaLoQueSea();

 

Si es borrar igual, si hago una clase o un objeto le llamo por el nombre que le corresponda, 

 

Cuando se crea digamos las respuestas de algún metodo, igual, si es un objeto le llamo Retorno o Resultado, y dentro agrego en casi todos los casos dos campos

 

tieneError (Si, No, True, False),

mensaje (string)

 

Si es un valor (string, Integer, Float, etc), les nombro con éste tipo respuestaSuma, respuestaLoQueSea.....

 

Insisto no me complico, pero como digo, ese soy yo, cada quien se la complica como quiere y ninguno está mal, eso es lo bonito de todo esto.

 

Saludos


  • 1

#12 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 14.446 mensajes
  • LocationMéxico

Escrito 29 agosto 2016 - 04:44

Creo que estos tipos de preguntas que nos hacemos son inevitables... pareciera menor el asunto como lo dice Eliseo.

Pero al menos yo he llegado a corregir muchas veces código ya hecho debido a que "no me sonaba bien lo que estaba escribiendo". Para el compilador es algo indiferente, pero para el desarrollador que tendrá la tarea de darle seguimiento desarrollar una nomeclatura y un método que elimine la ambigüedad de algunas expresiones es importante.

 

Martin Fowler dijo que el buen programador escribe programas para que una persona lo entienda. Y a mi me parece una máxima que siempre hay que conservar.

 

Yo ya tengo una media decisión tomada, me parece apropiado que un estado (State) esté en "ing". Y dejar a Status como posibles valores de respuesta o valores internos. Por ejemplo, el enumerativo que comenté en este hilo:


delphi
  1. TItemState = (isNew, isExist, isToDelete, isToModify);

No es correcto. Debería ser así:


delphi
  1. type
  2. TItemPersistentState = (ipsNothing, ipsInserting, ipsModifying, ipsDeleting);

De esta manera se ilustra realmente que operación está representando el Item Frame, que luego se traduce a una operación a nivel de base de datos.

 

Aún así, creo que debería dejarse la posibilidad a excepciones a esta regla.

 

Saludos,

 

Pues en realidad no es un asunto menor, solo que como digo, cada quien se lo complica o se lo simplifica como quiere. A mi me ha dado buenos resultados generar nombres "simples" en código no tan simple, para que la persona que llegue no tenga problemas para entender el código aún sin contar con la documentación del proyecto.

 

Saludos


  • 0

#13 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 14.446 mensajes
  • LocationMéxico

Escrito 29 agosto 2016 - 04:51

 

Yo ya tengo una media decisión tomada, me parece apropiado que un estado (State) esté en "ing". Y dejar a Status como posibles valores de respuesta o valores internos. Por ejemplo, el enumerativo que comenté en este hilo:


delphi
  1. TItemState = (isNew, isExist, isToDelete, isToModify);

No es correcto. Debería ser así:


delphi
  1. type
  2. TItemPersistentState = (ipsNothing, ipsInserting, ipsModifying, ipsDeleting);

De esta manera se ilustra realmente que operación está representando el Item Frame, que luego se traduce a una operación a nivel de base de datos.

 

Aún así, creo que debería dejarse la posibilidad a excepciones a esta regla.

 

Saludos,

 

Hay un debate fuerte acerca de que lenguaje utilizar para codificar, en lo personal me gusta utilizar el español, precisamente para no entrar en rollos de ambigüedad.

 

Y me parece que la ambigüedad de tu ejemplo radica mas en la Persistencia que en los elementos que contiene.

 

Saludos


  • 0

#14 JoAnCa

JoAnCa

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 775 mensajes
  • LocationPinar del Río, Cuba

Escrito 09 septiembre 2016 - 11:08

Pues yo coincido con egostar, uso nombres en español, si es largo en abreviaturas, y solo en ingles cuando el nombre en ingles resulte mas corto o "feo"

 

Por ejemplo:

 

1.- CreaUsuario, BorraUsuario

 

2.- ModificaUsuario lo veo un poco largo y uso ModUsuario

 

3.- AutenticarUsuario, demasiado largo y la abreviatura la veo fea, lo uso en ingles LoginUser

 

 

En resumen, pensando igual que egostar, poner nombres descriptivos en español, te ahorra tiempo y neuronas ;)

 

El tiempo que empleas en buscar un nombre en ingles que no sea ambiguo o que se ajuste a lo que quieres, lo empleo mejor en desarrollar el resto del codigo


  • 0




IP.Board spam blocked by CleanTalk.