Formulation - reformulation

Réponses à toutes vos questions de la 2nde à la Terminale toutes séries
Razes
Membre Rationnel
Messages: 964
Enregistré le: 28 Juil 2014, 21:24

Re: Formulation - reformulation

par Razes » 20 Aoû 2016, 23:19

Ce sont des langages que je connais très bien.

Dans le cas du C tu utilise par exemple la directive #define HC 16907, ainsi ça t'évitera de taper ce nombre à chaque reprise. Tu peux même l'inclure dans un fichier de données Donnee.h que tu incorpore dans tes programmes via #include "Donnee.h"

C'est vraiment beaucoup plus pratique.



Valentin03
Membre Relatif
Messages: 429
Enregistré le: 23 Déc 2012, 15:08

Re: Formulation - reformulation

par Valentin03 » 21 Aoû 2016, 12:25

Razes a écrit:C'est vraiment beaucoup plus pratique.

Oui, mais on se plante beaucoup mieux en manipulant des variables qui ne représentent rien (coeff's), qu'avec des qui représentent quelque chose de tangible (4000 litres de flotte à 50°C, c'est pas rien)
Vaste débat entre manipuler des concepts ou des abstractions

Razes
Membre Rationnel
Messages: 964
Enregistré le: 28 Juil 2014, 21:24

Re: Formulation - reformulation

par Razes » 21 Aoû 2016, 18:33

Valentin03 a écrit:
Razes a écrit:C'est vraiment beaucoup plus pratique.

Oui, mais on se plante beaucoup mieux en manipulant des variables qui ne représentent rien (coeff's), qu'avec des qui représentent quelque chose de tangible (4000 litres de flotte à 50°C, c'est pas rien)
Vaste débat entre manipuler des concepts ou des abstractions

Là je ne suis pas d'accord, par exemple le nombre que tu utilise assez souvent et qui est doit signifier quelque chose.

Par ailleurs, si tu monte une application pour résoudre des problèmes d'échange thermique alors ton application doit traiter des cas divers avec des conditions initiales différentes et des réfrigérants différents et dans ce cas tu ne dois pas réécrire des routines pour chaque réfrigérant.

Avatar de l’utilisateur
Rockleader
Habitué(e)
Messages: 2126
Enregistré le: 11 Oct 2011, 20:42

Re: Formulation - reformulation

par Rockleader » 22 Aoû 2016, 12:25

Je me permets aussi d'intervenir.

Utiliser une variable que tu définis c'est la norme en vigueur et c'est pas pour rien.

De la même manière que tu définis une fonction pour ne pas avoir à re-écrire son code 99999 fois, tu définis une variable pour ne pas avoir à l'écrire de nouveau.

Qui dit écrire de nouveaux dit potentiellement erreur de recopie. Et après pour trouver ton erreur bonjour le bordel.

Alors que si ta variable est stocké dans un fichier header comme indiqué plus haut, tu sais ou est la variable et elle n'est écrite qu'une seule fois donc aucun risque de se tromper.

Dans le cas de ton exemple d'eau à 50 degré.

On pourrait très bien imaginer un fichier données.h

#define VOLUMETRIE_EAU 4000
#define TEMPERATURE_EAU 50

Il ne faut pas avoir peur d'utiliser des noms parlants même s'ils sont long.

Il faut bien se dire une chose, si tu as besoin de commentaire un nom de variable, c'est que ton nom de variable est mauvais. On doit comprendre ça sans commentaire.

Pour avoir eu à reprendre quelques programmes dans divers langages il n'y a rien de pire que de se retrouver avec des a=5555 ou h=54542 et devoir aller chercher on sait pas où dans une doc fumeuse à quoi correspond la variable.
Cette histoire est entièrement vraie puisque je l'ai inventé du début à la fin !

Razes
Membre Rationnel
Messages: 964
Enregistré le: 28 Juil 2014, 21:24

Re: Formulation - reformulation

par Razes » 22 Aoû 2016, 13:52

@Rockleader
Effectivement.
C'est exactement ce que j’essaie de faire passer comme message, d'autant plus, plus le programme grandit plus sa maintenance devient difficile et parfois impossible (avec des programmes de 10000lignes on va ressentir l'effet de balader un nombre style ou même un paramètre appelé et on se pose la question "Mais ça correspond à quelle donnée physique?" alors qu'il était plus pratique de l'appeler par exemple.

Bien entendu il restera des fonction standards qui ne dépendent d'aucun paramètre physique, comme la fonction qui interverti les données de deux parametres. dans ce pas de soucis c'est une fonction standard.

La programmation était ma passion, c'est pour ça que je souhaite que tu évite certaines erreur.

Valentin03
Membre Relatif
Messages: 429
Enregistré le: 23 Déc 2012, 15:08

Re: Formulation - reformulation

par Valentin03 » 22 Aoû 2016, 14:38

Par delà les règles, chacun sa philosophie; moi je laisse les coeffs en dur
ça me passera peut-être
Chaque méthode a ses avantages et ses inconvénients

Razes
Membre Rationnel
Messages: 964
Enregistré le: 28 Juil 2014, 21:24

Re: Formulation - reformulation

par Razes » 22 Aoû 2016, 14:39

Bonne continuation, On est là au cas où.

Avatar de l’utilisateur
Rockleader
Habitué(e)
Messages: 2126
Enregistré le: 11 Oct 2011, 20:42

Re: Formulation - reformulation

par Rockleader » 22 Aoû 2016, 15:13

Valentin03 a écrit:Par delà les règles, chacun sa philosophie; moi je laisse les coeffs en dur
ça me passera peut-être
Chaque méthode a ses avantages et ses inconvénients


Ce n'est pas une règle à proprement parler dans le sens ou ton compilateur ne viendra pas te dire que c'est faux. Mais ça va au delà de la philosophie, il en va d'adopter une méthode de travail propre. C'est autant une question de méthodologie que de respect envers tes futurs collègues.

Quand on fait du dev il ne faut pas oublier que l'on dev aussi pour les autres.

Quand tu as un fichier coefficient.h ça ne pose aucune contestation, on sait d'avance où trouver tout et si on veut modifier on le modifie à un seul endroit. C'est autant pour te faciliter la vie qu'aux autres. Même pour toi, quand tu reviendras sur ton code 5 ans plus tard tu ne sauras plus à quoi correspondent tes chiffres. Ou alors à chaque fois que tu mettras ton coef en dur, il y aura un commentaire à coté.

Mais sache que les commentaires passent souvent à la trappe lors des maintenance et que souvent tu te retrouves avec des commentaires qui ne sont plus adaptés.

Dans le cas de la méthode que tu nous explique si on peut appeler ça une méthode je n'y vois réellement aucun avantage. Maintenant c'est toi qui voit, mais franchement prendre de mauvaises habitudes comme ça c'est vraiment pas bon.


Exemple à la con: La fusée arianne qui a explosé, si je me rappelle bien cela venait d'une constante qui était en dur et qui n'avait pas été mise à jour par rapport à une précédente version...Une constante à plusieurs millions d'euro donc....voilà à quoi peut mener ce genre de mauvaises habitudes. Certes cas extrême ici, mais pas tellement.

La balle est dans tes mains. Quoi qu'il en soit bonne chance pour la suite.


EDIT: Si je me permets la remarque c'est que j'ai vu que tu avais commencé ton thread dans la partie informatique, j'imagine donc que c'est là le gros du travail et qu'il vaut mieux que tu restes propre là dessus. Si tu remontes à la sources en arm, c'est pas pour rien que toutes les variables sont insérées dans des registres.
Cette histoire est entièrement vraie puisque je l'ai inventé du début à la fin !

Avatar de l’utilisateur
fatal_error
Modérateur
Messages: 6610
Enregistré le: 22 Nov 2007, 14:00

Re: Formulation - reformulation

par fatal_error » 22 Aoû 2016, 20:37

c'est légèrement à côté compte tenu du but du topic, mais je suis obligé de nuancer vos propos.
Académiquement, on enseigne les constantes.
Mais en vrai, on s'en contrefout si la valeur n'est pas répétée partout.
ex:
Code: Tout sélectionner
function getMonth(date){
 var d = date.getDayIndex()//returns 0-365
 var months = [31,28,31,30,31,...]the number of days per month
 //this function must return the correct month index
}


ci dessus, il ne fait absolument AUCUN intérêt de remplacer respectivement les constantes par NB_DAYS_JANUARY, NB_DAYS,... ce qui serait inutilement verbeux. Un lecteur normalement constitué devrait comprendre ...

Par ailleurs, concernant les directives de preprocesseur, l'argument est mal choisi concernant le changement de paramètres, car il faudrait recompiler le programme, ce qui est stupide! Cela implique d'avoir un fichier, ou de gérer des arguments, ce qui dans les deux cas implique un développement supplémentaire qui n'est pas forcément le but escompté.

D'une manière générale, je vais dans le sens de valentin03, une valeur numérique a parfois le mérite pour l'implémenteur de ne pas avoir à se soucier outremesure du -contrat- de fonction (quid du boulet qui remplace la constante par une valeur inappropriée).

Bref, je suis ok pour les constantes, ou littéraux pour désigner des valeurs, mais il ne faut pas TOUJOURS jurer par ca car ça ajoute de l'entropie (valeurs modifiées, validité de fonctions, test unitaires, commentaires, contrat de fonction inutilement complexe, etc).

tout dépend de pourquoi on fait le programme, pour qui (des idiots, des gens avec un minimum de bagage,...), quelle est sa durée de vie, etc
la vie est une fête :)

Valentin03
Membre Relatif
Messages: 429
Enregistré le: 23 Déc 2012, 15:08

Re: Formulation - reformulation

par Valentin03 » 22 Aoû 2016, 22:02

@ rockleader: Un coeff ne se modifie pas (par définition); sinon c'est un paramètre
La navette Colombia: Ce n'est pas parce que la valeur a été codée en dur mais parce que le gars chargé du boulot a merdé. nuance...
Perso je préfère avoir les coeff et constantes à l'oeil, pour ne pas dire sous surveillance
Parce que si G-G=0 la gravité n'en disparaît pas pour autant

Razes
Membre Rationnel
Messages: 964
Enregistré le: 28 Juil 2014, 21:24

Re: Formulation - reformulation

par Razes » 22 Aoû 2016, 23:21

Bonsoir,

Si j'ai parlé de la directive define c'était uniquement pour les constantes (température d'évaporation, chaleur massique, chaleur latente, ...)

Pour ce qui est des parametres, c'est plus du nom de codification que je suis intervenu, (j'avais une assistante en thermique qui avait donné le nom "tata" à l'enthalpie, quand j'ai voulu relire le code, cela n'était pas facile et il avait fallu l'appeler pour changer le nom de plusieurs parametres, car il fallait respecter un certain code d’appellation).

Pour ce qui est des parametres, on les enregistraient dans un fichier données, il ne sont pas interprétés comme une directive mais plutôt lus comme des données qu'on affecte aux paramètres du programme.

Si je suis intervenu, c'était uniquement pour faire bénéficier de mon expérience. Ceci dit, chacun reste maitre de ce qu'il veux faire et ce qui lui semble bon.

Désolé d'avoir dérangé vos habitudes.

 

Retourner vers ✎✎ Lycée

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 87 invités

Tu pars déja ?



Fais toi aider gratuitement sur Maths-forum !

Créé un compte en 1 minute et pose ta question dans le forum ;-)
Inscription gratuite

Identification

Pas encore inscrit ?

Ou identifiez-vous :

Inscription gratuite