27 respuestas en este tema

[egostar]

Estaba generando una auditoría de calidad QA a un programa resultando algunos avisos de NC Use Camel casing.

Yo normalmente utilizo esta forma:


FxlDataSet
FFilePath
FFileName


Estuve investigando al respecto y encontré que el estilo que uso es Pascal Case y no Camel Case, resulta que la regla del Camel Case es que la primer letra debe estar en minúscula.


fxlDataSet
fFilePath
fFileName


Mi pregunta es ¿cual forma es la que utilizan ustedes?.

History around Pascal Casing and Camel Casing

Salud OS

[cadetill]

Buenas,

Pues yo ninguna, porque no sabía ni que existía

Será cuestión de darle una ojeada

Nos leemos

[cadetill]

Buenas,

Bueno, visto un poco que es eso, ya me encuentro en disposición de decirte lo que hago.

Para definición de clases uso PascalCase, en cambio, para nombrar a los objetos suelo usar camelCase.

Si te sirve.....

Nos leemos

[felipe]

Buenas,

Pues yo ninguna, porque no sabía ni que existía

Será cuestión de darle una ojeada

Nos leemos

Somos dos, pero según Wikipedia el asunto no es cosa de otro mundo

La verdad no veo una diferencia significativa, yo creería que para quienes desconocíamos el tema es más de comodidad o estilo propio para hacer las cosas.

De ser así, el mío sería Pascal Casing


Saludos!

[Delphius]

Hola Amigo,
Estoy un tanto confundido...

¿Qué significa el aviso NC Use Camel casing? O mejor dicho... ¿a que hace referencia dicho aviso... sobre todo la sigla NC? 

Supuestamente conviven ambos estilos, al menos así lo indica y da a entender la nomeclatura. Por ejemplo, en los tipos enumerados, y en conjuntos se utiliza CamelCase. Por ejemplo:

delphi

type TAnchors = set of TAnchorKind;
type TAnchorKind = (akTop, akLeft, akRight, akBottom);

Pero al nombrar las propiedades, métodos, y atributos (por dar algunos ejemplos) utiliza, en su lugar PascalCase:

delphi

FTransparentColorValue: TColor;
procedure RefreshMDIMenu;
...
function GetMDIChildren(I: Integer): TForm;

Me pregunta es... ¿si utilizamos CamelCase o PascalCase en qué... atributos, variables, propiedades... ?

Si tu preocupación amigo es respetar lo más posible la nomeclatura de Delphi, recomiendo la lectura de Object Pascal Style Guide.

Por cierto... ¿PascalCase?  Yo a eso lo conozco como lowerCamelCase. Que consiste en que la primera letra sea minúscula, que se antepone a UpperCamelCase.

Tanto lowerCamelCase como UpperCamelCase no son más que los posibles casos de uso de la Notación CamelCase.

Podría considerarse a los tipos enumerados y de conjunto como una especie de lowerCamelCase mezclado con una variación de la Notación Húngara. Si prestan atención, los nombres de los tipos enumerados siguen la nomeclatura lowerUpperCase, pero siendo en minúscula las letras capitales del nombre. En el ejemplo que he dado, si el nombre del tipo es TAnchorKind, sus valores se nombran como el prefijo ak.

Yo trato en lo posible de apegarme a la nomeclatura de Delphi cuando programo.... aunque reconozco que en las últimas semanas se me ha dado por empezar a adoptar un criterio formal de nomeclatura para nombrar los controles y componentes. He estado sintiéndome un tanto molesto y confundido al ponerles nombre a los componentes y controles... en ocasiones no logro recordar que tipo de controles son... ¿botón? ¿label? ¿edit?

Es así que, aprovechando las características de cnPack, voy a empezar a tener un estilo:
Antepongo al nombre del componente, un prefijo (en minúsculas) que sigue unas reglas simples: las letras capitales del nombre de la clase más la última letra. En caso de que un segundo componente o control tenga el mismo prefijo, se agrega la segunda letra del nombre y no sólo la primera letra capital.

Por ejemplo: los componentes de la clase TButton llevan el prefijo bn; los TCheckBox llevan cbx; CheckListBox se transforma en clbx; TStringGrid en sgd.
Un ejemplo de la regla de "desempate"... CheckBox y ComboBox... si siguiera sólo la regla de letras capitales ambos se transforman en cbx, pero como CheckBox está primero en la lista, el ComboBox pasa a ser cobx.... Más adelante aparece un TColorBox, otro empate con cobx. por tanto para el TColorBox queda en colbx.

