Creando rutinas para programar mejor

[[José Luis Garcí]]

Ley hace un par de meses, en una de las revistas de programación que tengo, sobre sistemas y métodos para programar mejor y después de este tiempo he de decir que tenían toda la razón, daban una serie de consejos, de los cuales unos eran aplicables a mi manera de trabajar y otros no, por lo que os comento, por encima lo que me he acostumbrado a hacer, a la hora de programar.

Uno de los primeros pasos, es que utilizáramos, un esqueleto base para nuestros Forms, por lo que cree el mi AutoABM, este sistema nos permite primero ahorrarnos horas de programación al tener creado la estructura principal del programa, y en segundo lugar, dar una imagen homogénea de los form.

Realmente el tema del form de uso Estándar, es el que más tiempo nos ahorra, luego el resto, es mas pequeños tiempo de ahorro, entre ellos van los siguientes, son pequeñas chorradas que fun cionan muy bien, os pongo una pequeña lista

-Nombre del Form y de la unidad el mismo, añadiendo delante F para Fom y U para la unidad
-Espacio vertical entre componentes igual (yo lo he dejado en tres, si tienes CNPACK seleccionas los componentes y pulsas el botón para colocar igualado verticalmente con el interrogante, te pregunta "Please Enter the Space", ami por defecto me sale 4, lo cambio por 3 y listo.
-DbEdits con bevelKind (bkSoft) y BevelOuter(Bvnone) y ecolor Entrada en clMoneyGreen y Salida clWhite, La verdad es que le da un Aspecto diferente, ademas por cada 10 caracteres el espacio en el With le doy 65, con lo que no nos queda unos edits larguísimos que nunca vamos a rellenar del todo.
-En los IBDataSet y en los IbQuerry (son los que suelo usar) pulso en el Fields Edytor y añado los Campos, pulso sobre cada uno de ellos y cambio el texto del display label por lo que quiero que aparezca en mi caso, esto nos ahorra a la hora de arrastrar al form (con el Datasorce ya vinculado) el label del Campo con el texto que queremos y Dbgrid también, no suelo usarlo pero cuando puede ser necesario también el Editmask del Fields Edytor.
-Tamaños Estándar de botones en mi caso Spedd butons (son de 70x70 para img. 48x48 y de 105x105 para img de 100), los Buttons suelo usarlos según el espacio necesario.
-En el Código Cabecera identificativa de Cada procedimiento, función o Identificación de procesos más complicados y usar anotaciones de aclaración.
-Usar un archivo Pas con todas las funciones a usar, para tenerlas controladas.
-Procurar usar el mismo tipo de Form, aux. para las diversas partes del Código (form Logín, petición de datos, Mensajes de aviso, Etc).
Se que tengo más rutinas pero no recuerdo ahora mismo, ya que más o menos escribo de memoria y de mis apuntes, me quedan por acostumbrarme e implementar el añadir en cada modulo la Estructura de creación de las tablas, creación modular de la aplicación (estoy empezando a estudiarlo) y auto crear por código la base de datos y las tablas filtros y demás de Firebird, para que el programa pueda regenerar de cero en caso de aplicación multi Empresa (ni idea) ,tablas con Campos Estándar (nombre, Tipo, Ancho) para usar el mismo código, en estos campos y por último aprovechar el manejo de Campos res para tener las imágenes de botones ya establecidas en estos y no en el código, Cargando estas en el Create De cada Form, con el subsiguiente ahorro de espacio y memoria.

más o menos por aquí van mis tiros, el problema es implementarlo todo, acostumbrarse a ello, realmente nuestros form son dispersa por lo menos en mi caso así era) y la verdad que voy añadiendo los metodos y se nota en los cambios, tanto en tiempo como en rendimiento y visualmente.

Ahora me pregunto que rutinas y metodos para programar usas tú?.

[[newtron]]

Hola.

Aparte de tener en cuenta la mayoría de las opciones que comentas una cosa que intento hacer es declarar las variables con un nombre que empiece por el tipo de variable que es, por ejemplo:

