Victor H. Montenegro Isidin

Cuando escribimos un programa y definimos variables, funciones o procedimientos acostumbramos a colocarle un nombre descriptivo que nos dice de cierta manera que guarda la variable o que hace la función.

Ejemplo: si guardamos la suma de algún procedimiento en una variable, le podríamos poner a la variable SUMA, o si alguna función realiza una suma de dos números, le colocamos como nombre a la función SumaDosNumeros( ), etc.

Pero la descripción que le damos a nuestra variable o función, no nos entrega más información, como por ejemplo en el caso de una variable, el ámbito de la variable, el tipo de dato de la variable, la funcionalidad de la variable si es pasada la variable por referencia o por valor, etc. En el caso de una función podría interesarnos conocer el alcance de la función, el resultado que nos devuelve la función (tipo de dato), etc.

Es por todo lo anterior que se propone una nomenclatura para la denominación de Funciones/Procedimientos y/o variables:

1º Funcionalidad del identificador
      v   :   Variable
      p   :   Parámetro
      f   :   Función o Procedimiento
      c   :   Constante
      t   :   Tipo Definido por el Usuario -(Cuando se crea)

2º Alcance de Identificador
      p   :   Private
      g   :   Global o public
      l   :   Local
      v   :   ByVal
      c   :   ByRef

3º Tipología de resultado para function, variable (atributo), parámetro
      s   :   String
      o   :   Object
      i   :   Integer
      l   :   Long
      b   :   Boolean
      t   :   Tipo Definido por el Usuario-(Cuando se usa)
      v   :   Variant
      n   :   Sin resultado (ejecución como procedimiento)

Por ejemplo si tenemos la variable denominada SUMA en nuestro código, podriamos usar la nomenclatura y denominarla de la siguiente manera:

VPI_SUMA // En este caso se trata de una variable, de tipo privada y con tipo de dato Integer.

Luego para nuestra función SumaDosNumeros( ), podriamos usar la nomenclatura y nos quedaría:

FLI_SumaDosNumeros( ) // En este caso se trata de una función con ámbito local y devuelve un Integer.

Nomenclatura para la denominación objetos gráficos

      SynthText   :   txt
      SynthList   :   lst
      PushButton   :   cmd
      CheckBox   :   chk
      Label   :   lbl
      Grids (Grilla)   :   grd
      Frame   :   fra
      Form   :   frm

Nomenclatura propuesta por el Sr. David Contreras, docente de la Universidad Arturo Prat de Iquique.

Cuando iniciamos un proyecto es conveniente que el código que generamos en la construcción de esté, este lo más ordenado posible, para que en un futuro cuando deseemos hacerle mantenimiento, ampliarlo o simplemente que otra persona quiera modificarlo, sea los mas legible posible.

Esto es de vital importancia sobre todo en medianos y grandes proyectos, y es casi indispensable cuando utilizamos la Programación por Capas. Para lograr esto es conveniente que el código que generemos este lo más ordenado posible y para lograr esto es que separamos los archivos del proyecto en distintos directorios:


Los directorios contendrán la siguiente información:

DB --> Las Bases de Datos locales si es que las tiene.
DOC –> Toda la documentación relacionada con el proyecto.
EXT --> Archivos externos que necesita nuestro proyecto para funcionar.
OUT --> Ejecutables y otros (Ej. en Visual Basic los DLL)
PRJ --> Archivos que contienen un grupo de archivos de proyecto (Ej. en Visual Basic los .vbg)
SRC --> Códigos fuentes del proyecto.
TEST --> Archivos que utilizamos para hacer Tests.

A su vez cuando programamos por capas es indispensable separar el directorio SRC en:


Donde:

CLIENT --> Aquí van los archivos de la Capa de Reglas de Negocio.
SERVER --> Aquí van los archivos de la Capa de Datos.
SERVICE --> Aquí van los archivos de la Capa de Servicios.
USERINTERFACE --> Aquí van los archivos de la Capa de Presentación o Interfaz Gráfica.

Programación por Capas