"J'ai passé plus de 3h devant Eclipse et ça m'a un peu fatigué^^ "
Un jour tu passeras comme moi 8h par jour devant Eclipse

Bonne soirée ^^ (au fait je suis belge, ça m'a donné envie de t'aider, vu que tu es néerlandophone :p )

Un belge xD
Je n'y aurais jamais pensé ! XD

Et je ne crois pas que je passerais 8h sur un jour pour Eclipse .
L'informatique est ma passion, et non mon métier, qui lui est l'électricité .

Bonbon, ouvrons Eclipse et codons notre multilanguage !

Bon courage
Quand tu auras terminé, tu peux nous montrer ton code ? Ainsi on pourra te donner notre avis

Oui, mais je code toujours très cochement^^
J'essaie de m'améliorer

Après une petite heure j'ai enfin compris le fonctionnement de Properties ! Yeah

C'est bien parce que ce que tu vois, ça te servira sûrement encore à l'avenir

Si je ne pose pas de questions, ce n'est pas car je maîtrise les XML, mais avant d'instaurer le multlanguage je préfère mettre mon code à claire et mettre du javadoc et peut-être un petit uml je posterais le tout ici !

J'aimerais avoir le plus de critique possible, car seul dans mon petit coin, sans prof, ce n'est pas très simple à voir où sont mes erreurs !

Si tu veux des critiques, montre nous ton code , tu peux le poster sur le site pastebin par exemple. Ou, s'il y a beaucoup de fichiers, tu peux uploader ton projet en ligne sur un site d'hébergement / upload de fichiers.

Perso, à l'époque j'utilisais un fichier Excel avec 4 colonnes

nom du message - Francais - Allemand - Anglais

et j'avais fabriqué un petit générateur de code avec freemarker qui me générait mes 3 fichiers ressources de langue ainsi qu'une classe Translation ayant des méthodes correspondant au nomDuMessage() avec en commentaire la chaîne française. Très pratiquer dans les IDE qui ont l'affichage du commentaire dans l'intellisense.

Ainsi pas de risque de se gourrer dans le nom du message, les traducteurs pouvaient bosser sur le fichier excel sans me faire chier et tout était bien centralisé.

Ça m'intéresse ce fichier Excel.

Dans mes souvenirs il existait une classe en Java qui permettait de lire les fichiers Excel non ?

Mais Silvermo a dit que les fichiers XML étaient très utilisées, eux aussi. Ça serait peut-être le bon moment pour apprendre le XML ? Mais les fichiers Excel me sembles plus facile à manier^^

Je posterais mon code ici dès que j'ai le temps et que le code me conviendrait, par contre j'ai une bonne 20ène de classes différentes répartit dans pas mal de packages différents. Je posterais donc mon projet Eclipse en entier

Dans une archive, bien faite, au bon format ... déjà eu des soucis quand on a demandé des archives de projet -_-'

Le fichier JAR de mon projet
https://rapidshare.com/files/3814123890/Elec_21-04_.jar

Les sources de mon projet(j'ai mit tout mon fichier Eclipse, parce que je suis un gros cochon et j'ai codé n'importe comment et j'ai honte de mes packages )
https://rapidshare.com/fifiles/31595834/Electricité.rar

J'aimerais avoir le plus de critiques si possible, je sais que j'ai encore énormément à apprendre et je vois de moi-même mes fautes, et quand je les corriges je refais des fautes... J'aimerais avoir de l'aide

Cordialement,
MDA !

La localisation, ça se fait avec l'i18n et pas en bricolant. Comme l'a dit un intervenant sur ce thread, ça dépasse le cadre de la simple substitution de chaînes. Pour un travail propre, mieux vaut utiliser les API fournies par le langage. Surtout que c'est plutôt facile en Java.

http://docs.oracle.com/jaavase/tutorial/i18n/index.html

Bonjour MDA-Hack :
Première chose :p , n'oublie pas que ton code peut être lu par d'autres, et comme c'est le cas maintenant, je le lis, et je remarque que les packages, les classes et variables etc sont souvent en néerlandais. Ce qui complique fort la compréhension du code.

En programmation, l'anglais est communément utilisé pour le code et la doc. Essaie de t'y tenir ^^
Je vois qu'il y a des commentaires en néerlandais, et en français. Essaie d'uniformiser, et en anglais évidemment !

