なぜWordpressのコードはそんなに「スペースハッピー」なのですか？

WPコア、多くのWPプラグイン、およびWPコーディング標準自体は、Space文字の非常に「寛大なアプリケーション」を使用します（インデントではなく、括弧と括弧の「内部」）。これはWordpressに固有のようです-このスタイル/哲学は、他の同様のプロジェクト（PHPなど）には存在しないようです。

このアプローチの詳細については、https：//make.wordpress.org/core/handbook/coding-standards/php/#space-usageを参照してください。

例： foreach ( (array) $foo as $bar ) { ...

foreachの後、最初のの後、(最後の前の)スペース（および上記のリンクの「スペースの使用法」に示されている他の同様のスペース）を参照しています。

このスタイルは私には不要なようです-それはより多くのタイピングを必要とし、（意見）コードを視覚的に解析することをより困難にします。（/意見）

私の願いは、このスタイルが良いアイデアであるかどうかを議論することではありません。むしろ、単にこれが推奨スタイルである理由の動機を理解したいだけです。WPコーディング標準に関するコメンターでさえ興味があります。

ここに画像の説明を入力してください

MK Safiの質問に対する回答は、基本的に次のとおりです。

読みやすくするために
現状（別名「それはあるがまま」）

私が尋ねる理由は、私たちの内部専用プロジェクトでWPコーディング標準（「スペース使用量」に関して）を採用することに個人的にあまり価値がないことです。ただし、何かが足りない場合は興味があります。

Wordpressの「スペース使用量」スタイルに従うことについて、上記の2つを超えて、表面上は有効であるかどうかの理由はありますか？

coding-standards

— りのご
ソース

一貫している限り、社内プロジェクトで好きなことを行うことができます。サイドノートとして、スペースではなくタブを使用しているので、間違いなく入力が少なくてすみます。これは、すべての書式設定を行い、さまざまなスタイルに再書式設定できる最新のIDEを持っている場合（たとえば、崇高なパッケージ、PHPStormなど）

— トムJノウェル

コメントありがとうございます、@ TomJNowell！私は「質問」で誤解したのではないかと思います-私はインデントのタブ/スペースについては少なく、make.wordpress.org / core / handbook / coding-standards / phpの「スペース使用量」で言及されているルールについてもっと尋ねています/…。申し訳ありませんが、私はもっと明確ではありませんでした！

— rinogo

構文の強調表示がない場合、読みやすくなります。それが少なくとも私が内部プロジェクトでそのスタイルを使用している理由です。最小限の構成でviを使用してプレーンコンソールでPHPを頻繁に編集する必要があります。

— FUXIA

FWIW、MediaWikiには非常に似たスタイルの規則があり、実際には（少なくともコアでは）強制的にかなり厳密です。不足しているスペースを自動的に追加するスクリプトもあります。私が言えることは、しばらくすると慣れることです。

— イルマリカロネン

@rinogo私が知っている、コメントは時々コメントであり、答えではありません：）

— トムJノウェル

回答:

共鳴

「空白」について（タブでもスペースでも）：プロジェクトにこだわったのは単に個人的な好みです。

WPコーディング標準imoは混乱しており、無視できます-コアに貢献していない限り、

別の話と
スタイルガイドも同様に無視されます。

「[...] svn / gitの履歴を使用するのが非常に難しくなるため、古いコードにさかのぼって適用されません。新しいポリシーはスタイルガイドに従う必要がありますが、隣接するコードを正しくフォーマットする場合それだけではありませんが、コードのみをフォーマットするパッチ、またはコードのみをフォーマットするコミットは禁止されています。」

^{-コメントの@TomJNowell}

代替案

PSR標準（つまり：2）またはSymfony標準（または独自の標準）に固執する方が良いでしょう。

パフォーマンスの向上とツール

コーディング標準を持つこと（共有するものとそれを嫌う少数派はあるが、残りはそれを指示することは別として）や、多かれ少なかれタブやスペースを持つことから得られる利益はありません。不要なディスク領域の使用やプログラムの速度低下が心配な場合は、コミット時にコードを圧縮できます（GitPHPHooksプロジェクトを参照）。あなたが得る利益は、元のファイルスペースから最大で約5％であり、HTML構文の圧縮/縮小によって得られるものとほぼ同じです。そのためにnpm経由でNode.js縮小ツールを使用できます。

私が個人的に本当に役立つとわかったのは、PHP Linterと_PHP Mess Detectorです。両方をGitPHPHooksライブラリに組み込んだため、実行することを考えたり気にしたりする必要はありません。

— カイザー
ソース

スタイルガイドはCoreでは無視されませんが、svn / gitの履歴を使用するのが非常に難しくなるため、古いコードに過去にさかのぼって適用されることはありません。公式のポリシーでは、新しいコードはスタイルガイドに従う必要がありますが、隣接するコードを正しくフォーマットする場合は、コードをフォーマットするパッチ、またはフォーマットコードのみをコミットするパッチは禁止されます

— トムJノウェル

@TomJNowellしたがって、スタイルガイドを役に立たないものにします:)とにかく、編集を提出し、それを回答に追加してください。それは注目に値する情報です。

— カイザー

私は自分の質問ではあまり明確ではなかったと思います-タブとスペースのことではなく、make.wordpress.org/core/handbook/coding-standards/php/…の "Space Usage"に言及しています。質問をより明確にするために編集します。

— -rinogo

@rinogo最初に正解だったので、最初の段落です。ところで、これも読みやすいと思います。

— カイザー

などのドットの後のスペースは正常です。$baz . '-5'このスタイルは、演算子の多くのコーディング標準で使用されています（y + z）。

これは、読みやすさを向上させるために行われます。たとえば、これらの1つは他の文字より読みやすいです。

$cow.$dog.$cat.$table.$chocolate.$puddle.$iterator.$stuctureone.$stucturetwo

$cow . $dog . $cat . $table . $chocolate . $puddle . $iterator . $stuctureone . $stucturetwo

これは、他の「コード」で囲まれている場合にさらに明らかになります。

括弧の周りのスペースについてはわかり( 1, 2, 3 )ませんが、議論は読みやすさのためでもあると思います。

WordPress 標準自体にはスペースのないコメントの括弧付きの例があり、コードベース自体は同じ関数内でもスペースのある部分とそうでない部分（下のスクリーンショットを参照）と混同しているため、混乱する可能性があります。

ほとんどのPHP標準は、実際には逆の呼び出しを行います。括弧はその内容を抱きしめます。実際、他の言語のほとんどのコーディング標準は次のように記述しています。(1, 2, 3)したがって、WPがこのように行う理由は少し謎です。

WordPress関数から比較する例を次に示します。

ここに画像の説明を入力してください

比較する大きなバージョン：http : //i.imgur.com/nTEbV7v.jpg

私は、特にコードのフルスクリーンを見るとき、右側のものを好みますが、それは個人的な好みです。

— ワイク
ソース

ご回答有難うございます！.間隔は、私には理にかなっている.と同じように、実際には二項演算子です+か-。その内容を「抱き締める」括弧に関するあなたの考えは、まさにこの質問をした理由です。この動作は、角括弧のもののようにも奇妙なルールと一緒に（WPが使用することを言う$foo['bar']と$foo[ $bar ]、私はこの質問をした理由を正確にされています）。:)

— rinogo