Js-beautify: 変数宣言のコンマファーストスタイルをサポート

JSとPythonの両方をサポートしていることを考えると、パッチ（かなり古くなっています）はせいぜい不完全です。

リクエストは受け付けていますが、個人的には「カンマファースト」はアンチパターンだと考えています。 本質的に、js-beautifierは、広く受け入れられている「慣用的な」JSにほぼ準拠する合理的なオプションを使用して、JSがどのように見えるべきかについて意見が分かれています。 私の意見では、コンマファーストは美しくなく、広く受け入れられていません。 さらに、それは非常にわずかな利益のために美化コード（すでに信じられないほど複雑です）をひどく複雑にします。

indent=4設定されている場合、どのインデントが適切ですか？ 一貫性の観点から、私はこれを主張します：

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

これは明らかに期待される出力ではありません。 そして、タブインデントでどのように見えるでしょうか？

セミコロンはどこに住んでいますか？ 最後に？ どこにも？ （私は両方を見てきました、そしてもっと）

この要点は同じように時代遅れですが、必要な変更をより簡単に理解できるようになります： https ：

これは＃80に似ているので、理由は同じかもしれないと思いました。つまり、差分と並べ替えが簡単です。

ただし、このシナリオでは、＃80とは異なり、これらの要件を満たす実行可能な回避策があります。

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

少し冗長ですが、恐ろしいことではありません。

もちろん、誰かが＃80を実装する場合、最も単純な変更はおそらくこのシナリオもカバーするでしょう。
@evocateurが言ったように、プルリクエストは大歓迎です。

@evocateur ：あなたはあなたの意見を@bitwisemanが言うように

@bitwiseman ：インデントの任意のレベル（2または4）で、これがどのように見えるべきかを推測します：

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

これは、一部のSQLエディター（コンマが最初の方が一般的）の方法とも一致していると思います。

そして、私は悪いレイアウトを宣伝することを主張していませんが、慣用的なものと独断的なものの間には常に微妙な境界線があると思います（ここでCrockfordを考えてください）。 フォーマッターの多くは、理由が何であれ、コンマをサポートしていないため、最初にコンマが普及していない可能性があります。

あなたはコードに関して状況に精通しているので、私はあなたのROIの議論に完全に同意します。 とはいえ、これらのことを公開し、定足数で話し合い、コミュニティからの要望があれば、考え直してほしいと思いました。

PS私は、何かをすばやくスピンオフできるかどうかを確認するために数時間を費やしましたが、あまり成功しませんでした。 たぶん、もう一度試してみます。

@mrchief昨日は無愛想だったことをお詫びします。イライラするデバッグセッションから休憩していました。 あなたは良い点を述べています、そして私もあなたの選択を尊重していることを明確にしたいと思います。 私自身、パッチ（コンマ優先、セミコロンなし、その他の奇抜さ）を提供している場合は、特定のプロジェクトのスタイルを維持しようとします。このようなオプションは、少なくとも、それらを採用することを選択したプロジェクトの一貫性。

+1。 差分とマージの際の利点として、コンマファーストパターンを使用します。

セミコロンの位置について： varキーワードに沿って、次のように改行します。

var a
  , b
  , c
;

同じパターンを使用するいくつかのプロジェクトを見てきました。

また、私見では、宣言の横に値が指定されていなくても、各変数を別々の行に保持できると便利だと思います。 上記の例では、美容師はすべてを1行var a, b, c;グループ化しますが、これもコンマ拳スタイルを使用するという目的全体を破ります。

カンマ優先のサポートの場合は+1。

2スペースのインデントでは、変数を配置する最もきれいな方法です。

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

タブごとに4つのスペースはどうですか？ 実際のタブ？

9:36で金、2013年11月8日には、ルーク・マーティン[email protected]
書きました：

カンマ優先のサポートの場合は+1。
2スペースのインデントでは、変数を配置する最もきれいな方法です
var foo = true
、bar = 'こんにちは'

、 なにか;

このメールに直接返信するか、GitHubで表示してください。
https://github.com/einars/js-beautify/issues/245#issuecomment -28081629

カンマファーストの問題の核心は、実際にはタブの設定にあると思います。

