Il y a bien les vieux débats comme les tabs et les espaces, mais cette fois la question porte sur l’ajout d’espaces.
Par exemple, imaginons que l’on ait du code comme dans l’exemple ci-dessous.
Dans ce cas, certains préfèrent aligner from et le signe égal sur la même colonne, tandis que d’autres non.
// Case A.
import potato from 'potato';
import sweetpotato from 'sweetpotato';
const red = 0xff0000;
const orange = 0xff8000;
// Case B.
import potato from 'potato';
import sweetpotato from 'sweetpotato';
const red = 0xff0000;
const orange = 0xff8000;
Dites-nous en commentaire lequel des deux cas vous préférez.
Je me demande surtout s’il existe un nom spécifique pour désigner ces styles.
- Je préfère A.
- Je préfère B.
- Je préfère X, mais au travail on utilise Y (...)
10 commentaires
Je préfère B, et dans l’entreprise aussi, nous utilisons B.
Je préfère principalement A.
Mais il m’arrive très occasionnellement de l’utiliser quand je définis plus de 10 lignes de constantes et de variables.
Moi, c’est A. Avec B, si ce n’est pas défini par convention, je trouve ça gênant pour collaborer.
Je préfère A.
Il m'arrive parfois de voir du code écrit par d'autres dans le style B, et à chaque fois je suis impressionné par sa grande lisibilité. Mais dès qu'on code en B, le formateur et le linter font un scandale pas possible, donc je n'ai presque jamais codé ainsi. Et puis c'est aussi un peu pénible à écrire.
Parfois en style B, mais j’écris le code en m’alignant sur la position des tabulations.
Je ne suis pas très fan, parce qu’il y a l’inconvénient que le diff se propage inutilement à d’autres lignes.
Bien sûr, on peut consulter le diff en ignorant les espaces, mais on ne peut pas non plus l’imposer aux autres intervenants ou aux relecteurs de code…
Dans la plupart des cas, je préfère A.
En écrivant du code, il n’y a eu qu’une seule fois où j’ai trouvé qu’un cas comme B était préférable. C’était du code nécessitant une intégration avec une DLL externe, et j’avais utilisé une approche comme B pour des raisons de lisibilité dans la partie où étaient définies diverses constantes à utiliser par cette DLL.
Bien sûr, le fait que ce code d’intégration n’ait pratiquement aucune raison de changer, et qu’une fois écrit je n’aie plus eu à y toucher, fait aussi partie des raisons qui m’ont permis de choisir une approche comme B. S’il s’était agi d’un code modifié fréquemment, j’aurais très probablement maintenu l’approche A.
Je préfère le formatage automatique avec les formatters propres à chaque langage !
(D’habitude, c’est A, mais il me semble que pour
gofmtde Go, c’était B.)A, sans hésiter !
Le style B est pénible à maintenir s’il n’y a pas de formateur dédié, et selon la police l’alignement peut aussi se décaler...