más buenas prácticas de programación

[[Al González]]

Empezado por donald shimoda

Tenes absolutamente razón, lo escribí rápido y me olvide que en realidad soy yo el que hago siempre:

Código Delphi [-]
if Assigned(x) then
  FreeAndNil(x);

Esto segun Allen Bauer es un vicio horrendo de programación . Ahora si mirás el código delhi de FreeAndNil:

Código Delphi [-]
procedure FreeAndNil(var Obj);
var
  Temp: TObject;
begin
  Temp := TObject(Obj);
  Pointer(Obj) := nil;
  Temp.Free;
end;

Si obj = nil estas llamando a nil.free!!!! No jodamos, es inaceptable o muy arriesgado para mis pareceres. Aunque se enoje Allen Bauer , escucho argumentos en contra que me quiten el vicio.

Saludos

Un placer, Donald. Argumentos dados tal como los solicitó. Sólo que es una pena no conocer si te convencieron para erradicar ese vicio y, en caso contrario, las razones.

Una disculpa a elcigarra por las derivaciones que tuvo el hilo (al menos por lo que a mí me toca).

Saludos.

Al González.

[donald shimoda]

Empezado por Al González

Un placer, Donald. Argumentos dados tal como los solicitó. Sólo que es una pena no conocer si te convencieron para erradicar ese vicio y, en caso contrario, las razones.

Como le dije a Román estoy totalmente de acuerdo en sus explicaciones, se las agradezco, son correctas, que mas debo decir?

Si han sido suficientes para erradicar el vicio? Primera regla del programador es no toques código que funciona sin una buena razón. No veo una buena razón en revisar código viejo.

Para el código nuevo probaré, te cuento cuando tenga mis propias pruebas de uso.

Saludos.

[[Al González]]

Empezado por donald shimoda

...Para el código nuevo probaré, te cuento cuando tenga mis propias pruebas de uso...

Urbana respuesta, gracias. Y una disculpa si te hice sentir presionado, no era esa la intención. Cuando gustes te invito un trago en La Taberna.

[roman]

Empezado por ContraVeneno

changos, era broma maese Roman

Je, je. Yo me di cuenta de tu mensaje oculto sólo hasta que cité tu mensaje. Pero de todas formas fue lo primero que me vino a la mente. No sé si sea cierto, pero alguna vez leí que de ahí viene la palabra nil.

// Saludos

[roman]

Una pregunta, porque creo que me perdí en algún punto. Exactamente ¿qué es lo que no aceptaría FPC de mi codigo? ¿No compila? Es que se me hace raro, porque Delphi igualmente "protesta" marcando una advertencia, pero no impide la compilación y no veo porque no compilaría. Sintacticamente es correcto ¿no? ¿Qué error marca?

// Saludos

[donald shimoda]

Empezado por roman

Una pregunta, porque creo que me perdí en algún punto. Exactamente ¿qué es lo que no aceptaría FPC de mi codigo? ¿No compila? Es que se me hace raro, porque Delphi igualmente "protesta" marcando una advertencia, pero no impide la compilación y no veo porque no compilaría. Sintacticamente es correcto ¿no? ¿Qué error marca?

// Saludos

Protesta y corre. A eso me refería con que no lo *acepta*. Lo mismo que sucede en Delphi.

Saludos.

[roman]

¡Ah! Ok, gracias.

Y, como dice Al, hemos desviado el hilo, pero creo que nuestro compañero no lo verá tan mal ya que, a fin de cuentas, hemos estado hablando de buenas prácticas de programación.

Aunque no le veo problema al nil.Free, lo cierto es que ejemplos como el que puse de la clase TPersona, no deben hacerse. No lo hagan en casa niños

-----------------

Por otra parte, retomando el hilo original, quiero comentar que voy de acuerdo con lo expresado: un método no debe devolver objetos, a no ser que sea una especie de fábrica y quede claro tanto en la documentación como en el nombre:

Código Delphi [-]
var
  Persona: TPersona;

begin
  Persona := Dios.CrearPersona();
end;

// Saludos

[[Delphius]]

Empezado por roman

Por otra parte, retomando el hilo original, quiero comentar que voy de acuerdo con lo expresado: un método no debe devolver objetos, a no ser que sea una especie de fábrica (...)

Y como por lo general (aunque no siempre) una Fábrica se accede mediante el patrón Singleton. ¡Ahora si! ¡En este caso si hay Singleton! ¡Santos patrones!

Lo siento, no pudo evitarlo tenía que decirlo.
Disculpen que haya desviado el hilo.

Saludos,

[olbeup]

Hola ???

Retomando la pregunta inicial.

Código Delphi [-]
function TForm1.GetStrings:TStrings;
var
  miLista: TStrings;
begin
  miLista := TStringList.Create;
  miLista.Add('uno');
  miLista.Add('dos');
  Result := miLista;
  FreeAndNil(MiLista); // Esta linea da un error EAccessViolation
end;
procedure TForm1.Button1Click(Sender: TObject);
begin
  memo1.Lines.Assign(GetStrings);
end;

Por que no haces esto:

Código Delphi [-]
function TForm1.GetStrings:TStrings;
begin
  Result := TStringList.Create;
  Result.Add('uno');
  Result.Add('dos');
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  memo1.Lines.Assign(GetStrings);
end;

Al salir de la función GetStrings, la variable se libera sola.

Un saludo

[[Lepe]]

Empezado por olbeup

Al salir de la función GetStrings, la variable se libera sola.

¿quien te ha dicho eso? ¿eh? que yo me entere

[Casimiro Notevi]

Empezado por olbeup

Al salir de la función GetStrings, la variable se libera sola.

Empezado por Lepe

¿quien te ha dicho eso? ¿eh? que yo me entere

Evidentemente, no, no se libera sola.

Creo que hay una regla simple para no equivocarse:
Si tú coges memoria --> tú tienes que liberarla cuando terminas
Si Delphi coge memoria --> Delphi la libera cuando termina.


No recuerdo si existe alguna excepción a la regla, como casi siempre

[elcigarra]

Empezado por roman

Y, como dice Al, hemos desviado el hilo, pero creo que nuestro compañero no lo verá tan mal ya que, a fin de cuentas, hemos estado hablando de buenas prácticas de programación.

El haber iniciado este hilo es el único derecho que siento, como humilde mortal, de escribir entre inmortales. Cuando sea grande me gustaría saber todo lo que saben ustedes... Ups! me olvidaba, no me queda tiempo porque ya me pasé de "grande".

Como sea... sinceras gracias.

[[Lepe]]

Empezado por Casimiro Notevi

No recuerdo si existe alguna excepción a la regla, como casi siempre

¿_CopyObject?


(perdón).

Saludos