Salut, et bienvenue sur le forum
Citation:
Envoyé par
RT222
Je suis d'accord pour dire qu'elle est bien conçue pour les nouveaux élèves qui, arrivés en piscine, ont tendance à coder des put_nbr de 6 fonctions de plus de 20 lignes. Elle pousse à l'économie de code et donc indirectement d'opérations effectuées, ce qui n'est pas un mal. Mais autant ceci vaut pour les débutants, autant lorsque l'on commence à acquérir un minimum de compétences et que l'on attaque des projets plus consistants, cette norme est une plaie à suivre, particulièrement la limite absolue de 25 lignes par fonctions.
Pourquoi 25 lignes piles?
A mon avis, c'est essentiellement historique:
A l'époque où windows et son système de fenêtrage n'était encore qu'un doux rêve, les moniteurs affichaient... 25 lignes de 80 colonnes.
La limite des 80 colonnes et des 25 lignes permettait donc de s'assurer:
- qu' il n'y aurait pas de passage à la ligne pour afficher une ligne unique de code
- que l'ensemble de la fonction serait affichable à l'écran, sans risquer de voir les premières lignes "mangées" par le manque de place.
D'ailleurs, on croise aussi souvent des conseils qui préconisent de se limiter à 50 lignes (2* la hauteur de l'écran)... Mais c'est tout autant arbitraire, et cela commence à faire des fonctions pour le moins importantes :P
Citation:
Je sais que le découpage fonctionnel est très important
Oh que oui, c'est vachement important... peut être même plus que ce que tu ne pourrais le croire pour l'instant :D
Citation:
dans un programme, seulement imposé comme ça, c'est juste une plaie et ça rend plus sale les codes, d'autant plus que pas mal de raccourcis sont interdits : déclaration de plusieurs variables de même type sur une seule ligne, initialisation de ces variables lors de leur déclaration... Combien de fois j'ai été obligé de tricher à mort sur une fonction, en utilisant des raccourcis d'écriture très peu clair à lire, mais plus courts à écrire, pour tenir à tout prix cette limite et éviter ainsi un découpage inutile? Pourquoi suis je obligé bien souvent de morceler des fonctions, alors que leur action était linéaire et ne nécessitait absolument pas de découpage? :?
Peut être en demandais tu simplement trop à tes fonctions :question:
Il est vraiment rare que j'atteigne les 25 lignes dans une fonction, même en déclarant chaque variable dans une ligne...
Mais ce qui importe surtout, c'est d'essayer de suivre le principe de la responsabilité unique: chaque fonction ne devrait faire qu'une seule chose, mais devrait la faire correctement :D
Citation:
Je ne suis pas convaincu non plus par l'interdiction totale (et non expliquée d'ailleurs des for et des switch (et pourquoi les ternaires sont-ils autorisés eux?).
Ca, par contre, cela me semble effectivement aberrant...
Citation:
Ne pas les employer n'est pas en soi un problème, là où ça gêne à mon sens, c'est qu'ils sont utilisés dans de très nombreux programmes et que leur non connaissance peut gêner à la compréhension de codes en dehors d'Epitech (bien que cette lacune soit comblée en quelques minutes, mais bon...).
Tout à fait... la connaissance des boucles (de tous les types de boucles) et des tests (de tous les types de tests) reste quand même la base de la programmation structurée...
Citation:
L'école prend aussi le parti de nous décourager à utiliser les commentaires, alors que j'ai toujours lu que bien commenter son code est capital.
Il y a à boire et à manger sur ce point:
Un code correctement écrit ne devrait, en effet, pas nécessiter de commentaires.
Par contre, il est vrai qu'un commentaire utile est souvent appréciable. Encore faut il qu'il soit effectivement utile, et qu'il ne vienne pas rajouter une couche sur ce que le code permet de comprendre.
Un commentaire proche de
Code:
i++; // on ajoute un à i
n'a en effet aucun intérêt, mais si un commentaire mets les invariants en évidence ou précise la logique qui est suivie (ou du moins qui doit etre suivie) par le code présente malgré tout un intérêt majeur ;)
Citation:
Et pour finir, les globales sont autorisées dans la norme (qui se contente de les déconseiller). :P
En fait, c'est le cas à peu près partout:
On peut te donner une quantité inimaginable d'arguments contre les variables globales, mais tu restes malgré tout seul maître de ton code, et il peut toujours arriver un moment où... une variable globale sera la "moins mauvaise solution".
Mais Emmanuel a bien raison de dire qu'il est préférable d'attendre de savoir pourquoi tu dois t'en priver avant de décider de les utiliser :D
Citation:
J'ai bien sûr un très grand respect pour Nicolas Sadirac, et j'admire ce qu'il a fait et ce qu'il est capable de faire, mais cela ne m'empêche pas de pester contre la norme d'Epitech (qu'il n'a sans doute pas écrite lui même d'ailleurs) que je trouve, pour les raisons citées ci-dessus, fort mal conçue (bien qu'elle ait certaines qualités, je ne le nie pas non plus).
Le problème de ce genre de "norme" est qu'elles sont rarement mises à jour, et ne prennent donc que rarement l'évolution de l'état de l'art en compte.
Et, comme on oublie régulièrement de préciser l'année où elles ont été mises au point, on en arrive régulièrement à remarquer que certaines règles sont en désaccord total avec ce que l'état de l'art nous conseille ;)
Citation:
Ceci dit, il s'agit là d'un avis de débutant, et peut être ais-je tort de penser ainsi, mais cette norme m'a pour le moment tellement posée de problèmes que je ne peux m'empêcher de lui vouer une certaine haine. :mrgreen:
On peut le comprendre, mais il faut te dire que les "règles de codage", pour bizarres ou perfectibles qu'elles puissent paraitre, sont malgré tout indispensables pour s'assurer la cohérence du code dans un projet d'importance.
Citation:
Oh non, ne me dis pas qu'il ne faut pas faire comme ça, j'adore procéder ainsi. :( Je précise que je n'y met pas tout bien entendu, l'idée n'est en aucun cas de ne plus avoir de variables locales aux fonctions (ce qui serait très moche je le sais :P). Par donnée, j'entends tout ce qui a un rapport avec la configuration du programme et les objets qui y ont été chargés.
Mais pourquoi ne pas utiliser une variable classique et veiller à ce qu'elle soit accessible par les objets qui en ont réellement besoin :question:
La liste des objets qui en ont besoin de doit, malgré tout, pas être *si* importante que cela ;)
Citation:
Voici la véritable structure que j'utilise, ça sera plus clair. C'est encore en chantier donc il manque plein de trucs, je précise :
Main_Structure_Data.h
Code:
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
35
36
37
38
39
40
41
42
43
44
45
|
#pragma once
namespace mdt
{
struct videoParams
{
short int screenWidthMax;
short int screenWidth;
short int screenHeightMax;
short int screenHeight;
short int refreshRateMax;
short int refreshRate;
short int fpsMax;
};
// Déclarations anticipées
class Mesh;
class DiffuseMap;
class SpecularMap;
class NormalMap;
class OcclusionMap;
class EnvironMap;
class Skeleton;
class Animation;
class Camera;
struct MainData
{
videoParams *videoParams;
Mesh *models;
DiffuseMap *diffusesMaps;
SpecularMap *specularsMaps;
NormalMap *normalsMaps;
OcclusionMap *OcclusionsMaps;
EnvironMap *EnvironnementalsMaps;
Skeleton *skeletons;
Animation *animations
Camera *cameras;
int drawParams; // masque de bit, voir définitions dans 3D_Draw.h
};
} |
Alors, réfléchissons un peu...:
VideoParams est un ensemble de données qui n'est réellement intéressant que pour la partie "affichage" de ton programme (on pourrait d'ailleurs en dire sans doute autant pour camera (dont j'imagine qu'elle permet de sélectionner le type de vue), et d'animations).
Les autres données de MainData semblent essentiellement nécessaires à la partie "métier", même s'il parait évident qu'il sera nécessaire de les passer à la partie affichage ;)
Citation:
Je trouvais cette manière de procéder très pratique et efficace car, ayant besoin de stocker et parfois de faire transiter un grand nombre de paramètres entre les fonctions (bon pas en l'état actuel, mais ça va venir), tout était rassemblé en un seul et unique pointeur qu'il me suffit de passer à une fonction pour avoir accès à toutes les données. En plus d'être pratique, il me semblait que c'était plus léger que de passer des tonnes de paramètres en entrée. En prime, cela me permet d'avoir facilement accès à l'intégralité des données de mon programme (paramètres et contenu), et de pouvoir plus facilement suivre sa configuration et tout ce qui a été chargé en mémoire. Enfin c'est ce que je croyais, si j'ai tort, je serais ravi de le savoir. Loin de moi l'idée de vouloir coder salement. :)
Tu dois, encore une fois, veiller à respecter au mieux la règle de la responsabilité unique.
Il est, surement, possible de regrouper certaines de ces données dans des structures / classes clairement déterminées, mais il faut, malgré tout veiller à ne pas transmettre trop de choses inutiles ;)
De plus, si tu code en C++, tu devrais surtout t'intéresser aux services que tu attends de la part de tes objets. Ils te permettront fatalement de déterminer quelles données seront nécessaires pour leur permettre de rendre le service attendu ;)
Citation:
Merci pour le lien, très intéressant à lire. Ma structure respecte clairement le premier point, puisqu'elle est créée au démarrage du programme, et détruite uniquement à sa sortie.
Mais alors, pourquoi la déclarer en variable globale, et non comme une variable locale à la fonction main :question:
Citation:
Je ne sais pas si elle respecte le deuxième point, sachant que même si son contenu change, la structure vers laquelle pointe le pointeur, ainsi que le pointeur lui même restent les mêmes du début à la fin.
c'est le problème des variables globales: n'importe quoi peut y accéder depuis n'importe où et en faire n'importe quoi...
Si tu crées ta variable de type MainData ne serait-ce que dans la fonction main (et que tu en fais donc bel et bien une variable locale) (à défaut de revoir l'ensemble de l'analyse), les seules fonctions qui pourront accéder à tout ou partie de son contenu seront celles... auxquelles tu transmettra les informations sous la forme de paramètres ;)
Citation:
Ok ok, je me rends et suivrais donc ton conseil avisé. Point de globales dans mon programme. :D
voila une sage décision :D
