コードエディターが、入力したとおりにタブ/スペースなしでコードをフォーマットした場合、どのように感じますか？[閉まっている]

ほとんどの場合と同様に、私はこの概念が以前に試されたことを確信しています-私が「仮想フォーマット」と呼んでいるものを使用するエディターに出会ったことがありません。原則は、コードをフォーマットするために開発者またはエディター自体によって従来挿入されていたパディングスペース/タブ文字の効果をシミュレートする浮動左マージンがあるということです。入力すると、エディターは（コメントアウトされている場合でも）コードを継続的に解析し、各改行が見つかったコンテキストに基づいて必要なインデントを計算します

XMLには文字の書式設定に特有の問題があり、入れ子になっている傾向があるため、特にXMLエディターを使用してこのアイデアを開発しています。ただし、多くの原則は従来のコードにも当てはまると思います。

そのようなツールを使ったコーディングの経験はありますか、それとも役立つか、妨げるかについての見解はありますか？バージョン管理システムで問題が発生しますか？（既存のパディング文字をすべて検出して取り除きます）

試していない限り、そのようなツールの動作を説明するのは困難です。実際に編集を開始するまでは、従来のように見えます。私は、XMLの編集、階層の変更、ドラッグ/ドロップ、コピーと貼り付けの操作、そして無効な文字が入力された場合のフォーマットの破損/修正を示す、プロトタイプの動作を示すスクリーンキャストビデオを公​​開しました。

編集 すべての回答/コメントはこれまで否定的でした-バランスを是正しようとするために、仮想フォーマットが考えるいくつかの利点：

• フォーマット標準についての議論は不要で、選択した/必須の規則に準拠する場所に改行を配置するだけです
• スペースが限られている場合（本/ブログ/ドキュメント）、ワードラップは可能ですが、完全なインデントを取得できます
• 各コードブロックには、画面の端に押し込まれずに、開始位置のすぐ隣に「マウスハンドル」があります。これをクリックして、ブロック全体または内部ブロックを選択します。
• ドラッグアンドドロップして忘れる-初めて実行可能になります
• 他の人々のコードを再フォーマットする時間はありません
• 正しくフォーマットされていないコードはありません（レンダリングがないという意味で）
• Ctrl + Backspaceの代わりにBackspaceを使用すると、キーボードのガイドキーを指で維持できます
• 柔軟なレンダリング-レンダリングされたフォーマットを環境に適合させます。誰かが携帯電話/小さな画面のタブレットでコードを読んでみましたか？
• 編集可能な文字が（サンプルXSLTで）およそ25％少ないと考えてください。効率の面でメリットはありませんか？

編集-これまでの結論

1. 開発者は、インデントに使用される埋め込み文字の使用に固有の欠点のほとんどを効率的に克服するツールと作業方法を確立しています。

2. 書式設定文字を削除すると、一部の差分ツールに悪影響が及ぶことが懸念されます。

3. 開発者は、自動レンダリングでは処理できないような方法でフォーマットを「微調整」する柔軟性を求めています。

4. 先頭のスペース/タブを削除すると、そのようなコードを効率的に確認するには、コードをフォーマットできる「コード認識」ツールが必要になります。プレーンテキストエディターではフォーマットが表示されません。

5. （仮想インデントに対して）いくつかの仮想的なメリットがある可能性があると感じている人は、デメリットがこれらの潜在的なメリットを決定的に上回っていると考えています。

編集-評決

障害の認識といくつかの利点（ある場合）は、一般的な言語向けにこのスペースのない編集コンセプトを追求することは、単一の開発者としては賢明ではありません。ただし、XML / XSLTの場合（空白の特別な処理のため）、少なくとも可能性についてはある程度の合意があるようです。

編集-出荷された製品

ここで一般的に否定的な感情があったにもかかわらず、私は編集者を出荷しました。私は実際の経験に基づいて、より具体的な問題という形で批判をもたらすことを期待して無料版を作成しました。ややイライラして、これまでのところ不満はありません（実際、ダウンロード量を考慮したフィードバックはほとんどありません）。これは、ユーザーがこれを「そう何なのか」と考えるほどうまく調整したためだと思います。一種の機能-しかし、伝える方法はありません...