Código Delphi [-]
sAux: String;
cAux: Currency;
iAux: Integer;

cosa que me salto muchas veces pero lo intento, lo intento.

[Casimiro Notevi]

Todas esos detalles y muchos más los tengo en cuenta desde... 1985

Los que corresponden a programación gráfica (no existía antes para mí) desde 1998.

[[newtron]]

Empezado por Casimiro Notevi

Todas esos detalles y muchos más los tengo en cuenta desde... 1985

¿Y no nos ilustras?

[[ElKurgan]]

Aunque no está sólo orientado a Delphi (cubre Java o C++), este documento de Alexander Hristov es uno de los mejores que conozco en cuanto a uniformidad de estilo.

Saludos

[Casimiro Notevi]

Empezado por newtron

¿Y no nos ilustras?

Pues bueno, nada que no se encuentre en los libros
Básicamente es tener siempre unas normas comunes a cumplir entre todos los programadores, desde la nomenclatura a usar hasta los iconos, las herramientas, cosas a hacer, no olvidar, etc.
Todos los forms heredan de una plantillaform, todos los forms de mantenimientos de tablas heredan de un form "plantillatablas" que a su vez hereda de plantillaform. Todas las funciones comunes están en un uutiles.pas, todas las de bases de datos en uutilesbd.pas, todas las de gráficas en uutilesgraficas.pas, etc.
Siempre usar los datamodule para cada sección del programa, ejemplo: dmmain, dmmasientos, dmexportaciones, dminformes, etc.
Al usar siempre un form plantilla y usar siempre los iconos disponibles y unas normas para la presentación, entonces queda todo bastante homogéneo.
La nomenclatura está descrita para todo, variables, componentes, procedimientos, triggers, tablas, etc. por lo que muchas veces es difícil distinguir quién ha escrito un código, salvo pequeños detalles como la forma de escribir los comentarios, la posición de los "begin", etc.
Para las variables uso una "versión propia" de la notación húngara de Charles Simonyi, que siempre ha sido el programador más admirado por mí, aunque trabajara para microsoft
Antes de cualquier proyecto "me rodeo" de las herramientas necesarias, control de versiones, backups, "to-do", utilidades, etc. y previamente documento todo mediante un análisis bastante completo del proyecto a realizar.
Evidentemente mis jefes ponen el grito en el cielo porque piensan que todo eso es perder el tiempo, incluso me dijeron una vez que hacer un análisis previo no sirve para nada, que no existe la profesión de analista , me quedé "planchao".

[[fjcg02]]

Empezado por José Luis Garcí

...
Uno de los primeros pasos, es que utilizáramos, un esqueleto base para nuestros Forms, por lo que cree el mi AutoABM, este sistema nos permite primero ahorrarnos horas de programación al tener creado la estructura principal del programa, y en segundo lugar, dar una imagen homogénea de los form.
...

Creo que publicaste este módulo en su día. Me interesó y le estuve echando un vistazo. Creo que mejor que esa solución es la herencia entre formularios.
Un buen ejemplo lo teneis en esta serie de artículos, basados en un curso de Ian Martins. ( corrígeme si me equivoco, por favor ). Espero que sea de utilidad.

El resto de las directrices indicadas por José Luis son absolutamente recomendables.

Saludos

[[José Luis Garcí]]

interesantes comentarios, el mayor problema de ser autididacta es que realmente somos vampiros asorbiendo información, pero sin un correcto sistema de control
fjcg02, me interesa esos articulos podrias poner el enlace.

[[Chris]]

Muy buenos consejos. Muchas gracias por compartirlos José!

Pero tengo que discrepar en lo siguiente:

Empezado por José Luis Garcí

-Usar un archivo Pas con todas las funciones a usar, para tenerlas controladas.

Para mí, entre más unidades mejor. Déjenme les explico: Organizo las funciones según su propósito en el código. Por ejemplo, en una unidad que se llame gui_tools.pas agrupo todas las funciones que asistan en la programación de la GUI. Así mismo lo hago cómo por ejemplo con una unidad que se llame system_utils.pas agrupo funciones que hagan uso de la API del S.O. Sin embargo, busco como irlas separando según su nivel. Por ejemplo la unidad gui_tools.pas puede hacer uso de otras unidades de más bajo nivel que también ofrezcan exclusivamente funcionalidades para la GUI.

