独自の行の閉じ括弧は受け入れられませんか？[閉まっている]

私はかなり長い間Emacsを使用してきましたが、最近、コーディング標準に出くわしました。そこにはそれが述べられています：

自分で行に閉じ括弧を付ける習慣をつけないでください。Lispプログラマーはこれを当惑させます。

これは、コードを読みやすくするために、私が構築した習慣とまったく同じです。Emacsで提供されるパッケージに混合スタイルが表示されます。私の質問は、この混乱がほとんどのelispプログラマに共通しているかどうかです。

編集：私のコードを見て、私は厳密にこれに従っていません。次に、コードはかなり恐ろしいでしょう。ほとんどの場合、defun、let、ifなどです。しかし、それは木目に反しているようなので、おそらくこれをやめるべきです。入力のための乾杯。

（ボーダーラインの意見に基づいていますが、C ++での閉じ括​​弧に関連しているようです。この場合、通常は独自の行にあるべきであると述べることは議論の余地がないはずです）。

まあ短い答えは「必要がない」です。EmacsはLISPのs式を解析できるので、フォームがどこでバランスするかを正確に知っており、コードを正しくインデントすることができます。この場合、ブラケットをそれ自体の行に移動すると、余分なスペース行が無駄になるだけでなく、標準的なスタイルに慣れている他のLISPプログラマにとって不快であると同時に不快になります。コメントで述べたように、垂直の空白を使用してコードのチャンクを視覚的に分離することを妨げるものではありません。

実際には、LISPプログラマーを使用する多くのEmacs は、閉じ括弧の密なネストをナビゲートするのに役立つshow-paren-modeなどのさまざまな追加の視覚的手がかりを使用します。pareditやsmart-parensなどのモジュールを編集サイクルに組み込んだエンジニアは、ASTと一体になり、式のバランスが常に取れて完全になるように直接構造を直接操作しています。

RiastradhのLispスタイルガイドでは、この特定のトピックについてもう少し詳しく説明しています。彼は通常、独自の行に閉じかっこを配置することを推奨していませんが、前の行の閉じかっこがコメント化されていることや、最初または最後に新しい要素を追加するときに常に差分をめちゃくちゃにする本当に長いリストなど、いくつかの例外を認識しています。 。

私は約2〜3年前からElispを書いています。最初はぶら下がっている括弧のことをしていましたが、あなたが言ったルールを発見したので、私は自分でそれを始めました。そして、適切にスタイル設定されていると、コードを読むのがはるかに簡単になったと言えるでしょう。

LISPのかわいらしいコードをここに書きました： lispy-tab。

そしてもちろん、私はいつも持っshow-paren-modeています。