これに関するいくつかの質問:
私が言いたいのは、このようなものです:
#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 Compressorを使用して、終了セミコロンを自動的に削除することをお勧めします。
ブラウザが「壊れる」ことがありますか?
いいえ、ブラウザは仕様のこの部分を正しく実装しているため、安全です。 CSS2仕様 はこうして宣言を定義します:
declarationは空であるか、プロパティ名、コロン(:)、プロパティ値の順に構成されています。
さらに重要なことには:
...同じセレクターの複数の宣言は、セミコロン(;)で区切られたグループに編成できます。
この意味は ;
は、複数の宣言を分離するために使用されますが、それらを終了するために必要ではありません。
Javascriptの最後の関数も同じですか?
JavaScriptは完全に異なる仕様を持つまったく異なる獣です。この特定の質問は詳細に回答されました スタックオーバーフローの前に何度も 。
いいえ、セミコロンはアプリケーションに多大なリスクをもたらしますが、要素にさらにスタイルを追加すると、セミコロンを追加し直すのを見逃すのは簡単すぎます。その時点で、手動プロセスと詳細への注意に頼って、非セミコロンラインを誤って置き忘れないようにしています。さらに悪いことに、各要素の最終的なスタイル行を台無しにしないように、本番環境に行く準備ができるたびにcssファイルを物理的にチェックする必要があります。
おそらく、ファイルは小さくなりますが、その差はごくわずかです。読み込み時間が心配な場合は、 Gzipping ファイルをサーバーに配置する前にファイルを使用すると便利です。
ほとんどのブラウザは、あなたが何を意味するのかを知るのに十分賢いですが、最後のスタイルに注意を払わないことで、CSSファイルを台無しにすることを心配する必要があります。
私の意見では、いいえ。最後のルールの下にルールを追加する場合、セミコロンの追加を忘れがちです。
ロード時間に大きな違いが生じるとは想像できません。
いいえ、セミコロンはCSSブロック内のルールを分離するためにのみ必要です。セミコロンは区切り文字であり、終端文字ではありません。
はい、セミコロンを追加するためにJavaScriptインタープリターに任せないでください。
declaration stops を削除しても、ブラウザは「壊れません」が、自動化されたミニファイヤはそのままにしておく必要があります(特に懸念がある場合)読み込み時間-セミコロンだけでは追加できません)が、保守性の理由からソースでは避ける必要があります。
ベストプラクティスを探している場合は、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が「呼び出され」、エラーが発生します。
x[ffVersion][isIE]()
を呼び出そうとすると、実行時に「そのようなプロパティは定義されていません」というエラーが表示される可能性が高くなります。resultOfOperation()
がdie
であり、_THINGS_TO_EAT
_がdie()
の結果に割り当てられない限り、NaN
が呼び出されます。どうして?
JavaScriptでは、ステートメントの存在を安全に推測できると思われる場合を除き、ステートメントをセミコロンで終了する必要があります。これらの各例では、関数宣言、オブジェクト、または配列リテラルがステートメント内で使用されます。閉じ括弧は、ステートメントの終わりを示すには不十分です。次のトークンが中置演算子または大括弧演算子である場合、Javascriptはステートメントを終了しません。
これは人々を本当に驚かせたので、割り当てがセミコロンで終わっていることを確認してください。
これにより、ロード時間がわずかに改善されます。十分な大きさのCSSファイルで、それは目立つことさえありえます(まあ、全体的な縮小は可能です;私は疑わしいjust最終的なセミコロンを削除するだけで十分でしょう)。
ただし、ロード時間を気にする場合は、CSSを手動で試行するのではなく、プログラムを使用して縮小する必要があります。縮小されたCSSは(ほとんどの場合)読むことができません。これを「ソースコード」で使用するのは、いわば簡単です。忘れるのはあまりにも簡単だからです。
これは重複した質問です。こちらをご覧ください:
JavaScriptでセミコロンを適用することに関しては、宣言的に割り当てられない限り、関数はセミコロンで終わるべきではありません。 var a = function() {};
ただし、不注意に(または意図的に)除外すると、ブラウザーは自動セミコロン挿入を実行します。
それは良い習慣ですか?
スマートな縮小プロセスがこれを処理するので、新しい定義を追加するときにセミコロンを配置するのを忘れるとエラーが発生するため、私はそれを避けます。
大規模にすると、ロード時間が短縮されますか?
はい、ファイルサイズが小さくなります。ただし、違いはごくわずかであり、縮小プロセスが自動的にこれを行います。
ブラウザが「壊れる」ことはありますか?
番号
Javascriptの最後の関数(/ jQuery)にも同じことが当てはまりますか?
いいえ、関数ステートメントの最後にセミコロンを除外することは「無効」です。
私の経験に基づいて、1)良い習慣ではありません。2)非常に大規模な場合でも、ロード時間はわずかです。 3)これから中断するブラウザを認識していません。 4)jQueryについても同じ
CSSについては、IE9、FF、GC、Safari、およびOperaでこれを試しましたが、違いはありませんでした。
Javascriptに関しては、FFとGCでエラーが発生したため、スクリプトではこれを行わないでください。ロード時間に関しては、違いは決して目立ちません。