Js-beautify: Prend en charge le premier style de virgule de déclaration de variable

Étant donné que nous prenons en charge à la fois JS et Python, le correctif (qui est gravement obsolète) est au mieux incomplet.

Nous sommes ouverts aux demandes de tirage, mais je considère personnellement que "la virgule d'abord" est un anti-modèle. À la base, js-beautifier a une opinion sur l'apparence de JS, avec des options raisonnables qui sont largement conformes au JS "idiomatique" largement accepté. La virgule d'abord n'est, à mon avis, pas belle et n'est pas non plus largement acceptée. De plus, cela compliquera sévèrement le code embellisseur (qui est déjà incroyablement compliqué) pour très peu de gain.

Avec indent=4 défini, quelle indentation est appropriée ? Du point de vue de la cohérence, je dirais ceci :

var a = 1
    , b = "foo"
    , c = false;

Ce qui n'est clairement pas le résultat attendu. Et à quoi cela ressemblerait-il avec les retraits de tabulation ?

Où vit le point-virgule ? À la fin? Nulle part? (J'ai vu les deux, et plus)

Cet aperçu est tout aussi obsolète, mais facilite la compréhension du changement souhaité : https://gist.github.com/nemtsov/2864266/revisions

Ceci est similaire à #80, alors j'ai pensé que les raisons pourraient être les mêmes - une différence et une réorganisation plus faciles.

Mais dans ce scénario, contrairement à #80, il existe une solution de contournement viable qui répond à ces exigences :

var a = 1;
var b = "foo";
var c = false;

C'est un peu plus bavard, mais pas horrible.

Bien sûr, si quelqu'un implémente #80, le changement le plus simple couvrirait probablement aussi ce scénario.
Comme l'a dit @evocateur , les pull request sont les bienvenues.

@evocateur : Vous avez droit à votre avis et je le respecte. Personnellement , je l' ai toujours détesté par des virgules premier style , mais tout au long des années, je suis venu à apprécier la facilité de se déplacer, sortir (commentaires, suppression , etc.) et comme le dit @bitwiseman - diffing. Je suis donc prêt à laisser cela en option et à laisser l'utilisateur faire ce qu'il préfère. Parfois, ce n'est pas entre ses mains et il doit se conformer à des normes déjà établies. Ouais, moche mais réalité !

@bitwiseman : À n'importe quel niveau d'indentation (2 ou 4), je suppose que c'est à quoi cela devrait ressembler :

var a = 1
  , b = "foo"
  , c = false;

Je pense que cela est également cohérent avec la façon dont certains éditeurs SQL (où la virgule en premier est plus répandue) le font.

Et bien que je ne préconise pas la promotion de mauvaises mises en page, je suppose qu'il y a toujours une ligne fine entre être idiomatique et dogmatique (pensez à Crockford ici). La virgule d'abord peut ne pas être répandue car de nombreux formateurs ne la prennent pas en charge, quelle qu'en soit la raison.

Vous êtes plus familier avec l'état des choses en termes de code, donc je suis parfaitement d'accord avec votre argument de retour sur investissement. Néanmoins, j'ai pensé à demander pour que nous puissions faire connaître ces choses au grand jour, avoir un quorum pour discuter des choses et s'il y a une demande de la communauté, peut-être que vous pouvez y repenser.

PS J'ai passé quelques heures à essayer de voir si je pouvais rapidement créer quelque chose et je n'ai pas eu beaucoup de succès. Peut-être que je vais essayer une autre fois.

@mrchief Mes excuses pour avoir été brusque hier, je faisais une pause après une session de débogage frustrante. Vous faites valoir de bons arguments et je tiens à préciser que je respecte également votre choix. J'essaie moi-même de maintenir le style d'un projet donné si je contribue à un correctif (virgule d'abord, sans point-virgule, autre farce), et je suis d'accord que des options comme celles-ci peuvent au moins aider à imposer un peu de cohérence dans les projets qui choisissent de les employer.

+1. J'utilise le modèle de virgule d'abord pour ses avantages lors de la différence et de la fusion.

Quant à la position du point-virgule : je l'ai mis dans une nouvelle ligne, en ligne avec le mot-clé var , comme ceci :

var a
  , b
  , c
;

J'ai vu plusieurs projets qui utilisent le même modèle.

De plus, à mon humble avis, je pense qu'il serait bien de pouvoir conserver chaque variable dans une ligne distincte, même si aucune valeur n'est donnée à côté de la déclaration. Dans l'exemple ci-dessus, l'embellisseur regrouperait tout sur une seule ligne var a, b, c; ce qui brise également l'objectif d'utiliser le style poing virgule.

+1 pour le support de la virgule d'abord.

Avec l'indentation à 2 espaces, c'est la manière la plus ordonnée d'organiser les variables :

var foo = true
  , bar = 'hello'
  , something;

Qu'en est-il de 4 espaces par onglet ? Onglets réels ?

Le vendredi 8 novembre 2013 à 9h36, Luke Martin [email protected]
a écrit:

+1 pour le support de la virgule d'abord.
À l'indentation à 2 espaces, c'est la façon la plus ordonnée d'organiser les variables
var foo = vrai
, barre = 'bonjour'

, quelque chose;

Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/einars/js-beautify/issues/245#issuecomment -28081629

Je suppose que le nœud du problème de la première virgule se résume en fait à la préférence de tabulation.

J'utilise des tabulations à 2 espaces, et la virgule avant est le seul moyen d'organiser les variables sans ajouter d'espaces inutiles (~ représentent des espaces supplémentaires ajoutés pour aligner les choses):

// eww
var foo = true,
  ~~bar = 'hello',
  ~~something;

// yum
var foo = true
  , bar = 'hello'
  , something;

Inversement, si vous utilisez des tabulations à 4 espaces, la virgule avant aura l'air mauvaise, et vous ne vous soucierez naturellement pas de la prise en charge.

// also eww
var foo = true
    , bar = 'hello'
    , something;

Il y a donc une discussion sur la virgule avant d'être plus facile à commenter et à déboguer et bla bla bla. Mais pour moi, c'est juste une question d'esthétique. J'utilise des tabulations à 2 espaces, je dois donc utiliser une virgule avant. Actuellement, je ne peux pas utiliser embellir car j'ai une préférence pour les onglets à 2 espaces.

Maintenant, je sais que je suis probablement en minorité, et je n'exige absolument pas de soutien pour ma petite préférence. J'ajoutais juste mon +1 à la conversation. Je pourrais même envisager d'ajouter un support moi-même si j'ai le temps.

À votre santé :)

J'aimerais voir cela pour les objets json.

 var a = ({
 un : 1
 ,b : 2
 });

@lukemartin C'est une perspective intéressante ! :+1:

Un autre +1 pour la première prise en charge des virgules, pour la déclaration de variables ainsi que pour les tableaux et les objets - https://gist.github.com/isaacs/357981

J'ai travaillé sur un correctif pour prendre en charge cette fonctionnalité "à la demande" (l'utilisateur peut activer ou désactiver l'option d'utiliser d'abord la virgule avec un paramètre que j'ai créé).