Saludos,
Chris

[[Al González]]

Busca el término herencia visual, es algo que no hay que pasar por alto cuando se programa en Delphi.

No suelo emplear prefijos en los nombres de las variables de una aplicación, pero sí en los nombres de componentes y otros elementos que representan objetos:

Prefijos de dos letras minúsculas para nombres de objetos según su tipo genérico:

ae Application Events
al Action List
bn Band (como las bandas de un reporte)
bt Button
bv Bevel
cb Combo Box
ch Check (verificadores como los usados en bases de datos)
ck Check Box
cl Check List box
cm Color Map
cn Connection
co Column
db Database
de Data Entity
dl Dialog
dm Data Module
ds Data Source
dt Data Set
ed Edit
ev Events
ex Exception
fk Foreign Key
fl Field
fm Form
fr Frame
gb Group Box
gn Generator
gr Grid
il Image List
im Image
ix Index
lb Label
ll Level (niveles como los de cxGrid)
lx List Box
mm Memo
mn Menu
mi Menu Item
mr Mark
mw MagiaWord
nv Navigator
od Open Dialog
pb Progress Bar
pc Page Control
pl Pipe Line
pn Panel
pr Provider
pt Point
qr Query
rb Radio Button
rg Radio Group
rl Role
rp Report
sb Scroll Bar
sh Shape
sl Style (estilos como los de Developer Express), Save point List
sp Stored Procedure, Save Point
sr Style Repository (depósitos de estilos como los de Developer Express)
ss Style Sheet (hojas de estilo como las de Developer Express)
st Status Bar
sx Scroll Box
tb Table
tc Tab Control
tg Trigger
tm Timer
tr Tool Bar
tn Transaction
ts Tab Sheet
vr Viewer (visores como el TppViewer de ReportBuilder)
vw View (vistas de bases de datos o vistas como TListView, TTreeView o como las de cxGrid)

...más los que se sigan acumulando.

Y mis abreviaciones (aunque algunos autores un poco desorientados desaconsejan usar abreviaciones) son las siguientes:

En los identificadores en inglés, sólo abreviar palabras frecuentemente utilizadas y compuestas por tres o más sílabas, usando abreviaciones estándares y sin repetir la misma abreviación para dos o más significados (abreviar sólo la acepción más común). También abreviar cuando el identificador tenga conflicto con alguna palabra reservada o tipo de dato estándar ("Object", "Message", "String", "Type", "Variant", etc.). En estos casos no abreviar si es un monosílabo combinado (ejemplo TypeName).
Lista de abreviaciones aceptadas:

Absolute Abs
Application App
Array Arr
Attribute Attr
Auxiliary Aux
Boolean Bool
Calculate, Calculated Calc
Character Chr
Class Cls
Condition Cond
Configuration Config
Currency Curr
Decrement Dec
Definition Def
Delimit / Delimiter Delim
Descriptor Desc
Destination Dest
Difference Diff
Dimension Dim
Directory Dir
Document Doc
Enumerate Enum
Expression Expr
Extension Ext
Function Func
Increment Inc
Information Info
Initialize Init
Integer Int
Interface Intf
Maximun Max
Memory Mem
Message Msg
Minimun Min
Object Obj
Operator Op
Original Orig
Parameter Param
Pointer Ptr
Position Pos
Previous Prev
Procedure Proc
Property Prop
Record Rec
Reference Ref
Register / Registry / Registration Reg
Relation Rel
String Str
Sub String SubStr
Supplementary Suppl
Synchronize Sync
Temporary Temp
Transaction Trans
Type Typ
Variant Var

...más las que se sigan acumulando.

Saludos.

Al González.

[roman]

Empezado por Al González

Y mis abreviaciones (aunque algunos autores un poco desorientados desaconsejan usar abreviaciones) son las siguientes:

