Vider un tableau

Pourquoi faire ? C'est rarement utile. Il y a peut êre un problème de conception ou de codage.
Montre le code de la fonction.

c'est qu en fait, j ai une boucle dans laquelle j ai mon tableau.
Dans ce tableau j ajoute à chaque fois une lettre à partir d une grille, donc ce tableau contiendra le prefixe d'un mot qui peut exister ou pas.
S il existe je l ajoute à une liste de mots sinon je dois le vider et repasser par la boucle pour essayer de creer un autre..

Je sais pas si c'est assez clair mais le code encore moins comprehensible....

Tu 'ajoutes' avec quoi ? Ce serait plus simple de voir le code...

Commence par faire du code comprehensible, tu verras c'est mieux pour tout le monde  

C'est un probleme simple, tu n'aurait probablement pas besoin d'une autre fonction mais bon voici:

void CleanTable(char* ioDirty, const int iSizeOfDirty)
{

//corrigez moi si je me souvient pas de l'api.
memset(ioDirty,iSizeOfDirty,0);

//Ou vive la force brute:
for( i = 0 ; i < iSizeOfDirty; i++)
{
*ioDirty+i = 0
}

}

No excuse...

http://dpobel.free.fr/man/html/affiche_man.php/1765/man...

memset (ioDirty, 0, iSizeOfDirty);

Pour la peine tu te prends une Force 5 pour "Usage de la 'Notation Hongroise' version Microsoft (avec les types)"

http://mapage.noos.fr/emdel/goret.htm

et size_t c'est pour les chiens ?

  quand je lis le code du projet sur lequel je travaille (1 000 000 lignes écrites depuis 7-8 ans par 15-20 personnes), et bien on est allègrement dans le niveau 9-10, avec quelques portions de codes récentes de niveau 5...

je vais me pendre  

c'est un peu conffu cette echelle de goret, en plus certaines regles sont discutables (genre la guerre tab vs space), et on fond on ne sait pas ce qu'est un ''code parfait''

sinon :
comment tu la fait alors ta gestion d'erreur ?

Avec un seul return...

j'aime pas ce genre de code moi:

int FaireUnTasDeTruc(b) {

        int YaUneErreur=NON;

        if (ArgumentCorrect(b)) {

                ChezPasQuoi machin;

                machin=FaireUnTruc(b);

                if (NoError(machin)) {

                        ChezPasQuoi2 machin2;

                        DesDonnees* a;

                        a=NULL;

                        a=FaireUnTrucImportantGenreUnMalloc()

                        machin2=FaireUnAutreTrucavec(a);

                        if (NoError(machin2) && a!=NULL) {

                                if (!TraiterLeTrucQuaFaitFaireUnAutreTrucAvec(a))

                                       AfficherLeTruc(a);

                                else YaUneErreur=AfficherUneErreur();

                        }

                        else YaUneErreur=AfficherUneErreur();

                        DefaireLeTrucImportant(a);

                }

                else YaUneErreur=AfficherUneErreur();

        }

        else YaUneErreur=OUI;

        return YaUneErreur

}

c'est incompréhensible, le seul truc qui ressort c'est la gestion d'erreur ...

ERR FaireUnTasDeTruc (T b)

{

   ERR Erreur = OK;

   if (ArgumentCorrect(b))

   {

      ChezPasQuoi machin = FaireUnTruc(b);

      if (NoError(machin))

      {

         DesDonnees* a = FaireUnTrucImportantGenreUnMalloc();

         ChezPasQuoi2 machin2 = FaireUnAutreTrucavec(a);

         if (NoError(machin2) && a != NULL)

         {

            if (!TraiterLeTrucQuaFaitFaireUnAutreTrucAvec(a))

            {

               AfficherLeTruc(a);

            }

            else

            {

               Erreur = ERR_A;

            }

         }

         else

         {

            Erreur = ERR_B;

         }

         DefaireLeTrucImportant(a);

      }

      else

      {

         Erreur = ERR_C;

      }

   }

   else

   {

      Erreur = ERR_D;

   }

 
   /* eventuellement...

 
   if (Erreur != OK)

   {

      AfficherErreur(Erreur)   

   }

   */

 
   return Erreur;

}

mon dieu que c'est moche
vive les exceptions !

ça c'est plus joli ?

ERR FaireUnTasDeTruc(T b) {

	DesDonnees* a;

	ChezPasQuoi machin,machin2;

	a=NULL;

	if (!ArgumentCorrect(b)) {

		return ERR_D;

	}

	if (!NoError(machin=FaireUnTruc(b))) {

		AfficherUneErreur();

		return ERR_C;

	}

	if (!NoError(a=FaireUnTrucImportantGenreUnMalloc())) {

		AfficherUneErreur();

		return ERR_B;

	}

	if (!NoError(machin2=FaireUnAutreTrucavec(a))) {

		AfficherUneErreur();

		DefaireLeTrucImportant(a);

		return ERR_B;

	}

	if (!TraiterLeTrucQuaFaitFaireUnAutreTrucAvec(a)) {

		AfficherUneErreur();

		DefaireLeTrucImportant(a);

	}

	AfficherLeTruc(a);

	DefaireLeTrucImportant(a);

	return OK;

}

Le problème, c'est qu'à chaque fois que tu es susceptible de quitter la fonction, tu dois penser à faire le nettoyage nécessaire.

1 point de sortie par fonction, 1 endoit où tu fais le nettoyage, c'est bien plus maintenable et plus clair.

du moins c'est mon avis...

ca depend aussi des fonctions ...

+1 avec batchy pour plus d'un return par fonction, c'est vraiment beaucoup plus lisible, quitte à faire une fonction de nettoyage

sauf que la mon cas il est simple : il se résume à ca dans le cas normal

machin=FaireUnTruc(b)

a=FaireUnTrucImportantGenreUnMalloc();

machin2=FaireUnAutreTrucavec(a);

TraiterLeTrucQuaFaitFaireUnAutreTrucAvec(a)

DefaireLeTrucImportant(a);

il ne fait qu'appeler quelques fonctions en utilisants les valeurs de retours des autres, il n'y a aucun choix, aucune boucle, et quand tu rajoute un code un peu complexe avec de la gestion d'erreur avec des if imbriqués tu différencie plus la gestion d'erreur de ce que la fonction est cencé faire.

surtout essaye de sortir de plusieurs boucles imbriquées lorsque tu as une erreur ...

c'est vrai que ça dépend des fonctions, et des règles de codage que l'on se doit d'appliquer.
Chez nous, les règles sont (en résumé et non exhaustif) :
- ne pas dépasser 3 niveaux d'imbrications dans les structures de contrôle,
- pas plus de 100 lignes par fonction

du coup, si tu respectes ces 2 contraintes, il n'est pas très dur de gérer les cas d'erreur sans mettre de goto et de return partout.

De plus, dans une autre expérience professionnelle, un outil de vérification de règles était utilisé (Logiscope). Les services des méthodes et de la qualité imposaient 1 point de sortie par fonction. Si ce n'était pas le cas, la pièce de code était rejetée et impossible de livrer le composant.

Du coup, j'ai pris certaines habitudes