Création de standards - Page 1

Pkoi y'en a pas encore vraiment eut de fait ? y'a bien le zip qui est a peu pres passé mais c'est tout.

donc voilà le sondage:
[sondage=12893]

voula

c sur, c plus pratique, mais il fo que ça convienne à tout le monde, sinon y aura toujours des c** qui vont développer leur propre format dans leur coin

-

Les standard, c'est une bonne chose je penses... quand ils sont parfaits...
Par exemple, sur TI, la norme de Kevin pour les TSR est une bonne chose...
Mais si le "standard" n'est pas nikel, iil y aura forcément des gens qui refuseront de l'utiliser, pour utiliser leur propre technique.

ça peut être une bonne chose pour les utilisateurs, mais c vraiment frustrant pour les programmeurs...

Il faudrait déjà définir dans quels domaines il y a besoin de standards.

compression, images, textes ...

multitaches....

si le standard est bien conçu (cf post 3) ce n'est nullement frustrant pour le programmeur.
Le standard de Kevin (c'est le seul exemple de standard que je parvienne à trouver) est pas mal, et, en temps que programmeur, il ne me pose aucun pb.

tout à fait d'accord, squale : bien fait, les standards ne sont que des moyens de mieux canaliser ses idées.

comme guilc a dit, il faut que tout le monde soit d'accord sur le standard...en particulier pour le hardware...

kler ... c pour ca que j'ai un peu lancé le sujet ...

si y'en a qui ont un peu de tps pour y reflechir (moi je suis assez pris avec les concours) ben .. balancez des idées

-

oué, poru la compression, pphd a commencé uen version de LZ(W?) donc faudrait lui demander comment est son fichier compressé pis hop fichier compressible

sinon, il pourrait peut-etre le faire en nostub

Nan. Pas de nostub.

-

Le probleme des standard, c'est que certaines personnes sont bornées d'esprit (que nostub , ou que Stub...) ce qui rend la tache impossible.. dons si le compresseur de pphd n'est pas nostub, il faudra faire un autre format qui sera presenté en stub et nostub ....

Perso, je penses qu'il pourrait être pratique de définir une sorte de "standard" concernant les codes sources en C, du moins pour ceux qui sont ammenés à être distribués...

Etant donné le tutorial que j'ai écrit, je suis souvent ammené à recevoir des mails accompagnés de codes sources... et certains sont particulièrement difficiles à comprendre à cause de ce que je considère (attention : avis perso !) comme des absurdités... (par exemples, des variables nommées var1, var2, var3, var4 et ainsi de suite !!!)
De même, une partie des programmes réalisés en C sont open-source... et une partie de ceux-ci sont difficilement compréhensible, je trouve. Ce n'est pas pour cela qu'il sont innefficaces, bien au contraire ! Mais certaines pseudo-normes seraient bien pratiques...

Donc, je serait d'avis qu'il faudrait qu'un groupe de programmeurs C se lance dans l'étude d'une norme possible...
Elle pourrait porter, dans une première version, sur les noms de variables, puis s'élargir sur d'autres choses...

Un exemple POSSIBLE serait quelque chose comme ça :
Pour les variables de type HANDLE, précéder le nom de H_
Pour les variables de type SYM_ENTRY, précéder le nom de SE_
Pour les variables de type short, précéder le nom de S_
pour les variables de type unsigned short, précéder le nom de US_

Pour les types définis par le codeur (avec typedef, par exemple), précéder de T_

Des "règles" (ou plutôt, des habitudes) existent comme ça chez les programmeurs C++ je crois, pour la programmation en C++ sous Windows... et c'est clair que ça facilite la lecture de sources...

Ce type de chose se retrouve, par exemple, dans les fonctions de TIGCC concernant la status line,qui sont toutes précédées de ST_ !


Naturellement, chacun serait libre d'utiliser ou non ce type de norme, de la même façon que chacun est libre de mettre son prog en open-source ou non...


Voila, j'attend des réactions...
Si certains ici sont interessés...


/me propose le commité de normalisation TI-C-v1...

mouais, imposer des débuts obligatories, c'ets vrai que c'ets bien, mais c'est plutôt chiant...
Mais si c'est adopté, je ne suis pas contre.

je fais déjà ça, mais c pas les mêmes débuts...

pour les programmes en C je précede tous les noms de variable de 3 lettres (SYM_ENTRY -> sym_, unsigned / signed int -> int_, char -> chr_, SCR_RECT -> scr_, etc...)
et pour les programmes en basic je met qu'une lettre parceque bon... 8 c pas beaucoup alors si c pour en virer la moitié

Enfin tout ça pour dire que le système de Squale est très bien, en tout cas ça m'interesse vu que c à peu près celui que j'utilise

c'est plutôt chiant pour le programmeur au début, quand il n'a pas l'habitude...
mais mettre das le readme (si le prog est open-source) que le code est au standard de la norme TI-C-vX.Y peut permettre aux débuttants de l'adopter dès qu'ils commenceront à coder.

Perso, je peux modifier mon tuto pour le rendre conforme à d'évetuelles normes si celles-ci sont acceptées.

Je sais que ce sera dur pour le programmeur qui prog depuis longtemps de s'y mettre.... mais si les nouveaux en prog C adoptent ce standard dès qu'ils commencent à coder en C, cela sera pour eux un réflexe... qui facilitera bcp les choses...

post croisé...

Bob> c bon, j'ai vu ton post.

COmme l'a un jour dit un de mes profs (y'en a un qui fait je sais plus trop quoi dans un commité IEEE), qd on veut un standard, c'est bine beau, tous ceux du commité sont d'accord pour un standard... mais chacun veut imposer le sien...
Le pb, c'est de trouver les compromis...

