Re: Non, mais ...

Euh… sur tes 4 points, les deux qui ne sont pas normales me semblent être une bonne pratique. C'est un peu comme si tu disais qu'avec Java t'es obligé (je ne suis même plus sûr de savoir si c'est une obligation ou de si ça pète juste un warning) de déclarer une seules classe par fichier (sans compter les hinners classes), ça me semble être une bonne pratique.

C'est sans doute une bonne pratique en Java (on y est un peu obligé), mais en C++ c'est totalement artificiel, vu que la bibliothèque standard ne respecte pas cette convention, et heureusement. Personne ne s'amuserait à créer un fichier pour y mettre uniquement

# include <implementation_detail/binary_operator>
namespace std {
 template <typename T>
 struct less : std::__implementation_detail::binary_operator<bool, T,T> {
 bool operator()(const T& a, const T& b) const { return a < b; }
 };
}

et à faire ça 6 fois pour les opérateurs relationnels sans parler de la centaines de classes/fonctions de la bibliothèque standard qui s'implémentent en moins de dix lignes ou qui ne sont que des alias/typedef.

Non, la bonne pratique en C++ c'est d'activer son cerveau et de distinguer les grosses classes/fonctions à mettre dans un fichier séparé des petites classes/fonctions que l'on peut regrouper intelligemment dans un seul fichier si ça a un sens de les mettre ensemble. Sachant que, bien entendu, les petites classes sont préférables aux grosses (il faut mieux casser des grosses classes pour les remplacer par un typedef d'amas de petites classes templates).

Pareil pour les namespaces; La bibliothèque standard ne met pas tout ses includes dans std/. Et les namespaces de boost ne correspondent pas forcement aux répertoires dans lequel se trouvent les includes.

Enfin bref: "Apply common sense".

Pour comparer avec le C++, tu dois remplacer Toto par TotoProvider et le package 2 fois chacun (une fois pour l'entête et une fois pour le corps). Puis changer les directives d'include conditionnelle dans le corps (à 2 endroits au moins, personnellement je préfère aussi le mettre en commentaire à la suite de la fin du if). Pareil je parle pour une classe qui n'est pas utilisée.

C'est certes plus de boulot, mais toutes ces opérations impliquent uniquement d'utiliser son éditeur de texte. C'est beaucoup plus confortable que de devoir créer un répertoire et y déplacer ses fichiers.

Et tu te retrouve avec un dossier src qui contient en vrac différents namespace.

Mauvaise idée, vaut mieux faire le contraire: les namespaces en C++ ne servent pas à catégoriser les classes ou a limiter leur visibilité comme en Java, mais uniquement à éviter les conflits de noms. Utiliser un ou deux namespaces par projet est suffisant (exemple: la bibliothèque standard, encore une fois…), il n'y a pas de raison d'en avoir plus si tu ne compte pas avoir de conflits de noms (les principaux types de conflits étant ceux liés à la recherche dépendant des paramètres). Et même lorsque tu à besoin d'un namespace, tu peux toujours le planquer en utilisant un typedef ou autre.

Absolument rien ne t'empêche de simplement séparer tes fichiers dans des répertoires différents en gardant le même namespace.

Les imports à « grains fin » (tu peut utiliser des wildcard, mais je n'aime pas)

Le compilo non plus, ça augmente ses temps de compilations, mais pas autant qu'une compilation C++.

permettent de voir ce qui est utilisé ou non dans la classe. Là encore à comparer au C++, il va falloir ajouter des includes qui vont bien, les modifier ou pas va dépendre de comment tu organise tes classes.

Si tu sépare des classes intelligemment, tu n'a pas plus de problème qu'avec des wilcards en Java. Parce que les imports à grain fin, en plus de rentre inintelligible la liste de ce que tu utilise, t'oblige à la maintenir avec un IDE. Une liste d'include est plus courte et mieux catégorisée.

Tu entends quoi par là ? La javadoc, me paraît tout à fait lisible (et immédiatement à jour par rapport à cppreference ou cplusplus ()j'apprécie beaucoup ces 2 sites là n'est pas la question) qui sont moins à jour et qui, dans le cas de cppreference, se contente de décrire l'API (Java à ce genre de choses). Après je trouve qu'il mange des chose, j'aimerais bien avoir dans la javadoc la complexité de certaines fonctions et indiquer de manière systématique si une méthode est thread-safe ou non.

Gahh, des frames, en 2013. Passons, j'ai pris une classe au hasard: AbstractQueue: http://docs.oracle.com/javase/7/docs/api/java/util/AbstractQueue.html

J'ai :
- de l'information bateau qui m'intéresse pas forcement (savoir de quoi ça hérite, qui l'implémente …) mais qui se trouve au début, donc c'est ce qui s'affichera en premier dans une petite fenêtre
- La doc (normal)
- Les constructeurs/méthodes de la classe avec leur description courtes (normal)
- Un trop bref résumés des méthodes héritées des classes mères, alors que pourtant, elles font partie de l'API.
- Le détail des méthodes, qui prend une place absolument folle.

La plupart des programmeurs Java que je vois préfèrent naviguer dans les méthodes et leur documentations dans leur IDE (ou son autocompléteur de code) que regarder la javadoc. Il y a peut-être une raison. Bizarrement, les IDE ne planquent pas les méthodes héritées, et n'affichent les hiérarchies de classe que dans la doc.

Excuse-moi de revenir à C++, mais c'est le langage le plus proche que je connaisse. Peut être que Objective-C ou un autre langage fait mieux.

Je fais du C++ avec vim. Et j'ai pas absolument besoin de ses fonctionnalités d'IDE les plus avancées (elles ne font qu'augmenter ma productivité). Des windowsiens utilisent des éditeurs plus pauvres comme notepad++ pour des petits projets C/C++, et ça ne semble pas les gêner pas tant que ça.

Mais en Java, je n'ai jamais vu quelqu'un utiliser un IDE moins lourd que netbeans ou eclipse, même pour des petits projets de 3 classes. C'est juste impossible de programmer sans.