Je ne comprend pas j'ai coder exclusivement en anglais, ou est-ce mon anglais qui est franglais (c.a.d que je traduit du français littéralement en anglais ce qui ne donne pas un anglais correct) ?
J'ai l'impression que tes noms (variables, fonctions) mélangent les 2 langues allègrement, même au sein d'un même nom. Peut-être que le problème viens de fautes, après tout beaucoup de mots anglais sont en fait issus du vieux français.
La fonction main n'appelle pratiquement que la fonction de génération de la GUI et c'est dans les callback de celle-ci que j'appelle les fonctions du programme. Qu'appelle tu unité logique ?
La définition est floue je te l'accorde, mais en gros, j'essaie de séparer de manière claire les portions de code qui manipulent les structures.
J'en prend bien note. Je pense que mon organisation est trop bordélique pour voir la logique des fonctions et donc leurs spécialisations.
J'ai appris à organiser mon code grâce au C++, je ne te le cache pas: en C++, on à généralement 2 fichiers par classe (une classe --sans méthodes virtuelles ni héritage--, ce n'est rien d'autre qu'une structure et un jeu de fonctions qui manipulent cette structure, après tout): un hpp et un cpp.
On peut appliquer la même chose au C: la structure et les prototypes de fonction qui manipulent cette structure (et uniquement elle) dans le .h, l'implémentation des fonctions dans le .c.
Après, comme je t'ai dis, je me suis fixé des objectifs quantitatifs pour le nombre de lignes de code, de fonctions manipulant une seule et unique structure, etc.
Un outil très intéressant pour ça: cccc qui scanne tes sources et indique un certain nombre de métriques, notamment concernant la complexité cyclomatique.
Cet outil à été un très bon prof pour m'apprendre à faire du code plus simple à maintenir.
Entièrement d'accord je voulais en finir a la fin et j'ai oublier de faire des sessions de commentaires du code pendant le développement, comme je fait d'habitude, ce qui fait que le code n'est pas très documenter.
J'ai dit documenté, pas commenté :)
La différence entre les deux, pour moi, c'est qu'il n'y à pas besoin de commentaire dans le code pour documenter. Pour moi, des fonctions courtes dont le nom indique ce qu'elles font, et un ou deux diagrammes (dia est pas trop mal pour faire des diagrammes avec une GUI, mais je pense sérieusement commencer à utiliser dot à la place: plus léger, utilisable sans souris, versionable, bref, que du bonheur) qui représentent les principaux flux d'appels et c'est réglé.
Je ne contredit en rien ce qui été dit mais bon la vision de celui qui code et de celui qui relit n'est jamais la même.
C'est clair, d'autant que jusqu'à preuve du contraire, personne n'est capable de se mettre d'accord sur le code idéal :)
Et puis comme on dit: les conseilleurs ne sont pas les payeurs.
J'admets même que ce n'est pas du code C propre, trop noyer par GTK+3.
Je ne connais pas GTK, et quand je vois la direction ou ça va, je n'ai pas envie d'apprendre. Pour le moment, je suis très heureux avec mes scanf/printf en fait. Si je dois utiliser des GUI, j'aurai plus tendance à partir sur wxWidgets, voire Qt.
Il y à d'autres libs aussi, genre fltk qui passeront avant GTK.
PS: Est a cause de l'erreur d'orthographe du mot opérande en anglais que tu dit que mon code est du franglais...???
C'est possible, comme je t'ai dit, je n'ai lu que le fichier contenant la fonction main, et encore, très vite. C'était une impression à chaud, jamais 100% pertinent.
Merci d'avoir pris le temps de lire mon code, c'est vraiment gentil d'avoir fait l'effort je t'en remercie encore une fois.
C'est normal. Si un jour j'utilise ton soft, et que j'ai un truc à corriger, je préfèrerai autant que le code soit propre, et n'en déplaise aux fanatiques du libre, c'est rarement le cas. Ce n'est pas parce que le source est ouvert qu'on peut modifier un programme, certains sources sont dans un tel état qu'il est plus simple de modifier le binaire que le source! J'exagère un peu, mais pas tant que ça...
D'ailleurs, pour choisir entre 2 softs, depuis quelques temps j'essaie de lire le code, histoire d'être capable de hacker les outils que j'utilise.
Et puis, je t'avoue, galculator commence à me lasser sérieusement, changer de calculatrice est un truc auquel je pense de plus en plus fortement. Je me suis donc dit: pourquoi pas (mais j'ai pas compilé, flemme d'installer les libs de dev gtk).
conseils si tu veux refacto
Si tu veux refacto ton code pour le rendre plus lisible, à mon avis il faudrait que tu fasses ça:
déplacement de chaque structure dans un header dédié à la structure.
déplacement des blocs de code qui ne manipulent qu'une structure dans un .c dédié à la structure, sous forme de fonctions minimales (même si elles ne font que 3-5 lignes, peu importe) avec un prototype dans le header contenant la structure
suppression des notions d'indices dans les variables ( operand_1, operand_2, par exemple ça devrait aller dans un tableau )
Déjà, ça devrait te rendre le code moins violant: si ton code t'a gavé c'est à cause du manque de structuration. Je ne sais pas quel outil tu utilises pour coder, mais perso, je me contente d'un bête éditeur de texte avec coloration syntaxique et d'un terminal. Séparer le code en pleins de fichiers me permets de savoir très rapidement ou se trouve le code lié à telle ou telle fonction, en fonction de la structure manipulée.
Le problème, c'est que pour la compilation c'est moins simple, du coup il faut utiliser un système de build: j'ai adopté cmake, mais il y en a d'autres genre scons (que je n'ai même pas vraiment testé en plus).
Ces 3 étapes vont probablement péter la compilation, c'est pour ça qu'il vaudrait mieux le faire structure par structure, avec un outil de versionning correct (git, mercurial, bazaar ou fossil entrent dans cette catégorie. Il y en à sûrement d'autres aussi, mais évites CVS ou SVN) ce qui te forcera à réfléchir à ton organisation.
Normalement, en, disons, 2 ou 3 heures (ton code est assez petit après tout), tu devrais te retrouver avec un code qui te motivera plus à le maintenir sur la durée, plutôt qu'un "code jetable".
[^] # Re: précision des flottants
Posté par freem . En réponse au message Une calculatrice multibases écrit en C avec GTK+3.. Évalué à 3.
Sommaire
J'ai l'impression que tes noms (variables, fonctions) mélangent les 2 langues allègrement, même au sein d'un même nom. Peut-être que le problème viens de fautes, après tout beaucoup de mots anglais sont en fait issus du vieux français.
J'appelle unité logique des blocs de code type:
La définition est floue je te l'accorde, mais en gros, j'essaie de séparer de manière claire les portions de code qui manipulent les structures.
J'ai appris à organiser mon code grâce au C++, je ne te le cache pas: en C++, on à généralement 2 fichiers par classe (une classe --sans méthodes virtuelles ni héritage--, ce n'est rien d'autre qu'une structure et un jeu de fonctions qui manipulent cette structure, après tout): un hpp et un cpp.
On peut appliquer la même chose au C: la structure et les prototypes de fonction qui manipulent cette structure (et uniquement elle) dans le .h, l'implémentation des fonctions dans le .c.
Après, comme je t'ai dis, je me suis fixé des objectifs quantitatifs pour le nombre de lignes de code, de fonctions manipulant une seule et unique structure, etc.
Un outil très intéressant pour ça: cccc qui scanne tes sources et indique un certain nombre de métriques, notamment concernant la complexité cyclomatique.
Cet outil à été un très bon prof pour m'apprendre à faire du code plus simple à maintenir.
J'ai dit documenté, pas commenté :)
La différence entre les deux, pour moi, c'est qu'il n'y à pas besoin de commentaire dans le code pour documenter. Pour moi, des fonctions courtes dont le nom indique ce qu'elles font, et un ou deux diagrammes (dia est pas trop mal pour faire des diagrammes avec une GUI, mais je pense sérieusement commencer à utiliser dot à la place: plus léger, utilisable sans souris, versionable, bref, que du bonheur) qui représentent les principaux flux d'appels et c'est réglé.
C'est clair, d'autant que jusqu'à preuve du contraire, personne n'est capable de se mettre d'accord sur le code idéal :)
Et puis comme on dit: les conseilleurs ne sont pas les payeurs.
Je ne connais pas GTK, et quand je vois la direction ou ça va, je n'ai pas envie d'apprendre. Pour le moment, je suis très heureux avec mes scanf/printf en fait. Si je dois utiliser des GUI, j'aurai plus tendance à partir sur wxWidgets, voire Qt.
Il y à d'autres libs aussi, genre fltk qui passeront avant GTK.
C'est possible, comme je t'ai dit, je n'ai lu que le fichier contenant la fonction main, et encore, très vite. C'était une impression à chaud, jamais 100% pertinent.
C'est normal. Si un jour j'utilise ton soft, et que j'ai un truc à corriger, je préfèrerai autant que le code soit propre, et n'en déplaise aux fanatiques du libre, c'est rarement le cas. Ce n'est pas parce que le source est ouvert qu'on peut modifier un programme, certains sources sont dans un tel état qu'il est plus simple de modifier le binaire que le source! J'exagère un peu, mais pas tant que ça...
D'ailleurs, pour choisir entre 2 softs, depuis quelques temps j'essaie de lire le code, histoire d'être capable de hacker les outils que j'utilise.
Et puis, je t'avoue, galculator commence à me lasser sérieusement, changer de calculatrice est un truc auquel je pense de plus en plus fortement. Je me suis donc dit: pourquoi pas (mais j'ai pas compilé, flemme d'installer les libs de dev gtk).
conseils si tu veux refacto
Si tu veux refacto ton code pour le rendre plus lisible, à mon avis il faudrait que tu fasses ça:
Déjà, ça devrait te rendre le code moins violant: si ton code t'a gavé c'est à cause du manque de structuration. Je ne sais pas quel outil tu utilises pour coder, mais perso, je me contente d'un bête éditeur de texte avec coloration syntaxique et d'un terminal. Séparer le code en pleins de fichiers me permets de savoir très rapidement ou se trouve le code lié à telle ou telle fonction, en fonction de la structure manipulée.
Le problème, c'est que pour la compilation c'est moins simple, du coup il faut utiliser un système de build: j'ai adopté cmake, mais il y en a d'autres genre scons (que je n'ai même pas vraiment testé en plus).
Ces 3 étapes vont probablement péter la compilation, c'est pour ça qu'il vaudrait mieux le faire structure par structure, avec un outil de versionning correct (git, mercurial, bazaar ou fossil entrent dans cette catégorie. Il y en à sûrement d'autres aussi, mais évites CVS ou SVN) ce qui te forcera à réfléchir à ton organisation.
Normalement, en, disons, 2 ou 3 heures (ton code est assez petit après tout), tu devrais te retrouver avec un code qui te motivera plus à le maintenir sur la durée, plutôt qu'un "code jetable".