私は、個々のコーディングスタイルを持っていることはプログラマにとって良いと思っていました。 これは、優れたコードがどのように見えるかを知っている経験豊富な開発者であることを示しています。
大学では、私のクラスメートが特別なコーディングスタイルのために、私のクラスメートが仕事で私のコードをいつ使用するかを理解していると私の先生は言いました。 私のコードは少なくとも何らかの形でフォーマットされていたのに、他の人は完全に混乱していたので、彼らはこれを理解したと思います。
それ以来、コーディングスタイルとその実装に使用するツールの選択について多くの時間を費やしました。 何かを変える時です。
いくつかの例
「
プログラマーの石 」を読んだ後
、私は長い間このように括弧を付けました。
if (food === 'pizza') { alert('Pizza ;-)'); } else { alert('Not pizza ;-('); }
しかし、その後、私はおそらくこれを行うユーザーの中で私だけであることに気付きました。 他の誰もがこのスタイルを固守しています：
if (food === 'pizza') { alert('Pizza ;-)'); } else { alert('Not pizza ;-('); }
またはこれ
if (food === 'pizza') { alert('Pizza ;-)'); } else { alert('Not pizza ;-('); }
そこで、スタイルを上記に変更しました。
私はこのスタイルを使用してチェーンを作成するのが本当に好きです：
function foo(items) { return items .filter(item => item.checked) .map(item => item.value) ; }
私の意見では、これは
コンマを移動するときのリファクタリングにも貢献し
ます ：
const food = [ 'pizza', 'burger', 'pasta', ]
しかし、おそらく、このスタイルを使用する場合、ブラケットを使用する場合よりもさらに孤独です。
このスタイルを使用して検証のためにコードを送信する人はいません;コード品質管理ツールがこれを強制することはありません。 そのため、現実世界に近づけるために、使用をやめなければなりませんでした。
私以外に誰もしていない何かがあります。 行末のコメントの前には常にダブルスペースを使用します。
const volume = 200;
これによりコードの可読性が向上すると思いました。 しかし、実際には、残りの開発者はスペースを1つしか配置しないため、これによりコードベースの一貫性が失われます。
JavaScript開発者は何をしますか
残念ながら、JavaScriptには公式のコーディングスタイルがありません。
Airbnbや
Standardなど、いくつかの
一般的なコーディングスタイルがあります。 これらを使用して、コードを他の開発者に馴染みやすくすることができます。
ESLintを使用して、コーディングスタイルを設定し、コードを自動フォーマットすることもできます。 しかし、それはあなたのコードベースを100％一貫させるものではありません。 Airbnb構成のESLintは、最初の最初の例のみを合理化し、他の2つの例で矛盾を作成します。
JavaScript開発者がすべきこと
一部の言語には、強力なコーディングスタイルと、コードをフォーマットするためのツールがあります。 したがって、開発者はコーディングスタイルについて議論する時間を無駄にしません。
Remt for Reasonまたは
Rustfmt for Rustを
ご覧ください 。
JavaScriptは最終的
にこの問題の
解決策を持っているようです。
Prettierと呼ばれる新しいツールは、ルールに従ってコード
を再フォーマットします。 コードの元の外観を完全に無視します。
私の例で
Prettierの仕事を
試してみましょう：
if (food === 'pizza') { alert('Pizza ;-)'); } else { alert('Not pizza ;-('); } function foo(items) { return items.filter(item => item.checked).map(item => item.value); } const volume = 200;
このスタイルに挑戦できます。 例えば、私は
elseの配置が好きではあり
else ;疑問はまた、1行に機能チェーンを書くことによっても引き起こされます。 ただし、Prettierの実装には大きな利点があります。
- 議論することは何もありません-Prettierにはいくつかのオプションがあります。
- チームで作業している場合、特定のルールに関する論争はありません。
- パートナーはプロジェクトのコーディングスタイルを学ぶ必要はありません。
- ESLintによって報告されたスタイルエラーを修正する必要はありません
- 保存形式を設定することができます。
おわりに
Prettierは、ReactやBabelなどの
人気のあるプロジェクトで既に使用されています。 そして
、私は自分のプロジェクトを
作り直し始め、いつものコーディングスタイルから離れて、Prettierを支持しました。 Airbnbのコーディングスタイルの代わりに使用することをお勧めします。
Prettierとの私の仕事の初めに、「ふむ、これはひどい」と思った瞬間がたくさんありました。 しかし、たとえば、単一行ビューから複数行ビューにJSXコードを手動でフォーマットする必要があると思うとき、別のプロップを追加し、それが1行に収まらない場合、それは絶対に価値があることを理解しています。
Prettierは、ファイルを保存するときにコードをフォーマットします。Prettierをプロジェクト
に組み込む方法
をお読みください。
PS
私の新しいツールをご覧ください。ESLint、Prettier、その他のツールのプロジェクトへの追加、およびそれらの設定の保存と同期が簡単になります。
この翻訳は、 Amiro.CMSおよびWordPressのプロのWebサイト開発会社であるEDISON Softwareによって、および大規模な顧客向けにサポートされていました。