C'est pas vraiment un PEBKAC.
Selon moi, la question est légitime. Sémantiquement une constante ne "sert" à rien. C'est juste un confort, tout comme les fonctions ou le fait de mettre des noms parlant à ses variables.
Ca rend le code plus lisible et plus facilement maintenable --> C'est d'ailleurs la réponse correcte à la question.

Si c'est un développeur, c'est un gros PEBKAC.
"C'est juste un confort, tout comme les fonctions" oh wait a minute. Les fonctions sont un confort ? Tu peut m'expliquer ? xD
Ça me fait penser au devs pour qui la programmation objet ne sert que pour les projets à échelle européenne, à ceux qui font des pages web en tableaux...

<légèrement hors sujet>
Ce PEBKAC m'a fait penser au xslt, le seul langage que j'aie jamais vu où on ne peut pas modifier la valeur d'une variable... Je n'ai jamais compris pourquoi avoir appelé ça une variable et pas une constante (ou autre nom).
</légèrement hors sujet>

Il est facile de mal utiliser une constante et avoir un "const int max = 5" au MILIEU d'une fonction, là PEBKAC

Pour moi, leur seule utilitée c'est pour les code retours (ex: ERR_BAD_PARAM = 1001) ou pour les chaines de caractères (et encore en ressources c'est mieux).


@poupipou, on peut très bien copier le corp d'une fonction à la place de son appel en général, mais c'est vrais, c'est une metaphore extreme d'une constante.

Une constante n'est qu'une variable non modifiable et on peut très bien ne quasiment jamais en avoir besoin

Il faut bien 2ans de prog pour comprendre l'interet

Il y a plein de langages où il est considéré de bon style, voire obligatoire, que toutes les variables soient des constantes: Haskell, Erlang, Scala, Coq, Agda, Miranda, Clean...

Une grande partie de la subtilité réside dans le fait qu'il est possible d'appeler une fonction avec des valeurs différentes pour ses arguments, tout en considérant l'argument comme une constante a l'intérieur de sa portée.

@poupipou : "C'est juste un confort, tout comme les fonctions" oh wait a minute. Les fonctions sont un confort ? Tu peut m'expliquer ? xD
Rien ne t'oblige à faire une fonction, hein.
C'est d'ailleurs très rare d'avoir une fonction vraiment utile et bien codée. Souvent dupliquer le code est bien plus lisible et maintenable qu'avec des fonctions.
J'ai des exemples à la pelle : personne ne s'amuse à faire une fonction Addition(a,b : int) : int. Personne ne s'amuse à faire une boucle i=i+UN (avec const int UN=1)

@Bastok : "C'est d'ailleurs très rare d'avoir une fonction vraiment utile et bien codée. Souvent dupliquer le code est bien plus lisible et maintenable qu'avec des fonctions. "
OMG. PEBKAC.

Les fonctions sont bien un confort.
On peut faire un programme entier sans fonctions, c'est illisible et pas maintenable certes.

GCC a une option pour compiler en mettant tout bout-à-bout, ça explose la taille du programme mais c'est en théorie plus rapide (moins de sauts, pas de sauvegarde de contexte, etc).

Pareil pour les boucles.

S'ils vous plaît les devs en mousse, voulez-vous bien arrêter de maltraiter l'algorithmie ainsi ?
Parce que, ça me fait mal, d'entendre des conneries pareilles.

"Les fonctions sont bien un confort. On peut faire un programme entier sans fonctions"

L'art et la manière de défendre l'indéfendable ?

On peut aussi écrire un programme entier directement en hexadecimal,
il suffit de connaitre par cœur les correspondances des instructions ASMx86 en hexa,
comme ça on économise même la compilation !

Les langages de programmation sont donc un confort ?

Allez, au lit les enfants.

@poupipou: pour que tu augmentes un peu ton faible niveau : mettre des paramètres sur la pile et brancher sur une autre zone mémoire pour débrancher par la suite, c'est géré au niveau processeur (68k, x86, ppc, arm, pour ne parler que de celles sur lesquelles je développe)... tu as même des instructions particulières pour sauvegarder tout un contexte (fourchette de registres empilés, dépilés automatiquement)...

ton programme - en soi - est tout simplement appelé par les OS actuels comme une fonction (avec paramètres et valeur de retour) donc c'est le premier exemple de fonction...

et ensuite, ton programme est certes une série d'octets (que tu l'exprimes en hexa, en décimal, ou même en binaire) mais au final ce sont des opcodes langage machine obtenus à partir de bitfields définis selon le jeu d'instructions… et généré par un assembleur ou un compilateur… et connaitre ces définitions d'instructions (bitfields), permet de développer un assembleur, un compilateur… de faire de l'opti… du code auto-généré...

donc avant de vouloir donner des leçons aux autres... et de se prendre pour un cador.. hem...

"On peut aussi écrire un programme entier directement en hexadecimal,
il suffit de connaitre par cœur les correspondances des instructions ASMx86 en hexa,
comme ça on économise même la compilation !"

Je crois que tu n'a pas saisi la totale dérision dans cette affirmation,
qui n'était la que pour souligner le raisonnement stupide suivant, je cite :
"Les fonctions sont bien un confort. On peut faire un programme entier sans fonctions"

Maintenant je reprend tes propos.


@4e71: "mettre des paramètres sur la pile et brancher sur une autre zone mémoire pour débrancher par la suite, c'est géré au niveau processeur"

Hors sujet total. Lié au fait que tu n'a rien compris de mes propos.

"et ensuite, ton programme est certes une série d'octets (...) du code auto-généré"

C'est bien, tu me fait un cours sur le langage machine, sur lequel je travaille au quotidien je te remercie,
en quoi ca contredit ce que j'ai dit ?

En quoi ca corrobore les affirmations précédentes - et stupides - sur l'inutilité des constantes et des fonctions dans la programmation aujourd'hui ?

"donc avant de vouloir donner des leçons aux autres"

L'arroseur arrosé ?

@poupipou: Puisque t'arrives pas à comprendre je vais te donner un exemple.
Tu préfères
Function mafonctionavecunnomalacon(a,b int) : boolean;
begin
if a > b then
result := true
else
result :=false;
end;
Procedure toto;
Var
a,b : int;
Const
strSUP='supérieur';
strINF='inférieur ou égal';
begin
//...
if mafonctionavecunnomalacon(a,b) then showmessage(strSUP) else showmessage(strINF);
end;

------- ou bien ------------

Procedure toto;
Var
a,b : int;
begin
//...
if a>b then showmessage('supérieur') else showmessage('inférieur ou égal')
end;

pour revenir au sujet de base:
une constante permet de préciser des choses au compilateur... le fait d'avoir une variable read only affecte pas mal le langage machine généré : lecture directe en mémoire, utilisation d'un registre d'adresse, adressage direct... bref pas de registre de donnée chargé pour garder l'état de la variable sur un scope donné pour être mis à jour par la suite...
donc c'est loin d'être inutile surtout lorsqu'on est au cycle près, et même en dehors de cela je conseille vivement d'être conscient de ce qui se passe un peu derrière ça évitera les écueils que l'on peut voir

@Bastok: notsureiftrollingorjuststupid.jpg