Aún no he decidido como llevar un criterio para mis propias variables que no sean componentes... no estoy totalmente convencido de adoptar Notación Húngara.
He notado que algunos la utilizan. Por el momento mis variables se capitalizan, excepto aquellas que cumplen un rol de matemática, como la eterna i, j, k que solemos utilizar en ciclos, sumas, restas... Un criterio mio que todavía lo tengo bastante apegado es el de adaptar la nomeclatura a la de mis fuentes. Por ejemplo, si en libros utilizan C_i, yo en código lo transformo en Ci.
Lo que si tengo como manía es el uso del guión bajo en constantes para separar las palabras y el uso de mayúsculas. Por ejemplo:

delphi

RESULTADO_CORRECTO = $0001;

Supuestamente eso viola la guía.

Saludos,

[felipe]

Que tal Delphius,
Me parece muy claro lo que comentas, aparte conoces bien el tema; por mi lado reitero un total desconocimiento de ello, y aún así como dije "el tema es más de comodidad o estilo propio para hacer las cosas", considero que no estaba tan perdido despues de todo  , puesto que igual comparto la forma de trabajo a como lo expones, trato de ser ordenado y por simple observación tomé por costumbre cosas similiares a lo que decías, por ejemplo:

si el nombre del tipo es TAnchorKind, sus valores se nombran como el prefijo ak.

De igual forma, el nombrar componentes y usar prefijos que identifiquen su clase.

En algunos casos es conveniente comentar el código, pero pocas veces lo pongo en práctica, aquí si me declaro culpable 


Saludos!

[egostar]

.....¿Qué significa el aviso NC Use Camel casing? O mejor dicho... ¿a que hace referencia dicho aviso... sobre todo la sigla NC? 

Supuestamente conviven ambos estilos, al menos así lo indica y da a entender la nomeclatura. Por ejemplo, en los tipos enumerados, y en conjuntos se utiliza CamelCase. Por ejemplo:
......
Si tu preocupación amigo es respetar lo más posible la nomeclatura de Delphi, recomiendo la lectura de Object Pascal Style Guide......

Bueno, no es preocupación, de hecho es solo un asunto simple de curiosidad, lo de NC es la abreviación de Naming Conventions del resultado del QA Audit.

Debo reconocer que nunca me preocupé por este asunto y me dió como he dicho curiosidad.

Salud OS

[egostar]

Otro aviso que muestra dice esto

PSIB Place Statment In Block

Según la descripción del aviso

Place Statement In Block (PSIB)
Description:

The statement of a loop should always be a block. The then and else parts of if statements should always be in blocks. This makes it easier to add statements without accidentally introducing bugs (due to forgetting to add braces).

Me dice que en éste código hay probabilidad de un bug.

delphi

  if not Campo.IsNull  then
    xsDecArray[Index].DecimalString := Format('%f', [Campo.Value])
  else xsDecArray[Index].DecimalString := Format('%f', [0.0]); 
  Result := xsDecArray[Index];

Lo correcto es así:

delphi

  if not Campo.IsNull  then
  begin
     xsDecArray[Index].DecimalString := Format('%f', [Campo.Value]);
  end
  else begin
         xsDecArray[Index].DecimalString := Format('%f', [0.0]);
  end;
  result := xsDecArray[Index];

Salud OS

[cadetill]

Buenas,

La verdad no veo una diferencia significativa, yo creería que para quienes desconocíamos el tema es más de comodidad o estilo propio para hacer las cosas.

Completamente de acuerdo y, como comentaba, para temas de clases uso el PascalCase o UpperCamelCase, en cambio, hago lo mismo que Delphius en los enumerados e incluso en los nombres de los componentes, ayudado también por cnPack como Delphius, es decir, mis TButton se llaman bLoQueSea, mis TDBGRids, gLoQueSea,....

En fin, no se, más manías o formas de acordarte del nombre de un componente sólo con mirarlo en el form.

Nos leemos

[Delphius]

Bueno amigo Felipe,
Pues si... el tema da pa' mucho.... y es habitual que esté lleno de subjetividad y al final uno termina adoptando y formando su estilo.
Pero al menos, en teoría, se recomienda seguir la misma nomeclatura y estilo del lenguaje. Es decir que nuestros propios desarrollos deberían escribirse siguiendo la misma nomeclatura y estilo que el aplicado en el lenguaje. Si usamos Delphi, utilizar su estilo, si empleamos VB, utilizar el estilo de VB.
Suena lógico este principio y tiene un beneficio directo: nos sentimos más familiarizados con el lenguaje y nos resulta más fácil entender nuestros desarrollos, y nos motiva a seguir continuando con ello.

