Definitelytyped: Tabulations vs espaces ?

Il n'y a pas de bataille. Utilisez des onglets.

Je vote les espaces !

Que le conflit interne commence ! :le sourire:

haha. nous n'avons pas besoin de ça. Mais vous savez... nous n'aurions pas cette conversation si nous utilisions des tabulations et chaque développeur aurait toujours son code parfaitement aligné comme il le souhaite (2 espaces ou 4 espaces). Je dis juste.

J'aime l'onglet.
mais je pense que nous devrions respecter les paramètres par défaut de VisualStudio.

Espaces avec une taille de retrait de 4 (valeurs par défaut de VS).
Configurez votre IDE pour créer des onglets virtuels pour vous et tout le monde est content.
Je n'aime tout simplement pas voir [tab] [tab] [space] [space] [space] pour le code qui veut s'aligner sur un mot de la ligne ci-dessus.

Si quelqu'un a envie d'écrire une règle TSLint pour appliquer un style cohérent (par exemple : soit des tabulations, soit 4 espaces mais pas les deux), alors nous l'exécuterons dans un nouveau testeur (il prend en charge TSLint).

Voir aussi https://github.com/palantir/tslint/issues/122

Les espaces! Les bibliothèques FWIW JS utilisent des espaces (angular / jquery)

Cela est probablement dû à Crockford : http://javascript.crockford.com/code.html

L'unité d'indentation est quatre espaces. L'utilisation de tabulations doit être évitée car (au moment d'écrire ces lignes au 21ème siècle) il n'y a toujours pas de norme pour le placement des tabstops. L'utilisation d'espaces peut produire une taille de fichier plus importante, mais la taille n'est pas significative sur les réseaux locaux et la différence est éliminée par minification.

Puisque TS est JS, nous devrions vraiment nous conformer.

Eh bien, Crockford est un vieil homme un peu grincheux alors je le prends avec un grain de sel.

Il y a quelque temps, il y avait une statistique sur Reddit où quelqu'un analysait une bonne partie de Github et c'était comme 60% / 40% en faveur des espaces. Moi-même et tous les endroits où j'ai travaillé jusqu'à présent étaient des onglets (bien qu'une grande partie de cela soit AS3). Cela fonctionne tout à fait bien. L'alignement du code est une perte de temps, mais si nécessaire, les onglets intelligents fonctionnent également bien là-bas.

Le vrai fléau dont je veux me débarrasser est le mélange des _indents_. Avant de passer au thermonucléaire sur l'un ou l'autre sur l'ensemble du référentiel, il doit au moins être cohérent _par fichier_.

À un moment donné, nous ferons #2228, mais c'est un grand pas (il bousille beaucoup d'attributions pour que nous puissions laisser @dt-bot le faire).

Eh bien, Crockford est un vieil homme un peu grincheux alors je le prends avec un grain de sel.

D'accord

Si jamais vous vous ennuyez, je vous conseille de lire les pull request faites à JSON.js. invariablement, ils sont soumis par des personnes qui ne connaissent pas les manières légèrement grincheuses de Doug. Ils sont tous refusés catégoriquement :-)

Je viens de voir ceci : https://github.com/iplabs/typescript/blob/languageService-v2/src/services/languageService.ts#L199 -L213 les valeurs par défaut sont 4 espaces avec des tabulations converties en espaces

    export class EditorOptions {
        public IndentSize: number = 4;
        public TabSize: number = 4;
        public NewLineCharacter: string = "\r\n";
        public ConvertTabsToSpaces: boolean = true;

        public static clone(objectToClone: EditorOptions): EditorOptions {
            var editorOptions = new EditorOptions();
            editorOptions.IndentSize = objectToClone.IndentSize;
            editorOptions.TabSize = objectToClone.TabSize;
            editorOptions.NewLineCharacter = objectToClone.NewLineCharacter;
            editorOptions.ConvertTabsToSpaces = objectToClone.ConvertTabsToSpaces;
            return editorOptions;
        }
    }

Quelle satisfaction @basarat !

Les CRLF sont un peu stupides mais peu importe.

Peut-être qu'on devrait juste y aller. Je vais essayer d'exécuter typescript-formatter sur tout et voir ce qui se passe.

Cher seigneur, quel abattoir.. 562 fichiers .d.ts au total, avec 446 fichiers modifiés..

https://github.com/Bartvds/DefinitelyTyped/tree/34907936bfc22562f30bb09ee82282ca0515b8b3

https://github.com/Bartvds/DefinitelyTyped/commit/34907936bfc22562f30bb09ee82282ca0515b8b3

