23 respuestas en este tema

[JoAnCa]

Hola a todos
Pues eso, a veces se usan variables con 2 o 3 caracteres, y a veces le ponen un nombre completo de lo que trata la variable (por ejemplo: obtenerdatosiniciales)

Y mi pregunta es:
Afecta en algo el rendimiento o uso de memoria, el usar nombres de variables largos?

Claro que al usar un nombre largo es mas descriptivo y permite saber con claridad para que es esa variable

[enecumene]

No, no afecta en el renidmiento, pero a veces es tedioso escribira variables tan largo mientras creas lineas de codigo, para mi es mas recomendable nombre mas cortitos

[look]

igual se puede utilizar una especie de sigla o acronimo de una palabra
obtenerdatosiniciales:
- ODI
- OBDAIN

Saludos!

[Fenareth]

Es verdad, como tener problemas pues no los tiene, pero después escribir tanto puede ser tedioso....

Yo haría algo como: ObtDatosIni (me parece claro y no tan largo  )

Saludox !

[Rolphy Reyes]

Saludos.

Soy pro a escribir el nombre del tamaño que sea necesario para entender de que se trata; ya sean variables, funciones o procedimientos.  A mí parecer es más confuso los nombres cortos que los largos.

Fenareth, si te fijas en los fuentes de los DevExpress ellos tienen nombres largos para la mayoría  de su código.

Hasta donde tengo entendido eso no afecta el rendimiento.

[look]

yo creo que es muy comodo utilizar variables con nombres abreviados, si quiero saber para sirve cada variable lo que hago es que la documento, le pongo un comentario :

delphi

var nc:String; // contiene el nombre del cliente

claro, esto es mas que todo una tecnica de programacion que depende mas del gusto del programador...
saluditos! 

[Fenareth]

Saludos.

Soy pro a escribir el nombre del tamaño que sea necesario para entender de que se trata; ya sean variables, funciones o procedimientos.  A mí parecer es más confuso los nombres cortos que los largos.

Fenareth, si te fijas en los fuentes de los DevExpress ellos tienen nombres largos para la mayoría  de su código.

Hasta donde tengo entendido eso no afecta el rendimiento.

Si amigo pero yo me refiero al código escrito por mi, prefiero que sea algo más breve y conciso, claro no al grado de usar las típicas variables de cuando se comienza a programar: a, b, x, y... etc

Pero bueno, como en todo, es cuestión de estilos... en este caso no tiene que ver el rendimiento

Saludox !

[Marc]

Saludos.

Soy pro a escribir el nombre del tamaño que sea necesario para entender de que se trata; ya sean variables, funciones o procedimientos.  A mí parecer es más confuso los nombres cortos que los largos.

Fenareth, si te fijas en los fuentes de los DevExpress ellos tienen nombres largos para la mayoría  de su código.

Hasta donde tengo entendido eso no afecta el rendimiento.

Totalmente de acuerdo.

Mal negocio haces si ahorras longitud en los nombres de variables solo para ahorrarte unos miserables segundos a la hora de escribir el código. Esos segundos los perderás más tarde (multiplicados por mil) en el momento de mantener la aplicación.

El código tiene que ser lo más legible posible, ya que normalmente vas a dedicar mucho más tiempo en su mantenimiento que en su programación.

Saludos.

[enecumene]

EL que usa métodos abreviados no siempre tendrá problemas al momento de mantener la aplicación como comentas amigo Marc, claro, siempre y cuando lo tengas todo documentado

[egostar]

hey, y para que sirven las "HotKeys", con un Ctrl+Space te ahorras escribir todo el nombre de la variable

Salud OS

[Caral]

Hola
Mis variables siempre son a, b, c, d ......
Mas facil nada 
Saludos

[Marc]

Hola.

EL que usa métodos abreviados no siempre tendrá problemas al momento de mantener la aplicación como comentas amigo Marc, claro, siempre y cuando lo tengas todo documentado

No he dicho que te vaya a traer problemas, sino que te va a hacer perder tiempo durante el mantenimiento, ya que el código es menos legible, y cuando te encuentres con una variable no sabrás inmediatamente lo que hace, sino que vas a tener que mirar donde está declarada, donde se usa, ...

NOTA: ¿ Documentas las variables de tu código ?, yo desde luego no lo hago, siempre he pensado que la mejor documentación es un código bien legible.

Saludos.

[Delphius]

Efectivamente, como todos han dicho: no afecta en nada si la variable se llama variableparagenerarinformesmedicospersonales o si es la típica i, j, k.

