problema con funciones

[anubis]

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


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

[egostar]

Ya la declaraste en el Type de TFHabitacion??

algo asi


type
TFHabitacion = class(TForm)
BitBtn1: TBitBtn;
procedure BitBtn1Click(Sender: TObject);
private
{ Private declarations }
function verificaanadircliente(Key:word):word;
public
{ Public declarations }
end;



Salud OS.

[jhonny]

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

function tfhabitacion.verificaanadircliente(Key:word):word;
begin
//...
//...
Result := key;
end;


o

2:

function tfhabitacion.verificaanadircliente(Key:word):word;
begin
//...
//...
verificaanadircliente := key;
end;


Espero te sirva ;).

[roman]

[Warning] habitacion.pas(200): W1035 Return value of function 'Tfhabitacion.verificaanadircliente' might be undefined


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,


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

[seoane]

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:

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;

[anubis]

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

[roman]

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:


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

Value assigned to 'divide' never used

si, por ejemplo, haces:


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

[seoane]

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

[dec]

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:


function LoqueSea(){
$resultado = false;
/* */
return $resultado;
}


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

[roman]

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

[dec]

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

[roman]

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.


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

[roman]

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


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:


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

[seoane]

No me dí 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.


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 :)

[dec]

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

[egostar]

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.


function TForm1.algo(dato:String):Bool;
begin
If dato = 'e32er433432e' then
Result := True
else Result := False; // Else
end;



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.

[dec]

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:


function TForm1.algo(dato:word):integer;
begin
case dato of
0 : Result := 1;
1 : Result := 0;
else Result := -1; // Else
end;
end;



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

[egostar]

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.

[dec]

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í... :)

[roman]

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

[egostar]

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


Yo creo que si puede afectar al código final si no tomamos las medidas necesarias.

Veamos este pequeño ejemplo,


function TForm1.algo(dato:String):Bool;
begin
If dato = 'e32er433432e' then
Result := True;
end;

procedure TForm1.BitBtn1Click(Sender: TObject);
begin
If algo('1234') = True then
ShowMessage('Validado');
end;


Salud OS.

[roman]

Me refiero a que la técnica me parece útil para depurar, pero ya en el código final, se omite, una vez que se han llenado los huecos.

// Saludos