No es tan fácil en cambio si nuestro estilo se ve impulsado o presionado de forma externa. El programar de esa manera, con un estilo ajeno al entorno no lleva a la armonía y esto puede llevar a un mayor desapego con la herramienta. ¿No les pasa que de vez en cuando se sienten incómodos con su programación, a pesar de estar perfectamente escrito, sin errores semánticos y sintácticos? ¿No sienten que están mezclando estilos? ¿O confundidos o de una forma extraña... como de inseguridad? Si sus respuestas han sido afirmativa ahora respondan: ¿A quien le hechan la culpa? No se extrañen si mayormente le acachan al IDE/lenguaje por su "incompatibilidad" de nomeclatura con las suyas.

Esto me recuerda a mi práctica profesional... el primer día en la empresa me dieron un documento impreso en el que estaba bien aclarado como había de nombrarse cada cosa, cómo debían de diseñarse las interfaces, etc. Su estilo "chocaba" con la nomeclatura y la sintaxis de Visual Basic (el lenguaje que utilizan allí... asquito) y se me hizo un poco más difícil adaptarme a eso... algunas cosas que escribía me resultaban "extrañas" a lo que esperaba y estaba acostumbrado a ver en VB.

Por ello es que existen las guías... como una buena práctica que se sugiere seguir. Claro está, en la práctica es distinto... más aún si provenimos de un lenguaje distinto... queremos llevar el estilo seguido en el antiguo lenguaje al nuevo... y en ocasiones este no nos resulta tan familiar a como estábamos acostumbrados.

Volviendo a mi caso en la pasantía... debía sumarse que para ese entonces yo no sólo tuve que adaptarme a un estilo impuesto sino que debía repasar VB. Mi cabeza se acostumbró a pensar al estilo Delphi y tuve que hacer unos giros conceptuales para llevarlo a VB... Peor aún: estaba trabajando sobre algo que otro había comenzado. Conclusión: toda una semana para ponerme al día.

Felipe, no te creas que yo sigo demasiado la guía... respecto a la documentación... yo me lo tomo en serio: tiendo a documentar todo. Había adoptado un estilo que me resultaba muy natural... pero cuando leí la guía me topé con que mi manera era marcada como desaconsejable... yo ahora estoy en una disyuntiva: ¿Tanto daño hace?

Yo hacía algo como:

delphi

implementation
...
procedure TMiClase.Ejemplo;
{*************
Aquí la documentación bien bonita y completa
***************}
begin
// aqui el código...
end;

Pero la guía indica que debe hacerse en interface:

delphi

interface
 
TMiClase = class
...
procedure Ejemplo;
{**************
aquí documentación... ¡y breve!
***************}
...
end;

Yo me hacía la idea de que debe estar en implementation puesto que es allí donde uno codifica y necesita la información de como se lleva a cabo el código.

Dentro del código si documento. Aquellas líneas que necesitan una adecuada aclaración. Me ayuda reordenar las ideas.

Eliseo te agradezco el comentario. Es que como si bien conozco que las versiones modernas tienen métricas y refactoring... no tengo idea de cada de ellas... yo aún ando con D6 y el término NC me suena a "No Cazo la idea"... 

Si tienes curiosidad, como dije... está la lectura de la guía.

Saludos,

[egostar]

Si tienes curiosidad, como dije... está la lectura de la guía.

Gracias por la referencia amigo, prometo que en algún momento la leeré, aunque sabes que soy vago para leer

En realidad, siempre he escrito código cuidando dos cosas 1.) Asignar el nombre de mis variables y métodos de forma que se conozca la utilidad, 2.) Cuido mucho el identar el código para una mejor comprensión. Pero nunca me preocupé ni me ocupé del estilo de escritura que da inicio a este hilo, creo que voy a poner un poco de atención al tema aunque no creo que llegue a ser tan purista en ese aspecto, sin embargo, lo tomaré en cuenta

Salud OS

[Delphius]

Eliseo ese ejemplo, y en especial el uso de la construcción IF me resulta un tanto molesta... tengo que admitirlo. La verdad es que me resulta chocante la manera en como se estila emplearlo...

no me agrada la idea de un:

delphi

IF (condicion) then
  sentencia_then
else sentencia_else;

Yo me siento mucho más cómodo con esta variante:

delphi

if (condicion)
  then sentencia_then
  else sentencia_else;