Désolé, nous n'avons pas pu afficher l'intégralité du diff car trop de fichiers (446) ont été modifiés

Il h.

Et fait les tests aussi :

https://github.com/Bartvds/DefinitelyTyped/tree/46f9d17b2b074c887bff35b06112070b28924248

https://github.com/Bartvds/DefinitelyTyped/commit/46f9d17b2b074c887bff35b06112070b28924248

Désolé, nous n'avons pas pu afficher l'intégralité du diff car trop de fichiers (442) ont été modifiés.

Joli. Nous avons donc la technologie, c'était la partie facile. Mais maintenant, nous devons décider si c'est quelque chose que nous voulons, car cela aura un impact sérieux.

Pour une seule ligne, l'attribution va à l'enfer. Et si nous acceptons cela, nous devrions probablement appliquer le formatage dans le testeur. J'ai configuré TSLint dans le testeur (mais il est désactivé) donc cela peut faire beaucoup.

Peut-être devrions-nous améliorer le testeur en un utilitaire CLI qui peut exécuter le formateur et exécuter les tests, d'une manière agréablement utilisable (il fonctionne maintenant en quelque sorte localement mais devrait être amélioré avec une API CLI propre, etc.).

Je dis le plus tôt sera le mieux. Mais la bonne nouvelle est que vous ne perdrez pas l'historique du blâme . J'aurais aimé que GitHub ait également implémenté cette fonctionnalité dans leur vue diff.

Oui, mais ça craint que git blame -w -M ne fonctionne pas en ligne. Je viens d'envoyer un e-mail au support Github à ce sujet.

@Bartvds , une réponse de GitHub ?!

Ignorer les espaces dans la vue de blâme de GitHub n'est pas possible actuellement, mais nous pourrions l'ajouter à l'avenir. Merci pour la suggestion, je vais l'ajouter à la liste des demandes de fonctionnalités afin que l'équipe puisse la voir.

Cela pourrait donc prendre un certain temps, si jamais.

Peu m'importe ce que disent les soi-disant je-sais-tout ou les guides de style - les onglets pour l'indentation sont le seul moyen de préserver l'intention du développeur lorsque l'alignement est impliqué. Voir mon article de blog à ce sujet .

le concept d'alignement du code (aligner sur var et = dans votre cas) est bon. Mais difficile à maintenir dans les refactorings. Donc je ne l'utilise tout simplement pas. De plus, les outils de formatage automatique ne le respectent pas, par exemple le code de formatage automatique dans TypeScript

Aussi pour

  public string FirstName { get; set; }        =>  public  string  FirstName { get; set; }    
  public string Surname { get; set; }          =>  public  string  Surname   { get; set; }
  public int Age { get; private set; }         =>  public  int     Age       { get; private set; }
  private Address Address { get;  set; }       =>  private Address Address   { get; set; } 

Ajoutez une nouvelle propriété et vous devez _reformater_ toutes ces lignes. Pas un bon changement de code à revoir.

