Notación húngara Vs Notación CamelCase
 

Pues, ahora que he estado estudiando C#, he leido en un libro que Microsoft aconseja usar la notación CamelCase.

Yo estoy muy acostumbrado a la notación Húngara, desde la escuela me mostraron sus bodades, (bondades que he apreciado mayoritariamente cuando programo en Php).


Ustedes que opinan?, que notación es su preferida?

Hey amigo poliburro, yo uso C# y NPI de eso que dices, no sabia ni siquira la existencia de eso que mencionas.:eek::rolleyes:

En fin, siento no ser de ayuda

Salud OS

Notación Húngara

Notación CamelCase

;)

jajaja, son estándares que se usan mi buen amigo egostar, deja te paso los links de info,

Notación Húngara

CamelCase

Y aprovechando amigo egostar, que estilo utilizas para codificar?

utilizas algún estándard?

Notación húngara, desde... 1987 :eek: todavía no lo usaba ni Charles Simonyi :D

que extraño, en tiempos de Basic se acostumbra usar la notación Hungara pero como siempre use PASCAL sigo usando la CamelCase :D

jajaj yo desde pascal uso la notación húngara.

Charles Simonyi :eek: :rolleyes: recuerdo un libro, "Programadores en acción" (Programmers at work) en el que entrevistaban a este (además de a otros 18 programadores) y se les preguntaba cómo hacían lo que hacían y por qué hacían lo que estaban haciendo y fue entretenido de leer :)


Saludos

P.D: TObject que sería ?

No entiendo muy bien el título del hilo, ya que no veo Contradicción en usar ambas.

La notación húngara y lowerCamelCase la uso para los controles:
cboProvincias TCombobox
edtNombre TEdit
etc.
(en esto, cnpacks ayuda un poquito ;)).

Las variables, simplemente con ver donde se usan o cómo se usan, ya se ve el tipo, y más siendo delphi un lenguaje altamente tipificado.

La notación CamelCase la uso en procedimientos, métodos, funciones, etc.. y lowerCamelCase para tipos enumerados, vamos igual que Borland en su código fuente.

He intentado atenerme a otros estándares de notación, pero al final acabo rompiéndolos porque son demasiadas letras, así que uso las mías propias (por ejemplo TDBComboboxLookUp lo abrevio con el prefijo "lu", algunos estándares dirían que corresponde con "dbcbblu" y si encima representa las "observaciones del cliente" quedaría como dbcbbluObservaciones .... mucha tela para mi :p).

Saludos

Pues me imagino que es el estandar amigo poliburro, solito me arregla los bloques. :rolleyes::cool:

Asi es como codifico amigo poliburro

PD: Leyedo lo de los estandares, creo que uso una combinación entre las dos.....

Salud OS

jeje... "Programadores en acción"... fue mi libro de "cabecera" durante mucho tiempo... aprendí bastante leyendo sobre esos programadores.

Yo en Procedimientos y funciones utilizo CamelCase + guiones:

Código Delphi [-]
 Procedure Preparar_Comision(n:Integer);
  Function Calcular_Comision_SiNo(cBusca:String):Boolean;

En variables como Lepe.

Un Saludo.

Yo uso CamelCase, hehe.

Saludos.

Yo huyo de la notación húngara como de la peste. Yo, cuando programo, necesito saber qué hace o qué contiene, no el cómo. Sabiendo el qué ya puedo imaginarme el tipo de datos que se necesita y, si no, para algo están los prototipos y la opción de búsqueda.

Cuando programo en C utilizo "slashing": funcion_muy_util_de_suma
Cuando programo en Pascal utilizo "Ucase": OtraFuncionDeSumaDistina

Soy así de chulo, yo :cool::D

Si, la verdad es que yo también tengo mi propio standard también... El problema es cuando programas con otras personas o alguien tiene que revisar tu código, pero hasta ahora sigo con mi propio standard, igual que Ñuño.


[:D]Me temo que nos parecemos a Microsoft creando nuestros propios standard[/:D]

yo igual que Lepe... no le veo conflicto en usar las dos:

Un TComboBox para filtrar el estatus de una factura: cmbFiltraFactura.ItemIndex ... etc. etc

Precisamente en microsoft usan obligatoriamente la notación húngara. Ten en cuenta que el creador de la citada notación, Charles Simonyi, fue el programador jefe, mano derecha de Gates, creador de Multiplan (precursor del MsExcel) y luego toda la saga de MsOffice.

Es lo único bueno de microsoft :p

Interesante hilo Edgar.

Concuerdo con los que dicen que lo mejor es aprovechar un poco de cada mundo. La propia VCL utiliza CamelCase con una especial variación para las "constantes de grupo" similar a la Notación Húngara, pero cuyo prefijo, en este caso de dos letras minúsculas, no necesariamente indica el tipo de dato sino además (o en lugar de eso, cuando son enteros y no enumerados) el grupo al cual pertenecen. Un ejemplo clásico son las constantes dsBrowse, dsEdit y dsInsert que pertenecen al tipo enumerado TDataSetState (el "grupo" de estados de conjuntos de datos).