Pour ta classe GetTaal, je pense que tu as pris un mauvais départ, tu ne devrais pas créer une méthode pour chaque chaîne de caractères. Tu devrais plutôt appeler une seule méthode, et passer en paramètre un identifiant, et cette méthode te retournerait le texte en fonction de l'identifiant.

D'une manière générale, évite également d'utiliser une seule lettre pour nommer les instances de tes classes.
Par exemple, dans la classe SetSpanning :

private Spanning u;

Il faudrait plutôt avoir ceci :
private Spanning spanning;

Ce qui est plus clair, quand tu es quelque part dans le code, pour savoir avec quel objet tu travailles.

Je remarque, dans les commentaires de la classe MenuBestand, que tu décris ce que fait le code :

//Déclarations des actions
ActionSluiten actionSluiten = new ActionSluiten();
ActionWissen actionWissen = new ActionWissen();
MenuTaal menuTaal = new MenuTaal();

//Ajouts d'items
add(menuTaal);
add(itemVerwijderen);
add(itemSluiten);

Tout programmeur sait que ceci est une déclaration :
ActionSluiten actionSluiten = new ActionSluiten();
et que ceci est un ajout :
add(menuTaal);

Tu dois essayer de commenter uniquement ce qu'il est utile de préciser.
C'est le cas dans d'autres classes également, par exemple MenuStroom, et sûrement d'autres (MenuWeerstand, MenuVermogen... )

En parlant de ces classes (MenuStroom, MenuWeerstand, MenuVermoogen)
Tu remarqueras que leur code est très similaire. Un programmeur efficace n'est pas celui qui crée le plus de classes, mais celui qui arrive à ne pas écrire quatre fois la même chose.

Bref, s'il faut choisir entre ajouter 10.000 lignes de code ou en supprimer 10.000, pour arriver au même résultat, celui qui en enlève 10.000 est sûrement plus efficace dans sa manière de travailler.

Je remarque également, dans ton projet, que de nombreuses lignes de code sont mises en commentaire.
On appelle celà du code mort, et dans les projets, ça a tendance à augmenter de plus en plus si on n'y prête pas garde.
Essaie d'éviter de laisser trainer des bouts de code qui ne font rien.

Il y a d'autres choses à améliorer dans ton code, par exemple éviter de créer des méthodes qui ne font que retourner une chaîne de caractère, par exemple ceci, dans la classe Eenheid :

public String getEenheid() {
return "Ik ben een gewone Eenheid";
}

D'ailleurs cette méthode ne semble appelée nulle part dans ton projet, que fait-elle ?

Bref, quelques petites choses à faire pour la prochaine fois :

1) Utiliser de l'anglais au lieu du français et néerlandais pour tout le code (classes, noms de variables, commentaires)
2) Eviter d'utiliser des noms de variables / classes trop courts. En fait, la longueur du nom d'une variable devrait être proportionnelle à la portée de la variable.
Par exemple, si tu crées une variable qui est souvent utilisée, il faut un nom plus précis et donc plus complet que si elle est utilisée une seule fois dans une boucle ou dans une méthode.

Exemple de variable ayant une portée réduite, la variable i dans le cas ci-dessous :

for (int i = 0; i<10; i++) {
...
}

ici, la variable i a une portée limitée, puisque en dehors de la boucle for, la variable i n'existe plus. Elle n'existe que dans la boucle for.

Exemple d'une variable ayant une grande portée : la variable p, dans ta classe Vermogen.

Elle est utilisée dans 8 méthodes différentes de la classe. Elle peut être modifiée, lue à de nombreux endroits dans le code. Elle a donc une grande portée. Donc elle devrait avoir un nom plus précis.

3) Eviter d'écrire plusieurs fois le même code. Quand seules les noms de variables ou les valeurs changent alors que le comportement du code est similaire ou identique, alors il faut définir une seule fois le comportement du code, et passer en paramètre les valeurs qui changent. C'est une solution, mais il y en a d'autres

4) Eviter les commentaires inutiles
5) Eviter le code mort

Remarque : i18n signifie internationalisation et l10n signifie "localization".
Ce sont 2 termes utilisés couramment pour écrire plus vite. 18 et 10 sont simplement le nombre de lettres entre la premier et la dernière lettre.

C'est con, mais quand on connaît pas la signification, on cherche longtemps.

Alors je remercie déjà ceux qui m'ont répondu

