-
indenter avec des espaces :
127(6.1 %)
-
traiter le XML sans parseur XML :
99(4.7 %)
-
faire des boucles avec goto :
74(3.5 %)
-
nommer des variables d’une lettre :
108(5.2 %)
-
ne pas gérer la mémoire :
112(5.3 %)
-
créer du logiciel privateur :
180(8.6 %)
-
assumer de n’avoir aucune honte :
186(8.9 %)
-
celle que je (re)découvre en lisant mon code d’il y a deux ans :
547(26.1 %)
-
coder directement en production :
357(17.0 %)
-
tester, c’est douter :
307(14.6 %)
Total : 2097 votes
# suggestion
Posté par Pol' uX (site web personnel) . Évalué à 5.
[x] de celles que je (re)découvre en lisant mon code d'il y a deux ans
Adhérer à l'April, ça vous tente ?
[^] # Re: suggestion
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Ajoutée, merci.
# Indenter avec des espaces
Posté par Eh_Dis_Mwan . Évalué à 10.
Il me semble que c'est ce qui est conseillé pour python. Non ?
[^] # Re: Indenter avec des espaces
Posté par Maclag . Évalué à -4. Dernière modification le 17 mars 2019 à 01:07.
Ma réponse va faire cliché mais…
Si tout le monde devant toi marche et tombe de la falaise, tu suis?
(Je n'ai pas d'opinion sur les espaces et indentations, c'est juste sur le principe)
[^] # Re: Indenter avec des espaces
Posté par Peter Moulder . Évalué à 3.
À mon expérience, c'est surtout ceux qui emploient des tabulations qui tombent de la falaise, principalement à cause de différences entre logiciels.
Mais c'est peut-être parce que moi et mes collègues ont tendance d'employer un logiciel (tel que vim ou emacs) qui gère bien les espaces et les changements d'indentation ; quels sont les problèmes des espaces, à part la taille du fichier ?
[^] # Re: Indenter avec des espaces
Posté par BFG . Évalué à 10.
La tabulation est sémantique, c'est un caractère dédié à l'indentation, à ajouter un niveau de profondeur, pas forcément à son aspect visuel. Une espace est un caractère uniquement visuel, qui n'est pas de l'indentation.
Les tabulations servent à l'indentation et les espaces à l'alignement, ce qui sont deux choses très différentes.
Chacun son rôle, et nul besoin de se baser sur une certaine longueur de tabulation. Par exemple une largeur de 8 :
Et pour un éditeur configuré avec une largeur de tabulation de 4, nul besoin de changer un quelconque octet, l'affichage s'adapte et reste aligné :
[^] # Re: Indenter avec des espaces
Posté par Anonyme . Évalué à 4. Dernière modification le 18 mars 2019 à 09:14.
Cette façon de faire ferait une erreur en python, il est interdit de mélanger espaces et tabulations.
[^] # Re: Indenter avec des espaces
Posté par raphj . Évalué à 3.
Non, parce que l'indentation n'est pas analysée entre les parenthèses.
[^] # Re: Indenter avec des espaces
Posté par BFG . Évalué à 1.
Avez-vous vraiment testé ? Même en utilisant
-Wall
, il n'y a aucune erreur ni aucun avertissement.[^] # Re: Indenter avec des espaces
Posté par Eh_Dis_Mwan . Évalué à 3.
De là à avoir honte pour suivre les préco ? Tu es sérieux ?
[^] # Re: Indenter avec des espaces
Posté par malt . Évalué à 10.
En effet il est vivement conseillé d'indenter avec des espaces:
REF PEP8
[^] # Re: Indenter avec des espaces
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
J'ai hésité à ajouter l'indentation avec des tabulations, mais j'ai supposé que ça génèrerait plus de débat sans, et que l'auteur voulait la même chose. Avec des tabulations de cinq caractères évidemment (et UTF-16 comme il se doit).
[^] # Re: Indenter avec des espaces
Posté par marty314 . Évalué à -2.
L'idéal est normalement de configurer son éditeur afin qu'il transforme les tabulations en espace mais j'vais pas la ramener je fais les espaces à la main la plupart du temps… (fut une époque où je configurais VIM mais j'ai pas l'impression que le gain de temps soit réel)
[^] # Re: Indenter avec des espaces
Posté par 2PetitsVerres . Évalué à 7.
Les gens qui utilisent des espaces sont mieux payés, en tout cas.
Du coup ils devraient avoir honte d'être vénaux, effectivement.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
# Le choix multiple serait intéressant
Posté par marty314 . Évalué à 2.
Pour ma part il faudrait plusieurs choix :
Indenter avec des espaces
Ne pas gérer la mémoire
Coder directement en production
Tester c'est douter
-> Le meilleur environnement de test c'est la production ?
Bref je code avec les pieds
[^] # Re: Le choix multiple serait intéressant
Posté par BAud (site web personnel) . Évalué à 2.
pour voter plusieurs fois, suffit de le faire sur plusieurs jours ;-) ou en changeant d'IP (boulot / chez soi / wifi d'un troquet - ou de plusieurs :p)
cf. https://linuxfr.org/aide#aide-sondage
ouah, belle dextérité des orteils \o/
# coder sans savoir où l'on va
Posté par saltimbanque (site web personnel) . Évalué à 6.
la meilleure des pires pratiques, débuter l'écriture alors que l'on n'a pas conçu de modèle. Ma fonction servira t'elle vraiment telle quelle? faudra t'il en jeter la moitié? où suis-je simplement en train de perdre mon temps en partant dans la mauvaise direction? mieux vaudait reprendre un verre pour se donner de la force.
# De ne pas être omniscient
Posté par sizvix (site web personnel) . Évalué à 4.
Ne pas être omniscient sur quelque-chose que je code U
( syndrome de l'imposteur :-/ )
Essaie pour vivre sans brider les utilisateurs https://www.indiegogo.com/projects/iwinote
# Retour de fonction
Posté par David Marec . Évalué à 3. Dernière modification le 18 mars 2019 à 13:13.
A mettre dans la même catégories que "ne pas gérer la mémoire".
{str|mem}cpy
et cie.[^] # Re: Retour de fonction
Posté par goeb . Évalué à 2. Dernière modification le 19 mars 2019 à 21:15.
Ok, je suis d'accord.
Mais pour printf ? Qui contrôle le retour de printf ? (en langage C)
[^] # Re: Retour de fonction
Posté par fearan . Évalué à 2.
pourquoi contrôler le retour de strcpy, ça renvoi le pointeur destination ? Pareil pour memcpy, dans quel cas ces fonctions peuvent elles renvoyer autre chose que la destination?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Retour de fonction
Posté par Anthony Jaguenaud . Évalué à 4.
Je vois un cas d’usage dont il ne faut pas abuser pour la lecture…
[^] # Re: Retour de fonction
Posté par David Marec . Évalué à 3.
Oui, un test utile serait le le suivant:
[^] # Re: Retour de fonction
Posté par Anthony Jaguenaud . Évalué à 2.
Non, si ta source est plus petite que str, le dernier caractère ne sera pas écrit… et rien ne prouve qu’il vaille '\0'.
[^] # Re: Retour de fonction
Posté par David Marec . Évalué à 3.
Man strncpy:
Donc, si la source est plus petite que la cible, il remplira la cible de
0
.Si elle est égale, le caractère
null
est inclu.Sinon, il n'y avait pas assez de place pour copier la source en entier.
[^] # Re: Retour de fonction
Posté par Anthony Jaguenaud . Évalué à 2.
Ok, je ne pensais pas. Merci d’améliorer ma culture.
# Je cumule les tares
Posté par Nibel . Évalué à 3. Dernière modification le 18 mars 2019 à 15:02.
[x] traiter le XML sans parser XML (parce que la flemme après 10h de code :p)
[x] assumer de n'avoir aucune honte
[x] celle que je (re)découvre en lisant mon code d'il y a deux ans (notamment, hurler au con qui n'a pas parser son XML… et se rendre compte que ce con, c'est moi…)
[x] coder directement en production (histoire de recevoir ma dose quotidienne d'adrénaline)
[x] tester c'est douter (et puis faut bien qu'ils travaillent à la QA aussi)
Il manque le multi-choix sur ce sondage.
Mais que voulez-vous, j'aime vivre dangereusement…
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Je cumule les tares
Posté par Lutin . Évalué à 6.
Si tu coches "assumer de n'avoir aucune honte" tu ne peux cocher aucune autre case en toute logique, cette réponse est d'ailleurs elle même contradictoire au vu de la question posée.
[^] # Re: Je cumule les tares
Posté par fearan . Évalué à 2.
pourquoi en avoir honte
en travail collaboratif, c'est le seul moyen de ne pas avoir de code qui ressemble à rien
pourquoi en avoir honte? parfois c'est nécessaire (j'ai du faire du code perl qui prenait du code xml (bien formé) pour multiplier les petits blocs en fonction de certaine directives ;), devoir faire la même en xml aurai nécessité du DOM, avec recherche dans les attributs / textNodes / balise des chaines à cloner puis remplacer…
pour un compteur, i,j,k,l je ne vois pas le problème
En fait c'est du code plus vieux qui me fait honte ;)
jamais fait, mais un gdb sur le serveur de prod, malheureusement oui.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Je cumule les tares
Posté par vv222 . Évalué à 3.
Là je vais avoir besoin que tu expliques à quoi tu penses.
De ce que je vois, le code est propre s’il est indenté seulement avec des espaces, ou seulement avec des tabulations. Et il devient peu lisible à partir du moment où on les mélange
Mais je ne vois pas ce qui fait d’un code indenté uniquement avec des tabulations quelque chose qui ne « ressemble à rien », alors que le même code indenté uniquement avec des espaces serait propre.
[^] # Re: Je cumule les tares
Posté par fearan . Évalué à 4.
le soucis c'est l'alignement lors des retours à la ligne, certains vont faire les tabulations complètes suivies de quelques espaces, là où d'autre feront tout en espace, et enfin des qui vont mixer indentation + alignement.
Pour ceux qui n'ont pas les mêmes taille de tabulation ça fout la zone.
Je suis d'accord sur le fait que les espaces sont un pis-aller, mais ça à le mérite d'être très simple à imposer via des règles de pré-commit.
J'ajoute que certains s'amusent à coder avec les police de caractère à chasse variable, et là c'est le festival ;) mais ce n'était pas le sujet.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Je cumule les tares
Posté par Nibel . Évalué à 2. Dernière modification le 20 mars 2019 à 16:57.
Chez nous, on a obligé tout le monde a avoir la même taille de tabulation. Nous utilisons tous les mêmes IDE (Netbeans pour Spring/Java, VSC pour Angular grossièrement) et avec la même configuration. C'est d'ailleurs une des premières choses à faire à l'installation de son poste.
C'était surtout pénible sur les commits sur SVN (git n'a pas ce problème) où l'indentation était prise comme une modification de code… Bon courage pour la review :D.
On a la chance de n'avoir personne qui n'indente à coup d'espace. C'est une bonne pratique plutôt bien assimilée.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Je cumule les tares
Posté par fearan . Évalué à 2.
2? 4? 8?
Chez nous aussi c'est imposé mais ça fait râler ceux qui n'ont pas leur taille favorite, d'ailleurs si c'est que indenté que via tabulation quel est l'intérêt de forcer leur taille?
Aië, pourquoi pas intelliJ?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Je cumule les tares
Posté par Nibel . Évalué à 3. Dernière modification le 20 mars 2019 à 19:00.
4 après vote. Mais ça ne fait pas tant râler que ça, la plupart s'y sont fait rapidement…
Comme dit précédemment, les commits sous SVN prenaient en compte la taille de tabulation, une ligne modifiée par un dev avec une taille de tabulation différente rendait le fichier totalement modifié => insupportable en code review.
Raison historique. Beaucoup préféreraient IntelliJ en effet. Je n'ai aucune affinité pour Java me concernant et j'avoue ne pas avoir d'avis sur la question. Je me contente de Netbeans même si je râle régulièrement sur sa lenteur…
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Je cumule les tares
Posté par vv222 . Évalué à 4.
Ce que tu rapportes ici est étrange, une tabulation n’ayant pas de taille définie. C’est d’ailleurs une des propriétés qui la rendent intéressante pour l’indentation de code.
Bien sûr, si tu utilises un IDE qui les convertit en espaces ça change tout.
[^] # Re: Je cumule les tares
Posté par vv222 . Évalué à 2.
Là tu compares seulement l’utilisation exclusive d’espaces et le mélange tabulations/espaces ;)
Ce souci ne se présente pas lors de l’utilisation exclusive de tabulations, situation dans laquelle on n’aligne pas lors des retours à la ligne.
Un exemple récent dans un de mes bouts de code, qui n’utilise que des tabulations :
https://framagit.org/vv221/play.it-api/blob/128df17d7e2258e71e053078a4b5f81a602a26bc/app/Archive.php#L134
Dans cet exemple, quelle que soit la taille des tabulations à l’affichage la présentation restera similaire.
# hall of shame
Posté par steph1978 . Évalué à 2. Dernière modification le 18 mars 2019 à 20:19.
avec comme convention :
ça donne:
[^] # Re: hall of shame
Posté par steph1978 . Évalué à 6. Dernière modification le 18 mars 2019 à 22:10.
bon, ok, là j'ai honte…
# traiter le XML sans parser XML
Posté par steph1978 . Évalué à 4.
Même pas honte ! C'est pas moi qui ait commencé à stocker des données tabulaires dans un format trop compliqué alors que du CSV aurait largement fait le taf. #overengineering
# fonctions trop longues
Posté par Seb . Évalué à 3.
De mon côté j'ai honte de ma tendance à faire des fonctions de 600 ou 700 lignes sans segmentation.
Mais au moins ça me permet de réviser mon catalogue d'insulte quand je reprends le code qq mois après.
# Le test
Posté par 2PetitsVerres . Évalué à 7.
Les tests ne servent qu'aux gens qui font des erreurs. Pour tous les autres, les tests ne servent à rien.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Le test
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4.
Et les sauvegardes c'est pour les faibles, c'est ça ?
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Le test
Posté par nico4nicolas . Évalué à 5. Dernière modification le 20 mars 2019 à 09:42.
Ca me rappelle un collègue qui disait choisir de ne pas écrire de bug alors que je prétendais laisser des bugs volontairement pour me laisser un peu travail.
# Commentaire supprimé
Posté par Oumarali . Évalué à -7. Dernière modification le 24 mars 2019 à 18:39.
Ce commentaire a été supprimé par l’équipe de modération.
# et le copier / collé alors
Posté par Old Geek . Évalué à 4.
C'est tellement horrible que ce n'est même pas dans les choix du sondage ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.