Je suis d'avis que une lettre (deux au max) + le _ pour séparer c pas mal, et qu'il ne faut pas faire plus (ce serait trop long)

De plus, mettre en majuscule permettait de montrer qu'il s'agit de quelque chose de spécial...
cela dit, avant d'avancer plus mes idées, je veux avoir plus d'avis...

bah c l'idée qui est bien, le nombre de lettre avec l'underscore on s'en tape un peu...
j'aurais une préference pour mettre toujours le même nombre de lettre (pas 1 pour certaines variables et 2 pour d'autres) mais c pas très important...

si tu met toujours le même nombre de lettre, comment veux-tu faire la différence entre signés et non signé (par exemple)

Mais, comme je l'ai dit, avant de commencer à geueler ds tous les sens pr se mettre d'accord, attendons qu'on soit plus nombreux à penser que c une bonne idée.
Notament, je voudrais savoir si ça sera utilisé ou non, si jamais ça se fait...

D'ailleurs, je sens qu'un petit sondage dans la rubrique C s'imposera.
(mais pas maintenant !!! cf le paragaphe plus haut)

je suis entierement d'accord avec les conventions
le C connais pas trop mais en VB je les mets tjrs sinon après je me perds car j'utilise plusieurs objets avec le même nom ou presque

je pense que ca augmenterait la lisibilité et faciliterait la comprehension par tous

personnellement, en regardant mes sources après coup - genre quand je vais me remettre à mon tableau de Karnaugh... -, je sais ce que sont les variables, mais comme dit, si on décide d'un standard à ce niveau, je suis près à l'adopter. Je pense que les abréviations de squale sont pas mal du tout. On rajoute naturellement les constantes en majuscules, je pense ?

pr ca par exemple, suffit de picker USHORT ...

sinon, je pense pas que Nostub vs. Stub soit un probleme, pour le programme de pphd, suffit qu'il dise comment il structure son fichier compressé pis apre, on se demerde pour en faire un en nostub

bon, je vois que vous commencez a être un peu inspiré par ca, y'a d'ailleurs de tres bonnes idées qui traines .. allez .. commencez a en proposer

Par pitié, pas de noms de types en début de noms de variables! Ça s'appelle "notation hongroise", ça a été inventé par un programmeur hongrois chez M$, et il n'y a pratiquement que M$ qui utilise ça. Tous les bons programmeurs ont horreur de cette notation.

n'empeche c'est pratique quand ta un gros programme Kevin...

ta fait un sondage sur combien de programmeur mondiaux pour savoir qu'ils ont horreur de ca ?. [nosmile]