2009-06-02 6 views
8

Est-ce un bon style de faire déclarer le prototype de fonction à l'intérieur de la fonction principale?Prototype de fonction déclaré à l'intérieur de la meilleure pratique?

Je regardais un tutoriel C, je pense est tout à fait démodé. Cependant, ils déclarent le prototype de fonction à l'intérieur de main. Je déclare normalement à l'extérieur avant principal.

#include <stdio.h> 

int main() 
{ 
    char myname [30]; 
    int theage; 
    int getage(); 

    printf ("\nEnter your name:"); 
    gets (myname); 
    theage = getage(); 
    printf("\n AGE = %d and NAME = %s", theage, myname); 
    return 0; 
} 

int getage() 
{ 
    int myage; /* local to only getage() */ 

    printf ("\nEnter your age: "); 
    scanf ("%d",&myage); 
    return (myage); 
} 
+0

Je ne vois pas la déclaration de fonction dans votre code.Vous parlez de la fonction principale? ou le "fichier" principal? S'il vous plaît noter que "stdio.h" n'est pas correct, il devrait être ... Pourriez-vous préciser votre question? – LB40

+1

@LB Le prototype de la fonction est la ligne 6 (int getage();) – nuriaion

+0

+1 pour la question. Sur la base des réponses suivantes, il semble que déclarer une fonction prototype dans les fonctions n'est pas une bonne pratique, alors la question de suivi est, y a-t-il un avantage à le faire dans la fonction main()? – TimeString

Répondre

16

Personnellement, je dire « non » pour plusieurs raisons:

  • il fait le code principal plus
  • il peut confondre un débutant en penser ing la fonction est portée a été définie par le principal
  • en code réel, je mettrais normalement la fonction dans une unité de compilation différente et #include son fichier d'en-tête
+1

4) il est plus difficile de trouver le prototype de fonction – hiena

1

i pense que c'est juste un petit exemple pour le tutoriel ... c'est ce que vous faites lorsque vous commencez à introduire des fonctions ...

Je suis d'accord avec Neil ...

4

Ce n'est pas un bon style.

Vous pouvez soit déclarer les prototypes de fonction locale au début, soit les déplacer dans un fichier d'en-tête.

Les prototypes de fonction (ainsi que les variables externes) peuvent être déclarés presque partout dans le langage c. Cependant, juste parce que c'est possible, il ne devrait pas y avoir de raison d'écrire le style spaghetti C.

Cela rend le code moins lisible. Pour moi, de telles pratiques sont un signe clair d'odeur de code.

5

Je dirai aussi non avec la raison supplémentaire que si vous commencez à utiliser des déclarations explicites partout dans le code, vous aurez très certainement des externals non résolus lorsque la fonction que vous appelez subitement changera sa signature. Si vous avez UNE déclaration dans un fichier d'en-tête, vous n'avez besoin de modifier UNE déclaration que lorsque la fonction change. Cependant, je dirais oui pour la raison suivante: Si vous écrivez simplement une méthode de test simple qui est écrite pour un usage unique, c'est-à-dire si vous voulez tester quelque chose de très rapide et ensuite jeter la fonction tout de suite . Ensuite, il peut être intéressant de jeter une déclaration juste avant de vouloir faire l'appel.

Pour le code de production -> Non non non! :)

1

Depuis que je n'ai pas sauté le nombre requis de cerceaux dans cette émission de poney je n'ai pas d'autre choix que de poster ce commentaire comme réponse. Gardez à l'esprit que ce n'est qu'un extrait d'un livre et non le type de code que l'on voit dans un environnement de production. L'extrait de code est bien mais pas idéal. Neil a donné la meilleure réponse donc je lui ai donné +1. Je voudrais noter son troisième point si vous voulez vraiment savoir comment cela se fait en dehors des tutoriels/manuels.

Aussi, un point depuis que je les fais: le "stdio.h" vs est simplement une façon de dire au préprocesseur où chercher le fichier stdio.h. Encore une fois, dans la plupart des cas, vous verrez stdio.h entouré par <> au lieu de "". Cependant, vos propres fichiers d'en-tête, comme mentionné par le 3ème point de Neil, seront entourés de "".

Questions connexes