problema con funciones
 

hola de nuevo, tengo un medio problema con las funciones (al final voy usando casi todo el armamento de delphi, pero poco a poco):):)

Cree una funcion

Código Delphi [-]
function tfhabitacion.verificaanadircliente(Key:word):word;

se supone que le entra el valor key y me devuelve un valor word, en si mismo es el mismo key.
El programa me funciona pero me da un aviso:
[Warning] habitacion.pas(200): W1035 Return value of function 'Tfhabitacion.verificaanadircliente' might be undefined

pero no se como resolverlo.
gracias

O mejor me explico lo que necesitaba por si se os ocurre como resolverlo.

tengo esta procedure
procedure Tfhabitacion.anadirnomKeyDown(Sender: TObject; var Key: Word;
Shift: TShiftState);

ahi recoge el key, pero dentro de esa procedure he realizado otra llamada a otra procedure, pero ya no me conserva el valor key (estoy partiendo el programa en procedures tal y como recomendabais) y para eso he creado la funcion anterior, para conservar el valor del key, imagino que el aviso me sale porque en esa funcion no hay asignacion del valor key, es asi?.

Ya la declaraste en el Type de TFHabitacion??

algo asi

Código Delphi [-]
type
  TFHabitacion = class(TForm)
    BitBtn1: TBitBtn;
    procedure BitBtn1Click(Sender: TObject);
  private
    { Private declarations }
    function verificaanadircliente(Key:word):word;
  public
    { Public declarations }
  end;

Salud OS.

No has definido el valor resultante de la función, colocare un ejemplo muy sencillo de lo que puedes hacer:
1:

Código Delphi [-]
 
function tfhabitacion.verificaanadircliente(Key:word):word;
begin
  //...
  //...
  Result := key;
end;

o

2:

Código Delphi [-]
 
function tfhabitacion.verificaanadircliente(Key:word):word;
begin
  //...
  //...
  verificaanadircliente := key;
end;

Espero te sirva ;).

Lo que esto indica es que tu función no está regresando un valor, no al menos en todos los casos, de manera que usar la función es riesgoso. Debes revisar el código y asegurarte que siempre hay un valor de regreso.

Por ejemplo,

Código Delphi [-]
function divide(a, b: Integer): Integer;
begin
  if b <> 0 then
    Result := a div b;
end;

te generará esa advertencia, porque la función no regresa nada cuando b = 0.

// Saludos

Una costumbre que tengo al crear funciones es asignarle un resultado por defecto en la primera linea, así me aseguro de que la función no devuelve nada inesperado. Es algo personal, pero me atrevo a recomendarlo:

Siguiendo el ejemplo de roman:

Código Delphi [-]
function divide(a, b: Integer): Integer;
begin
  // Así nos aseguramos de devolver siempre un resultado
  Result:= 0;
  if b <> 0 then
    Result := a div b;
end;

gracias, asi si funciona, son cositas que van saliendo.

No está mal. El problema es que así te expones a otro warning:

si, por ejemplo, haces:

Código Delphi [-]
function divide(a, b: Integer): Integer;
begin
  Result := 0;

  if b <> 0 then
    Result := a div b
  else
    raise Exception.Create('Regrese a la primaria');
end;

:D

Aunque menos "dañino", no me gusta que aparezca ninguna advertencia.

// Saludos

Bueno roman, yo empiezo poniendo esa linea, luego si la cosa se tuerce se quita y en paz :p

Hola,

Yo suelo hacer lo que hace Seoane, ciertamente. La primera línea es una instrucción: "Result := false" o "Result := true", según si se supone que la función ha de retornar "false" o "true" por defecto. Sin embargo, últimamente, programando en PHP, las cosas cambian amigos. :)

¿Cómo? Pues porque en PHP no vale algo como "return false" al principio de la línea, puesto que el "return" impedirá que se ejecute lo que venga después, es decir, que no es lo mismo que el "result" de Delphi. Lo siento. :)

Ahora, aún así sigo utilizando a veces algo como:

Que es como copiar lo que hago en Delphi: asegurarme de que la función tiene un resultado por defecto. Sin embargo, es verdad que a veces ocurre lo que menciona Román, y bueno, que, últimamente también estoy tirando por el lado de no tener un resultado por defecto, aunque, eso sí, asegurándome de que lo que la función X retorna tiene sentido en cualquier caso. ¡O eso intentamos! :D

Hola,

A decir verdad me extraña un poco este tipo de técnicas, o la necesidad de ellas. Parece que damos un valor por defecto para "cubrirnos las espaldas" ante algún posible caso no considerado. Pero el valor por defecto no arreglará tal omisión- de haberla -, de tal suerte que el problema seguirá latente. En el caso de Delphi, al menos, prefiero que el compilador me notifique que hay un problema, a ocultar el mensaje con un valor por defecto.

// Saludos

Hola,

Bueno. Tú eres mucho más experto que yo, Román, empero, yo no trato de ocultar ningún problema o mensaje de error... sino que, simplemente, asigno un valor de retorno por defecto para una función: nada más y nada menos.

Cuando escribo una función, digamos, "EsUsuarioAdministrador()", a veces (así lo he hecho más a menudo en Delphi que en PHP, eso sí), nada más comenzar la función, escribo un "Result := False", por ejemplo. Es una forma de decir "ningún usuario será considerado administrador a no ser que se cumplan X condiciones... en un primer momento ningún usuario es considerado administrador".

