これに関するいくつかの質問:
- それは良い習慣ですか?
- 大規模な場合、読み込み時間が短縮されますか?
- ブラウザが「壊れて」しまう可能性はありますか?
- JavaScript(/ jQuery)の最後の関数についても同じことが言えますか?
私が言いたいのはこのようなものです:
#myElement {
position: absolute;
top: 0;
left: 0
}
それは良い習慣ですか?
セミコロンを手動で除外することはお勧めできません。これは純粋に、スタイルを追加するときに見落としがちなためです。特に、チームで作業している場合はそうです。
あなたが始めたと想像してください:
.foo {
background-color: #F00;
color: #000 <-- missing semi-colon
}
そして、誰かがいくつかのスタイルを追加します:
.foo {
background-color: #F00;
color: #000 <-- missing semi-colon
width: 30px;
z-index: 100;
}
突然、他の開発者は、宣言が機能しない理由を理解するために時間を無駄にしてwidth
います(さらに悪いことに、それが機能していないことに気づいていません)。セミコロンはそのままにしておく方が安全です。
大規模な場合、読み込み時間が短縮されますか?
最も確実に、すべてのブロックについて、数バイトを節約できます。これらは、特に大きなスタイルシートの場合に加算されます。これらのパフォーマンスの向上を心配する代わりに、YUI CompressorなどのCSSコンプレッサーを使用して、終了セミコロンを自動的に削除することをお勧めします。
ブラウザが「壊れて」しまう可能性はありますか?
いいえ、ブラウザは仕様のこの部分を正しく実装しているため、安全です。CSS2仕様では、次のように宣言を定義しています。
宣言は空であるか、プロパティ名、コロン(:)、プロパティ値のいずれかで構成されます。
さらに重要なことには:
...同じセレクターの複数の宣言は、セミコロン(;)で区切られたグループに編成できます。
これは、;
複数の宣言を分離するために使用されることを意味しますが、それらを終了する必要はありません。
JavaScriptの最後の関数についても同じことが言えますか?
JavaScriptは、まったく異なる仕様のまったく異なる獣です。この特定の質問は、StackOverflowでこれまで何度も詳細に回答されています。
いいえ、セミコロンを除外すると、アプリケーションに多大なリスクが発生します。要素にさらにスタイルを追加すると、セミコロンの追加を見逃す可能性が非常に高くなります。その時点で、手動のプロセスと細部への注意に依存して、セミコロン以外の行を誤って置き忘れないようにします。さらに悪いことに、各要素の最終的なスタイル行を台無しにしないように、本番環境に移行するたびに css ファイルを物理的にチェックする必要があります。
おそらく、ファイルが小さくなるためですが、違いはごくわずかです。読み込み時間が心配な場合は、ファイルをサーバーに配置する前にGzipで圧縮することをお勧めします。
ほとんどのブラウザーは、あなたが何を意味するかを理解するのに十分賢いですが、最後のスタイルに注意を払わないと、CSS ファイルが台無しになることを心配する必要があります。
私の意見では、いいえ。最後のルールの下にルールを追加すると、セミコロンを追加するのを忘れがちです。
ロード時間に大きな違いがあるとは想像できません。
いいえ、セミコロンは CSS ブロック内のルールを区切るためにのみ必要です。セミコロンは区切り記号であり、ターミネータではありません。
はい、JavaScript インタープリターにセミコロンの追加を任せないでください。
これは重複した質問です。ここを参照してください:
JavaScript でのセミコロンの適用に関しては、関数が宣言的に割り当てられない限り、関数をセミコロンで終わらせないでください。var a = function() {};
ただし、誤って (または意図的に) 省略した場合、ブラウザは自動的にセミコロンを挿入します。
ロード時間がわずかに改善されます。十分な大きさの CSS ファイルを使用すると、目立つことさえあります (まあ、全体的な縮小は可能です。最後のセミコロンを削除するだけでは十分ではないと思います)。
ただし、読み込み時間をそれほど気にする場合は、CSS を手動で縮小するのではなく、プログラムを使用して CSS を縮小する必要があります。縮小された CSS は (ほとんど) 読むことができません。いわば「ソースコード」でこれを使用するのは悪い習慣です。なぜなら、忘れがちだからです。
宣言の停止を削除してもブラウザが「壊れる」ことはありませんが、自動化されたミニファイア用に残しておく必要があります (特に読み込み時間を気にしている場合 - セミコロンだけではそれほど多くはありません) が、保守性の理由からソースでは避ける必要があります。
ベスト プラクティスを探している場合は、Google css スタイル ガイドのCSS フォーマット ルールを開始するのに非常に適しています。彼らの提案をやみくもに適用するのではなく、その背後にある理由を確認してください。
すべての宣言の後にセミコロンを使用します。一貫性と拡張性の理由から、すべての宣言をセミコロンで終了します。
/* Not recommended */
.test {
display: block;
height: 100px
}
/* Recommended */
.test {
display: block;
height: 100px;
}
Javascriptは別の話ですが、短い答えは常にセミコロンを使用し、暗黙の挿入に依存することはありませんが、Googleがさらに別のスタイルガイドで規定したものよりも優れた完全な答えを見たことがありません:
セミコロンの欠落が特に危険な場所がいくつかあります。
// 1.
MyClass.prototype.myMethod = function() {
return 42;
} // No semicolon here.
(function() {
// Some initialization code wrapped in a function to create a scope for locals.
})();
var x = {
'i': 1,
'j': 2
} // No semicolon here.
// 2. Trying to do one thing on Internet Explorer and another on Firefox.
// I know you'd never write code like this, but throw me a bone.
[normalVersion, ffVersion][isIE]();
var THINGS_TO_EAT = [apples, oysters, sprayOnCheese] // No semicolon here.
// 3. conditional execution a la bash
-1 == resultOfOperation() || die();
それでどうなるの?
- JavaScript エラー - 最初に 42 を返す関数が 2 番目の関数をパラメーターとして呼び出され、次に数値 42 が "呼び出され" てエラーが発生します。
- を呼び出そうとすると、実行時に 'no such property in undefined' エラーが発生する可能性が高くなります
x[ffVersion][isIE]()
。die
が呼び出さresultOfOperation()
れNaN
、THINGS_TO_EAT
の結果が割り当てられdie()
ます。なんで?
JavaScript では、ステートメントの存在を安全に推測できると判断した場合を除き、ステートメントをセミコロンで終了する必要があります。これらの各例では、関数宣言、オブジェクトまたは配列リテラルがステートメント内で使用されています。閉じ括弧は、ステートメントの終わりを示すのに十分ではありません。次のトークンが中置演算子またはブラケット演算子である場合、Javascript はステートメントを終了しません。
これは人々を驚かせたので、割り当ては必ずセミコロンで終わらせてください。
それは良い習慣ですか?
スマートな縮小プロセスがこれを処理し、新しい定義を追加するときにセミコロンを配置するのを忘れるとエラーが発生するため、私はそれを避けます.
大規模な場合、ロード時間は短縮されますか?
はい、ファイルサイズが小さくなります。ただし、違いはごくわずかであり、縮小プロセスはこれを自動的に行います。
ブラウザが「壊れる」可能性はありますか?
いいえ
Javascript (/jQuery) の最後の関数についても同じですか?
いいえ、関数ステートメントの末尾にあるセミコロンを除外するのは「無効」です。
CSS については、IE9、FF、GC、Safari、Opera で試してみましたが、違いはありませんでした。
Javascript に関しては、FF と GC でエラーが発生したので、スクリプトではこれを行わないでください。ロード時間に関しては、違いはまったく目立ちません。
私の経験に基づくと、1) 良い習慣ではありません。2) 非常に大規模なロード時間でも、重要ではありません。3) これから壊れるブラウザを認識していません。4) jQuery についても同様