私は2スペースのタブを使用していますが、不要な空白を追加せずに変数を配置する唯一の方法はコンマビフォアです（〜は、物事を並べるために追加された余分なスペースを表します）。

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

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

逆に、4スペースのタブを使用する場合、コンマビフォアは見栄えが悪くなり、当然、サポートについては気になりません。

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

したがって、コンマについての議論があります-コメントとデバッグが簡単になる前に、何とか何とか何とか。 しかし、私にとって、それは美学に帰着します。 2スペースのタブを使用しているので、カンマビフォアを使用する必要があります。 現在、2スペースのタブを優先しているため、beautifyを使用できません。

今、私はおそらくマイノリティにいることを知っています、そして私は私の小さな好みのためにサポートを絶対に要求していません。 会話に+1を追加していました。 時間があれば、自分でサポートを追加することも検討するかもしれません。

乾杯 ：）

これをjsonオブジェクトで見たいです。

 var a =（{
 a：1
 、b：2
 }）;

@lukemartinそれは興味深い視点です！ ：+1：

変数宣言と配列およびオブジェクトのコンマファーストサポート用の別の+ 1- https：//gist.github.com/isaacs/357981

私はこの機能を「オンデマンド」でサポートするパッチに取り組んでいます（ユーザーは、作成した設定で最初にコンマを使用するオプションを有効または無効にできます）。

変数宣言の次のフォーマットを実現しました（2つのスペースを使用）。

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

しかし、私にはいくつか疑問があります。

配列、オブジェクト、引数の宣言をどのように扱うべきですか？ 最近、私は次の形式を使用しています。

myArray = [
  item1
, item2
, item3
];

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

ご覧のとおり、これは変数宣言のフォーマットとまったく同じではありません。この最後のフォーマットには、2番目の変数の+1インデントレベルが含まれています（「item2」のコンマの前に存在しないコンマの前の2つのスペースに注意してください） 「prop2」用のものでもありません）。 Var宣言は、@ lukemartinで指定されているように、各変数名の先頭を同じ列に揃えるために、この追加のインデントを使用します。

上記のコードに示されているフォーマットを使用する理由は次のとおりです。

1.- jshintによってスローされるリンティングエラー（インデントエラー）をため。 例えば：

myArray = [
    item1
  , item2
];

「1ではなく3にインデントがあると予想される]をスローします。 提案に従うと、非常に醜い結果が得られます。

2.-各プロパティ名、配列項目などの先頭を揃えるという利点を維持するため。次に例を示します。

myArray = [
  item1
  , item2
];

また、リンティングエラーは発生しませんが、上記の例ほど見栄えがよくありません。

これらのケースをどのように処理するかについてより明確な考えがあれば、この機能の実装を完了してプルリクエストを発行できます。

上記のすべてをサポートすることは可能ですか？ あなたがリストしたものはすべて、技術的には「コンマファースト」です。

それは可能だと思いますが、ユーザーが希望する結果を達成できるように、より多くの設定を実装する必要があります。 たとえば、配列、オブジェクト、引数に2つのインデントレベルを使用するか、1つだけを使用するかをフォーマッターに指示する必要があります。

最初に基本的な機能を実現してから、より多くの設定で拡張したほうがいいと思います。 2番目のパッチでそれらを実装するのに問題はないと思います。

あなたが言うように、基本的な機能は問題ありません。 _all_フォーマットオプションをサポートすることは、このプロジェクトの_非目標_です。 ：笑顔：

// 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
];

これらにより、コードがシンプルになり、使用するインデントに関係なくフォーマットが一貫し、この問題を閉じて、個別に指定および実装できる「コンマ優先識別子の列化」（またはその他）の新しい問題を開くことができます。 。

プルリクエストをお待ちしております！

@tgirardiお疲れ様でした。 これを試すのが待ちきれません。

すべてのフィードバックを歓迎します：-）!!!

私の考えは、正しい解決策と見なされるまでコードを調整してから、次のTODOリストに進むことです。

1.-この新機能のテストを作成する
2.- Pythonバージョンに機能を適用します（誰かがこれを志願するなら、さらに良いです！...私はPythonの経験があまりありません）。
3.-コンマファーストスタイルの他の可能なバリエーションについて話し合う

