Citation : Yno

for (foo(), bar(); barfoo() < foobar() && broo() == faar(); n++, i++, k += (i ? i-- : ++n))

Je suppose que c'est de ce genre d'abus dont il veut parler.

Plutot que d'interdire for vaudrait interdire l'opérateur virgule (ou l'interdire dans les expressions du for). Et puis on doit pouvoir faire faire la meme chose avec une boucle while (sauf l'initialisation).

Citation : tc

Citation : joccd

tu t'écoutes quand tu parles écris ?

?

Ou alors tu n'as jamais codé, parce que dire que 10 initialisations, 10 conditions et 10 incrémentations sont aussi lisibles que de tout séparer ...

On est bien d'accord la norme, sur certain point, est ridicule...
Mais bon replacons nous dans le contexe:

1 promo = 400 eleves (pour la 2012)
400 eleves qui vont faire des projets tout au long de l'annee
400 eleves qui bosseront parfois en rush(projet eclair= sujet le vendredi soir, rendu le dimanche soir), colle (sujet a 19h30, rendu a 23h30), ou sur des projet a plus ou moins long terme (corewar, 42sh(shell), raytracer)

EDIT add: alors imaginons les echanges inter promos

Pour moi, et c'est ce que devais penser l'ecole, mieux vaut avoir une norme tres severe quitte a etre ridicule pour eviter les abus, et que tout le monde puisse lire le code des autres (Genre j;ai du mal avec les code qui passe sur le forum quand il sont mal indente, aucun espace et j'en passe)

Donc je vois pas la norme en elle meme, je vois plus les facilitees qu'elle apporte

Edit: ptites modifs

EDIT2:
Les 25 lignes par fonctions, 80 col max
sont deux bons points qui ont ete omis

Citation : joccd

Citation : candide

On n'a pas le droit d'utiliser for ? mais c'est quoi ce délire ?

Ceci a été décidé car certains en abusaient (du style faire un for de 80 caractères juste pour gagner des lignes)

D'ailleurs, faudrait aussi supprimer while parce que tu peux presque faire exactement la meme chose, exemple :

j'ai cette boucle qui vient d'un tri par insertion :

while ((i > 0) && (t[i - 1] > temp))
        {
          t[i] = t[i - 1];
          i--;
        }

Tu peux la réécrire comme ça :

int p;
      while ((p = (i > 0) && (t[i - 1] > temp)) ? t[i] = t[i - 1], i--, p : 0);

et avec un peu d'astuce, tu dois pouvoir y incorporer les initialisations du for. Franchement, moi, des interdictions débiles comme ça, ça ne me donne qu'une envie : les contourner ou faire de la provo.

Citation : daedric

On est bien d'accord la norme sur certain point est ridicule...
Mais bon replacons nous dans le contexe:

1 promo = 400 eleves (pour la 2012)
400 eleves qui vont faire des projets tout au long de l'annee
400 eleves qui bosseront parfois en rush(projet eclair= sujet le vendredi soir, rendu le dimanche soir), colle (sujet a 19h30, rendu a 23h30), ou sur des projet a plus ou moins long terme (corewar, 42sh(shell), raytracer)

Pour moi, et c'est ce que devais penser l'ecole, mieu vaut avoir une norme tres severe quitte a etre ridicule pour eviter les abus, et que tout le monde puisse lire le code des autres (Genre j;ai du mal avec les code qui passe sur le forum quand il sont mal indente, aucun espace et j'en passe)

Donc je vois pas la norme en elle meme, je vois plus les facilitees qu'elle apporte

Je pense qu'on est tous d'accord sur le fait qu'il faut des normes de codage, notamment pour facilité la correction. Tout le monde a l'air aussi d'accord sur l'existence de certains points douteux. Il n'y a plus qu'à souhaiter que les améliorations se fassent.

De toute maniere, nous ne sommes soumis que deux ans a la norme, ce n'est pas la mer a boire...

De toutes les regles une seule me derange, le for

Citation : daedric

De toute maniere, nous ne sommes soumis que deux ans a la norme, ce n'est pas la mer a boire...

De toutes les regles une seule me derange, le for

2 ans, c'est plus qu'il n'en faut pour prendre de mauvaises habitudes et passer à-coté de la puissance (maitrisée) qu'offre le C.

Citation : -ed-

Citation : daedric

De toute maniere, nous ne sommes soumis que deux ans a la norme, ce n'est pas la mer a boire...

De toutes les regles une seule me derange, le for

2 ans, c'est plus qu'il n'en faut pour prendre de mauvaises habitudes et passer à-coté de la puissance (maitrisée) qu'offre le C.

Objectivement je ne vois pas qu'elle mauvaise habitudes (ormis les parenthese autour du return) on peut prendre ?

Citation : daedric

Objectivement je ne vois pas qu'elle mauvaise habitudes (ormis les parenthese autour du return) on peut prendre ?

La non utilisation du for par exemple.

Est ce vraiment une mauvaise habitude que de faire 2/3 lignes en plus ?

Citation : daedric

Est ce vraiment une mauvaise habitude que de faire 2/3 lignes en plus ?

Oui... ? Perte de temps et autres problèmes de maintenance.

En quoi la perte de temps ? le temps que tu mets a les taper ?

Problemes de maintenance ?
En quoi un code dans for est il moins maintenable qu'un code avec ?

ps: j'essais de comprendre ton point de vu la dessus et ne suis pas d'accord avec toi, ceci dit je suis contre l'interdiction et je l'utilise dans mes projets perso

Salut,

Je vois que tu as ton points de vue sur la norme (qui n'est pas parfaite, loin de là). Mais as tu essayer d'entrer directement avec l'adm pour leur en parler ? (Contact)
Si tu veux faire bouger les choses pour la norme, le meilleur endroit est surement l'adm et pas le forum du SDZ.

Sinon pour parler de la norme, je dirais qu'une fois les habitudes prises, et même si elle est contraignante sur certains points, elle est bien pratique pour, entre autres, partager son codes, le relire, le modifier, etc.

Et pour les fautes d'orthographe et les fautes de normes dans la présentation, il parait que c'est fait exprès.

POur la norme je sais pas, pour le corewar oui

Sinon on a essayait l'annee derniere de faire bouger les choses mais l'adm est reste inflexible

Ce n'est sans doute pas le sujet, mais je trouve certains points de la norme très peu esthétiques :

Citation : norme

- Pas d'espace entre le nom d'une fonction et la '(', par contre toujours un espace entre un mot clé C (avec argument) et la '('

- On alignera les noms des variables sur le nom de la fonction qui les contient et uniquement celle ci.

Moi, je trouve ceci hideux...

Je ne suis pas d'accord avec ceci non plus :

Citation : norme

Le symbole de pointeur (*) porte toujours sur la variable (ou fonction), et jamais sur le type:

Je trouve cela moins correct, et moins lisible. Le seul intérêt serait de pouvoir déclarer plusieurs variable, ce qui n'est pas recommandé.

La norme Epitech est à appliquer dès le début de la piscine de tek1 sur le C et c'est une période déjà assez riche en infos pour en perdre pas mal.

De plus le fichier de description de la norme fournie dans le message de base est (comme c'est précisé dedans) suffisante pour les premiers programmes, ce qui signifie que c'est une norme simplifiée ne prenant pas en compte certaines subtilités telles que celles citées ci-dessus.

Interdire le for pour un débutant est beaucoup plus simple que de lui dire qu'il n'a pas le droit au séparateur virgule etc, chose qu'il ne comprendrait d'ailleurs pas étant donné qu'il débute.

Maintenant il faut savoir qu'en pratique dans l'école il y a des exceptions, des interdictions qui deviennent tolérées sur les projets de fin d'année.

Exemple : pas de norme pendant un exam machine, même pas de limitation de language sauf si précisé.

Le norme oblige par ailleurs à pousser la réflexion algorithmique au maximum en ne faisant que des fonctions de 25 lignes, ce qui peu réellement bouleverser la logique d'un programme dans certains cas.

Après il y a ceux qui vont toujours chercher à gratter des lignes en faisant des trucs moches (un peu comme moi) du genre :

Pour gagner 3 lignes faire :

int i;

i = 0;
while (i < 10)
    toto(i++);

Au lieu de :

int    i;

i = 0;
while (i < 10)
{
    toto(i);
    i++;
}

Et ceux qui vont chercher à réellement structurer leur programme à une action par fonction.

C'est vrai que ça peut paraitre abusif mais après un certain temps à l'appliquer, à en chier carrément parfois à cause d'elle, on se rend compte que même une fois qu'elle a disparu (arrivé en entreprise) on continue à chercher à faire un code propre, structuré et que les blocs de 100 lignes nous font carrément gerber.

Au final moi je le vois comme ça :
chacun prend son identité, sa façon de coder en restant dans le moule de l'école pendant le cursus, et une fois sorti et qu'on peut se lâcher on reste quand même correct et pas aussi éloigné de la norme qu'on l'avait imaginé pendant la formation.

Un Astek qui arrive vers un tek1 en piscine à au moins la norme pour se repérer dans le fouillis sans nom que sont à 90% du temps les premiers codes que l'on crache.

Tout tes points sont totalement subjectif...
Personnellement avant epitech je n'aimais deja pas les codes trop aerien donc les espaces jamais... et les * sur les variables, au final je trouve ca plus lisible: tu vois directement si c'est un pointeur ou pas...

Enfin totalement subjectif aussi

Citation : Gagaro

Sinon pour parler de la norme, je dirais qu'une fois les habitudes prises, et même si elle est contraignante sur certains points, elle est bien pratique pour, entre autres, partager son codes, le relire, le modifier, etc.

En quoi une norme plus correcte serait moins pratique ?

Citation : Myriad

Pour gagner 3 lignes faire :

int i;

i = 0;
while (i < 10)
    toto(i++);

Au lieu de :

int    i;

i = 0;
while (i < 10)
{
    toto(i);
    i++;
}

Fais gaffe dans certain cas ca n'auras pas forcement l'effet escompte

Citation : yoch

En quoi une norme plus correcte serait moins pratique ?

+1

Citation : joccd

Citation : tc

Citation : joccd

tu t'écoutes quand tu parles écris ?

?

Ou alors tu n'as jamais codé, parce que dire que 10 initialisations, 10 conditions et 10 incrémentations sont aussi lisibles que de tout séparer ...

Ne me fais pas dire ce que je n'ai pas dit. Le point de mon propos était que quelqu'un capable de compacter 10 incrémentations, 10 conditions et 10 incrémentations dans l'entete d'une boucle for est certainement capable de faire aussi bien avec une boucle while.On peut parfaitement écrire ce genre de code:

#include <stdio.h>

int main(void)
{
    char const *tampon1 = "Bienvenue sur le Sdz";
    char const *tampon2 = "ou vous apprendrez le c a partir de zero";
    size_t i, j;

    for (i = 0, j = 0; tampon1[i] != 0 && tampon2[j] != 0;
            putchar(tampon1[i]), putchar(tampon2[j]), i++, j++)
    {
    }

    printf("\n");

    while ((*tampon1 != 0 && *tampon2 != 0) &&
            (putchar(*tampon1), putchar(*tampon2), tampon1++, tampon2++, 1))
    {
    }

    return 0;
}

Et ce n'est pas parqu'on interdit le for qu'il m'est impossible d'écrire quelque chose d'illisible.

Thierry

Citation : tc

Et ce n'est pas parqu'on interdit le for qu'il m'est impossible d'écrire quelque chose d'illisible.

+1 mais l'administration n'est pas d'accord (me demande pas pourquoi je ne sais pas)

Citation : daedric

Objectivement je ne vois pas qu'elle mauvaise habitudes (ormis les parenthese autour du return) on peut prendre ?

La plupart des points on été exposés dans mon post initial.

Citation : yoch

Citation : Gagaro

Sinon pour parler de la norme, je dirais qu'une fois les habitudes prises, et même si elle est contraignante sur certains points, elle est bien pratique pour, entre autres, partager son codes, le relire, le modifier, etc.

En quoi une norme plus correcte serait moins pratique ?

Je n'ai jamais dit que la norme serait moins pratique en étant plus correcte, mais bien qu'elle était pratique dans l'état actuel.

Citation : daedric

Citation : tc

Et ce n'est pas parqu'on interdit le for qu'il m'est impossible d'écrire quelque chose d'illisible.

+1 mais l'administration n'est pas d'accord (me demande pas pourquoi je ne sais pas)

Il me semble que c'était autorisé au départ et que ça a été interdit car il y avait beaucoup d'abus et de confusions. Enfin du moins c'est ce qu'on m'a toujours laissé entendre..

Mais bon encore un for c'est pas vital, je trouve l'interdiction du switch bien plus contraignante car sur un grand nombre de conditions c'est quand même beaucoup plus lisible.

Citation : Gagaro

Citation : yoch

Citation : Gagaro

Sinon pour parler de la norme, je dirais qu'une fois les habitudes prises, et même si elle est contraignante sur certains points, elle est bien pratique pour, entre autres, partager son codes, le relire, le modifier, etc.

En quoi une norme plus correcte serait moins pratique ?

Je n'ai jamais dit que la norme serait moins pratique en étant plus correcte, mais bien qu'elle était pratique dans l'état actuel.

OK. Mais le débat est surtout si elle est correcte ou non (tout le monde semble d'accord sur l'utilité d'une norme, il me semble).

Citation : -ed-

Citation : daedric

Objectivement je ne vois pas qu'elle mauvaise habitudes (ormis les parenthese autour du return) on peut prendre ?

La plupart des points on été exposés dans mon post initial.

Citation : -ed-

pas de {} avec la structure de code if, ce qui ralentit la mise au point et l'évolution du code.

Pas eut besoin de la norme pour ne pas mettre les {}, apres meme si je le fais, je suis d'accord avec toi

Citation : -ed-

Pas d'accord pour la 2 ème fois. Ça surcharge le codage inutilement et ça créée un excès d'indentation qui nuit à la lisibilité.

Pure question de gout

Citation : -ed-

Bah, non. On suit l'indentation par défaut, c'est beaucoup plus clair (et automatisé)...

Toujours une question de gout

Citation : -ed-

return ? Pouquoi ? Il faut des parenthèses à return ?

D'accord avec toi

Citation : -ed-

On atteint les sommets de l'absurdité...
Il vaudrait mieux imposer un préfixe p aux identificateurs de pointeurs. Ce serait beaucoup plus utile...

pour les prefix ok, mais je trouve pas ca absurde

Je m'arreterais la

Tout ca pour dire que les normes quelqu'elle soit sont purement subjective, correcte ou pas d'ailleurs car c'est subjectif...

Citation : Myriad

je trouve l'interdiction du switch bien plus contraignante car sur un grand nombre de conditions c'est quand même beaucoup plus lisible.

Je la trouve plus justifiée pour la raison suivante. Au début il est très fréquent que l'on abuse de séquences if(){} else if(){}. Si les étudiants avaient le droit à switch, ils l'utiliseraient en le trouvant fort pratique, ce qui est vrai en théorie, mis à part que les novices pensent rarement à remplacer un switch par une indexation dans un tableau statique par exemple. Poser une contrainte peut forcer les étudiants à mieux réfléchir.
C'est une explication que je me suis faite, elle est peut-être fausse.

Citation : Yno

Citation : Kun

Et pour les variables, elles ne doivent être déclarées qu'en début de fonction

Non, au début de n'importe quel bloc d'accolades

Je parlais des recommandations de la norme, pas de ce qui peut se faire en langage C.

Citation : Yno

Citation : Kun

C'est une école, les étudiants sont là pour apprendre, ils ont le temps (jusqu'au rendu du projet).

Ce n'est pas parce qu'on a le temps qu'on peut le perdre.

Comme ça a déjà été dis :
- Ça fait parti de l'apprentissage (rigueur, code "propre", etc...),
- Ça fait gagner beaucoup de temps à la relecture (par d'autres étudiants de l'école),
- Passé le(s) premier(s) mois, le codage à la norme devient un automatisme, il ne fait donc pas perdre de temps.

Citation : Yno

Citation : Kun

De nombreux éditeurs admettent qu'une tab fait 8 espaces, les autres sont configurables

On ne va pas commencer à configurer son éditeur pour chaque code source d'une provenance différente ? Et que fait-on si on veut lire à la fois un code source en mode mélangé de Emacs et un code qui indente à coups de tabulations ? Je soutiens l'indentation via espaces.

Le code de 1ère et 2ème année n'a pas vraiment pour vocation d'être distribué à l'extérieur de l'école, donc tout le monde a la même config. (sauf le projet libre de 2ème année, mais la norme ne s'y applique pas)
Et pour la tabulation, c'est un gain de temps sous emacs (alt+i).
Mais je suis d'accord que les espaces, c'est plus portable.

Citation : Yno

Citation : Kun

Et concernant le for, il me semble qu'il est admis à partir de la deuxième année.

Pourquoi ? Un motif particulier ? for est trop complexe pour les novices ? Si on veut parcourir un tableau en première année, j'en déduis que l'on doit utiliser une boucle while, moins lisible à cet effet ? Quel intérêt de se passer de la puissance d'un langage ?

Ça a déjà été dis, le for était beaucoup utilisé pour le "bourrer de code", afin d'éviter la contrainte des 25 lignes.
Ce n'est pas forcement une règle très censé, mais encore une fois, ça évite du code goret, et ce n'est applicable que pour les 1ère année.
De plus, le while prend plus de lignes quand il est utilisé comme un for, l'étudiant doit donc faire plus d'efforts pour se conformer aux fonctions de 25 lignes, ce qui incite à faire un découpage logique du code...

Citation : candide

Franchement, moi, des interdictions débiles comme ça, ça ne me donne qu'une envie : les contourner ou faire de la provo.

Il n'y a pas que la norme qui est regardée en soutenance, la propreté générale du code est aussi jugée.
Un étudiant qui arrive en soutenance en essayant de contourner la norme pour faire des choses immondes se fait fortement pénaliser.

Citation : -ed-

Citation : daedric

De toute maniere, nous ne sommes soumis que deux ans a la norme, ce n'est pas la mer a boire...

De toutes les regles une seule me derange, le for

2 ans, c'est plus qu'il n'en faut pour prendre de mauvaises habitudes et passer à-coté de la puissance (maitrisée) qu'offre le C.

En première année, tu vois toutes les "bases" (étendues) du langage C.
En deuxième année est bien plus large sur la norme, ce qui permet de pousser plus loin, de voir comment chaque chose est faite, etc...
Ça permet de se concentrer sur l'essentiel en 1ère année, et d'avoir suffisamment de connaissance pour pouvoir aller plus loin dans la compréhension du C en 2ème année.


Sinon, je rejoins globalement le point de vue de daedric et de Myriad.

Sur ce, je trouve que ce post dérive un peu, entre les affirmations fausses de la part des étudiants de l'école, d'autres qui ne cherche qu'à critiquer de façon non constructive (ce n'est pas ton cas -ed-), et principalement sur des critères esthétiques, etc...

Donc, je n'interviendrai plus ici (l'essentiel a été dit).

Bonne continuation.

Citation : daedric

Tout ca pour dire que les normes quelqu'elle soit sont purement subjective, correcte ou pas d'ailleurs car c'est subjectif...

Ce n'est pas en répétant 'c'est subjectif' que c'est vrai. Il y certains points qui nuisent clairement à la lisibilité. Personnellement, ça ne me dérange pas trop, car je repasse systématiquement le code à lire à l'indenteur automatique. Je dis simplement que c'est dangereux et qu'on se prive de techniques de programmation défensives dont la lisibilité fait partie (comme la réduction de la portée des variables, etc.)

Pour la reduction des portees des variables ok.
Sinon apres ce n'est pas parce que TU trouve que a nuis a la lisibilite que c'est forcement le cas, c'est seulement ce que je veux dire