Como se aprecia, tanto la parte then como else están a la misma "altura", o mejor dicho: al mismo sangrado. A mi modo de ver, es mucho más fácil esta lectura que la sugerida en la guía. De hecho, cuando veo un código ajeno o de la VCL mi cabeza automáticamente empieza a reordenar las líneas... aunque cuando el código es largo y/o complejo lo llevo en papel y lo codifico a mi modo a fin de entenderlo.

En lo único en que en ocasiones me siento tentado a utilizar el then en la misma línea del if es cuando se trata de una sola sentencia:

delphi

if (condicion) then sentencia_unica;

Aunque esto también contradice la guía, se recomienda esto:

delphi

if (condicion) then
  sentencia_unica;

Ese supuesto consejo y posibilidad de bug es viejo y conocido... viene desde Turbo Pascal... Hay quienes dicen que en ese sentido el compilador es un tanto "flojo" y que podría mal interpretar las sentencias. Se viene aconsejando el uso de begin-end a fin de obligar al compilador de interpretar correctamente en fin del then con el principio del else. Tengo que reconocer que esto es en parte un motivo de mi elección de escribir el then en la siguiente línea.

Saludos,

[felipe]

Es verdad Delphius,
de estilos hay, de lenguaje a lenguaje igual y de persona a persona también.

Pasa como cuándo aprendes un lenguaje nuevo o parecido, no es lo mismo como haces las cosas en Delphi a como se hacen en Java y de esta a como se hacen en los script de Phyton...

Cuándo es de persona a persona es complicado, más si se trabaja en grupo y fulano hizo tal parte, perengano la otra... finalmente llega el código a ti y piensas "¿y esto que p.... es?" 

Manejar un método de estándar o propio, siempre proporciona ventajas, son muchas.

Para el caso de los comentarios, en ocasiones hago esto:

delphi

implementation
...
{*************
Esto con eso hace aquello
***************}
procedure TMiClase.Ejemplo;
begin
// aqui el código...
end;

Para mi es claro e imagino que igual para otra persona.
En ocasiones no es necesario ser tan medidos y rígidos en métodos o estándares. Como diría la Chimoltrufia ¿tengo o no tengo razón? .

Las reglas son para romperse ... eso dicen


Saludos!

[egostar]

No se porque te parezca chocante, pero bueno, vale el ejemplo

¿ Y como entonces haces una estructura de varias órdenes en el if bajo tu criterio, sería así ?

delphi

if (condicion)
  then begin
    sentencias_then
  end
  else begin
    sentencias_else;
  end;

Salud OS

[Delphius]

Hola...
Me resulta chocante porque supuestamente en una lectura del código las cosas deberían estar a la misma altura, respetando el sangrado. Esto es cosa de mi como mi cabeza lee las líneas, las siento descolocadas, como que la parte then está en una altura o sangrado diferente al else... y en verdad... ¡se corre ese peligro! Nadie impide poner varias líneas de más haciendo más difícil su comprensión,... peor se pone cuando se tienen IF concatenados. No distingues cuando termina uno y empieza otro.

Para el caso de varias sentencias es algo parecido a eso:

delphi

  if (condicion)
    then begin
           sentencias_then;
         end
    else begin
           sentencias_else;
         end;

Como se aprecia todo termina en el mismo sangrado, se aprecian correctamente el principio y el fin de la parte then como del else.

Fíjate donde está el end del then en tu código. Justo arriba del ese... El ejemplo es simple... y aquí no indice a problemas... agrega unos cuantos ifs dentro y dime si no te mareas con los begins y ends entre el fin de un then y el principio del else y hasta del cierre mismo del if. 

El efecto es visual... y se debe por el tipo de letra. Si utilizara letra monoespaciada como la Courier New el efecto del sangrado diferente entre el then y el else sería menos pronunciado.

Como dije: es cosa de cerebro y la costumbre de como leemos. No me agrada ver un then en la columna 20 y luego que el else está en la 5. En términos lógicos una instrucción IF indica que se hace una cosa o la otra... por tanto ambas sentencias deberían estar a la misma altura, tienen el "mismo nivel de importancia". O es uno u otro... Esto es contradictorio me dice la cabeza... si bien las sentencias tanto del then como else están a la misma columna.

Pero nada impide que el sangrado se vea estropeado o nuble la vista. Con mi estilo fuerzo a que cada sangrado respete la linealidad de las sentencias.

No se si me explico.

Saludos,

[felipe]

Si de identación se trata, para mí siempre debe estar el código así:

delphi

