Creando rutinas para programar mejor

[[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.

[[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

[[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

[[José Luis Garcí]]

Empezado por elrayo76

...
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.
....

Muchas gracias por tus consejos, se agradece sinceramente, pero a que te refieres con setear, nos podrias poner un ejemplo.

[elrayo76]

Cuando digo setear los componentes es poner los valores que yo quiero a las propiedades de los mismos.

Ejemplo:

Label.Caption := 'xxxx';
Label.AutoZise := True;

Saludos,
El Rayo

[Casimiro Noteví]

Para las variables uso sólo una letra: iCodigo, cNombre, fSuma, dFecha...
Para componentes visibles uso dos letras: lbNombre, edNombre...
Para formularios, una: Fmain, Fclientes, Flogin...
Constantes: _PI_ = 3,141592565
Property (parámetros y valores entre formularios): _iCodigoCliente, _iCodigoDocumento...
Data Modules: DMventas, DMcompras...
En las bases de datos es similar, pero con dos letras:
Tablas: tbClientes, tbUsuarios...
Stored procedure: SPlogin, SPsumaSaldos...
Trigger: TRxxxxAI, TRxxxBP, TRxxxAU... (after insert, before post, after update)
etc.