coding guide

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.

  Revue du sujet
 

  Étendre la vue Revue du sujet : coding guide

par mcorgnet » 16 janv. 2007, 15:17

La question que mere-teresa et moi-même nous posons est "d'où provient cette limite". Probablement héritée d'une ancienne résolution utilisée sous DOS ? Tu dis que ta propre limite est 80, comment as-tu choisi ce nombre ?
Bonjour,

pardon pour le retard, j'ai repris les cours et j'ai du temps deux semaines par mois.

Sous windows, les éditeurs (tous ceux que j'ai pu utiliser jusqu'à présent), proposent une limite de base à 80 caractères.

En lisant le guide de développement c++, j'ai remarqué que cette limite est la même.

Si dès aujourd'hui, tout le monde me dit : "j'utilise une limite à 100 caractères", je change instantanément le guide. Mais comme vous le savez, seuls ceux qui ne sont pas d'accord interviennent :)

C'est un paragraphe que je vais mettre en vert, et je le ferai désormais pour tous ceux qui doivent être revus.

J'ai encore besoin de vos interventions, le guide avance de mon côté, je mettrai une mise à jour dès la semaine prochaine.

Merci de votre aide :d

Mathieu.

par Hubert Roksor » 10 janv. 2007, 12:30

J'ai tendance à m'adapter au plus restrictif. Moi même, j'ai une limite à 80 caractères par ligne.
La question que mere-teresa et moi-même nous posons est "d'où provient cette limite". Probablement héritée d'une ancienne résolution utilisée sous DOS ? Tu dis que ta propre limite est 80, comment as-tu choisi ce nombre ?

par mcorgnet » 05 janv. 2007, 13:11

Je suis du même avis, ça fait bien longtemps que plus personne n'est limité à 80 caractères par ligne.
Le problème reste entier. J'ai tendance à m'adapter au plus restrictif. Moi même, j'ai une limite à 80 caractères par ligne. Encore une fois, fixer cette limite est important dans le cas d'échanges de fichiers.

Si l'un de tes collègues t'envoie un fichier avec 150 caractères par ligne, tu perdras du temps à adapter ton outil de développement, et peut être à trouver un écran plus gros pour te faciliter la lecture.

Cela dit, si tu es seul à coder sur un projet, ça n'a qu'une importance relative.

par mcorgnet » 05 janv. 2007, 12:53

je mets toujours une espace après "if", "while", "for", etc...
parce que ce ne sont pas des fonctions mais des structures de contrôle.
J'ajoute ça au guide.

par Hubert Roksor » 05 janv. 2007, 12:40

Dès que tu commences à imprimer sur ton moniteur, promis.

par albat » 05 janv. 2007, 12:02

je mets toujours une espace après "if", "while", "for", etc...
parce que ce ne sont pas des fonctions mais des structures de contrôle.
+1 :pouce:

par Hubert Roksor » 05 janv. 2007, 11:47

Quel que soit le logiciel que j'utilise [...] j'ai toujours pu configurer la fonte (police et taille) pour en avoir le max sur mon écran.
Amen

Je suis du même avis, ça fait bien longtemps que plus personne n'est limité à 80 caractères par ligne. Avec l'agrandissement des diagonales, la popularisation du format "wide" et l'invention des palettes flottantes on peut sans prendre de risques dire que 100 symboles par ligne est une valeur décente. Perso, j'en affiche 110 avec mes palettes cachées, et ce sur le 15' de mon portable. (Bitstream Vera Sans Mono 12)

J'ai d'autres commentaires et recommandations, mais ça ne vaut pas trop le coup si on ne les explique pas donc ça devra attendre un tout petit peu, mais je ne résiste pas à l'envie de préciser que je mets toujours un espace après "if", "while", "for", etc... parce que ce ne sont pas des fonctions mais des structures de contrôle.

par mcorgnet » 05 janv. 2007, 11:29

Je comprends ce que tu veux dire, c'est très certainement possible aussi sous windows.

Mais, à priori, cette limite me paraît utile dans le cas d'échange de fichiers, et il faut la fixer.

