4

「セミコロンの暗黙的な挿入」は理解していますが、関数式の場合に発生するかどうかはわかりません。

たとえば、次の 2 つの式は常に同じように解釈されます。

Matrix.scale = function (mat, scaleX, scaleY, dest) {
// useful code
};

Matrix.scale = function (mat, scaleX, scaleY, dest)
{
// useful code
};

私は最初のものを気に入っていますが、Google も気に入っていることに気付きました: http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml?showone=Code_formatting#Code_formatting。しかし、私の同僚はこのスタイルに不満を持っていました。関数宣言があっても、この規則に厳密に従うかどうか、またはそれが均一性への賛辞であり、このコードがトリッキーな縮小後に壊れないかどうかという問題が生じますか?

4

5 に答える 5

9

他の言語では好みの問題かもしれませんが、JS ではエラーの原因を見つけるのが非常に難しい場合があります。次のスニペットを考えてみましょう。これは、一見しただけでは期待どおりに動作しない可能性があります。

function foo()
{
  return
  {
    bar: 1
  };    
};

console.log(foo()); // => undefined

さらに読む: http://en.wikipedia.org/wiki/JavaScript_syntax (「セミコロン挿入」を検索)

于 2012-08-13T20:53:30.543 に答える
1

「 CodeComplete」という本によると、角かっこはコードの論理構造を示していないため、2行目に入れると誤解を招くため、最初の行（制御ステートメントと呼ばれます）に入れる必要があります。グラフィカルな観点から見ると、2番目のアプローチは次のようになります。

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

ここで、線AEは次のことを表しています。これは、この質問で宣言された2番目のアプローチに似ています。

A function foo ()
B {
C     print "Hello";
D     print "World";
E }

行Bが行Aに従属しているかどうか、または行Bがそれ自体の別個のステートメントであるかどうかがわからないため、表示される内容は誤解を招く可能性があります。

編集：画像が抽象的すぎる場合は、制御ステートメントと一緒に中括弧が最初の行に含まれることが多い理由を簡単に説明します

関数には2つの主要な要素があります。

  1. コントロールコンストラクト
  2. 関数のステートメント

2行目（画像の行B）に中括弧を置くことにより、それは制御ステートメントにも関数のステートメントの一部にもなりません。

編集2

IMO、コードの各行には、垂直方向のスペースを節約して、画面に一度に多くの行を表示し、コードの論理的な意味を保持するという目的が必要です。したがって、中括弧が関数宣言と同じ行にある場合、中括弧はそれによって開くステートメントに関連付けられます。ただし、それ自体が1行にあり（私の例ではB行）、関数宣言に従属するようにインデントされていない場合は、制御構造に関連付けられていないため、コードの論理的な意味が壊れます。また、関数ステートメントでもありません。したがって、関数宣言と同じ行に中括弧を付けることで、コードのすべての行が目的を果たし、コードの論理的な意味を保持し、画面スペースを節約します。

function foo() { // brace is on the same line and it's associated with the statement that it opens
    print "Hello"; // this line does something
    print "World"; // this line does something
} // this last brace terminates the function which is part of the control construct
于 2012-08-13T21:04:35.437 に答える
1

コード スタイルは、コードのフォーマット方法と次の言語で作成された変数の名前に関する合意にすぎません。

  • この言語でコーディングしたり、特定のライブラリを開発したりしている人々の (サブ) コミュニティ。
  • あなたの会社。

これら 2 つの要因のどちらがより決定的であるかを言うのは難しいですが、優れた企業のコード スタイルは「実際の」コード スタイルと密接に関連していると言っても過言ではありません。部分的には、優れた企業ではコードがオープン ソースに提供されることが多く、再発明しないほうがよいためです。

圧倒的多数のスタイル ガイドによって認識されている、非常にしっかりとした完全な言語があります。たとえば、this_is_very_uncommon_to_java.

JavaScriptに関しては、これは当てはまりません。抽象的で一般的な「javascript コード スタイル」のようなものはありません。ブレースの問題は、セミコロンと同様に、JavaScript コミュニティで今でも頻繁に議論されているトピックです。これは、js 開発に関する他の問題が既に解決されているためだと思います ;)

アドバイスが必要な場合 (そして、それが必要なように思われる場合) は、同僚と和解してください。あらゆる種類の契約を結び、それに従ってください。これは最も重要なことです。チーム内の良好な関係は、コード スタイルの合意を過大評価します。

于 2012-08-13T20:58:07.307 に答える
0

これは100%味の問題です。あなたが好むものは何でも、私はそれが一貫していることが好ましいことに同意します. そのため、プロジェクトに初めて参加する場合は、確立されたスタイル ガイドに従う必要があります。

于 2012-08-13T20:46:45.533 に答える
0

Google で働いていないときは、その規則に従う必要はありません。それは何も壊しません。個人的には後者のバージョンが好きです。それはもう 1 行です。

于 2012-08-13T20:50:21.710 に答える