De todas formas para la máquina es una porción de memoria dependiente del tipo elegido... más no de su nombre... todas las variables integer tienen un tamaño de (corrijanme si meto la pata... no tengo Delphi abierto  ) 4 bytes. Tanto variableparagenerarinformesmedicospersonales como i ocupan lo mismo si es que ambas son del mismo tipo o de un "alias" equivalente (como se el caso de real = double).

En lo que hace a "productividad" también da lo mismo: el IDE ofrece las herramientas para facilitarnos la vida y no teclear demasiado.

¿Entonces en donde está el problema? En nuestras cabezas y la capacidad de retener el contexto y de llevar la propia escritura del código. Como lo han dicho, es cosa de documentar bien y tener un adecuado control de como escribimos.

Si se usa CamelCase (ya sea Upper o Lower)... si se utiliza Notación Húngara... no interesa, lo importante es ser ORGANIZADOS y evitar cosas como ésta: MiVariable, miVariable, MIvAriable1. Las mezclas hacen mal... y no necesariamente hablo de mezclas de bebidas alcohólicas.  Hay que ser consistentes y mantenernos en el contexto. Si se trabaja en equipo con mucha más razón.

Respecto a los pros y contras de los nombres cortos vs largos digamos que es un empate. Si tendemos a reducir los nombres se corre el riesgo de perder claridad en apreciar el contexto que estamos analizando. Por el otro lado una variable con un nombre largo quizá sea más "descriptiva" pero en combinación de la tupla: Clase.Método o situaciones familiares extiende la vista mucho más horizontal que vertical con lo que termina complicando la lectura.

El código está escrito para ser leído por seres humanos, es para nosotros por tanto si mantenemos el orden y adoptamos un criterio que nos permita llevar una adecuada documentación y escritura de código se puede utilizar tanto de lo uno como de lo otro.

Existe la tendencia a escribir nombres cortos, yo lo aconsejo, mientras ese nombre corto pueda transmitir la idea de para que se utiliza, donde se lo utiliza y de que tipo es.

Esto me hizo acordar a unos artículos que Joel Spolky ha redactado en su sitio Joel on Software:
Haciendo que el código defectuoso se vea defectuoso
12 pasos a un código mejor

Estos artículos son unas traducciones elaboradas por algunos voluntarios. Los originales pueden leerse en inglés desde aquí. Los artículos traducidos (o que se están traduciendo en algunos casos) pueden consultarse aquí.

Esto también es de mucha importancia recordar y a tener en cuenta.

La verdad es que Joel, a pesar de provenir de Micro$oft al que no muchos le tienen confianza, tiene ideas bastantes claras y sus artículos no son un desperdicio.
Yo apenas he leído unos cuantos... y tiene más de 1000 

Saludos,

[andres1569]

Hola, en mi caso tiendo a dar nombres descriptivos, sobre todo en funciones, métodos y demás, del tipo obtenerdatosiniciales, aunque es casi obligado resaltar con mayúsculas la inicial de cada palabra: ObtenerDatosIniciales. Lo mismo en el nombre de propiedades de componentes, prefiero un nombre descriptivo algo más largo que abreviado y confuso. Y en cuanto a variables, si son globales sigo la misma norma, y para las locales suelo abreviar al menos en las que siguen un fin lógico y universal, por ejemplo i, j, k para iteradores de tipo entero, s para cadenas de apoyo, T para almacenar tiempo, R para un real ... Si la función declara muchas variables y el cometido de las variables se sale de lo habitual entonces prefiero que se entienda, por ejemplo prefiero NumFilas a N, Contador a C, .. etc.

Otro detalle es que en inglés los nombres y verbos por norma general son más cortos y ayudan a describir a la vez que se ahorran caracteres. ObtenerDatosIniciales sería GetInitialData (lo que daría por tener une quivalente en español para Get y Set) 

Salu2

[Delphius]

Set) 

Eso ya entraría como otro debate  : ¿Programar en español o programar en inglés? Por mi parte escribo código en inglés por dos razones: 1. Como haz indicado, en su mayoría en inglés los identificadores tienden a ser mucho más cortos. 2. Armoniza mejor con la sintaxis de los lenguajes. No me agrada demasiado ver un

delphi

procedure TMaestra.DarTareas

Prefiero un

delphi

procedure TTicher.LiveHomeWork

Que se mezcle inglés con español en el código me da vueltas las ideas.

A la documentación si la hago en español... ¿para que documentar en inglés un código que ya está en inglés? La documentación me tiene que facilitar la lectura de ese código y me tiene que ayudar a llevar un registro de como se ha estado trabajando.

Gracias a CnPack tengo unas teclas rápidas asignadas a unas "plantillas" de documentación para mi código: unidades, métodos, enumerados, registros y otros (una genérica destinada para variables, constantes, tipos, etc).Saludos,

[Marc]

