langage C : coordonnées dans un jeu

[tatouille]

Les noms de variables explicites je trouve ça très bien mais en l'occurence pour i et j c'est tellement courant de s'en servir pour le parcours d'un tableau que les deux lettres sont assez explicites en elles mêmes.

Mais sinon appelé une matrice "m", "mat", "matrice" dans un vrai programme c'est pas coule par contre, la matrice c'est "quelque chose" : une grille de jeu par exemple. Donc faut lui donner un nom en rapport avec ça

EDIT: connexion internet foireuse y a eu deux réponses depuis que j'ai pas pu poster :-/

ou i,j,k est nomenclature utilisee pour les incrementales ou indexes, pas vraiment "la variable de reference"

 

[Didier Guillion]

"m" et "j" sont probablement moins parlants que "NombreDeColonnesDansLeTableau" et "PositionEnColonneDansLeTableau".

En revanche, ces deux derniers sont longs à taper, ils risquent à la longue d'occasionner de la fatigue et des erreurs de frappe, et puis ils sont finalement assez peu lisibles.

On rallongerait inutilement le temps de développement sans beaucoup gagner au niveau de la lisibilité (... pas bon !).

Les noms longs et explicites sont à réserver pour les éléments dont on ne voit pas immédiatement la fonction parce qu'ils sont trop délayées dans le code source.

Quand la portée d'un variable est limitée à trois ou quatre lignes, la question ne se pose pas vraiment, à moins que l'opération codée ne soit pas triviale.

Dans les autres cas, il me semble que pour les éléments qui apparaissent souvent, il est préférable de choisir un nom assez court mais suffisamment explicite, et d'accompagner sa déclaration ou sa première utilisation d'un commentaire explicatif.


Dans le cas présent, je laisserais "i" et "j", et je rallongerais "m" et "n", et éventuellement "mat".

Bof... Le temps de dev... Le copier/coller c'est autorisé.
Mais je ne te critique pas vraiment c'est ce que l'on apprends dans les écoles. On s'imagine que si le source est plus court, le résultat est plus optimisé. Faribole, billevesée.
Reste a savoir si tu veut coder ou écrire.
La prog, c'est un moyen pour toi ? (De passer à autre chose) Ou un but de t'exprimer ?
Soit verbeux, commente.
Fais toi plaisir.
N'oublie pas, petit scarabé, "Un source, c'est du commentaire avec des lignes de code autour".

Pense a ceux qui vont te lire. Ou toi même...
Dans 20 ans, tu te comprendra ?


Cordialement

 

[PA5CAL]

Bof... Le temps de dev... Le copier/coller c'est autorisé.
Mais je ne te critique pas vraiment c'est ce que l'on apprends dans les écoles. On s'imagine que si le source est plus court, le résultat est plus optimisé. Faribole, billevesée.
Reste a savoir si tu veut coder ou écrire.
La prog, c'est un moyen pour toi ? (De passer à autre chose) Ou un but de t'exprimer ?
Soit verbeux, commente.
Fais toi plaisir.
N'oublie pas, petit scarabé, "Un source, c'est du commentaire avec des lignes de code autour".

Pense a ceux qui vont te lire. Ou toi même...
Dans 20 ans, tu te comprendra ?


Cordialement

Ce n'est pas en faisant des copier-coller qu'on arrive à produire 300 à 500 lignes de code inédites par jour. Le code le plus court ne donne pas le résultat le plus optimisé, mais il prend sûrement moins de temps à être fabriqué et à être relu.

Sur des projets de plusieurs centaines de milliers de lignes de code, des budgets de quelques millions d'euros et des plannings calibrés au jour près sur plusieurs années, si l'on s'était permis d'utiliser des noms d'une trentaine de caractères, les retards accumulés nous auraient empêchés d'honorer nos engagements vis-à-vis de nos clients, on aurait dû payer des pénalités de retard astronomiques, perdu des marchés, et peut-être fini par mettre la clé sous la porte.

Quant aux commentaires et à la documentation, ils doivent être comme le code : en corrélation avec le but recherché et les ressources du projets. Ils doivent pouvoir être compris et remis à jour à chaque fois que nécessaire, et parfois plusieurs années après et par des personnes différents.

Pour info, j'ai eu à retravailler récemment sur des sources qui datent de vingt ans. Heureusement que j'ai réussi à les relire pour pouvoir les modifier, parce que le client, lui, n'attend pas.

 

[Didier Guillion]

Le code le plus court est certainement le plus rapide à écrire mais assurément pas le plus rapide à relire ! Ni à débogger !

Et tu arrive à caller des projets de plusieurs années au jour près, 'tain, tappe à la porte de M Gate, ils ont besoin de toi...


Cordialement

 

[PA5CAL]

Le code le plus court est certainement le plus rapide à écrire mais assurément pas le plus rapide à relire ! Ni à débogger !

Exact, mais il y a une juste limite à atteindre, dont j'ai indiqué quelques principes au post #17.

Et tu arrive à caller des projets de plusieurs années au jour près, 'tain, tappe à la porte de M Gate, ils ont besoin de toi...

Oui, au jour près sur plusieurs années, parce qu'on ne donne pas dans l'amateurisme.

Les projets qu'on traite sont parfois longs, et ils entrent en interaction avec d'autres qui nécessitent un partage des mêmes ressources. De plus, ils sont soumis à des contrats très stricts quant aux délais, avec des pénalités de retard, qui sont bien fixées au jour près des années à l'avance, elles.

Or, les éventuels ratages (et heureusement ils sont rares) ne peuvent pas se résoudre par un allongement des périodes d'allocation des ressources (programmeur, expert métier, client, ordinateurs, matériels, site d'étude, site d'industrialisation, site d'exploitation, hôtel, moyen de transport...). Un dépassement des délais, même minime, demande souvent un report et une réorganisation de l'ensemble du projet chez les différents acteurs (dont beaucoup sont extérieurs à l'entreprise). Et le report peut parfois atteindre plusieurs mois !

C'est pour cette raison qu'en cas de difficulté, on assiste à un allongement de la durée du travail, et à un gonflement des équipes. On passe la semaine de 40 heures à 70 heures (adieu les weekends et les congés), et même les directeurs reviennent parfois participer aux brainstormings ou "pisser de la ligne".

Alors pour éviter d'en arriver là, chacun doit faire son métier correctement, à commencer par le codage du programme qui ne doit faire ni plus ni moins que ce qui est nécessaire et suffisant.


Je ne pense pas que cette situation soit exceptionnelle, car certains parmi mes amis et les membres de ma famille la vivent aussi. Compte tenu de tes remarques, je me permets de m'interroger sur le sérieux avec lequel on pratique le développement logiciel dans ton milieu. Mais peut-être ne s'agit-il que d'un hobby.

Cordialement

 

[Didier Guillion]

Compte tenu de tes remarques, je me permets de m'interroger sur le sérieux avec lequel on pratique le développement logiciel dans ton milieu.

Cordialement

Touché ! En effet, je ne cherche pas a me prendre au sérieux. Je m'amuse a faire ce que je fait.
Ce que tu me décrit est une vision réaliste de ce qu'est le développement pour certains : "pisser du code" pour tenir le délai.

"It compile, ship it!"

Heureusement, il en reste pour prendre leur pied a coder et dans ce cas, un code propre et élégant, bien commenté et clair, avec des noms de fonctions et de variables adéqua est une satisfaction.

Cordialement