striiiiiiiiiiiiiiing - Page 47

Squalyl : non mais tu te crois malin avec tes noms de classes mi-coréens ?

bah ça aurait pu être russe ou thailandais mais j'ai qu'un seul clavier non latin configuré

(ça peut être une bonne méthode d'obfuscation )

Bon je regarde ça quand j aurai le temps. Ie peut être ce we

(Zut vous avez démasqué mon énorme troll pas trop déguisé sur Java… Enfin il me semblait quand même qu'il fallait absolument que les noms de classes commencent par une majuscule, mais j'ai peut-être confondu avec nom de classe == nom de fichier.)
./1382 > Ça prenait que 30sec d'en ajouter d'autres

La seule contrainte est que les fichiers ".java" doit avoir le même nom que la classe principale qu'il contiennent.
Donc si ton nom de fichier commençait par une majuscule ta classe le devait aussi.

(et doit être dans le dossier kivabien pour le package)

En C/C++, il n'y a pas de convention universelle pour les noms (alors qu'en Java il y en a une, mais le langage ne la fait pas respecter).

La convention de nommage utilisée à travers Qt et KDE ressemble à celle du Java: UpperCamelCase pour les noms de namespaces et de classes, lowerCamelCase pour les noms de variables et de fonctions ou méthodes, usage de l'underscore fortement déconseillé, sauf dans des cas comme m_foo pour les membres privés.

je voudrais bien voir la doc officielle de nommage en java.

Ca reste une proposition de standard, pas une obligation, non ?

Oui, bien sûr, quand tu codes pour toi tu fais ce que tu veux

Oui, enfin même pour soi c'est une mauvaise idée de s'en écarter (pour le nommage en tout cas), car il y a les appels au framework qui, eux, sont écrits selon cette convention.

Et puis quand tu n'as pas encore d'habitude, autant prendre la bonne directement

j'aime pas leur méthode </utile>

Les recommandations Microsoft pour .Net préconisent UpperCamelCase pour tout ce qui est classes et leurs membres non-privés, mais lowerCamelCase pour les paramètres de fonction et variables locales. Franchement, je trouve ça un peu bof-bof pour les variables membres.

Par contre, elles préconisent de préfixer toutes les interfaces de I majuscule, et je suis 100% d'accord avec ça.

et dans mozilla c'est tout préfixé par NSImachin #trilisible#

Ou aussi ns (en minuscules) et parfois Ns

Préfixé de I? Vois pas bien l'intérêt ni ce que ça signifie...

Je pense que ça signifie Interface, mais je me trompe peut-être

Oui, j'ai toujours fait ça que ça soit en Pascal objet/Delphi, en PHP ou en Java, perso.

Ouep, comme certains en C++ préfixent leurs classes de C comme Classe. (chez Microsoft justement ^^)

et après ça fait des DWORD dwValue, des LPTSTR lptoto, etc

Flanker (./1398) :
Je pense que ça signifie Interface, mais je me trompe peut-être

INon, Ic'est Ipour Icopier iApple iAvec iSes iProduits.

squalyl (./1401) :
et après ça fait des DWORD dwValue, des LPTSTR lptoto, etc

Et des char *lpcstrmagyarorszagasdfghFoo.

et des QGraphicsSceneContextMenuEvent, QStyleOptionTabWidgetFrameV2, QDesignerCustomWidgetCollectionInterface, QDesignerDynamicPropertySheetExtension, QXmlStreamNamespaceDeclaration.....

Flanker (./1398) :
Je pense que ça signifie Interface, mais je me trompe peut-être

Ho putain j'avais lu variables membres A ce moment là je suis bien d'accord ^^
Par contre le fait de préfixer les classes de C je ne suis pas fan, surtout si la classe est considérée comme un type de données abstrait. Je déteste aussi le fait de faire m_* pour les variables membres (d'ailleurs dans un bon IDE comme Eclipse les variables membres apparaissent toutes seules en couleur, donc c'est du gaspillage de le rappeler...). A la limite g_* pour les variables globales, vu que je ne m'en sers pas, sauf en C où elles sont de toute façon statiques donc on s'en fout de la pollution du namespace
Ce qui est marrant c'est qu'au contraire de ma formation plus le temps va plus je programme comme un matheux; il vaut mieux un code compact et qui montre tout seul ce qu'il fait, avec des noms de variables clairs et un sens (pattern) qu'un truc énorme illisible au premier abord qui nécessite de lire tous les commentaires et faire une synthèse globale pour faire un lien avec quelque chose qu'on connaîtrait.

Les m_, ça évite les conflits de noms à certains endroits, par exemple avec les paramètres du constructeur.

Ben tu rajoutes le this. Le constructeur et les setters sont justement les seuls cas où le code n'a pas besoin d'être "beau" puisqu'il est trivial. Amocher tout le reste du code pour simplifier 3 lignes qui parlent déjà d'elles mêmes... perso bof ^^
(En plus le this->val = val a plus de chance d'être compris tout de suite que m_val = val, qui pourrait aussi être pVal = val, lvVal = val ou autres selon l'entreprise de plus à mon sens l'affectation des variables locales -> membres devrait être l'affaire du langage par un simple appel... dommage qu'aucun parmi les connus ne le propose :/)

(T'es pas obligé d'utiliser des getter et setter en interne dans ta classe)

Heu? En fait tu es souvent obligé d'avoir des setters quand même. Et l'histoire ce serait de remplacer:
this->val = val;
par:
m_val = val;
Dans ces setters justement. Perso je verrais de toute façon plutôt un élément du langage genre dans le constructeur:

class Test is
    int val1, val2;

    @synthesizeMemberAssignment
    public Test(int val1, int val2) {}
}

Mais ce n'est pas possible dans aucun des langages dont on parle sans une grosse bidouille. Là où c'est par contre plus discutable, c'est pour les getters. De mémoire, il n'y a que le Java et l'Obj-C qui permettent de créer des méthodes (getters) du même nom qu'une variable. Pour les autres on est emmerdé, donc le préfixe peut se justifier. Mais c'est dommage parce que c'est à cause d'une limitation du langage

T'as oublié le C# (et autres langages .NET plus généralement) avec les propriétés.
toto (champ) => Toto (propriété). Getter et setter ont le "même nom" ! (Enfin, pas en interne, mais ça osef)