J'ai obtenu le formatage suivant pour la déclaration de variable (en utilisant 2 espaces):

var firstVar = 1
  , secondVar = 2
  , thirdVar = 3
;

Mais j'ai quelques doutes.

Comment traiter les tableaux, les objets et les déclarations d'arguments ? Dernièrement, j'utilise le format suivant :

myArray = [
  item1
, item2
, item3
];

myObject = {
  prop1: 1
, prop2: 2
, prop3: 3
}

Ce qui, comme vous pouvez le voir, n'est pas exactement le même que le formatage de déclaration de variable : ce dernier inclut un niveau d'indentation +1 pour la deuxième variable (notez les deux espaces avant la virgule qui ne sont pas présents avant la virgule pour "item2" ni pour celui pour "prop2"). Les déclarations Var utilisent cette indentation supplémentaire afin d'aligner dans la même colonne le début de chaque nom de variable comme indiqué par @lukemartin.

Les raisons de l'utilisation de la mise en forme indiquée sur le code ci-dessus sont :

1.- Pour éviter les erreurs de linting qui seraient générées par jshint (erreurs d'indentation). Par exemple:

myArray = [
    item1
  , item2
];

Lance "Expected ] pour avoir une indentation à 3, au lieu de 1". Si nous suivons la suggestion, nous obtenons un résultat très laid.

2.- Pour conserver l'avantage d'aligner le début de chaque nom de propriété, élément de tableau, etc. Par exemple :

myArray = [
  item1
  , item2
];

Ne produit pas non plus d'erreur de linting, mais n'a pas l'air aussi joli que les exemples ci-dessus.

Avec une idée plus claire de la façon dont je devrais traiter ces cas, je pourrais terminer la mise en œuvre de cette fonctionnalité et émettre une demande de tirage.

Est-il possible de prendre en charge tout ce qui précède ? Tout ce que vous avez indiqué est techniquement "la virgule d'abord".

Je crois que cela pourrait être possible, mais il serait nécessaire de mettre en œuvre plus de paramètres qui permettraient à l'utilisateur d'atteindre le résultat souhaité. Par exemple, il serait nécessaire d'indiquer au formateur si vous souhaitez utiliser 2 niveaux d'indentation pour les tableaux, les objets et les arguments ou un seul.

Je pense qu'il serait préférable d'atteindre d'abord la fonctionnalité de base, puis de l'étendre avec plus de paramètres. Je pense que je n'aurais aucun problème à les implémenter dans un deuxième patch.

Comme vous le dites, la fonctionnalité de base est très bien. C'est un _non-objectif_ de ce projet de prendre en charge _toutes_ les options de formatage. :le sourire:

// 2-space indents
var itemA = 1
  , itemB: 2
  , itemC: 3;

myObj = {
  itemA: 1
  , itemB: 2
}

myArray = [
  item1
  , item2
];

// 4-space indents
var itemA = 1
    , itemB: 2
    , itemC: 3;

myObj = {
    itemA: 1
    , itemB: 2
}

myArray = [
    item1
    , item2
];

Ceux-ci devraient garder votre code simple, le formatage cohérent, quels que soient les retraits utilisés, et nous permettent de fermer ce problème et d'ouvrir un nouveau problème pour "Columnize virgule first identifiers" (ou autre) qui peut être spécifié et implémenté séparément .

J'ai hâte de voir votre pull request !

@tgirardi Excellent travail. J'ai hâte d'essayer ça.

Tous les commentaires sont les bienvenus :-) !!!