最大の問題は、ファイルが他のツール、特にバージョン管理ツールにどのように表示されるかです。行末はこれらのツールにとって重要です。クラス全体が1行で表示されるマージ画面を表示したくないので、テキストの一部を列347でマージしてみます。

それは素晴らしいことです。Emacsは多かれ少なかれこれを行い、ほとんどの場合それを正しくします。EmacsのnXMLモードを試しましたか？それをどのように改善しますか？

すでに利用可能なものをサンプリングするまで、新しいエディターを作成することはできません。

とにかく、インデントは出力ファイルに保存する必要があるため、ファイルは他のツールで表示できます。Emacsのようなランタイムカスタマイズをサポートしていない限り、新しいエディターを採用することはあまりありません。

このアイデアは以前に見たことがありますが、実際にうまくいくのは初めてです。ほとんどの場合、アイデアが浮かび上がるのを見たとき、そこにいるすべての開発者によって打ちのめされました-またはそれが実装されたとき、折りたたまれたコードを表示するだけでファイルが変更されてさらに混乱するため、バージョン管理は事実上役に立たなくなりました差分ツール。（これがいかに悪いかの一例が、Witango Development Studioです。）

多くの開発者に役立つためにエディターが克服しなければならないいくつかのハードルを考えることができます。

• ファイルを変更しても、* nix diff -uwコマンドでノイズが発生しないようにする必要があります。（偽の差分はありません！）
• （以前はフォーマットされていない）ファイルを編集しても、SCMツールでのマージが複雑にならないようにする必要があります。
• 開発チームが使用する他のエディターとうまく連携する必要があります。
• ユーザーは、自分の心のコンテンツに合わせてフォーマットをカスタマイズできる必要があります。一部の人々は、コードがどのように表示されるかについて非常に熱心です。
• 既存のコードを編集しても、既存のフォーマットは変更されません。明らかな理由もなく、エディターがファイル全体を突然再フォーマットしないこと、および簡単な小さな編集のために行のフォーマットを変更しないことが重要です。これは、diffツールを混乱させ、他のチームメンバーを怒らせます。
• それはおそらく余計な空白を取り除いてはならない-それはおそらく誰かを怒らせるだろう。危険を冒さないようにしてください。
• ファイルに追加される新しい行は、既存のモードラインの設定に準拠するか、ローカル（+/- 3行以内）の既存のフォーマットに準拠する必要があります。
• エディターには、ユーザーが実際にエディターが表示するものとは別のチームのコードフォーマットポリシーを定義できる設定パネルが必要です。

言うまでもなく、これにはファイルの既存のフォーマットに関するメタデータがある程度必要になります。ソースから分離しておくことをお勧めしますが、刻々と変化するリポジトリと同期を保つことはおそらく非常に難しいでしょう。

Vimユーザーとして、私はまた、エディターがVim、Emacs、および他のエディターのモードラインを尊重し、最終的に何が表示されるかに関係なく、モードラインの禁止されたフォーマットを保持するべきだと考えています。

私の意見では、そのようなソフトウェアの要件は、それを受け入れられないものにします。このようなプロジェクトを成功させるには、あまりに多くのユーザーが期待しすぎます。

テキストベース（XMLなど）のフォーマッター構成ファイルを使用するソリューション：

• 持っている個人的なフォーマッタ、個々の開発者によって構成されています。

  • このフォーマッタをローカルに保存します。

  • ファイルはローカルのフォーマットでロードおよび編集されます。

  • 彼らは何も壊すことなくフォーマットスタイルを自由に変更できます。

  • 自動フォーマットをオフにして、未加工のファイルを表示および編集できます。

• チーム標準用に構成された最小限のチームフォーマッターを用意します。

  • このフォーマッターをチームのバージョン管理に保存します。

  • ファイルは、他のツールのフォールバックとしてチーム形式で保存されます。

  • 差分はフォーマットの問題の影響を受けません。

あなたがファイルを保存することにより、実際には何も失うことはありませんので、それは、余分な空白なしでファイルを保存する経済を心配する必要はばかげていくつかのチームが標準で定義された書式設定を。一人の開発者の場合、表示されたフォーマットをミラーリング（「チーム」の1つに）してミラーリングする機能を提供できます。

フォーマッタが不十分な場合、2つの実行可能なオプションがあります。

