Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Debido a las anteriores razones, en este trabajo se trataran temas como los que
siguen a continuación.
Estándares de Codificación
OBJETIVOS ESPECÍFICOS
¿Qué son?: son normas y reglas que convienen los programadores para
especificar como debe escribirse el Código Fuente y así evitar la incomprensión
del mismo, en procesos posteriores de mantenimiento, actualizaciones y
reparación de errores de ejecución. Por otro parte, vale la pena aclarar, que el
establecimiento de estándares de codificación no son de uso o de carácter
obligatorio, no obstante, son una herramienta útil para combatir un mal epidemial
que sucede en los mantenimientos, la dificultad para realizar los mismo de manera
eficaz y eficiente.
1. VARIABLES.
NOMENCLATURA DE VARIABLES
De igual forma, para que nuestro código sea más entendible y claro, el
identificador de la variable debe ser mnemotécnico, es decir que debe reflejar el
uso dentro del programa de la misma.
REGLAS Y CONSEJOS PARA EL NOMBRAMIENTO DE VARIABLES
Vemos que insertó caracteres especiales, ademas de que uso el guión normal ( no
el subguión ), por lo tanto puede que el programa entienda que es una resta,
entonces está mal delcarado por sintaxis.
Explicación: por sintaxis como ya hemos visto, deben cumplir con estas reglas,
entonces no se puede comenzar con un número, ya que se debe comenzar por
una letra como dice la regla, ejemplo:
Explicación: las variables no pueden llevar espacios en blanco, solo pueden ser
separadas por un signo dedicado a ser usado como un espacio, el cual es el
subguión ( _ ), entonces en una variable cuando vean un subguión, practicamente
estan separando algo ( para que no parezca una ensalda ), ejemplo:
FUNCIONES
Las funciones son subprogramas que dependen del programa principal y que se
usan para realizar tareas independientes y específicas y pueden ser invocadas
desde la misma función o desde cualquier parte del programa las veces que sea
necesario.
Nombramiento de Funciones
Tipos de Funciones:
Una función sin parámetros es aquella que no recibe variables de entrada para la
función. Se define de la siguiente forma:
Public Function suma() As Integer
Dim operacion As Integer
operacion = 5 + 5
Return operacion
End Function
Cuando tengamos nuestra función creada, solo queda darle utilidad, y fácilmente
se hace de la siguiente forma:
TextBox1.Text = suma ()
Al hacer esto, el valor que retorno la función “suma”, será el que contendrá el
“TextBox1”:
Una función con parámetros es aquella que recibe variables de entrada para la
función. Estas variables son procesadas y luego se retorna un único dato. Su
definición varia un poco, a diferencia de las funciones sin parámetros, estas se
definen de la siguiente forma:
Luego como en toda función con parámetros, procesamos los datos que
recibimos por parámetros, en este caso, la función la utilizamos de la siguiente
forma y pasaríamos nuestros parámetros así:
Nomenclatura de constantes
Por ejemplo:
SI NO
define("EDAD_VOTACION”, "18");
... if (18<$edad)
if (EDAD_VOTACION <= $edad)
COMENTARIOS DE CÓDIGO
No hay que olvidar que el código y sus comentarios forman un conjunto. Así
que debemos prestar la debida atención a ambos apartados. Para que nuestro
código sea elegante, limpio y fácil de mantener, podemos seguir los siguientes
consejos.
Es una regla básica, que aunque no está directamente relacionada con los
comentarios, influye mucho en ellos. Nuestras variables, clases y métodos, deben
tener un nombre descriptivo.
Lo normal es que los nombres de las clases sean sustantivos que representen una
entidad (Cliente, Proveedor etc.). Los métodos representan una acción, por lo que
su nombre suele contener algún verbo (devolverNuevoCliente, calcularPrecioTotal
etc.). Además deberemos intentar que las variables, propiedades y parámetros,
tengan un nombre que describa el valor que contienen (totalclientes,
totalpresupuesto etc.).
¿Qué conseguimos con esto? Pues además de un código fuente mucho más
legible, conseguimos reducir el número de comentarios necesarios. Por ejemplo:
No hace falta explicar cosas obvias. El código fuente en el 98% de los casos lo va
a leer otro programador. O al menos alguien con conocimientos de programación.
Por ejemplo:
// Comprobamos si el contador es 5
if (contador == 5)
Ese comentario no aporta nada. Mejor si lo eliminamos. Mejor todavía si no
llegamos ni a escribirlo.
Puede ser útil comentar lo que hace un método antes de su declaración. Incluso
podemos comentar sus parámetros. Pero hay que tener en cuenta que debemos
comentar el "qué" y no el "cómo". Es decir, debemos explicar qué hace nuestro
método. El "cómo" hace el método su función ya va explicado en el código.
Un comentario tiene que ser claro y explicar bien las cosas. Pero los comentarios
también hay que mantenerlos. Si describimos lo que hace un método, y en algún
momento la funcionalidad cambia, también tendremos que actualizar los
comentarios. Por tanto mejor que los comentarios sean breves y concisos.
Es algo que no suele hacerse a propósito, pero que puede darnos más de un
quebradero de cabeza. Tiene que ver con el punto anterior y el problema de no
mantener los comentarios. A veces porque nos dejamos algo por hacer, o por qué
una especificación ha cambiado, nuestro comentario queda obsoleto. O lo que es
peor, el comentario expresa algo distinto a lo que en realidad se está haciendo. Si
nos fiamos del comentario, podemos generar errores no esperados.
En general a los que desarrollamos, no nos gusta comentar. Es algo aburrido, que
solemos dejar para más tarde. Pero procrastinar el comentado del código es una
mala idea por varias razones. La primera es que, al final, nos veremos obligados a
comentar un gran volumen de código de golpe. Eso es todavía más aburrido, y
nuestros comentarios serán peores. La segunda es que las ideas pierden frescura
según pasa el tiempo. Escribir comentarios de código que no acabamos de hacer
es más complicado y lleva más tiempo.
Esto depende de un poco del ámbito del código fuente. En ámbitos laborales,
deberemos ser serios y correctos. Y más si el código es para un cliente. Si el
código lo estamos haciendo para nosotros, los comentarios pueden tener un tono
más distendido. Eso sí, mejor evitar palabras malsonantes, porque nunca se sabe
quién puede leer el comentario.
Conclusión