Jejejeje, deberías ver mi código, las variables están escritas en catalán. Así que en el código vemos mezclado las constantes y objetos en inglés, los textos que se van a mostrar en pantalla, en castellano, y las variables internas y comentarios en catalán.

NOTA: Nunca documento el código. Con un código muy legible y comentarios cuando sea necesario, me parece suficiente. ¿ Que estrategias de documentación seguís vosotros ?.

[poliburro]

pues, yo sigo la siguiente regla para nombrar a mis variables:

1) La Primera letra depende de su ámbito
    L  =  Local
    G  = Global
    F  = Miembro de una clase
    P  = Parámetro

2) La Segunda letra depende de su tipo
    I = Integer
    F = flotante
    B = Booleana 
    Btn = Acrónimo de la clase en caso de ser de este tipo

3) El nombre corresponde a un nemónico del uso que se dará a la variable.

Ejemplo:

Una variable local de tipo entero que será uisada como contador:

LICont


, igual les parece enredado pero cuando leen código el mismo nombre de la variable les dice, tipo, ámbito y una idea de su uso.

Saludox

[Delphius]

Jejejeje, deberías ver mi código, las variables están escritas en catalán. Así que en el código vemos mezclado las constantes y objetos en inglés, los textos que se van a mostrar en pantalla, en castellano, y las variables internas y comentarios en catalán.

¿Y el nombre del sistema, en... italiano?  jaja... es broma.

Por poco hay que salir a buscar a un políglota  .

Yo antes escribía en español... o castellano (o como prefieran decirlo) pero lentamente fuí abandonando e inclinándome hacia el inglés... ¡Y eso que lo detesto! Lo dije y lo sostengo... english kill neurons.
 

Al programar lo siento natural... aunque reconozco que en ocasiones tengo que ir a diccionario de 2 kilos que siempre tengo a mano para apoyarme en la traducción del español/inglés y en inglés/español.

NOTA: Nunca documento el código. Con un código muy legible y comentarios cuando sea necesario, me parece suficiente. ¿ Que estrategias de documentación seguís vosotros ?.

Por mi parte no sabría decir mucho. Recién en los últimos meses empecé a adoptar un proceso algo estandarizado y medianamente (bueno... quizá bastante  ) formal en como llevar la documentación.

En líneas generales lo que hago es escribir el código, lo reviso y en cuanto considero que ya anda más o menos visto empiezo a poner la documentación con las plantillas. Lo que si considero obligatorio documentar es la unidad y TODOS los métodos de cada clase... es resto solo si se considera necesario para aclarar las cabezas distraídas.

La plantilla de unidades consta del nombre de la unidad, fecha, autor (por ahora trabajo solo), versión. Seguidamente consta de un apartado de Descripción y un historial de versión indicando las mejoras, eliminaciones, etc.

Aquí debería corregirme... lo de las plantillas lo hago con GExperts. CnPack tiene un editor de plantillas más poderoso pero no lo termino de comprender... lo siento más complicado.

Mi diseño es el siguiente:

delphi

{DOC/Unit:----------------------------------------------------------------------
Unidad: %UNIT%
Fecha: %DATETIME%
Autor: Carlos M. Cuadrado Ramos
Versión: 0.M.n.c
********************************************************************************
Descripción:
|
Historial:
<Version>:
   <descripción-añadidos>[-] <descripción-eliminados>
  [=] <descripción-mejoras>
  [/] <descripción-planificados>
   <descripción-defectos>:DOC%UNIT%--------------------------------------------------------------------}

También hago lo similar con los métodos, clases, registros, etc.

La siguiente plantilla es para métodos (funciona también para procedimientos y funciones sueltas)

delphi

%BEFORE%
{DOC/Método: %PROCNAME%---------------------------------------------------------
Fecha: %DATETIME%
Versión: 0.M.n.c
================================================================================
Parámetros:%BEGINPARAMLIST%
* %PARAMNAME%: %PARAMTYPE% = %PARAMDEF%  
  <Descripción-parámetro>
%ENDPARAMLIST%
Resultados: %RESULT%
* <valor>: <descripción-resultado>
Excepciones:
* <Excepction>: <Descripción-excepción>
********************************************************************************
Descripción:
|
********************************************************************************
Documentación:
<lista-DOCS>
:DOC%CLASS%.%PROCNAME%--------------------------------------------------------}

Al generar la plantilla, toma los datos del método que esté en la línea anterior (de allí la cláusula %BEFORE%, de otro modo busca el método en la línea siguiente*) y automáticamente genera la lista de parámetros, con su tipo y lo mismo lo hace con el tipo de dato del resultado (si corresponde, en una función). Lo que resta es llenar los datos.
La sección Documentación me sirve para tener una lista de algunos documentos de apoyo... Por ejemplo digamos que tengo un diagrama de secuencia que explica el método que estoy implementando, entonces lo pongo en la lista. De ese modo tengo referencia a documentos de consulta en caso de ser necesario.