Votre flux de travail peut être différent et peut le permettre. Cela le rend beaucoup plus facile à lire (le code en tant qu'art) mais je n'ai pas réussi à faire l'expérience des équipes qui y évoluent.

C'est la chose la plus étrange. Ma réaction instinctive à l'idée de mélanger les onglets et les espaces est de frissonner et de penser "c'est juste sale !"

Complètement irrationnel je sais - mais tout à fait sincère. Les humains sont bizarres...

@johnnyreilly, vous êtes victime d' une idée reçue . Utiliser des tabulations pour l'indentation et des espaces pour l'alignement n'est PAS la même chose que _mixer_ des tabulations avec des espaces. Vous n'avez clairement pas lu le billet de blog.

L'utilisation d'onglets pour l'alignement est la raison pour laquelle tant de personnes ont été désactivées des onglets, car les gens le faisaient mal. S'ils l'avaient fait correctement en premier lieu, personne n'aurait remarqué quand ils ont changé la préférence de leur éditeur pour afficher la largeur des onglets à une taille différente. C'est ce que le gif animé, ci-dessus, essaie de démontrer, comment les gens ont mal fait.

@basarat , je suis tout à fait d'accord avec toi. Je travaille rarement sur des projets avec alignement de code, mais je le vois de temps en temps. Si vous pouviez d'une manière ou d'une autre faire en sorte que les développeurs de votre projet n'utilisent pas du tout l'alignement, alors je vous dirais d'y aller. Sinon, avec des espaces pour l'indentation, il n'y a aucun moyen pour les outils de lint, entre autres, de faire la distinction entre ce qui était destiné à l'indentation et ce qui était destiné à l'alignement, en dehors de l'analyse du code dans CST (way overkill).

Bien sûr, il existe une foule d'autres raisons de ne pas utiliser d'espaces pour l'indentation en cette ère moderne. Les éditeurs gèrent bien les tabulations, mais jamais les espaces. Navigation par touches fléchées, suppression, retour arrière - ils ne traitent tout simplement pas un retrait d'espaces comme une unité. J'ai utilisé Visual Studio, Sublime, PHPStorm et Notepad++, mais ils ont tous ce problème fondamental avec les espaces pour l'indentation.

Navigation par touches fléchées, suppression, retour arrière - ils ne traitent tout simplement pas un retrait d'espaces comme une unité.

Navigation : j'utilise ctrl + touches fléchées. Ils sautent des espaces (tous des espaces blancs vraiment) + des mots.

Pour la suppression/le retour arrière : pour la sélection de mots, j'utilise le mot d'extension (ctrl+w à partir des valeurs par défaut du réaffûteur) et la sélection de développement (ctrl+shift+w). J'ai rarement besoin de sélectionner _inside_ whitespace cependant, utilisez simplement tab (augmenter le retrait) et shift tab (diminuer le retrait).

@jedmao en fait, j'ai compris votre point - je partageais juste ma réaction instinctive (et irrationnelle). Je n'ai pas dit que c'était logique :sourire:

@johnnyreilly gotcha.

@basarat J'utilise les Home et End dans certains de vos scénarios d'espaces. J'ai essayé d'utiliser la navigation Ctrl + arrow key mais cela ne fonctionne pas toujours. C'est pourquoi je l'utilise rarement par cohérence mentale. Considérez l'exemple suivant :

for (var i = 0; i < 10; i++) {
    if (i > 5) {
        console.log('I am greater than 5');
    }
}

Supposons que mon curseur se trouve au début de la ligne 3 et que je souhaite naviguer jusqu'au début de la ligne 2.

En utilisant votre technique dans Sublime, je pourrais le faire de 2 manières :

• Up , Hold Ctrl , Left , Release Ctrl (4 étapes logiques)
• Hold Ctrl , Left , Release Ctrl , Up , Hold Ctrl , Right , Left , Release Ctrl (8 étapes logiques)

Dans Visual Studio, le 2ème scénario peut être réduit à 7 étapes logiques.

• Hold Ctrl , Left , Release Ctrl , Up , Hold Ctrl , Right , Release Ctrl (7 étapes logiques)

Avec les caractères de tabulation réels, le chemin le plus court n'est que de 2 étapes logiques sans touches de modification. Rien de plus simple.

• Left , Up

Je ne vois pas comment la sélection de mots aiderait à supprimer ou à reculer un retrait espacé. Je l'essaye dans Visual Studio sans succès. C'est pourquoi j'ai créé le plugin TabSanity pour Visual Studio . Malheureusement, je ne connais pas de tels plugins pour d'autres éditeurs.

Avec les caractères de tabulation réels, il s'agit toujours de 2 étapes logiques sans touches de modification. Rien de plus simple

:+1: Je vois votre avantage. Cependant, lorsque j'édite ce commentaire, ctrl etc. fonctionne de la même manière que mon VS, donc mes habitudes se perpétuent ;)

Je ne vois pas comment la sélection de mots aiderait à supprimer ou à reculer un retrait espacé

Mon mauvais, ma description était confuse. Ignorer le bit de sélection "mot". Concentrez-vous simplement sur I rarely need to select inside whitespace though, just use tab (increase indent) and shift tab (decrease indent). Cela fonctionne très bien avec les retraits espacés.

Avec les caractères de tabulation réels, il s'agit toujours de 2 étapes logiques sans touches de modification.

Qu'en est-il de :

public  string  FirstName { get; set; }    
public  string  Surname   { get; set; }
public  int     Age       { get; private set; }
private Address Address   { get; set; } 

Est-ce que le début de Age changerait pas le type de Surname c'est- string de la ligne précédente serait le même que le scénario Ctrl ?

@basarat J'utilise Tab et Shift+Tab religieusement ; cependant, généralement pour plusieurs lignes de code. Je suppose que vous pourriez dire que Shift+Tab est un bon alias pour une touche backspace sur un onglet, mais ce n'est clairement pas aussi simple ou intuitif qu'un backspace .

Ctrl+Delete serait l'alias le plus proche de la clé Delete , mais il a le potentiel de supprimer plus d'un retrait ; alors qu'une simple touche Delete sur un onglet supprime un seul retrait. Travailler parfois et pas les autres est la raison pour laquelle je ne l'utilise pas du tout (cohérence mentale).

Comme vous, j'ai aussi rarement, voire jamais, besoin de sélectionner à l'intérieur des espaces. Je n'ai jamais suggéré que je le ferais. Je ne sélectionne pas l'espace blanc, mais je le parcoure pour aller quelque part. Votre exemple d'alignement ci-dessus est certainement quand j'utiliserais la navigation Ctrl + arrow key . C'est pourquoi, comme je l'ai déjà dit, j'utilise rarement la navigation Ctrl + arrow key car le scénario que vous avez indiqué est probablement le seul cas dans lequel je l'utiliserais.

En fin de compte, ce qui me dérange le plus, c'est que vous devez changer totalement votre mémoire musculaire lorsque vous basculez entre un fichier avec des onglets pour l'indentation et des espaces pour l'indentation. Ce qui est efficace (le moins d'étapes logiques) dans un fichier avec des onglets pour l'indentation ne fonctionne tout simplement pas dans un fichier avec des espaces pour l'indentation. Vous pourriez reprocher aux éditeurs de ne pas vous offrir une expérience transparente, mais ce n'est pas juste car il est littéralement impossible (sans CST) pour les éditeurs de faire des hypothèses dans un fichier avec des espaces pour l'indentation sur ce qu'est un retrait et ce qu'est l'alignement.

