Oui tout à fait, d'ailleurs je fais un moteur de jeu depuis deux ans et j'ai absolument toute l'architecture de prévue dès le départ ! Il n'y a eu absolument aucun faux pas et je n'ai pas passé des semaines à régler des problèmes d'archi ...

Mais à qui tu veux faire croire ça :')

Oui c'est pratique, comme ça à chaque instruction on écrit un nouveau bloc de commentaire pour rappeler les spécifications de chaque variable.

A quand le compilateur de commentaires d'ailleurs ?

Concernant les "instructions déjà écrites" dont tu veux te débarrasser, pourquoi ne pas les commenter ? Tout le monde sera content !
Et tu pourras toujours les effacer lorsque vous commencerez un nouveau TP !

pour les noms de variables c'est pas si idiot que ça, personnellement les noms à rallonge genre Java c'est pas ma tasse de thé

A quand le compilateur de commentaires d'ailleurs ?

Techniquement, les directive de pré-compilateur en C sont des commentaires... C'est juste que pour éviter les problèmes, personne n'utilise # pour les commentaires unilignes (et C++ a introduit // ensuite).

Je trouve les conseils de l'enseignant pertinents au contraire... si on code sur des cartes perforées.
J'espère qu'il vous a aussi dit de numéroter les lignes de dix en dix.

Oui enfin ça dépend ce qu'il entend par "nom de variable court"... et à mon avis c'est plutôt des trucs du genre a ou z1...

Après c'est sûr que les variables du genre serializableArrayOfString (je dis n'importe quoi hein faîtes preuve d'imagination) c'est pas forcément mieux, mais au moins ça a le mérite d'être clair.

Et puis il y a généralement une auto-complétion sur les IDE !

Java, tasse de thé... Héhé.

Commenter une instruction déjà écrite, c'est la modifier. Il faut les mettre dans une condition invalide.
print "salut !";
deviendra :

if(false) {
 print "salut !";
 }

Tu remarqueras qu'on ne peut pas non plus toucher à l'indentation, ça fait partie de l'instruction.

Et si jamais tu veut rétablir ton code, il faut rajouter un
#define false true

Et si tu as plusieurs blocs de code à supprimer, il faut varier les conditions :

if(!true)
 if(0)
 if(1!=1)
 if(defined(undef)))

Ça te permettra de ne rétablir qu'un seul bloc, si besoin, via les lignes suivantes :

#define true false
 #define 0 1
 #define != ==
 #define defined !defined

Et si tu veux supprimer de nouveau le code, il faudra rajouter, au dessus des define précédents :

#define "#define true false" "#define true true"
 #define "#define 0 1" "#define 0 0"
 #define "#define != ==" "#define != !="
 #define "#define defined !defined" "#define defined defined"

Note pour Aaargh!!! : il recrute, ton pifenmoins patron ?

Pour information, il m'a sorti tout ça après avoir vu que mon indice de boucle s'appelait it (car i était déjà pris pour une variable qu'on aurait eu intérêt à appeler integrale_exacte et qu'iteration ne plait pas à mon binôme).