Para los enumerados mi diseño es este:

delphi

{DOC/Enumerado <NombreEnumerado>-----------------------------------------------
Fecha: %DATETIME%
Versión: 0.M.n.c
================================================================================
Valores:
* <valor>: <descripción-valor>
********************************************************************************
Descripción:
|
********************************************************************************
Documentación:
<lista-DOCS>
:DOC<NombreEnumerado>---------------------------------------------------------}

Y algo similar tengo para los tipos registros:

delphi

{DOC/Registro: <NombreRegistro>-------------------------------------------------
Fecha: %DATETIME%
Versión: 0.M.n.c
================================================================================
Campos:
* <campo>: <tipo>
  <Descripción-campo>
********************************************************************************
Descripción:
|
********************************************************************************
Documentación:
<lista-DOCS>
:DOC<NombreRegistro>----------------------------------------------------------}

Un genérica para cualquier otra cosa que considere necesaria:

delphi

{DOC/<Tipo-Doc>: <Nombre>-------------------------------------------------------
Fecha: %DATETIME%
Versión: 0.M.n.c
********************************************************************************
Descripción:
|
********************************************************************************
Documentación:
<lista-DOCS>
:DOC<Nombre>------------------------------------------------------------------}

Luego esto, cuando el código ya ha sido probado y corregido, va a un documento aparte. Es allí donde se unen los diagramas, escritos o lo que haga falta para aclarar lo que se hizo, se cambió, se probó, etc. En ese documento no va nada de código... solo esta documentación de la plantilla y cualquier información extra que sea necesaria y consuma demasiado espacio y no hace al código: Se acompaña de un ejemplo y una descripción a modo de uso.
Esto es lo que se imprimirá en un futuro y formará la dichosa biblioteca del proyecto.

¿Porqué repetir lo que está en las plantillas en un documento aparte? Por prolijidad y facilidades. Que esté en el código es una ventaja mientras se está programando y sirve de ayuda-memoria. La documentación más formal y seria de esto queda en el documento externo acompañado de un registro histórico de versiones más referencias a libros (no se ustedes, pero debido a mi proyecto constantemente tengo que recurrir a libros de cálculos entre otros), etc.

Si admito que mis plantillas ocupan demasiado espacio  (la métrica LDC no me preocupa demasiado... después de todo ignoro en la cuenta a todo lo que es comentario). A me gusta que la documentación sea vistosa. Después de todo, lo que no se considere apuntar de esa plantilla se borra con tranquilidad (el uso de las sección Documentación y su <lista-DOCS> es opcional y solo es de ayuda cuando hay muchas versiones y documentos, por dar un ejemplo).

La idea de esas líneas que ocupan los 80 caracteres me ayuda a separar mentalmente código de su documentación. He visto código documentado en donde hacen algo como esto:

delphi

{
   Procedimiento: MiObjeto
   Hace esto.
   Bla.
 }
procedure TObjeto.MiMetodo
begin
....
end;

Yo veo ese { simple y vacío y ando loco. Tengo que ir a la otra línea para enterarme de que es la documentación del método que viene después y no un simple comentario en el código.

*Retomo aquí el porque de mi insistencia de tener la documentación después del código y no antes: Primero veo la definición del método, luego veo su descripción e información adicional.

Así te haces una mejor idea del método que has visto. De la otra forma mientras lees una documentación te imaginas como estará el código.

Llevo esta forma de documentar puesto que el objetivo es que sea escalable. En el día de mañana, si tengo que formar un equipo (que ya desde hace tiempo que vengo intentando convencer a mis compas que nos unamos) esto puede ser de guía para tener la casa en orden.

Disculpen el rollo.

Saludos,

[Delphius]

Debería aclarar que todas esas plantillas sólo se observan en la sección interface de la unidad. La única excepción es cuando se declaran tipos, etc en implementation y sean de visibilidad privada respecto a la unidad.

Saludos,

[JoAnCa]

Pues yo uso nombres medianos, usando abreviaturas y muchas veces en ingles, por lo que ya han comentado, por ser mas cortos, incluso a veces combino abreviaturas en ingles y español

Por ejemplo:  InitValor, GetDatosIni
Y tambien siempre uso para los ciclos, los famosos i, j y k

Pero es que tambien he visto codigos con nombres largos, que tienden a perderme en la lectura, pero bueno en fin ya se que no tiene nada que ver con el rendimiento
Me quedo aclarado todo