Raspberry-Pi Voir le profil de Raspberry-Pi Merci pour le lien, je savais bien que j'étais mal parti, et Silvermo confirme que je suis mal parti, j'irais voir ça bientôt.

Silvermo Merci pour la critique, mais tu as mal compris 2/3 choses dans mon code^^

-Pour le nom des packages, classes qui sont en néerlandais, c'est parce que j'ai commencé à codé mes classes en néerlandais, car les termes électrique sont plus facile en néerlandais pour moi. Sinon t'en fais pas dans mes autres projets j'éssaie de faire tout en anglais, sauf les commentaires, aussi pour ma facilité en anglais.

-GetTaal je suis totalement d'accord avec toi et Raspberry, je me suis totalement gourré sur ça. Première fois que je tente ça, et c'est un échec, mais j'apprends beaucoup de mes échecs

-Pour mes instances à une seule lettre, c'est car en électricité le "u" représente la tension, comme le "i" représente le courant, et ainsi de suite. C'est pour ça que je m'en sors très bien et que chaque personne ayant une notion en électricité devrait s'y retrouver que j'ai mit une seule lettre. Sinon je ne mets jamais une seule lettre pour mes instances, je mets toujours quelque chose de très compréhensif, du genre menuItemHelp, nbEnfants, ... . Sauf bien sûr dans mes boucles for comme tu l'as démontré.

-Pour les commentaires inutile du genre déclaration, ajout, j'aime bien avoir une petite ligne de commentaire au dessus de mes lignes de code, même si ce n'est qu'une simple déclaration ou instantiation. C'est mon petit péché mignon .

-J'avoue que je fais beaucoup de doublons dans mes codes... Pourtant j'ai déjà réglé en grande partie mon code et mes doublons, heureusement que j'ai pas mit mon code au début de la semaine, je me serrais fait taper les doits^^
Je cherche toujours une manière pour régler ce problème de doublon, qui m'énerve vraiment beaucoup ! Mais j'ai aussi vu que dans pas mal de sources, les programmeurs créent tellement de classes, à la place de les mettre en un, que j'ai cru que c'était un genre de convention en Java.

-Le code mort j'ai peur de le supprimer car si j'en ai besoin dans le futur...

-Pour les méthodes inutiles, j'aimerais un peu profiter du polymorphisme, et j'éssaie de faire un peu de tout et n'importe quoi. Je suis un débutant je précise cela fait qu'une petite année que je suis occupé à ce language.

Je te remercie déjà d'avoir mit autant de temps pour m'avoir répondu c'est très gentil de toi !

En regardant rapidement, tu as aussi la méthode statique arrondi qui est déclarée 4 fois et qui fait 4 fois la même chose.
Tes interfaces sont déclarées, mais inutilisées (tu n'as aucun objet du type de l'interface), et de plus, selon ce que me signale mon IDE, toutes les définitions des méthodes sont les mêmes. Pour ces points, autant passer par une classe abstraite factorisant le code je pense.

Simple conseil : pour toute les chaînes statiques (String qui te servent de clé), je te conseil de les mettre en static final et de les utiliser.
Ainsi, aucun risque de faute de frappe, et dans le cas où il faut changer le comportement, ça va plus vite.

Bunyan Tu m'as appris un truc :D Et moi qui pensait que c'était juste un énième sigle à la con...

"Simple conseil : pour toute les chaînes statiques (String qui te servent de clé), je te conseil de les mettre en static final et de les utiliser.
Ainsi, aucun risque de faute de frappe, et dans le cas où il faut changer le comportement, ça va plus vite."
je plussoie

"-Pour le nom des packages, classes qui sont en néerlandais, c'est parce que j'ai commencé à codé mes classes en néerlandais, car les termes électrique sont plus facile en néerlandais pour moi."
C'est cependant une assez mauvaise pratique, il faut prendre l'habitude de programmer comme si ton code allait être repris par quelqu'un qui ne te connait pas, et ne parle pas ta langue. Ainsi tu te forces à enlever toute culture propre de ton code.

"
-Pour mes instances à une seule lettre, c'est car en électricité le "u" représente la tension, comme le "i" représente le courant, et ainsi de suite. C'est pour ça que je m'en sors très bien et que chaque personne ayant une notion en électricité devrait s'y retrouver que j'ai mit une seule lettre"
Soit, cela peut être accepté à condition que ce soient des termes qui soient couramment utilisés dans les applications que toi ou tes collègues développent, dans le cas contraire il faudra changer ça. Ou au moins rajouter des commentaires dans la classe, qui indiquent le rôle des variables (dans ce cas ci, des commentaires sont utiles, car le nom de la variable seule ne donne aucune indication sur son rôle, sauf pour quelqu'un qui s'y connaît... )