En particular, cuando se trata de alguna biblioteca de propósito general (es decir, no código particular de una aplicación específica), utilizo un prefijo en minúsculas para los nombres de sus funciones (no así los métodos) que identifica la biblioteca a la que pertenecen dichas funciones. Y para las constantes de grupo, en lugar de utilizar dos letras como lo acostumbra Borland, utilizo tres, además del prefijo que identifica a qué biblioteca pertenecen.

Para dar una idea, estas son algunas muestras de lo que he escrito últimamente:

Código Delphi [-]
    { Save Point Action type }
    TghSavePointAction = (ghspaNone, ghspaConfirm, ghspaRestore);

Código Delphi [-]
    { Magia Client Data Set Save Point class }
    TMagiaClientDataSetSavePoint = Class (TghCustomSavePoint)
      Protected
        { Fields }
        State :Integer;

        { Overridden methods }
        Procedure InternalConfirm; Override;
        Procedure InternalRestore; Override;
        Procedure InternalSave; Override;
        Procedure Invalidate (
          DetailAction :TghSavePointAction = ghspaNone); Override;
    End;

Código Delphi [-]
  Function TMagiaSQLConnection.ExecProc (Const Proc :String;
    Const Params :Variant) :Variant;
  Var
    I :Integer;

    { Avoid conflicts with TSQLStoredProc.Params.  In cases like this, we
      prefer his method instead of to prefix the formal parameter with "A",
      so operative programmers don't feel confused (connection component
      has a Params property, "AParams" would be related with this
      property). }
    AParams :Variant Absolute Params;
  Begin
    With TSQLStoredProc.Create (Self) Do
      Try
        SQLConnection := Self;
        StoredProcName := CasedName (Proc);

        { Assign input parameters }
        If VarIsArray (AParams) Then
          For I := 0 To VarArrayHighBound (AParams, 1) Do
            ghInputParam (Params, I).Value := AParams [i]
        Else
          ghInputParam (Params).Value := AParams;

        ExecProc;
        I := ghOutputParamCount (Params);

        { Return output parameter(s) or Null }
        Case I Of
          0 : Result := Null;
          1 : Result := ghOutputParam (Params).Value;
          Else
          Begin
            Result := ghVariantArray (I);

            For I := 0 To I - 1 Do
              Result [i] := ghOutputParam (Params, I).Value;
          End
        End;
      Finally
        Free;
      End;
  End;

Ésta última me da un poco de pena porque, como bibliotecario partidario de la atomización, hago mucho hincapié en que las rutinas no tengan más de 20 o 30 líneas de código, y ese método en particular tiene 43. :o

Nótese que los identificadores y comentarios están en inglés, y esto es porque se trata de bibliotecas de propósito general que cualquier programador del mundo podrá llegar a utilizar. Pero cuando es código particular de una aplicación, por lo general empleo el idioma español para sus identificadores y comentarios.

Y como habrán visto, soy poco convencional con el asunto de las mayúsculas, las minúsculas, la separación de bloques y paréntesis y la declaración de elementos tipificados. Es el resultado de un estilo que fui desarrollando con los años, pienso yo para bien, y que procuro respetar al pie de la letra manteniendo consistente mi código.

Nada que ver con la manera en que programaba en 1993, durante mi época de estudiante :D:

Código Delphi [-]
 PROCEDURE FORMAR;
 BEGIN
   TEXTCOLOR (0);
   YANO := FALSE;
   Y := - (ANY - 1);
   REPEAT
     INC (Y, ANY);
     X := - (ANX - 1);
     REPEAT
       INC (X, ANX);
       TEXTBACKGROUND ( ARCOLOR [RANDOM (MAXCOLOR)] );
       VENTIW (X, Y, X + (ANX - 1), Y + (ANY - 1) );
     UNTIL X >= 75;
   UNTIL Y >= 21;
 END;

¡No me pregunten para qué era esa rutina! :eek:

Por cierto, otra cosa que acostumbro es no utilizar más allá de la columna 75 por aquello de querer imprimir el código o mostrarlo en una pantalla de menor tamaño. Además de que resulta más cómodo de leer un texto que no es muy ancho (de ahí el estilo de los diarios).

Un abrazo a todos.

Al González. :)

Muy interesante y cómodo, con solo digitar 2 letras, lo mostrado en el Code Insight se reduce bastante. Ahora mismo se mezclan mis propias funciones con las de Borland/Codegear, y en lugar de ayuda, el code insight sirve para confundirme (igual te copio ;)).

Saludos

Utilizo CamelCase con guiones porque cuando entré en la Universidad nos enseñaron a hacerlo así, y me parece bastante legible.