viernes, 7 de septiembre de 2007

Estándar de codificacion

existe algún estándar para codificar?
yo se que este tema es muy discutido tanto dentro de las empresas como fuera.

por que surge mi inquietud, tengo que desarrollar un sistema en .NET con VBSCRIPT :( y están definiendo ciertas reglas para la definición de variables, parámetros y objectos.

por ejemplo para las variables anteponer el tipo en la declaracion.
VBSCRIPT

Dim inti as Integer
Dim strCadena as String
Dim objPersonaNueva as Persona
Dim longNumeroLargo as Long
Function foo(ByVal paramNumero as int)
// Anteponer la palabra param si es un parametro

bonus track: Como quedaría el típico for en c#
for (int i=0;i < largo;i++)
quedaria algo asi:
for (int intI=0;intI < intLargo;i++)

Por que no?

  • por que uno pierde la gracia de los ide, el típico control mas espacio(prediccion) si todo tiene el mismo prefijo cuando le damos control+espacio con la palabra int nos va a arrojar por lo menos 10 coincidencia
  • por usas prefijos si los ide, la mayoría tiene una opción de saber ir a la definición, ademas en este caso puntual, nadie edita cosas en punto en el block de nota, por que es muy complicado compilar por consola una aplicación web.
  • conversando ayer mi amigo y companero leo.soto, me comento lo siguiente:"Microsoft hasta antes de .NET, es decir VB6 recomendaba usar sufijos, pero actualemente no lo recomienda". ahora recomienda en cosas que el nombre de la variable no refleje mucho el tipo de la variable por ejemplo nombre sabemos que es de tipo String, pero rut de que tipo es?? por eso ahora Microsoft recomienda para estos cosas colocar rutInt o rutString.
A me me parece excelente dentro de una empresa que se trate de mojorar los codigos que uno genera pero creo que no se puede ser mu estrictos. por ejemplo seria bueno plantearse lo siguientes puntos.
  • Cantidad de lineas por métodos.
  • Nombre de variables a los C o a lo java personaNombre o persona_nombre
  • si es posible definir variables contadores dentro del for. for (int i =0..........
  • que siempre los nombres de las variables tienen que reflejar el contenido, no usar variables hola por ejemplo(parece autocritica).
lo que si encontró que es muy importante son los comentarios tanto por método y por clase,
ademas crear un tipo de membrete al inicio de cada clase con las fecha de creación, autor, y fecha de modificación, y quien las hizo, esto no esta de mas aunque, por lo general uno usa un sistema de control de versiones asi, que uno debería saber quien hizo que y cuando. pero no esta demás.

Conclusión:

Si estoy de acuerdo con los estándar, pero en esto punto solo se puede confiar en el criterio del desarrollar, aunque muchos somos unos descriteriados. pero el hecho de sufijar el tipo lo encuentro latoso y a lo mejor poco elegante para un codigo, perlo general uno va a terminar colocando el prefijo va a terminar enumerando las variables per ejemplo: objPersona1 y objPersona2.

por favor hagan sus aportes, ya que este tema es super amplio. Gracias

y de nuevo disculpen las faltas de ortografías.

8 comentarios:

  1. Primero lo más importante: Ya ni Microsoft recomienda la notación húngara. [notación húngara es como se conoce a la práctica de poner un prefijo que identifica al tipo de dato]

    En cuanto a mi opinión, coincido contigo en el argumento de que hoy por hoy, las herramientas te pueden indicar el tipo de dato de una variable sin necesidad de ensuciar el codigo con información redundante por todos lados.

    Pero además, se me acaba de ocurrir que el sólo tener dudas sobre el tipo de una variable (cuando realmente sea importante saberlo!) puede indicar que el código en cuestión no es claro. Y eso no se arregla adornando variables. ¡Se arregla mejorando el código! Hacer otra cosa es atacar el síntoma en lugar de la enfermedad.

    Finalmente: Yo nunca dije que rutString era una buena idea. Mi ejemplo era rutTextBox. Sé que es cosa de gustos, pero rutTextBox o rentaComboBox me parecen razonables, pero rutString y rentaInt me parecen horribles.

    Ah!, y eso de poner el nombre de los autores, fechas de modificación, blablahblah es como tu dices, datos que maneja el SCM, y si están de más en el código. Pero ya me extendí mucho, así que la argumentación la dejo para otro día.

    ResponderEliminar
  2. si leo, tienes toda la razón con lo de rutString, jojo, sorry.

    cuando tengas un tiempito puedes argumentar un poco por que no usar los comentarios en el código, ese como membrete de las clases.

    por que igual tienes razón que todo los comentarios están en svn, y siendo uno ordenado solo debería sacarle provecho a esta herramienta.

    ResponderEliminar
  3. bastante molesto estar anotando nombres de variables compuestas por el tipo de dato y el nombre.. a lo
    mejor util en tipos int,string..etc
    (lo dudo) pero bastantes apestosas al definir el nombre de un objeto, tengo clases con nombres bastante grandes y definirlo de la forma :

    NombreDeLaClase nombreDeLaClaseNombreDeMiObjeto; queda muy molesto ..

    ahora como bien comentaron cuando
    quiere ocupar el objeto generalmente
    el ide suguere o te autocompleta el resto..te encargo la cantidad de variables y objetos ke te va a sugerir en una aplicacion grande..

    ahora con ides gratis y bastante potentes ..quien ocupa el block de notas? (no,el Leo no juega)

    ResponderEliminar
  4. Cualquiera que ocupe el bloc de notas para programar es estúpido y/o masoquista: No tiene ventaja alguna (Ni siquiera ser lo unico disponible en casos de emergencia: hasta el wordpad y el edit de DOS están en todos lados y son algo mejorcitos)

    En cuanto a los membretes en el código fuente con los autores, fecha de modificación, etc: están de más pues son redundantes (están en el SCM) no son confiables (se escriben a mano => es fácil que tengan errores) y sirven para que algunos crean que porque existen 40 líneas de comentarios inútiles al principio del código entonces la lesera está "documentada".

    ResponderEliminar
  5. jajaja que wena y que mala ala vez la de los monos, y si muchas veces uno hace las cosas, simplemente, por que la demas gente la hace asi, y toma esa opcion como correcta sin plantearse el por que??..

    Con respecto a al famoso membrete, yo estoy de acuerdo que esto se debería manejarse en svn. de hecho comente esto en una reunión y no están dispuestos a sacar el membrete, al parecer, ese código le da mas profesionalismo con esos comentarios, al inicio(todo esto lo digo de forma irónica, por si no se entiende).

    Por otra parte a mi me queda la duda si por ejemplo tienes un proyecto de varios meses, y tienes todo en svn, con comentarios, y todo super bien ordenado. y después tienes que instalarlo en sus dependencias, después como mantienes esos comentarios y fechas en los repositorios por ejemplo en svn.

    ResponderEliminar
  6. "Por otra parte a mi me queda la duda si por ejemplo tienes un proyecto de varios meses, y tienes todo en svn, con comentarios, y todo super bien ordenado. y después tienes que instalarlo en sus dependencias, después como mantienes esos comentarios y fechas en los repositorios por ejemplo en svn."

    No entendí. ¿Tú dices cómo se mantienen la historia en el SCM si es que después se modifican los fuentes instalados en producción? ¿O te refieres a cómo el cliente conoce la historia del proyecto si sólo recibe los fuentes "finales"?

    [Ah, y la súper estrategia de aparentar profesionalismo vale hongo en el mediano/largo plazo.

    Y según el criterio, me imagino que (entre otros) Google , Microsoft, y Sun son poco profesionales por colocar sólo el copyright al principio de cada archivo.

    ResponderEliminar
  7. exite uno que se llama java EE

    http://www.epidataconsulting.com/tikiwiki/tiki-pagehistory.php?page=JEE&diff2=19&diff_style=sideview

    ResponderEliminar