4スペースインデント

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

変数名と属性名を並べる必要はありません。 これは読みやすさにはまったく影響しません。 私の意見では、列優先を使用する主な理由は、コメント、行の削除、挿入を簡単にするためです。 2スペースのインデントを使用すると、たまたま整列します。

'y'の後に新しい変数を追加しやすくするために、複数の変数を宣言した後、半列を独自の行に配置する必要があります。 この場合、VIMでは、 '$ aの代わりに' o '+'、z = c '、'+' z = c '

@lewisdiamondセミコロンのコメントに同意します。 独自の行に含めることで、最後の変数も簡単に編集できるようになります（削除、置換、行の前後の挿入など）。

ただし、次の点にも注意してください。

1.-あらゆる種類のフォーマットをサポートすることはプロジェクトの目標ではありません。
2.-一度に複雑すぎることを追加することは悪い考えです。 したがって、最初にこの機能をできるだけ単純に保ち、リリース状態に達してしばらくの間テストした後で改善を開始する方がよい場合があります。

+1はコンマファーストのサポートであり、コンマファーストスタイルには実用的な理由があるため、タブを正しく整列させることが最終目標ではないというlewisdiamondの感情に同意します。 jsonのサポートも欲しいです。 現在、私はグローバルなjs-beautifyコードをハックして、句読点を優先する多くの代替手段を実行しています（3値演算子の場合は必須でした）。

これを+1したすべての人へ：ブランチhttps://github.com/beautify-web/js-beautify/tree/feature/comma-firstをご覧ください。

これがあなたが望むものへの十分な最初のステップであり、次のリリースに追加する必要があるかどうかを教えてください。

@ olsonpm 、 @ lewisdiamond 、 @ lukemartin 、 @ mrchief-ブランチhttps://github.com/beautify-web/js-beautify/tree/feature/comma-firstをご覧ください。

今夜は30分かけて考えて対応します。 フォローアップしていただきありがとうございます。

今朝それを手に入れました。 あなたのテストのおかげで、それはすべて私には良さそうです。 私は多くのオペレーターファースト機能を備えた個人ブランチを持っています-私はあなたのブランチを通して私のコンマファーストテストを行いました、そしてそれらはすべて問題なく合格しました、それは素晴らしいニュースです。

個人用ブランチを作成したとき、コンマファースト演算子はパッシブであると判断しました。これは次のことを意味します。

var a,
    b;

変更されません。 コミットメッセージではそうではないと明確に述べましたが、opt.comma_firstを使用することを選択した場合に、他の人がどのような動作を期待するかについて話し合う価値があると感じています。

もう1つ、<Output> .previous_lineとflags.previous_textは私が信じているものと同じもので、最初は混乱していましたが、使用方法には意味がありました。

それ以外の実装の主な違いは、前の行を変更することを選択したことです。 開発するのがもっと混乱すると思ったので、「戻って編集する」のはやめようとしていました。 今、あなたのやり方は私のやり方よりも簡潔です-それは簡単に読まれ、あなたはすべてにコメントしました。 既存のコードも以前のトークンを編集するので、コードは完全に一致します。正直なところ、あなたの考えが何であるかを知りたいので、私はそれを取り上げています。 要するに、私の意見では、トークンが次のトークンに基づいてそれらの前の空白のみを担当している場合、このプログラムはデバッグがはるかに簡単になるでしょう。

これに対処してくれてありがとう！

編集：私の間違い-<出力> .previous_lineとflags.previous_textは完全に異なります。

フォワードのみが望ましいです。 カンマをどのように、どこで処理するかを決定する方法と場所のヘアボールを見ましたが、出力を適切な場所に戻すために出力をトリミングする場所がすでにあります。 私は少し単純なことをすることにしました。単純な動作を検証するいくつかのテストを取得し、後でチューニングとリファクタリングについて確認します。

あなたが言及する例：

var a,
    b;

後で説明できるチューニングの例になります。

いいですね。 フィードバックに感謝します。

そして、それを見てくれてありがとう。 追加したいテストがある場合、それは大きな助けになります。