Comment décidez-vous des documentations de fonction API à lire et comment sérieusement? [fermé]

Question

Supposons que vous écriviez ou mainteniez un élément de code utilisant une API avec laquelle vous n'êtes pas familier.

Comment décidez-vous s'il faut lire la documentation d'une certaine cible d'appel et combien de temps passer à la lire? Comment décidez-vous de ne pas le lire?

(Supposons que vous puissiez le lire en ouvrant la documentation HTML, en inspectant le code source ou en utilisant le mécanisme de survol dans l'EDI).

Answer 1

Idéalement, vous devriez en lire tout , mais nous savons que c'est pénible… vous savez. Ce que je fais normalement dans ces cas (et je l’ai souvent fait pendant que je travaillais en tant que pigiste), c’est peser certains facteurs et, en fonction du résultat, je lis la documentation.

Facteurs qui me disent que je ne devrais pas lire la documentation:

• Ce que la fonction fait est facile à deviner à partir du nom.
• Cela n’est pas pertinent pour le code que je gère: par exemple, vous vérifiez comment certains codes suppriment des fichiers et vous disposez d’une fonction qui effectue bien sûr la mise à jour de l’UI. Vous ne vous souciez pas de ça pour l'instant.
• Si débogage: la fonction n'a pas changé l'état du programme d'une manière significative pour la tâche à accomplir. Comme auparavant, vous ne voulez pas savoir ce que fait SetOverlayIcon si vous déboguez le code de suppression car il meurt avec une erreur du système de fichiers.
• L'API est simplement un cas particulier d'une API que vous connaissez déjà et vous pouvez deviner quel est le cas particulier et ce que font les arguments spéciaux (le cas échéant). Par exemple, supposons que vous ayez WriteToFile (nom de fichier de la chaîne) et WriteToFile (nom de la chaîne, remplacement booléen).

Bien sûr, tout dépend du contexte, donc même ces règles ont des exceptions.