"-Pour les commentaires inutile du genre déclaration, ajout, j'aime bien avoir une petite ligne de commentaire au dessus de mes lignes de code, même si ce n'est qu'une simple déclaration ou instantiation. C'est mon petit péché mignon .
"
C'est à éviter, car une ligne de commentaire inutile, c'est une ligne de commentaire à maintenir en plus du code !
Si un jour tu modifies beaucoup de code, et que tu insères du code en dessous du commentaire, le commentaire ne sera plus à la bonne place, et pourrait ne plus être valide par rapport au code.
Une règle de bonne pratique est d'éviter les commentaires le plus possible, car normalement le code doit être assez clair pour que les commentaires soient inutiles.

"-Le code mort j'ai peur de le supprimer car si j'en ai besoin dans le futur... "
La solution à ce problème est d'utiliser un outil de gestion de versions, comme Git, SVN, etc. Ce sont des outils qui te permettent de garder l'historique de toutes les versions "committées" de ton code. Ainsi, tu peux revenir en arrière pour retrouver un bout de code dont tu avais besoin.

Mais si vraiment tu penses avoir besoin de ton code un jour, demande toi pourquoi, et regarde si ce n'est pas possible de rendre ce code vivant, mais mis à l'écart, dans une fonction, ou dans une condition.

Voilà voilà

Bunyan Merci je tâcherai de mettre toutes mes chaînes static, en static final
Et pour ce qui est de mes interfaces, je le sais bien, mais je cherche encore une manière à les utiliser ! Et la méthode arrondi(c/c du sdz je précise ) je changerais ça aussi !

Silvermo Tu as totalement raison que je prends de dire que je prends une mauvais habitude en mettant tous en néerlandais ou en français, tout comme mes instances à lettre unique. Mais j'ai préféré le faire à ma manière sur ce projet^^
Si jamais tu me revois en train de faire ça sur un autre projet, tape-moi les doigts

On dirait aussi que tu détestes les commentaires, as-tu eu beaucoup de problème à cause de la surcharge de lignes dû aux commentaires ? Car pour moi ça me semble intéressent les commentaires. Et ce qui concerne les outils de gestion de versions, j'irais faire un tour sur google ;-)

J'ai beaucoup à rechercher moi, je vous laisse et vous dit peut-être à la prochaine en vous remerciant beaucoup pour votre aide !

MDA.

"On dirait aussi que tu détestes les commentaires, as-tu eu beaucoup de problème à cause de la surcharge de lignes dû aux commentaires ? Car pour moi ça me semble intéressent les commentaires"
Dans de gros projets, les commentaires peuvent souvent être à des kilomètres du code qu'ils commentaient à l'origine.
Laisser les commentaire se multiplier dans le code provoque une certaine paresse à écrire un code propre et compris par tous. C'est un peu comme une justification d'un mauvais code.
Quand un code est bien écrit, il est compris par tous, et donc le commentaire n'apporte rien. Le but est justement d'arriver à cet état des choses, avoir un code sans commentaires inutiles.

Par exemple :

// Cette fonction additionne deux entiers et retourne la somme
public int grrBrrrrZZZ(int brZZrr, int zg) {
return brZZrr + zg;
}

Ici, s'il n'y avait pas de commentaire, on serait obligé de lire le code pour comprendre ce que fait la fonction.

Mais si on améliore le code :

// Cette fonction additionne deux entiers et retourne la somme
public int sum(int a, int b) {
return a + b;
}

Le code est alors aussi clair que le commentaire, et le nom de la fonction suffit à lui tout seul pour ne plus avoir besoin de commentaire.

Il faut considérer que le commentaire est à éviter PARCE QUE il oblige le développeur à perdre du temps à le lire, alors que le développeur doit pouvoir naviguer clairement dans le code et comprendre ce qu'il fait sans perdre de temps.

Un programme qui voit un commentaire se sentira obligé de le lire.

Mais un programmeur met moins de temps à lire le nom d'une fonction qu'à lire un commentaire, il faut donc privilégier les noms de fonction clairs, les noms de variables clairs, et éviter les commentaires.