私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.140 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
>>700
それ逆にしても成立するよねｗ
それ逆にしても成立するよねｗ
セミコロンはつけすぎても問題は起こらないが（例えば2個連続の;;）
「省いた場合に問題が起こりうるということ」が問題だということが、
なぜ未だにわからないんだろうか。
「省いた場合に問題が起こりうるということ」が問題だということが、
なぜ未だにわからないんだろうか。
>>695
セミコロン必須派は文の終わりにセミコロンを付けようとする
毎行セミコロンを付けようとするバカは居ない
当然複数行に渡る文を書くこともあるし、その際には必須派でもセミコロンを付けない
そういうときに思わぬ自動挿入が起きて嵌まるというのはどちらかというと
自動挿入を利用している省略派ではなく必須派の問題
論理的に考えたらわかる
セミコロン必須派は文の終わりにセミコロンを付けようとする
毎行セミコロンを付けようとするバカは居ない
当然複数行に渡る文を書くこともあるし、その際には必須派でもセミコロンを付けない
そういうときに思わぬ自動挿入が起きて嵌まるというのはどちらかというと
自動挿入を利用している省略派ではなく必須派の問題
論理的に考えたらわかる
>>699
セミコロン要らない派はなぜそこで要らないか、なぜそこで要るのか、全然分かってないんだねｗｗｗ
functionの時点で関数式ならセミコロン付ける、関数宣言ならセミコロン付けない、だバーカｗ
セミコロン付ける派は関数宣言の終わり、
function foo() {};←ここにセミコロンなんて付けねーよｗｗ
function foo() {}←ここまでで関数宣言、
;つけたらただそのあとに空文追加してるだけじゃんｗｗｗ
関数式と関数宣言の違いすら分からんのかこれだから脳死セミコロン付けない派はｗｗｗｗｗ
セミコロン要らない派はなぜそこで要らないか、なぜそこで要るのか、全然分かってないんだねｗｗｗ
functionの時点で関数式ならセミコロン付ける、関数宣言ならセミコロン付けない、だバーカｗ
セミコロン付ける派は関数宣言の終わり、
function foo() {};←ここにセミコロンなんて付けねーよｗｗ
function foo() {}←ここまでで関数宣言、
;つけたらただそのあとに空文追加してるだけじゃんｗｗｗ
関数式と関数宣言の違いすら分からんのかこれだから脳死セミコロン付けない派はｗｗｗｗｗ
>>703
今までの流れ見てきて分かるようにセミコロン省略派必須派に限らず
ASIの挙動を抑えておかないと嵌まる可能性が残る
暗黙の型変更のようにJSerは無視できないこと
ならばそのJSらしい性質をJSを書く上で活用しようというのは自然
今までの流れ見てきて分かるようにセミコロン省略派必須派に限らず
ASIの挙動を抑えておかないと嵌まる可能性が残る
暗黙の型変更のようにJSerは無視できないこと
ならばそのJSらしい性質をJSを書く上で活用しようというのは自然
>>702
成立しないよ。
付けなければいけないところ、付けなくてもよいところ、そのどちらでも、何個もセミコロン置いても余分なものは単に空文になるだけだから。
逆に省いてはいけないところを省いちゃうととんでもないことになる。
セミコロン省略は仕様書も読まないバカにはお勧めできない。
成立しないよ。
付けなければいけないところ、付けなくてもよいところ、そのどちらでも、何個もセミコロン置いても余分なものは単に空文になるだけだから。
逆に省いてはいけないところを省いちゃうととんでもないことになる。
セミコロン省略は仕様書も読まないバカにはお勧めできない。
>>705
自分はクラス構文について話してるんだけど？
クラス構文中のセミコロンは空文ができるわけでなく
構文の柔軟性の一部でスペースのようなオプショナルな存在
それをセミコロンを付けようと意識してる人はどう考えるのかを教えて欲しかっただけだよ
自分はクラス構文について話してるんだけど？
クラス構文中のセミコロンは空文ができるわけでなく
構文の柔軟性の一部でスペースのようなオプショナルな存在
それをセミコロンを付けようと意識してる人はどう考えるのかを教えて欲しかっただけだよ
>>707
勿論付けない派の方が文法を知っていると言う
文法を知っているのにわざわざ付けるっていうのは完全に好みの話になるし
文法を知らないのに大胆にも付けないっていうのは論外なこだわり
だからあくまで文法に詳しくなく安全側に倒して付けようとしてる派と
文法を良く知って不要なものは減らそうという派という対比で当然話してる
君はそうじゃない意味がない対比がしたいのかもしれないけど俺は巻き込まないでくれよな
勿論付けない派の方が文法を知っていると言う
文法を知っているのにわざわざ付けるっていうのは完全に好みの話になるし
文法を知らないのに大胆にも付けないっていうのは論外なこだわり
だからあくまで文法に詳しくなく安全側に倒して付けようとしてる派と
文法を良く知って不要なものは減らそうという派という対比で当然話してる
君はそうじゃない意味がない対比がしたいのかもしれないけど俺は巻き込まないでくれよな
>>704
つかそもそも複数行の文の途中ってそれASI自体起こらなくね？
つかそもそも複数行の文の途中ってそれASI自体起こらなくね？
もともとセミコロンをバグなく極限まで省略するにはASI含め高い文法知識が要るという話だっただろ。
それに初心者でも脳死でセミコロン省略できるって噛みついてきたんじゃないか。いい加減にしろよ。
それに初心者でも脳死でセミコロン省略できるって噛みついてきたんじゃないか。いい加減にしろよ。
>>713
文法を完全に分かっているのなら当然どんなスタイルでも問題は起こらない
だがそうではないので意図しない問題が起きやすい弱点がそれぞれにある
セミコロンを付ける派も、return文など意図しない形で文が区切られて問題になることもあるという話
これは何十スレも前から度々話題になっているので詳細は割愛するが
==の代わりに積極的に===を使うようになればむしろ嵌まりやすくなるのと同じ
文法を完全に分かっているのなら当然どんなスタイルでも問題は起こらない
だがそうではないので意図しない問題が起きやすい弱点がそれぞれにある
セミコロンを付ける派も、return文など意図しない形で文が区切られて問題になることもあるという話
これは何十スレも前から度々話題になっているので詳細は割愛するが
==の代わりに積極的に===を使うようになればむしろ嵌まりやすくなるのと同じ
>>714
意味がわからない
脳死でプログラミングはできない
プログラミングというものは難しい
だけど入門者がセミコロン省略スタイルで学ぶのは
それはそれでその癖が付くだけだから何か問題があるとは思わないな
セミコロンを付けたほうが安全と思ってるかもしれないけど、
案外そうでもないよということでしょう
意味がわからない
脳死でプログラミングはできない
プログラミングというものは難しい
だけど入門者がセミコロン省略スタイルで学ぶのは
それはそれでその癖が付くだけだから何か問題があるとは思わないな
セミコロンを付けたほうが安全と思ってるかもしれないけど、
案外そうでもないよということでしょう
セミコロンあり派
if (x) return; ←あ、戻り値がないんだな
a();
セミコロンなし派
if (x) return
a() ←ん、これ戻り値のつもりかな、それともif文の外？
if (x) return; ←あ、戻り値がないんだな
a();
セミコロンなし派
if (x) return
a() ←ん、これ戻り値のつもりかな、それともif文の外？
>>720
派閥に関わらず、文法を理解して適切に使え、という考えがなぜ理解できないんだろう？
派閥に関わらず、文法を理解して適切に使え、という考えがなぜ理解できないんだろう？
一番人気のスタイルガイド、Airbnb JavaScriptスタイルガイド曰く、
セミコロンは付けるべきですか？
もちろん。
なぜ？
JavaScriptはセミコロンなしで改行を検出すると、自動セミコロン挿入(Automatic Semicolon Insertion)と呼ばれる一連の規則を使用して、
その改行をステートメントの終わりと見なし、（名前が示すとおり）改行の前にセミコロンを入れなければその行が壊れると考えた場所に、セミコロンを配置するかどうかを決定します。
ただし、ASIにはいくつかの風変わりな動作が含まれており、JavaScriptが改行を誤って解釈した場合、コードは壊れます。
新機能がJavaScriptの一部になるにつれて、これらのルールはより複雑になります。
ステートメントを明示的に終了し、不足しているセミコロンを検知するようにリンターを構成すると、問題に遭遇するのを防ぐのに役立ちます。
http://github.com/mitsuruog/javascript-style-guide/blob/master/README.md#semicolons
セミコロンは付けるべきですか？
もちろん。
なぜ？
JavaScriptはセミコロンなしで改行を検出すると、自動セミコロン挿入(Automatic Semicolon Insertion)と呼ばれる一連の規則を使用して、
その改行をステートメントの終わりと見なし、（名前が示すとおり）改行の前にセミコロンを入れなければその行が壊れると考えた場所に、セミコロンを配置するかどうかを決定します。
ただし、ASIにはいくつかの風変わりな動作が含まれており、JavaScriptが改行を誤って解釈した場合、コードは壊れます。
新機能がJavaScriptの一部になるにつれて、これらのルールはより複雑になります。
ステートメントを明示的に終了し、不足しているセミコロンを検知するようにリンターを構成すると、問題に遭遇するのを防ぐのに役立ちます。
http://github.com/mitsuruog/javascript-style-guide/blob/master/README.md#semicolons
何でそうまでして省きたいのか個人的にはサッパリ分からないが、どうしてもセミコロンを省きたい、かつ仕様の深い理解なんてしたくないという人は、
Airbnb JavaScriptスタイルガイドに比べ全く人気のないJavaScript Standard Styleというスタイルガイドにメクラで従うといい。
http://qiita.com/munieru_jp/items/ca16cbfa859468137d2e
Airbnb JavaScriptスタイルガイドに比べ全く人気のないJavaScript Standard Styleというスタイルガイドにメクラで従うといい。
http://qiita.com/munieru_jp/items/ca16cbfa859468137d2e
>>722
実はどちらも危険でも安全でもない
毎歩杖を付きながら歩けば安全か？
足元がおぼつかず見通せない状況ならそうだが
杖が原因で危険が起こることもあるし
大衆にとっては付こうが付かまいが安全になったり危険になったりしない
杖を付いても付かなくても躓くことはしょっちゅうあるし
躓いたところで大ゴケすることなんて滅多にないし
躓くことを一々恐れて何か対策をしたりはしない
実はどちらも危険でも安全でもない
毎歩杖を付きながら歩けば安全か？
足元がおぼつかず見通せない状況ならそうだが
杖が原因で危険が起こることもあるし
大衆にとっては付こうが付かまいが安全になったり危険になったりしない
杖を付いても付かなくても躓くことはしょっちゅうあるし
躓いたところで大ゴケすることなんて滅多にないし
躓くことを一々恐れて何か対策をしたりはしない
なんかつけない派は詭弁が多くない？
採用する理由だって今風だからとか、かっこいいから、とかしかないでしょ？
他に何かあるのメリット
採用する理由だって今風だからとか、かっこいいから、とかしかないでしょ？
他に何かあるのメリット
>>729
JavaScriptはセミコロンなしで改行を検出すると、自動セミコロン挿入(Automatic Semicolon Insertion)と呼ばれる一連の規則を使用して、
その改行をステートメントの終わりと見なし、（名前が示すとおり）改行の前にセミコロンを入れなければその行が壊れると考えた場所に、セミコロンを配置するかどうかを決定します。
ただし、ASIにはいくつかの風変わりな動作が含まれており、JavaScriptが改行を誤って解釈した場合、コードは壊れます。
新機能がJavaScriptの一部になるにつれて、これらのルールはより複雑になります。
ステートメントを明示的に終了し、不足しているセミコロンを検知するようにリンターを構成すると、問題に遭遇するのを防ぐのに役立ちます。
JavaScriptはセミコロンなしで改行を検出すると、自動セミコロン挿入(Automatic Semicolon Insertion)と呼ばれる一連の規則を使用して、
その改行をステートメントの終わりと見なし、（名前が示すとおり）改行の前にセミコロンを入れなければその行が壊れると考えた場所に、セミコロンを配置するかどうかを決定します。
ただし、ASIにはいくつかの風変わりな動作が含まれており、JavaScriptが改行を誤って解釈した場合、コードは壊れます。
新機能がJavaScriptの一部になるにつれて、これらのルールはより複雑になります。
ステートメントを明示的に終了し、不足しているセミコロンを検知するようにリンターを構成すると、問題に遭遇するのを防ぐのに役立ちます。
ぼく「よし、文の終わりにはセミコロンっと」
バカ「プーッ！ なにムダなセミコロン付けてんの？ｗｗｗ 付けなくても動くのにｗｗｗｗ」
ぼく「・・・」
－－－
バカ「あ、あれ？ 意図通り動かない…… エラーになっちゃう……」
（３時間後）
バカ「あっ、そうか！ ここセミコロン要るところだった！ さすが俺、華麗に解決できたぜ！ｗｗ」
ぼく「・・・」
バカ「プーッ！ なにムダなセミコロン付けてんの？ｗｗｗ 付けなくても動くのにｗｗｗｗ」
ぼく「・・・」
－－－
バカ「あ、あれ？ 意図通り動かない…… エラーになっちゃう……」
（３時間後）
バカ「あっ、そうか！ ここセミコロン要るところだった！ さすが俺、華麗に解決できたぜ！ｗｗ」
ぼく「・・・」
>>728
JSって色んな書き方ができて
ああいう書き方もある、こういう書き方もある
色々試して色々発見して自分のスタイルとJS知識を研磨していった先で到達するものであって
採用するとかいう話ではないと思うよ
Array()の代わりに[]を使うのと同じく
そちらの方が洗練されていると感じるから使う
Array()の方が分かりやすいと言えば勿論そうかも知れないけどね
JSって色んな書き方ができて
ああいう書き方もある、こういう書き方もある
色々試して色々発見して自分のスタイルとJS知識を研磨していった先で到達するものであって
採用するとかいう話ではないと思うよ
Array()の代わりに[]を使うのと同じく
そちらの方が洗練されていると感じるから使う
Array()の方が分かりやすいと言えば勿論そうかも知れないけどね
見にくくなるだけの記号って・・・
世にあふれるJavaScriptのコードをどういう気持ちで見てるんだろう
俺の思い通りにならないムキーってか？
世にあふれるJavaScriptのコードをどういう気持ちで見てるんだろう
俺の思い通りにならないムキーってか？
>>730
だから君は24時間風呂はいるときも寝るときも付けろというんでしょ
でも俺はポイントポイントで必要性があるときだけ付ければいいと思う
俺は常にヘルメットを被って生活してる君に対して違和感を感じてる
今ヘルメットを被らないで良いかどうかも分からない可愛そうな子にしか見えない
だから君は24時間風呂はいるときも寝るときも付けろというんでしょ
でも俺はポイントポイントで必要性があるときだけ付ければいいと思う
俺は常にヘルメットを被って生活してる君に対して違和感を感じてる
今ヘルメットを被らないで良いかどうかも分からない可愛そうな子にしか見えない
>>737
新しい配列を構築するためにArrayコンストラクターを使用することは、単一引数の落とし穴と、Arrayグローバルが再定義される可能性があるため、通常、配列リテラル表記を使用することをお勧めします。
例外は、Arrayコンストラクタを使用して、コンストラクタに単一の数値引数を与えることによって、意図的に指定サイズのスパース配列を作成する場合です。
新しい配列を構築するためにArrayコンストラクターを使用することは、単一引数の落とし穴と、Arrayグローバルが再定義される可能性があるため、通常、配列リテラル表記を使用することをお勧めします。
例外は、Arrayコンストラクタを使用して、コンストラクタに単一の数値引数を与えることによって、意図的に指定サイズのスパース配列を作成する場合です。
A「セミコロン省いたらエラーになることがあるよ」
B「文法を学んで気を付ければいいよ」
A「それならセミコロン省かないほうが安全じゃない？」
B「邪魔な記号だからいいんだよ！俺が気に食わないの！」
B「文法を学んで気を付ければいいよ」
A「それならセミコロン省かないほうが安全じゃない？」
B「邪魔な記号だからいいんだよ！俺が気に食わないの！」
>>737
よーし配列リテラルなんてうっちゃらかしてArrayコンストラクタで配列作るぜ！
var arr = Array(1, 2, 3);
console.log(arr);
//=> [1, 2, 3]
絶好調だぜ！配列リテラルなんて使ってられるか！要素１の配列も作るぜ！
var arr = Array(1);
console.log(arr);
//=> [undefined]
あ、あれ…？ (´；ω；`)
よーし配列リテラルなんてうっちゃらかしてArrayコンストラクタで配列作るぜ！
var arr = Array(1, 2, 3);
console.log(arr);
//=> [1, 2, 3]
絶好調だぜ！配列リテラルなんて使ってられるか！要素１の配列も作るぜ！
var arr = Array(1);
console.log(arr);
//=> [undefined]
あ、あれ…？ (´；ω；`)
>>743
思い付くのはgithubスター数と、babel-presetの週間ダウンロード数だな。
思い付くのはgithubスター数と、babel-presetの週間ダウンロード数だな。
仕事で書くときはプロジェクトのスタイルに合わせるんだし
個人の趣味で書いてるのは好きにすればいいじゃん
個人の趣味で書いてるのは好きにすればいいじゃん
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
JavaScript スレッド一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.141 + (881) - [97%] - 2021/4/19 9:00
- + JavaScript の質問用スレッド vol.120 + (1002) - [97%] - 2014/11/8 1:15
- + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
- + JavaScript の質問用スレッド vol.110 + (1001) - [97%] - 2013/10/13 14:01
- + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.142 + (984) - [97%] - 2020/8/27 19:15
- + JavaScript の質問用スレッド vol.142 + (926) - [97%] - 2019/12/23 13:15
- + JavaScript の質問用スレッド vol.141 + (1001) - [97%] - 2019/9/22 23:15
- + JavaScript の質問用スレッド vol.100 + (1001) - [97%] - 2012/6/13 22:46
- + JavaScript の質問用スレッド vol.143 + (753) - [97%] - 2020/4/19 5:00
- + JavaScript の質問用スレッド vol.144 + (288) - [97%] - 2020/5/17 20:00
- + JavaScript の質問用スレッド vol.123 + (966) - [95%] - 2020/10/20 2:30
- + JavaScript の質問用スレッド vol.122 + (116) - [95%] - 2018/5/2 18:30
- + JavaScript の質問用スレッド vol.122 + (1004) - [95%] - 2015/2/14 4:45
- + JavaScript の質問用スレッド vol.115 + (1001) - [95%] - 2014/5/29 16:16
- + JavaScript の質問用スレッド vol.121 + (1001) - [95%] - 2022/11/29 16:30
- + JavaScript の質問用スレッド vol.119 + (1002) - [95%] - 2014/10/3 15:30
トップメニューへ / →のくす牧場書庫について