Discussion :

[neufrdb]

Bonjour a tous j'ai un petit souci avec ce script

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
 
public class test 
{
	public static void main(String[]arg)
	{
		System.out.println(U(0));
	}
 
	public static int U(int k)
	{
		int resultat;
		if(k==0)
		{
			resultat = 0;
			return resultat;
		}
		if(k==1)
		{
			resultat = 3;
			return resultat;
		}
		else
		{
			if(k>=2)
			{
			resultat = 2 * U(k-1)+U(k-2);
			return resultat;
			}
		}
	}
 
 
}

eclipse me dit qu'il y a une erreur sur cette ligne
pourant j'ai mis que résultat était un int ?

je vous remercie d'avance de m'éclairer

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
	public static int U(int k)

[Robin56]

Mets un seul return à la fin comme ça tu seras sur qu'il renvoie toujours un résultat. Dans ton code là, il peut arriver qu'il n'y a pas de return dans certaines possibilités d'où une erreur qui fait qu'Eclipse n'est pas content.

[eric39]

Bonjour,

Tu devrais préciser de quelle erreur il s'agit, ça peut aider pour celui qui lit ton message.

Le problème vient du fait que ta méthode ne retourne pas toujours une valeur, le compilateur te dit que dans certains cas, lors de l'exécution il n'y aura aucune valeur de retour. Notamment dans le cas où k < 0.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
if(k>=2) {
	resultat = 2 * U(k-1)+U(k-2);
	return resultat;
} else {
	// Il faut retourner quelque chose lorsque l'on ne rentre dans aucun if.
	return ???;
}

[-gma-]

Bonjour,

Apparemment tu veux calculer une suite, donc les valeurs négatives de k ne t'intéressent pas. Dans ce cas tu peux lever une exception si l'argument n'a pas de sens.

Ensuite plutôt que de faire des suites de if, on utilise généralement un switch/case.

En gros, ta méthode aura une meilleure tête comme ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
public static int U(int k) {
	if (k < 0) {
		throw new IllegalArgumentException("k est négatif");
	}
	switch (k) {
	case 0:
		return 0;
	case 1:
		return 3;
	default: // k>= 2
		return 2 * U(k - 1) + U(k - 2);
	}
}

[Robin56]

Après dans tout les cas qui te sont mentionnés là (et bien plus détaillés que le mien ), j'appuierais sur le fait que je trouve plus "sain" de n'utiliser qu'un seul return en fin de fonction.

Remplacer ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
switch (k) {
  case 0:
	return 0;
  default: 
        return 1;
}

Par ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
int resultat;
switch (k) {
  case 0:
	resultat = 0;
  default: 
        resultat = 1;
}
return resultat;

Je trouve que c'est une pratique qui rend le code plus lisible et maintenable.

[neufrdb]

voici l'erreur qui'il affiche

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
la methode doit rentourner un int

mais comme vous me le dîtes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Le problème vient du fait que ta méthode ne retourne pas toujours une valeur, le compilateur te dit que dans certains cas, lors de l'exécution il n'y aura aucune valeur de retour. Notamment dans le cas où k < 0.

merci pour ces précisions j'ai donc compris que s'il n'est pas sur de retourner quelque chose dans une situation particulière il affichera une erreur

je vais donc utiliser le switch

je n'aborde pas les "throw erreur" car c'est un exercice alogrithme on ne fait pas appelle au exception

[-gma-]

Je trouve que c'est une pratique qui rend le code plus lisible et maintenable.

Sur de si petites méthodes, avec un IDE moderne et un langage comme Java dont le compilateur te protège de beaucoup de choses (variables non-initialisées, return manquant, etc.) je ne trouve pas ça vraiment gênant.
En fait je qualifierai presque ma façon de faire de "la meilleure", mais bon je ne dois pas être très objectif

Après quand on débute, c'est sûr que ne mettre qu'un seul return par méthode, ne pas utiliser de label ou d'opérateur ternaire permet de ne pas prendre l'habitude de faire n'importe quoi. Mais avec de l'expérience je pense que l'on peut prendre du recul sur toutes ces "règles".

[Robin56]

Sur de si petites méthodes, avec un IDE moderne et un langage comme Java dont le compilateur te protège de beaucoup de choses (variables non-initialisées, return manquant, etc.) je ne trouve pas ça vraiment gênant.

Ca c'est clair que ça passe pas la barrière de la compil' donc les impacts sont moindre (surtout avec un IDE), je te l'accorde.

En fait je qualifierai presque ma façon de faire de "la meilleure", mais bon je ne dois pas être très objectif

Par contre je suis curieux, pourquoi penses tu cette solution "meilleure" ?

PS : désolé de prolonger un topic résolu.

[neufrdb]

moi qui est débutant je trouve que d'avoir un la varaible resultat car cela évite d'avoir se trimballer la methode U(XX) ,
resultat est plus lisible on sait ce que c'est tandit que U(XX) si l'on a beaucoup de code on se noie dedant on peut l'exploiter plus facilement et evite d'avoir des erreurs de parenthèse fermé.

mais si c'est sur que ci c'était un get_Mon_resultat_recrusive c'est beaucoup plus parlant, et ca doit surement economisier de la resource éviter de crée une variable en plus et allongé la longueur du code

[-gma-]

J'ai tendance à préférer lorsque les choses sont plus concises, dans la limite du lisible bien sûr. Après, la limite entre clarté, lisibilité et concision est floue et subjective.

Sinon pour ce qui est de la performance neufrdb, la règle d'or (et la je pense que là tout le monde sera d'accord ) est de coder le plus clairement possible et d'optimiser ultérieurement si nécessaire.
Et dans le cas en question ça ne changera pas vraiment, un compilateur optimisera très bien ça tout seul.