No sé. Tal vez incluso sea una forma de hacer más legible la función, no sé si me explico. Pero, ya digo, la intención no es esconder errores, ni ocultarlos, ni nada de eso. :)

No me di a entender. No digo que hagan eso con la intención de ocultar el error. Digo que al dar un valor por defecto, corro el riesgo de no darme cuenta de que hay un error, porque el compilador no me lo marca.

// Saludos

Lo que describes es un caso muy particular, donde la propia semántica de la función requiere un valor por defecto, pero que yo ponga:

Código Delphi [-]
function esNumeroPrimo(n: Integer): Boolean;
begin
  Result := false;
  
  {
    algoritmo para determinar si n es primo
  }
end;

no me sirve, porque si mi algoritmo no cubre todos los casos, el valor por defecto tendrá igual de posibilidades de ser adecuado que inadecuado.

// Saludos

Exacto, cuando yo doy un valor por defecto, normalmente es un valor que a mi me indica un error, es decir, si la función me devuelve ese valor se que ha ocurrido algo. Por ejemplo, si la función me tiene que devolver el tamaño de un archivo y le pongo de valor por defecto -1, se que si devuelve ese valor a ocurrido un fallo.

Lo dicho, son manías que uno tiene, pero que no tengo problemas en cambiar si la función lo requiere :)

Hola,

Creo que todos estamos más o menos de acuerdo. Es cierto que no en todos los casos un valor de retorno por defecto puede no ser del todo "intuitivo"... yo creo que me limito a preparar un valor de retorno por defecto cuando por el contrario es intuitivo... ya digo, creo que me sirve para "leer" mejor la función... pero, ya digo que esto es algo que surje de un modo más o menos natural... no es forzado.

De hecho alguna vez se me ocurrió que todas las funciones tuvieran un valor de retorno por defecto: todas, todas las funciones. Y esto no funcionó. Es decir, que no programo de esa manera, sino que a veces lo hago así, y otras veces no. Tengo cierta confianza en que sé elegir qué función es menester de un valor de retorno por defecto y cuál no. :)

PD. Y no tengo abuela. :D

Yo creo que no es necesario inicializar el valor de retorno, la regla es que no haya ningún "vacio" en el retorno de la función.

Código Delphi [-]
function TForm1.algo(dato:String):Bool;
begin
  If dato = 'e32er433432e' then
     Result := True
  else Result := False; // Else
end;

Código Delphi [-]
function TForm1.algo(dato:word):integer;
begin
  case dato of
     0 : Result := 1;
     1 : Result := 0;
     else Result := -1; // Else
  end;
end;

De esta manera no hay ningún "vacio" para el retorno de la función de cualquier tipo.

Salud OS.

Hola,

Estamos de acuerdo egostar. Pero también puede verse como distintas formas de codificación... porque una cosa es lo mismo que la otra al fin y al cabo:

Código Delphi [-]
function TForm1.algo(dato:word):integer;
begin
  case dato of
     0 : Result := 1;
     1 : Result := 0;
     else Result := -1; // Else
  end;
end;

Código Delphi [-]
function TForm1.algo(dato:word):integer;
begin
  Result := -1;
  case dato of
     0 : Result := 1;
     1 : Result := 0;
  end;
end;

Ignoro si una forma es más correcta, elegante o aconsejable que la otra, pero, las dos formas son posibles y al cabo se consigue lo mismo... Así que es cuestión de la costumbre de uno, o de si se han establecido ciertas normas al respecto,... qué sé yo.

Yo no abogo ni por una forma ni por otra. Creo que esto significa que es cuestión de gustos... en este caso creo que no me equivoco si digo esto, vamos. :)

Pues si, estoy de acuerdo amigo David, todo depende del estilo de programar de cada uno y por supuesto que es válido, lo que no creo que sea bueno es dejar esos "huecos" en tu código.

Salud OS.

Hola,

Bueno. Como ha recordado antes Román el propio compilador se encargará de advertirte de que hay un "hueco" en tu código que puede ser contraproducente. O sea, que llevas razón, que no tiene que ser muy recomendable ir dejando huecos por ahí... :)

A mi me gustaría puntualizara algo.

Una cosa es que hay dos formas de poner un valor por defecto, como el caso del else y la asignación inicial; y otra cosa es usar como técnica para crear una función, el asignar un valor por defecto de incio y partir de ahí.

En el primer caso, ya conocemos bien la función y simplemente estamos escogiendo una u otra forma de programar, y eso es cuestión meramente de gustos.

En el segundo caso, podemos proceder como seoane, dando de antemano un valor erróneo. Nótese la diferencia sustancial: un valor erróneo, que no por defecto. Ese valor es el que le va a cuidar las espaldas.

Pero en otro caso, corremos el peligro de no advertir el error y es donde no me acomodaría esa técnica.

Ahora, en el caso de PHP, que no detecta ese tipo de cosas, quizá sea muy recomendable entonces la técnica de seoane, porque al no haber un compilador que nos eche la mano, ese valor erróneo nos ayudará.

De cualquier forma, es más- en mi opinión -una técnica para cuando estamos apenas probando o diseñando la función, que para el código final

// Saludos