Lorsque j'avais commencé à écrire le programme, j'avais déclaré toutes les variables nécessaires (comme elles étaient listées) et, comme on ne les utilise pas toutes, je les initialise. Il n'a pas aimé en me disant que j'aurais du savoir que celles-ci étaient initialisées ailleurs dans le code qui restait à écrire (et donc qu'il aurait fallu supprimer ces initialisations). C'est à ce moment qu'il a dit, en substance, ce que je présente dans le dernier paragraphe.

Oui, avec les normes Fortran pré 90, c'est le cas.

A make_install ?

Tu es directement bombardé chef archi !

J'ai mis autant de temps a comprendre, qu'un programme java a s'exécuter.

Je pense qu'il code tout avec sa machine à écrire, ensuite il scanne ses feuilles, passe les images dans un OCR et envoie le résultat au compilateur. Non ?

Il ne t'a pas aussi dit qu'il fallait coder sans bug ? :D

Heu, # c'est pas censé être uniquement pour le préprocesseur ? Certes, tu peux l'utiliser pour des commentaires parce que le préprocesseur s'en moque s'il ne reconnaît pas l'instruction.

Mais d'aussi loin que je me souvienne de K&R, les commentaires C ont été /* ... */ jusqu'au C99 où les // ont été introduits.

Encore un professeur qui n'a aucune réelle expérience professionnelle ni aucune notion de méthodologie...

Les bonnes pratiques de ces dernières années nous disent exactement l'inverse. Il devrait peut-être se mettre à jour, on est plus dans les années 80.

Le genre de prof qui a sa réputation quand tu arrives à l'iut quoi.

Suis-je le seul à être surpris qu'on donne encore aujourd'hui des cours d'un langage aussi arriéré que le FORTRAN ?

Je me sers de Fortran pour coder pas mal de méthodes de calcul en aérodynamique, mécanique des fluides et dynamique des gaz comme pré-étude avant de lancer les monstres de CFD, et il remplit trés bien son rôle pour ces applications calculatoires. C'est un peu LE langage pour ce genre d'application, par "tradition" et surtout parce que la plupart de nos chercheurs ont toujours bossé dessus, ce qui veut dire que tu as des chances de tomber sur des vieux softs en F90 voire F77, et là c'est pas mal d'avoir quelques bases.

Il a raison sur un point : une conception spécifiée dans un modèle abstrait depuis de le début et raffiné par étapes successives de manière formelle sera inifiniment plus robuste, plus facile à analyser (parce qu'on aura rarement besoin du code en lui même).
En revanche les variables a, b, c et compagnie, je suis d'accord c'est très con.

C'est rare que je le pense, encore plus que je le dise, mais puisque c'est Moi : you made my day. :')

Certes mais le prof pousse cela à l'extrême : il s'imagine que l'on doit avoir fait toutes les étapes de conception, programmation et débug dans sa tête et après seulement de taper le tout dans l'IDE.

Euh, Fortran et années 80, c'est un peu un pléonasme. En dehors de quelques cas très spécifiques de calcul scientifiques notamment, Fortran est un peu daté, comme ce prof en fait.

Tout de suite tu exagères, certes il ne faut pas mettre a, b ou c, mais il faut réduire. Exemple pour une gestion d'horaires :
horaire matin : hm,
heures sup : hs,
horaire midi : hm
horaire du soir : hs.

Chronologiquement, le C est un langage sacrément arriéré o/

Pour le coup, j'ai envie de donner raison au prof.

Le FORTRAN est un langage ultra formaté (du moins dans ces premières variantes).
A l'origine, le langage a été créé pour être codé non pas sur des ordinateurs, mais sur des cartes perforées.

Cartes perforées limitées en place, et sur lesquelles, bien sur, on ne pouvait pas revenir en arrière.

Le prof inculque donc les règles qu'on lui a apprises, certes, mais qui sont encore la règle dans la communauté scientifique, qui, seule, utilise encore régulièrement FORTRAN.


Second petit point, FORTRAN est encore extraordinairement utilisé dans les programmes scientifiques. Parfois nativement, parfois, sous forme de programmes permettant l'utilisation de routines FORTRAN (Matlab, Pro II, Aspen, etc...).
J'écris en ce moment un article scientifique (sur les Equations d'Etat cubique prédictives en l'occurence), et tout est basé sur un programme FORTRAN, car c'est relativement simple à utiliser, une fois retenues les contraintes citées plus haut, et que la communauté scientifique dans sa grande majorité comprend le FORTRAN, et peut donc critiquer les recherches, ce qui est la base de la recherche scientifique.

TL,DR: CTLP.

Oh oh oh, trop facile. Je valide. X)
C'est marrant, tu as un vote négatif sur ce commentaire : je me demande de qui peut-il venir...^^

Il n'y a pas de cartes perforées dans cette histoire. Aucun rapport avec la choucroute binaire.

Ça me rappelle mes profs (enfin, certains profs) d'IUT qui voulaient qu'on écrive tout son code sur papier avant de de le taper. On devait donc suivre trois étapes :
- algorithme en pseudo-code sur papier
- code sur papier (COBOL ou Pascal)
- code sur machine

Et Fortran, ça me rappelle mon stage de fin d'études où j'ai fait du Fortran IV ! Mais pour vous dire si c'est vieux : à l'époque, on avait un président socialiste !

Préfixer le nom des variables, leur donner un nom qui ait un minimum de sens... tout ça c'est pour les lopettes. Avec 26 lettres dans l'alphabet, tu devrais avoir de quoi faire !
Au pire, si c'est vraiment pas assez tu passes sur "aa", "ab", "ac", etc.

Le but ici c'est de te rendre indispensable : Si personne d'autre que toi ne peut relire ton programme parce que toutes les variables ne comportent qu'une ou deux lettres, et qu'en plus tu as pris soin de laisser des blocs de code qui ne servent à rien, alors tu t'assures de garder ta place dans l'entreprise où tu bosses.
Ben oui, comment faire pour modifier tes progs si t'es plus là ? Qui voudra mettre le nez là-dedans et risquer de sombrer dans la démence ?
Et puis si vraiment ta façon de bosser ne leur plait pas et que tu perds ton boulot à cause de ça, au moins pense que ta vengeance est déjà l'œuvre et que celui qui prend ta suite entame sans doute déjà une descente vertigineuse vers la dépression nerveuse. Juste grâce à tes programmes.

(Je ne vois pas d'autre explication au parti-pris de ton professeur)

FORTRAN a été conçu pour être codé sur carte perforée. OK, plus personne ne s'en soucie maintenant, mais ça reste dans les standards de programmation, et en plus dans la norme du langage (surtout en F77)

Chez moi on dit : "celui qui sait faire fait, celui qui ne sait pas faire commande, celui qui ne sait pas commander enseigne".

<troll>Dans moindre mesure, ce n'est pas complètement idiot, quand je fais un script, il ne me viendra pas à l'idée d'utiliser une variable de 128 caractères.</troll>
Après évidemment faut un juste milieu.
Je pense que le prof souhaitait surtout pousser ses élèves à comprendre qu'à réfléchir un projet en amont permet de moins s'eparpiller lors de la création.
C'est, au final un PEBKAC moyen parce que je comprneds la difficulté de débugger un programme de 5000 lignes avec des variables "caca" "ta_mere" et "roxor2000" absolument non commentées.
Il faut de la justesse en tout.

Pas à moi, mais c'était plus qu'insinué.

@KsassPeuk : je suis d'accord avec toi, et c'est comme ça que je procède lorsque j'écris du code. Malheureusement, l'enseignant de cette année a la fâcheuse tendance à surgir derrière nous au mauvais moment.

@Loute : la « réflexion » sur le projet est quasi inexistante dans cette série de TP. En effet, la structure et les algorithmes sont donnés (et sont assez simples). Du coup, il n'y a qu'à coder et c'est prévu pour (on a juste le temps de finir). Le projet sur lequel on doit vraiment réfléchir vient plus tard (on doit écrire tout un programme de résolution, de A à Z).

make install: le type même qui kissikonè pitoyable. Il a fait ses preuves sur de nombreux forums.

Apparemment, c'est pas le même "Make Install" que HFR.

J'espère pour celui de HFR.

J'avoue me poser des questions. Niveau pebkac il s'y connaît manifestement.

ROB : C'est ce que faisait Nikola Tesla, et ça ne lui a pas fait que du bien...

C'est pour ça qu'il faut pouvoir mettre des commentaires en favori.

Si tu codes avec notepad, je suis d'accord.

Personnellement, avant d'utiliser un IDE, la première chose que je fais est de vérifier s'il y a une fonction d'auto-complétion efficace. Et je fais des variables et fonctions avec des noms à rallonge, par exemple (véridique) : stackOfOperatorTokens.