Y, ¿por qué consideras desorientados a dichos autores?

// Saludos

[[Al González]]

Hace tiempo, en alguna página de Microsoft sobre .NET, leí la recomendación de evitar el uso de abreviaciones en aras de darle claridad al código. Pero considero que esto podría ser contraproducente si ni siquiera se acepta un pequeña lista de excepciones como la que expuse al final del mensaje anterior, la cual, dicho sea de paso, contiene muchas de las abreviaciones que Borland y miles de programadores hemos usado con fines de practicidad y sin restar un ápice de claridad o legibilidad al código.

No encuentro muy recomendable ver identificadores como "SynchronizeStringParameters" dentro de un nutrido párrafo de código lleno de nombres similares, mientras que "SyncStrParams" aligera el esfuerzo neuronal. Tal vez de forma aislada no se note mucho la diferencia, pero una vez inmersos en la realidad (una nutrida rutina de código) se aprecia de mejor forma.

Saludos.

Al.

[roman]

Bueno, pero eso no los hace desorientados. Es simplemente otra forma de ver las cosas. Yo trato de utilizar identificadores completos pues, contrario a tu visión, me produce menos esfuerzo neuronal a la hora de leer el código, sobre todo si el codigo no es mío. Además, la era del 8.3 terminó hace muchos años .

Pero estoy de acuerdo en que pueden hacerse excepciones, conforme uno lo crea conveniete. A fin de cuentas, lo impórtante es que uno trabaje en la forma que le sea cómoda y productiva, adoptando las técnicas que le parezcan mejores.

// Saludos

[[José Luis Garcí]]

Gracias por las recomendaciones voy apuntando, en las abreviaturas, suelo usar el siguiente sistema, por ejemplo nivel de usuario sería VarNivelUsuario, he de decir que me gusto la propuesta de Newtron y la AI Gonzáles y creo que voy a usar el siguiente sistema
indica variable, Tipo, Nombre abreviado de tres en tres, la misma variable de antes quedaría VarSNivUsu (Var-S-Niv-Usu)

En cuanto al tema de separa las funciones en varios archivos pas, la verdad es que se vuelve complicado según va creciendo

[[Al González]]

Empezado por José Luis Garcí

[...] por ejemplo nivel de usuario sería VarNivelUsuario, he de decir que me gusto la propuesta de Newtron y la AI Gonzáles y creo que voy a usar el siguiente sistema
indica variable, Tipo, Nombre abreviado de tres en tres, la misma variable de antes quedaría VarSNivUsu (Var-S-Niv-Usu)

No hagas eso, por más que ese tal "AI" que ni conozco te haya dado la idea.

De verdad, un sistema estricto de abreviaciones por cantidad de letras no es una buena idea. Por el contrario, sería inhumano.

[Casimiro Notevi]

Empezado por Al González

Por el contrario, sería inhumano.

Y que lo digas
Hay que buscar un término "intermedio", usar un lenguaje "humano", pero sin pasarse

function ExtraerElMayorNumeroParDeUnaCifraPasadaEnFormatoTexto(sNumeroComoTexto:string):string;
function ExElMaNuPaDeUnCiPaEnFoTe(sNuCoTe:string):string;

[[Al González]]

Empezado por Casimiro Notevi

Y que lo digas
Hay que buscar un término "intermedio", usar un lenguaje "humano", pero sin pasarse

function ExtraerElMayorNumeroParDeUnaCifraPasadaEnFormatoTexto(sNumeroComoTexto:string):string;
function ExElMaNuPaDeUnCiPaEnFoTe(sNuCoTe:string):string;

+1
Así es Casi, ni tanto que queme al santo...

[[fjcg02]]

Empezado por fjcg02

Creo que publicaste este módulo en su día. Me interesó y le estuve echando un vistazo. Creo que mejor que esa solución es la herencia entre formularios.
Un buen ejemplo lo teneis en esta serie de artículos, basados en un curso de Ian Martins. ( corrígeme si me equivoco, por favor ). Espero que sea de utilidad.