Ce qui est encore plus frustrant, c'est qu'il est si difficile pour les gens de le reconnaître. Les espaces pour l'indentation sont du mal pur... avec des cornes.

Conclusion finale? Je veux juste contribuer, qu'est-ce que tu utilises ?

Conclusion finale? Je veux juste contribuer, qu'est-ce que tu utilises

Cohérent par fichier. Ne les mélangez pas dans un fichier

@basarat la bande dessinée est fausse. Nous savons tous que le gars d'Apple utiliserait des espaces et le gars de Microsoft utiliserait des onglets.

@jedmao je suis un gars ms et j'utilise des espaces :)

Je pense que #4211 est une belle proposition.

Je proposerais d'utiliser 2 espaces comme dans le guide de style airbnb/javascript ...

Suggestion : Utilisez les normes de codage définies par la bibliothèque en cours de saisie. Si la bibliothèque en cours de saisie utilise des espaces, des guillemets simples et des LF, faites de même dans la définition de type. De cette façon, nous pouvons éviter l'argument espaces vs tabulations.

Le seul problème est qu'il ne sera pas facile de faire respecter cette règle. Si vous avez besoin de l'appliquer et d'avoir une cohérence totale, je vous recommanderais d'utiliser les conventions les plus populaires. Selon ce site, il s'agit d'espaces et de guillemets simples.

Ma préférence personnelle est les espaces (4) et les guillemets _doubles_, mais j'accepte d'utiliser des guillemets simples si cela signifie que tout est cohérent.

Les utilisateurs de pro-tab et pro-tab-space pourraient-ils accepter un compromis similaire ?

Ma préférence personnelle est les espaces (4) et les guillemets doubles, mais j'accepte d'utiliser des guillemets simples si cela signifie que tout est cohérent.

@glen-84 uniquement pour votre amusement ... voici pourquoi l'équipe du compilateur a utilisé des guillemets doubles : https://github.com/Microsoft/TypeScript/issues/5811#issuecomment -160187924

• JSON
• Fonctionne dans toutes les langues, donc moins de charge cognitive

Personnellement, je vais moi-même avec des guillemets simples car je me retrouve à faire de plus en plus de TypeScript exclusivement :rose:

Je pense que c'est aussi un peu plus lisible, et c'était 57% contre 43% (pas une grande différence), mais je suppose qu'il faut tracer la ligne quelque part. =)

J'aime le point de @jedmao sur les onglets pour l'indentation et les espaces pour l'alignement.

Divulgation complète : je viens du Go-land où nous avons go fmt et aucune discussion sur les tabulations ou les espaces jamais.

Des espaces bien sûr. Parce que personne ne sait comment les onglets sont rendus exactement dans différents éditeurs s'ils sont utilisés ailleurs.

@hinell, pourquoi est-ce important que les onglets soient rendus différemment dans différents éditeurs ? Il ne devrait pas, tant que les onglets sont "uniquement" utilisés pour l'indentation.

Je préfère les onglets, surtout à cause de ça : http://nickgravgaard.com/elastic-tabstops/

Il s'avère qu'il existe une raison encore plus importante d'utiliser les onglets : l' accessibilité des développeurs .

• https://github.com/prettier/prettier/issues/7475
• https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/