Bref, si on te suis, alors le libre n'a *jamais* de problemes de documentation. Si la doc n'est pas la, c'est que l'API / module /...
Tu remarqueras que je n'ai jamais fait le distingo libre/proprio pour le SDK. Alors pourquoi tu met le libre sur la table ?
(je n'ai pris en compte le libre que pour signifier que malgré que ce soit open source, ce n'est pas parce que c'est dans le source qu'on peut utiliser les fonction et ensuite raler sur leur documentation ou non).
Tu remarqueras à nouveau que ce n'est absolument pas ce que j'ai dis.
Et enfin je t'apprendrais que la documentation ne s'arrête pas forcément à une description extrêmement sommaire des fonctions "publiques".
La realite c'est que si cette interface est sujette a changements, la doc est sensee etre la pour le dire justement.
Ce n'est pas en utilisant des termes comme "la réalité" que ca correspond à la réalité.
Si cette interface ne doit vraiment pas etre utilisee, alors elle ne doit tout simplement pas apparaitre dans la doc(ou l'etre avec un gros signe "touche pas").
Tu te contredis en une seule phrase, c'est beau quand même.
"La réalité : la doc doit afficher l'interface et dire qu'elle est sujette à changement" . La phrase d'après "si elle ne doit pas être utilisé, alors elle ne doit pas apparaitre".
Faudrait savoir, soit tu l'indique, soit tu ne l'indique pas...
Bon on va t'apprendre qu'il y a au moins 3 positions de fonction, d'un point de vue hierarchique, qui pourrait expliciter ton exemple :
1°) les fonctions avec une API stable, et censé être publique.
Celles la sont indiqué avec une doc (normalement) à jour, et ne devrait pas (trop) changer.
2°) les fonctions/fonctionnalités en cours de développement (et censé être publique). Celles là peuvent OU PAS être documenté. Si elles sont indiqué, il est important de montrer que la fonction est en cours de developpement et que son interface pourrait changer. Si elles ne sont pas documentée, il ne faut pas aller chercher midi à quatorze heure : elles ne sont pas censée être utilisée publiquement.
3°) les fonctions dites privées , qui ne sont utilisée que pour le fonctionnement interne de l'application, et qui ne sont normalement pas documentée. Elles peuvent toutefois l'être en indiquant clairement leur range (ie privée).
On constate que ton exemple pourrait s'appliquer au point 2 ou au point 3. Le point 2 semble plus approprié vus qu'ils indiquent une volontée de dvp ultérieur.
[^] # Re: HS
Posté par briaeros007 . En réponse au journal Microsoft Windows dans les ordinateurs : un autre argument que la vent liée ?. Évalué à 1.
Tu remarqueras que je n'ai jamais fait le distingo libre/proprio pour le SDK. Alors pourquoi tu met le libre sur la table ?
(je n'ai pris en compte le libre que pour signifier que malgré que ce soit open source, ce n'est pas parce que c'est dans le source qu'on peut utiliser les fonction et ensuite raler sur leur documentation ou non).
Tu remarqueras à nouveau que ce n'est absolument pas ce que j'ai dis.
Et enfin je t'apprendrais que la documentation ne s'arrête pas forcément à une description extrêmement sommaire des fonctions "publiques".
La realite c'est que si cette interface est sujette a changements, la doc est sensee etre la pour le dire justement.
Ce n'est pas en utilisant des termes comme "la réalité" que ca correspond à la réalité.
Si cette interface ne doit vraiment pas etre utilisee, alors elle ne doit tout simplement pas apparaitre dans la doc(ou l'etre avec un gros signe "touche pas").
Tu te contredis en une seule phrase, c'est beau quand même.
"La réalité : la doc doit afficher l'interface et dire qu'elle est sujette à changement" . La phrase d'après "si elle ne doit pas être utilisé, alors elle ne doit pas apparaitre".
Faudrait savoir, soit tu l'indique, soit tu ne l'indique pas...
Bon on va t'apprendre qu'il y a au moins 3 positions de fonction, d'un point de vue hierarchique, qui pourrait expliciter ton exemple :
1°) les fonctions avec une API stable, et censé être publique.
Celles la sont indiqué avec une doc (normalement) à jour, et ne devrait pas (trop) changer.
2°) les fonctions/fonctionnalités en cours de développement (et censé être publique). Celles là peuvent OU PAS être documenté. Si elles sont indiqué, il est important de montrer que la fonction est en cours de developpement et que son interface pourrait changer. Si elles ne sont pas documentée, il ne faut pas aller chercher midi à quatorze heure : elles ne sont pas censée être utilisée publiquement.
3°) les fonctions dites privées , qui ne sont utilisée que pour le fonctionnement interne de l'application, et qui ne sont normalement pas documentée. Elles peuvent toutefois l'être en indiquant clairement leur range (ie privée).
On constate que ton exemple pourrait s'appliquer au point 2 ou au point 3. Le point 2 semble plus approprié vus qu'ils indiquent une volontée de dvp ultérieur.