El resto de las directrices indicadas por José Luis son absolutamente recomendables.

Saludos

Vaya soy un carck, cito una web y no pongo la dirección. La misma es de Salvador Jover. Son varios artículos.

http://www.sjover.com/delphi/2009/09...los-mayores-1/

Saludos

[[José Luis Garcí]]

Muchas gracias fjcg02.

[elrayo76]

Para los que no lo conocen, acá les dejo un sitio que encontre en mis comienzos con delphi hace mucho tiempo. Fue escrita por Xavier Pacheco and Steve Teixeira en 1998.

Tiene un monton de recomendaciones que ellos llaman Estandares de Código. Está en inglés pero vale la pena que la tengan a mano para estudiarla y poner en practica muchos de las cosas que dicen.

http://www.econos.de/delphi/cs.html

Yo he puesto en práctica mucho de los que dice. Igualmente me gustaría comentar algunas de las cosas que yo hago.

Para las variables las comienzo con tres letras minúsculas que indican el tipo de la misma. Por ejemplo una variable de tipo String sería strXxxxx, una de tipo Integer sería intXxxxx. A las qe son de tipo objetos las comienzo con obj.

Lo mismo hago con los nombres de los formularios (frm), datamodules (dm) y componentes. Aunque en aulgunos casos solo utilizo dos letras.

Si les sirve de algo el CnPack tiene una opción llamada Prefix Wizard que contiene una extensa lista de prefijos que se los agrega automáticamente cuando se carga un componente nuevo al formulario o datamodule. Estos prefijos se pueden cambiar si uno quiere.

----------
Para los formularios siempre tengo creados los formularios base para cada tipo de pantalla y heredo de ellos.

----------
Para las constantes me he acostumbrado a ponerlas siempre en mayúsculas para identificarlas de las variables. Tambien en estas para los mensajes al usuario trato de identificar que tipo de mensaje es. Por ejemplo: Si son errores uso ERROR_xxxxx, si son advertencias uso ADVERTENCIA_xxxxx, si son mensajes simples MENSAJE_xxxx, o si son de informacion INFORMACION_xxxxx

----------
Cuando en un formulario tengo un componente TLabel y uno TEdit que tienen relación los dos tienen el mismo nombre pero lo que cambia son las tres primeras letras que los identifican.

----------
Generalmente a las funciones/procedimientos para obtener datos (no importa de donde) los identifico con el prefijo Get y los de guardar con el prefijo Set. Esto viene de el Getter y Setter de la propiedades.

----------
Los mensajes, títulos, caption, ect que puedan llagar a cambiar de idioma en algun momento los pongo en constantes y los uso de ese lugar. Si solo son para un formulario en particular van directamente al comienzo de la parte de implementación y sino los pongo en una unit generica para el proyecto.

----------
Para las variables que uso en ciclos como FOR me acostumbre a usar y esto viene de largo cosas como una sola letra (Ejemplo: FOR i := 0 to 10). Si uso otra cosa es en casos especiales.

----------
Otra cosa que me acostumbre a hacer es setear todas las propiedades de los componentes que quiero distintas a las default por código. Esto lo empece a hacer porque en proyectos donde son varios lo que trabajan, siempre me las cambiaban desde el inspector de objetos.

----------
También y para finalizar por el momento, me acostumbre a ser muy prolijo con el armado de los formularios. Trato de que los componentes tengan el tamaño justo de los datos que se ingresan, que esten bien alineados, que el espacio entre ellos sea el mismo en todos (aunque puede que alguno este mas separado para identificar que no pertenece al grupo anterior). Tampoco hay que olvidar que hay que tabular bien los componentes en los formularios, en mi caso los tabulo de izquierda a derecha y de arriba hacia abajo (esto es en el sentido que todos leemos).

El orden en que aparecen los datos en los formularios debe ser estudiado con cuidado. Por algo hay un orden en los formulario de papel que todos solemos llenar, alguien se todo el trabajo de ver como quedan mejor los datos para hacernos mas facil la lectura y llenado de los mismos.

Saludos,
El Rayo