2022/02/03 21:54
gfx
Math.trunc() 使ったことなかったな〜。
2022/02/03 21:59
igrep
なるほど確かにそれは困るかも
2022/02/03 22:26
nmcli
完璧な解説
2022/02/03 22:27
sugyan
変換するときに必ず思い出したい
2022/02/03 22:29
yarumato
“Math.floorは整数化ではない。マイナスの値における挙動が違う。整数化はMath.truncを使う方が望ましい。Math.truncなかった時代（gc38)はビット演算で整数化。parseIntは「16進/2進数」文字列の数値変換だけには使ってよい”
2022/02/03 22:43
kkeisuke
“Math.trunc”
2022/02/03 22:46
lesamoureuses
“なお、例外として 16 進数文字列（もしくは 2 進数文字列など）を数値に変換する場合は積極的に使って良いです。”
2022/02/03 22:50
ponpon_qonqon
よーし、パパ、eval使っちゃうぞー
2022/02/03 22:53
kamocyc
へー
2022/02/03 22:56
kako-jun
.NETのint.Parse()も、変換できない文字列ではtryで囲まないとアプリごと落ちて危険なのでint.TryParse()を使うし、名前がparseから始まるものは基本使わないって覚えようかな……
2022/02/03 23:40
tyoro1210
明示的に cast しようとしてる関数の呼び出し時に、メソッドに渡す前に暗黙的な cast されてるのが渋いな
2022/02/04 00:04
yosuke_furukawa
言いたいことがほとんど書いてあった
2022/02/04 00:07
mattn
おおむね理解通りで良かった。
2022/02/04 00:24
teppeis
「JavaScript において、グローバル空間に生えている関数は基本ろくなものではない（暴論）」ここだけ覚えておけばOK
2022/02/04 00:49
Shisama
整数化には Math.floor　ではなく、Math.trunc を使うようにしよう
2022/02/04 00:56
Cherenkov
文字列を数値変換
2022/02/04 01:24
atcgouch
「どのメソッドは使わないほうがいい」とか覚えるのもかったるいので本音はさっさと撤廃して欲しい…
2022/02/04 02:05
itochan
めんどいね
2022/02/04 02:06
tettekete37564
2022年だからさ！いやいい加減JSやめようぜ。組み込みのライブラリや関数の類は命名も挙動もおかしいの多い。複雑にネストされたカッコが必用なのはJSのスコープとオブジェクトの扱いがおかしいのを回避する為だからね
2022/02/04 02:17
pj_lim
廃止して
2022/02/04 02:31
rryu
Number()は正しくないフォーマットに対してはNaNを返すというところがマシな挙動ではあるが、そもそも型の異なる値やフォーマットが不明な値を渡したりする使い方が不適切なのだと思う。
2022/02/04 02:40
onesplat
floorとtruncは単純に用途の違いなのでどちらを使うべきという話ではない気が。「整数化」の定義によるでしょ
2022/02/04 02:46
lbtmplz
俺の脊髄がグキリといい、俺は死んだ…
2022/02/04 02:55
sabotem
「JavaScript において、グローバル空間に生えている関数は基本ろくなものではない」
2022/02/04 03:20
kxkx5150
はっきり言う男らしさ　”グローバル空間に生えている関数は基本ろくなものではない” / 話変わるけど, Pythonの組み込み関数 len とかマジで不愉快なんだけど.. len, str, dir, id, zip をグローバルに置くの？って感じで..
2022/02/04 05:43
hidea
jsに限らずparseはその仕様を理解して使わないと怖いよね。この話も、直接数値を突っ込むのはどうかと思う人は多いけど、どこかでtoStringした文字列が巡り巡って渡される懸念までしてる人は見かけなかった。あと暗黙のtoS
2022/02/04 06:24
homarara
うーん？　そもそも余計な文字が入ってる文字列や、小数点入りの数値をparseIntで処理しようという時点で、バリデーションのバの字も知らん馬鹿者にしか見えないんだが、問題にする所を間違ってないか？
2022/02/04 06:46
natu3kan
仕様を理解してないと予期しない値がでるから気軽に使えないヤツだ。
2022/02/04 07:05
stefafafan
parse, truncate, floorの英語の意味を考えるとまあ納得感ある気はする
2022/02/04 07:07
xlc
グローバルな関数は初期に無考慮に作られ動作に問題があるが互換性のために残されているので、使わない方がよいものもある。ちゃんと考慮されてクラスメソッドとして再実装されたものもある。ということ。
2022/02/04 07:26
haccian
どんな理由があるのかと思ったら、普通にバグで草。というか、もうjsとかいう欠陥言語使うのやめよう。
2022/02/04 07:33
atsuououo
型を変換する関数は危険
2022/02/04 07:37
mayumayu_nimolove
JSは変態言語
2022/02/04 08:19
k-wacky76
"parse"なんだから文字列の入力を想定してるのに無思慮に数値型ぶっこんでるから起きるのか。他の言語はコンパイラやコード解析で止めてくれるはずが、型無しJSが予想外に普及してとんでもないことになってんのな…
2022/02/04 08:22
breathemeditatethink
String(0.0000000005)とかでコンソールに5e-10と表示してくれるならバグに気づけるけど、そのまま0.0000000005と表示されるのに、parseIntすると5になるから、非常に厄介だなあ。幸い、今まではひっかかってないから良かった。
2022/02/04 08:26
aya_momo
Math.floorの方がわかりやすい。/Pythonのlenは整数が帰ることが保証されているのがよい。メソッドだと何を返されるか分からない。
2022/02/04 08:28
klim0824
“JavaScript において、グローバル空間に生えている関数は基本ろくなものではない（暴論）”
2022/02/04 08:37
door-s-dev
jsはブラウザで動く唯一の言語だから仕方なく使ってる人も多いのでは
2022/02/04 08:46
lli
勘弁してくれ〜
2022/02/04 09:05
masarusanjp
なんでparseIntに文字列以外渡せるんだって思ったが、"parseInt は引数に数値ではなくて文字列を取ります。正確には仕様にある通り、まず引数を ToString によって文字列に変換します。" この仕様が罠っぽい
2022/02/04 09:26
morita_non
そもそも文字列以外渡すな。型が理解出来ない人間は型なし言語を使うべきではない。あれ？逆だったっけ？
2022/02/04 09:36
koogawa
“parseInt というのは、文字列を解析して整数値（int）を返すグローバル関数であり、引数をまず文字列に変換する仕様となっております” なるほど
2022/02/04 09:47
coolworld
そもそも、なんで文字列じゃないものを渡そうと思ったんだろう。
2022/02/04 09:54
strawberryhunter
昔、JavaとPHPを比べてPHPがいかにヤバい言語かを説明するブログなどがあったが、JavaScriptには比べるべき言語が無いので今まで表立って批判されてこなかったのではないか。
2022/02/04 10:01
h3poteto
わろた "JavaScript において、グローバル空間に生えている関数は基本ろくなものではない（暴論）"
2022/02/04 10:03
ducktoon
こんな糞仕様の糞言語が広まってしまって悲しい
2022/02/04 10:06
ene0kcal
悪いけど知ってた（クソなことね）。こういった詳細と代替案を整理してるのは素晴らしい。
2022/02/04 10:07
kazuhooku
「グローバル空間に生えている関数は基本ろくなものではない（暴論）」wwww良い記事
2022/02/04 10:11
mickn
“JavaScript において、グローバル空間に生えている関数は基本ろくなものではない”
2022/02/04 10:33
katsyoshi
"JavaScript において、グローバル空間に生えている関数は基本ろくなものではない（暴論）" ここすき
2022/02/04 10:41
send
"グローバル空間に生えている関数は基本ろくなものではない" せやなw
2022/02/04 10:56
otchy210
文字列から数値への変換は正当な使い方でありと思っていたが、Number(str) の方がモダンでより安全と。
2022/02/04 11:22
sa-yama321
if (!isString(val)) { throw new Error('xxx') }
2022/02/04 11:31
kns_1234
“JavaScript において、グローバル空間に生えている関数は基本ろくなものではない（暴論）”
2022/02/04 11:55
z1h4784
知ってるんだけどつい癖でparseIntを使っちゃうんだよな。たまにしかJavaScriptを書かないからMath.truncは忘れちゃう
2022/02/04 11:58
wataken44
そのうち思い出す用
2022/02/04 12:06
uunfo
parseなんちゃらは文字列を解釈する関数なんだから、そこに数値を与えたら予想外の結果が出るのは当たり前のように思う。parseInt(“0.0000005”) が5になるならバグだけど
2022/02/04 12:20
toaruR
『parseInt(0.0000005) === 5』……ｹﾞｹﾞｹﾞ＼(^o^)／
2022/02/04 12:32
fellfield
『全体が数値でない場合は NaN が返ってくるべきなので、変換の意図を正確に表現するためにも、文字列からの数値化は Number を使うべきです』
2022/02/04 12:47
HHR
“グローバル空間に生えている関数は基本ろくなものではない（暴論）” 草
2022/02/04 13:03
zkzi3254
はぇ〜
2022/02/04 13:12
rdrk
「猫を乾かすために電子レンジに入れたら死んだから、電子レンジは使わない方が良い」みたいなクレームは、どこまでつきあうべきなんだろな。
2022/02/04 13:31
pmint
と言われて鵜呑みにするのはコピペプログラマー。適材適所。
2022/02/04 17:03
azzr
"JavaScript において、グローバル空間に生えている関数は基本ろくなものではない（暴論）" fetch()に喧嘩売ってる？
2022/02/04 18:58
hamaco
“JavaScript において、グローバル空間に生えている関数は基本ろくなものではない（暴論）”
2022/02/04 19:23
mumei-0
“parseFloat(str) を使う場面では Number(str) を検討しよう parseInt(num) を使う場面では Math.trunc(num) を検討しよう”
2022/02/04 21:18
munieru_jp
“JavaScript において、グローバル空間に生えている関数は基本ろくなものではない” わかる
2022/02/05 01:17
yo_waka
"JavaScript において、グローバル空間に生えている関数は基本ろくなものではない（暴論）ので、どうしても使わなければいけない"
2022/02/07 06:36
UDONCHAN
parceIntもStringも使って良いんだけれども、結局無邪気な型変換をしてはいけないという結論なんじゃないだろうか。Math.trunc使ったとしても、バグるときはバグるるし。