• # précision des flottants

    Posté par . En réponse au message Une calculatrice multibases écrit en C avec GTK+3.. Évalué à 8.

    Si vous doutez de l'exactitude des calcules j'avoue que le plus gros problèmes a été les chiffres a virgules et la précision d'affichage car un:

    1.0002 + 2

    peut facilement se transformer en:

    3.00019999999999

    suivant la précision choisis dans un appel a sprintf().

    C'est normal, de ne pas avoir de résultats précis quand tu utilises des nombres flottants.
    C'est un sujet que je ne maîtrise personnellement pas, donc je vais éviter de risquer de dire des conneries: wikipedia sera plus instructif que moi.
    Toujours est-il que si tu veux manipuler des nombres à virgule en C, tu es probablement mieux à te trouver ou te faire une lib de manipulation de nombres qui ne se base pas sur float et double.

    Pour ce qui est d'avoir un avis sur ton code, voici le mien, que je vais diviser en 2 parties: objective (défauts du code), subjectifs (conventions, habitudes, etc):

    Objectivement, ton code:

    • est en franglais. Soit tu codes en français, soit tu codes en anglais, mais évites les mélanges, ça ne fait qu'ajouter à la confusion.
    • est monolithique. J'ai l'impression que toute la logique se situe uniquement dans le fichier contenant la fonction main. Tu devrais séparer ton code en unités logiques.
    • se répète trop. J'ai l'impression que tu répètes les mêmes blocs de code pour chaque instantiation de structure (ou est-ce un tableau?) de type, par exemple, "Operation": operande_1, operande_2, result.
    • tes fonctions ne sont pas assez spécialisées. Elles manipulent des données provenant de nombreuses sources, généralement des variables globales.
    • abuse des variables globales. Ces variables sont à éviter: elles rendent le code très difficile à maintenir, car on ne sait jamais quelle fonction à, ou non, des effets de bord et où s'arrêtent ces effets de bord.
    • ne vérifie pas que les appels aux fonctions se sont bien passés, alors qu'il utilise ensuite des structures allouées de cette manière. Attention aux crashs!
    • n'est pas documenté.

    Pour corriger ces problèmes, en gros, il te faut fracturer ton code.
    Pour chaque structure, tu dois implémenter un jeu de fonctions qui seront les seules à manipuler la structure. Ça peut sembler contraignant, mais c'est la seule façon de garder ton code maintenable.
    Ces fonctions ne doivent faire qu'une et une seule chose. Soit elles libèrent des ressources (mémoire, accès fichier, contrôle graphique, je sais pas), soit elles les allouent, soit elles manipulent les membres de la structure. J'ai pour standard personnel de ne jamais dépasser les 50 lignes par fonction. Quand je les dépasse, je réfléchis: ais-je mis un commentaire pour expliquer un bout de code (qui devrais donc être dans une fonction séparée, probablement)? Est-ce que je manipule des données de plus d'une structure au sein de la même fonction? Ais-je des pattern de code qui se ressemblent? Si je peux répondre oui à l'une de ces questions, alors c'est que ma fonction est mauvaise et je la refond. Si je répond oui à toutes, alors je vire directement le code et je recommence. Je n'ai pas peur d'avoir des fonctions qui ne contiennent que 3 lignes.

    Côté subjectif:

    • pas de versionning? Tu devrais t'y mettre, ça fait gagner un temps fou... à condition de garder à l'esprit de faire des commit minimaux et très fréquemment.
    • des majuscules dans les noms de fichier/dossier. Ça peut poser des problèmes, parce que tous les systèmes de fichier ne sont pas sensibles à la case.
    • aucune instruction pour compiler, un script d'install qui utilise sudo, aucune liste de dépendances. On ne peux pas tester sans devoir lutter pour comprendre ce que tu utilises? Désolé, j'ai la flemme. Si les Makefiles te soulent, ce que je comprend, il reste quand même de nombreuses alternatives: cmake, scons, et plein d'autres.
    • d'habitude, on utilise src pour Source, entres autres.
    • tu as une image au milieu de ton code source.

    Je pense avoir fait un tour rapide. Ce n'est pas exhaustif, mais travaille déjà sur les points objectifs.