if (condicion) then 
  begin
     sentencias_then;
  end
else
  begin
    sentencias_else;
  end;

Begin y end como deben ser ... no soy muy amigo de unir las declaraciones.

Esto me recuerda a cuándo veo código HTML ajeno


Saludos!

[egostar]

Pues ahí es donde no entiendo muy bien amigo, ¿ seguimos o no seguimos las prácticas de la guía de estilo de Object Pascal ?

Mira lo que dice la guía:

Aquí están algunas variantes que se consideran válidas:

delphi

  // CORRECT
  if Condition then
  begin
    DoThis;
  end else
  begin
    DoThat;
  end;
 
  // CORRECT
  if Condition then
  begin
    DoThis;
  end
  else
    DoSomething;
 
  // CORRECT
  if Condition then
  begin
    DoThis;
  end else
    DoSomething;

Y una que ha caído en desgracia, pero merece mención de honor:

delphi

  if Condition then
    DoThis
  else DoThat;

Salud OS

[Delphius]

Pues amigo, yo aconsejo leer la guía y aliento a que luego cada quien saque sus conclusiones.
Por algo yo decía que si bien busco respetar la guía, hay cosas que a mi cabeza le cuesta digerir.

Si sigo el estilo en cuanto declaro clases, algunos tipos, y algunas construcciones. (Por ejemplo las del while, repeat, try coincido al 100% con la guía). Pero en cuanto a constantes, variables e if... disiento un poco de su estilo recomendado.

Por algo he dicho: en teoría se debería seguir el estilo propuesto y empleado en el lenguaje, en la práctica no siempre es así.

Respecto al uso del IF confieso que me encantaría que todos adoptaran mi estilo, aunque vaya en contra de la guía. Yo sólo expliqué el porqué utilizo el IF de ese modo... y la posible ventaja que podría ofrecer.
Aclaré que mis diferencias en el uso del IF se debe a un criterio de lectura. Me gusta que se vea claramente la linealidad... que el then y el else estén al mismo sangrado. Eso me ayuda a mi a que en lo sucesivo tanto para uno como para el otro lado se mantenga la linealidad.

Si ustedes se sienten cómodos con el estilo estándar y por defecto no hay problemas.

Cada quien tiene sus mañas. A me gusta que el código pueda leerse bien de izquierda a derecha.

Saludos,

[Delphius]

Lo que si reconozco es que mi manera de llevar el IF tiene una desventaja que puede jugarle más en contra... se desperdician más columnas y no admite demasiados IFs concatenados... es muy fácil sobrepasar las 80 columnas rápidamente.

Con el estilo de la guía, nos damos el lujo de recibir más IFs concatenados ya que el código es más compacto y no se extiende demasiado horizontalmente. Invito a que prueben como se vería mi estilo con un IF concatenado.

Por ello en lo posible, evito llegar al 3er y 4to anidamiento. Cada IF dentro de otro introduce 2 V(G) y 4 nuevas posibilidades de pruebas.

Saludos,

[egostar]

Pues amigo, yo aconsejo leer la guía y aliento a que luego cada quien saque sus conclusiones.
Por algo yo decía que si bien busco respetar la guía, hay cosas que a mi cabeza le cuesta digerir.

Si sigo el estilo en cuanto declaro clases, algunos tipos, y algunas construcciones. (Por ejemplo las del while, repeat, try coincido al 100% con la guía). Pero en cuanto a constantes, variables e if... disiento un poco de su estilo recomendado.

Por algo he dicho: en teoría se debería seguir el estilo propuesto y empleado en el lenguaje, en la práctica no siempre es así.

Respecto al uso del IF confieso que me encantaría que todos adoptaran mi estilo, aunque vaya en contra de la guía. Yo sólo expliqué el porqué utilizo el IF de ese modo... y la posible ventaja que podría ofrecer.
Aclaré que mis diferencias en el uso del IF se debe a un criterio de lectura. Me gusta que se vea claramente la linealidad... que el then y el else estén al mismo sangrado. Eso me ayuda a mi a que en lo sucesivo tanto para uno como para el otro lado se mantenga la linealidad.

Si ustedes se sienten cómodos con el estilo estándar y por defecto no hay problemas.

Cada quien tiene sus mañas. A me gusta que el código pueda leerse bien de izquierda a derecha.

Saludos,

Sabes porque a mi no me acaba de gustar tu estilo del IF, me parece como regresar a BASIC  , sin embargo, respeto, por supuesto, tu razonamiento, cada quien codifica como le entiende mejor

Salud OS