• カスタムフォーマッタのインターフェイスを公開します。

  • 正解です。これが最良のソリューションです。

  • 間違っています、それは最悪です。

• 自動フォーマットの手動オーバーライドを許可します。

  • 使いやすさは損なわれません。Ctrl-（Enter | Tab | Space）を検討してください。

  • サニティは、このフォーマットをどこに保存しますか？あなたは？

言語がフォーマットに敏感でない咳 Python 咳でなければ、コードがオートフォーマットされても大丈夫でしょう。

EmacsはLispのフォーマットを非常に優れたものにし、その場でフォーマットしました。括弧やその他の区切り文字の自動挿入には我慢できません。私が試したどの自動挿入機能も、入力方法に適したものに近づけません。

私はアイデアのコンセプトを心に留めています。そして、あなたは成功するかもしれませんが、私はフォーマットに関して私がやりたいことすべてを十分に行うエディターをまだ見つけていません。これがいくつかの障害物（IMO）です。

• 空白の多い言語
• 出力に何が保存されますか？（ツールがなくても他の人が読めるようにするには、ある程度、インデントを少なくともいくらか保存する必要があります）
• すでに導入されている既存のソース/バージョン管理製品と完全にうまく機能する必要があります
• それは高度にカスタマイズ可能でなければなりません、特にコードがどのようにフォーマットされインデントされるか（そしてそのコンマがリストのどこに置かれるべきかについて非常にうるさい）行を分割するなど）
• 言語を本当に理解しなければならない。これは、コンパイラが理解するとおりに言語に準拠する必要があることを意味します。RegExpで単純に処理することができない言語のちょっとした面があるので、構文が間違っている色付きの構文を持つエディターが多すぎます。確かに、言​​語を継続的に解析することをおっしゃっていましたが、解析する内容は、使用しているコンパイラに準拠していると誰が言うのでしょうか。（私を信じてください、そこには多くの標準があり、ほとんどの言語で行われている面白いビジネスがたくさんあります。単純なパーサーには間違っているように見えますが、コンパイラーには完全に正しいコードが含まれます。）
• 速くなければならない。そして、ここでゴムが道を歩みます-パーサーをN度に最適化できない限り、（特に大規模なプロジェクトで）キーストロークごとに私のコードで完全なコンパイル実行を行うことはできません。エディターに遅いというヒントさえあれば、誰もそれを使用しません。（私は遅いエディターを断念してより速いエディターを支持する完璧な例です。もしそれが少しでも遅れれば、私は出ています。）

ほとんどの基準を満たすものを合理的に作成できますか？多分。しかし、私たちのプログラマーは細心の注意を払い、うるさいので、変更を嫌い、問題の最初の兆候でジャンプ出荷します。ここで問題となるのは、出力が開発チームの他の誰かをチックしたり、バージョン管理システムで100％うまく機能しない場合や、コードが正確にフォーマットされていない場合や、言語を誤解し、コードを誤ってインデントしたり、予想よりもミリ秒遅れている場合。というのも、私はこのアイデアに心を注いでいるのと同じように、お気に入りのエディターにハートビートですぐに出荷するからです。

さらに根本的なアプローチ-純粋なセマンティックエディターがあります。IDEは、プレーンテキストではなくASTとして内部的に表現されるコードも扱います。たとえば、JetBrains MPSを参照してください。

私の質問で説明したXMLエディターを公開したので、私はこれに自分で答えようとする（理想的ではありません）ので、次のようにします。

2週間未満で500回を超えるダウンロードを行った後、動的コードフォーマットのこの画期的な新しいコンセプトに対する反応は...

NIL

文句なし、賞賛なし。これについての私の（希望的な）解釈は、人々は普通に感じてコードをめちゃくちゃにしないエディターを望んで期待しているだけだというものです。ユーザーは、自分のフォーマットが完全に仮想的であることにほとんど気づかず、証拠が彼らがさらに気にかけていないことを示唆しています。

この非反応を読みすぎるのは間違いですが、このツールは無料です。残念ながら、これは少なくとも一部のユーザーが批判する傾向が少なくなることを意味します。彼らがそれを好まなかった場合、彼らは単にそれを捨てて別のものを使用したのかもしれません。