Personne n'est obligé de suivre ces règles, mais certains ont besoin de faire des projets à plusieurs, et ça là qu'une charte prend tout son sens.

Il faut prendre une décision à ce sujet, pour l'instant je pars du principe que c'est 80 caractères, même si ça évoluera à l'avenir.

par mere-teresa » 05 janv. 2007, 10:57

Je ne comprends pas : je n'ai, avant aujourd'hui jamais développé sous Windows, et j'ignore quelle est cette police du Bloc Notes.
Quel que soit le logiciel que j'utilise (Dreamweaver, HAPEdit, à mes débuts, Scintilla et JEdit aujourd'hui), j'ai toujours pu configurer la fonte (police et taille) pour en avoir le max sur mon écran.

Actuellement, j'ai un 19" pour développer, même avec mes palettes sur les côtés dans JEdit ou Eclipse (explorateur de code, listing fichiers, recherche, etc..), j'ai un config qui me permet d'avoir la fameuse barre à 150 carac.

Mon imprimante n'est pas limitée, elle non plus à 80 car/ligne, et même si j'imprime rarement mes programmes, ce n'est pas un souci cette limite.

Je joins une copie d'écran de mon espace de travail avec JEdit. Vous apercevez à droite une ligne : c'est ma limite de wrap.

Image

par mcorgnet » 05 janv. 2007, 10:52

Pour info, je viens de mettre le document à jour, avec une partie des avis que j'ai pu recevoir.

Je vais essayer de les synthétiser.

par mcorgnet » 05 janv. 2007, 10:46

Un détail à propos des délimiteurs <?php et surtout ?> :

Balises d’ouverture et de fermeture de PHP
*** IMPERATIF ***
L’ouverture du code doit impérativement être réalisée avec la balise < ?php (en
minuscules). La fermeture avec la balise ?>.
D'accord pour l'ouverture, mais attention à propos de la fermeture :
A.2.1. Général

Pour les fichiers contenant uniquement du code PHP, le tag de fermeture ("?>") n'est jamais permis[Note de Cyrano : lire "dans l'écriture de classe pour le ZF"]. Il n'est pas requis pas PHP. Ne pas l'inclure permet de prévenir les problèmes liés à l'injection accidentelle d'espaces blancs dans la sortie.

Source : Documentation du Zend Framework
Je corrige

par mcorgnet » 05 janv. 2007, 10:44

Par contre, le fait de les limiter à 80 caractères, c'est clairement voulu. 80 caractères, c'est pile la largeur d'impression sur une page, du coup, quand on commente les lignes, ça devient un réflexe de pratiquer ainsi. Les commentaires sont uniformes, également.
Heu...dans quelle police ? En quel corps ?[/url]
Disons, la police du bloc notes, qui est utilisée à priori dans tous les logiciels de développement.

Quelque soit le caractère que j'utilise sous phpedit, je peux l'envoyer 80 fois avant d'avoir ma barre de fractionnement de la page.

par momox » 04 janv. 2007, 22:22

J'ai la facheuse tendance de mettre les accolades a la ligne pour les if et les else, ainsi que pour les classes et fonctions (sauf en javascript, je sais pas pourquoi :lol:)
Mais sinon, le seul cas ou je mets l'accolade sur la même ligne, c'est pour les switch...

@+

par naholyr » 04 janv. 2007, 17:15

Concernant les accolades j'ai pris l'habitude de faire comme ça :
for() {

}

while() {

}
Je l'ai déjà vu chez d'autre mais je ne sais pas si c'est courant...
C'est en tous cas ma façon de faire. Pour tout ce qui est structure de contrôle (if, else, for, while, etc...) l'accolade ouvrante est sur la même ligne. Ceci me permet d'insister dans la forme sur le fait que la structure de contrôle est une partie intégrante du bloc de code en cours.
À l'inverse les fonctions et classes voient leur accolade ouvrante à la ligne, pour la raison opposée bien sûr ;)

par Rei Itchido » 04 janv. 2007, 16:47

Concernant les accolades j'ai pris l'habitude de faire comme ça :
for() {

}

while() {

}
Je l'ai déjà vu chez d'autre mais je ne sais pas si c'est courant...