Mon idée est d'ajuster le code jusqu'à ce qu'il soit considéré comme la bonne solution, puis de procéder avec la liste TODO suivante :

1.- Créer des tests pour cette nouvelle fonctionnalité
2.- Appliquer la fonctionnalité sur la version Python (Si quelqu'un se porte volontaire pour cela, c'est encore mieux ! ... Je n'ai pas beaucoup d'expérience avec python).
3.- Discutez d'autres variantes possibles des styles de virgule d'abord

Retrait de 4 espaces

var x = a
    , y = b
;
obj = {
    attr1: "value1"
    , attr2: "value2"
    , attr3: "value3"
};

Les noms de variables et les noms d'attributs n'ont pas besoin d'être alignés. Cela n'affecte en rien la lisibilité. À mon avis, la principale raison de l'utilisation de la colonne en premier est de faciliter les commentaires, la suppression et l'insertion de lignes. Il arrive juste de s'aligner lors de l'utilisation d'un retrait à 2 espaces.

La demi-colonne doit être sur sa propre ligne après la déclaration de plusieurs variables pour faciliter l'ajout d'une nouvelle variable après 'y'. Dans ce cas dans VIM, 'o' + ', z = c' au lieu de '$a,' + 'z = c'

@lewisdiamond Je suis d'accord avec votre commentaire de point-virgule. L'avoir dans sa propre ligne garantit que la dernière variable peut également être facilement modifiée (supprimer, remplacer, insérer une ligne après/avant, etc.).

Mais il a également été noté que :

1.- Ce n'est pas le but du projet de prendre en charge toutes sortes de formatage.
2.- Ajouter trop de complexité à la fois est une mauvaise idée. Il pourrait donc être préférable de garder cette fonctionnalité aussi simple que possible et de commencer à l'améliorer après qu'elle ait atteint un état de version et qu'elle ait été testée pendant un certain temps.

+1 pour le support par virgule d'abord, et je suis d'accord avec le sentiment de Lewisdiamond selon lequel s'assurer que les onglets s'alignent correctement ne devrait pas être l'objectif final car il y a des raisons pragmatiques pour le style d'abord par virgule. J'aimerais aussi prendre en charge json. Actuellement, j'ai un hack dans le code global js-beautify pour faire beaucoup d'alternatives à la ponctuation d'abord (pour les opérateurs ternaires, c'était un must).

À tous ceux qui ont attribué +1 à ceci : veuillez jeter un œil à la branche https://github.com/beautify-web/js-beautify/tree/feature/comma-first .

Dites-moi si c'est une première étape suffisante vers ce que vous voulez que je devrais l'ajouter à la prochaine version.

@olsonpm , @lewisdiamond , @lukemartin , @mrchief - pourriez-vous jeter un œil à la branche https://github.com/beautify-web/js-beautify/tree/feature/comma-first .

Je vais y consacrer 30 minutes ce soir et répondre avec des pensées. Merci pour le suivi.

Je m'en suis occupé ce matin. Tout me semble bon grâce à vos tests. J'ai une branche personnelle avec beaucoup de fonctionnalités d'opérateur en premier - j'ai mis mes tests de virgule d'abord dans votre branche et ils ont tous réussi sans problème, ce qui est une excellente nouvelle.

Lorsque j'ai créé ma branche personnelle, j'ai décidé que l'opérateur virgule d'abord serait passif, ce qui signifie ce qui suit :

var a,
    b;

ne serait pas changé. Vous avez clairement indiqué que ce n'était pas le cas dans le message de validation, je pense simplement que cela vaut la peine de discuter avec les autres du comportement auquel ils s'attendraient s'ils choisissaient d'utiliser opt.comma_first.

Une autre chose, <Output>.previous_line et flags.previous_text sont la même chose que je crois, ce qui m'a dérouté au début mais a du sens dans la façon dont vous l'avez utilisé.

En dehors de cela, la principale différence entre nos implémentations est que vous avez choisi de modifier la ligne précédente. J'essayais de ne pas « revenir en arrière et éditer des choses » parce que je pensais que c'était plus déroutant à développer. Maintenant, votre chemin est plus concis que le mien - il est facile à lire et vous avez tout commenté. Le code existant modifie également les jetons précédents afin que votre code soit parfaitement conforme - honnêtement, je le mentionne simplement parce que j'aimerais savoir ce que vous en pensez. En bref, mon avis est que ce programme serait beaucoup plus facile à déboguer si les tokens n'étaient en charge que de l'espace blanc devant eux en fonction des tokens suivants.

Merci d'avoir abordé cela !

Edit : Mon erreur - <Output>.previous_line et flags.previous_text sont complètement différents.

Avant seulement est préférable. J'ai regardé la boule de poils de comment et où nous décidons quoi faire avec/à propos des virgules, il y a déjà des endroits où nous rognons la sortie pour les mettre au bon endroit. J'ai décidé de faire quelque chose d'un peu simpliste, de faire des tests pour vérifier le comportement simpliste, puis de voir comment le régler et le remanier plus tard.

L'exemple que vous citez :

var a,
    b;

Serait un exemple de réglage qui pourrait être discuté plus tard.

Ça a l'air bien. J'apprécie les commentaires.

Et merci beaucoup de l'avoir regardé. Si vous avez des tests à ajouter, ce serait d'une grande aide.