  |
はてなキーワード: 変数とは
https://www.nhk.or.jp/shutoken/wr/20240202a.html
国連機関などで移民・難民政策などの実務に長年携わってきた一橋大学の橋本直子准教授に聞きました。
「川口市の広報によれば、犯罪の認知件数は10年ほど前と比べて半数ほどになっています。問題は『体感治安』です。日本語で意思疎通ができない人が夜中に集まっていたら、恐怖を感じる人も多いと思います。
https://anond.hatelabo.jp/20231005132847
川口市は『広報かわぐち』という広報誌を配布しているが、この10月号で犯罪認知件数が過去最低を記録しているとの広報を打っている。
https://www.city.kawaguchi.lg.jp/material/files/group/3/202310-04.pdf
川口市の広報ももちろん嘘は書いていない。実はこれにはカラクリがある。
川口市の広報は犯罪認知件数が一番少なかった令和三年の数字を飛ばしてる。そして令和四年度の数字を使っているから少なく見えているだけだ。また、今年はもっと犯罪が増えている。
埼玉+4.5%
全国+2.2%
去年（令和４年）から今年（令和５年）（７月まで）の増加率が
川口+25.9%
となっている。
◯全国的に犯罪認知件数は減少傾向である（犯罪認知件数ってのは高齢化や経済などさまざまな変数によって増減するもので、単に減っているからと言ってクルド人による治安の悪化があったなかったは不明であり、それを根拠に論ずるのは妥当ではない）
◯近年の川口市の犯罪認知件数の増加率は埼玉県と比べても全国と比べてもかなり多い。
この学者さん、実際の数字を取り上げずに「川口市の広報によれば」って責任を投げてるの非常に頭が良いですね（もちろん誉めてません）
「10年ほど前と比べて約半数」が正しいならミスリードに誘導しているのは直近2年の数字を使って否定しようとしている増田の方だね
何言ってんの？
そもそも犯罪件数の総数の動向とクルド人による犯罪件数は結び付けて論じられないって言ってんの。
pythonコードの速度のボトルネックを見つけるにはline_profilerが使える。
だが一部の開発者は「速度に凝り過ぎるとコードが読みづらい」という。
これには異論がある。
大幅に速度を改善するようなコードの改善は、むしろコードをシンプルに保つ上でも重要な働きがある。
傾向としては、マルチプロセッシングなどを使わずに速度を改善した場合は、プログラムの長さは減少する。
速度を改善すれば、特定の出力をするコードの最小長(コルモゴロフ複雑性)に近づく。
速度改善によってわかりにくくなるという人は、数学ができないのかもしれない。
物理学では、変数を単一の文字で表すことが多いが、こういうのに慣れていると「シンプル」の概念に差が開く。
こういった科学的な「シンプルさ」を理解できない人に対して、意味を説明する形で変数名を決めても、結局コードは理解できないだろう。
確かに、ビジネスドメインに近いコードであれば変数名をドメイン語に合わせるのがわかりやすい。
しかし「ボトルネックを改善しなければシステムが要件通りの速度にならない」ようなケースでは、数学的なコードの方がわかりやすくなるのである。
等比数列の漸化式が初見では理解できなくて数日間悩んだ記憶のある地方旧帝大卒業生としては、「変数の概念を全員が理解し得る」みたいなことを言われるよりはよほど尤もらしいと感じる
プログラミング言語側に組み込まれている「型」だけでなく、プログラマーが独自に「型」を定義する方法も用意されています。
struct、class、interface、type, enumなどを使って独自の「型」を定義します。
開発しているソフトウェア独自の「型」は、ドメインモデルの要素になります。
多数の「型」を分類し、組織化するために名前空間を利用します。
近年「クラス」が「型」の定義であるという基本概念を理解していないエンジニアが増えているので、エンジニアを採用する際には注意しましょう。
ソフトウェアを起動すると、メモリ上には、たくさんのデータを読み込まれます。各データには、データの種類を表す「型」が割り当てられています。
例えば、ゲームならばCartという大分類の「型」を用意し、その要素としてMarioCart, LuigiCartという「型」を用意します。
業務システムならば、Reportという大分類の「型」を用意し、その要素としてCostReport, SalesReportのような「型」を用意することになります。
これらの大分類の「型」と、要素の「型」は、is-a関係にある、といいます。
CPUは機械語しか理解できません。一方で人間は機械語でプログラミングすることは困難です。
人間が「1ドル」のつもりで、メモリに「1」と記憶させても、CPUは「ドル」だとは扱ってくれません。
CPUは、「円」のつもりで記憶させた「1」と、ドルの「1」を区別出来ないので、そのまま足し算などの演算を実行してしまいます。
そこで、人間にとってプログラムを読みやすくすることと、CPUに意図しない演算をさせないために、データの種類を表す「型」という概念がプログラミング言語に用意されるようになりました。
金融やECサイトなどのお金の計算間違いが致命的なシステムでは、1ドル、1円を整数型などで扱うのではなく、予期せぬ演算が実行されないように「ドル型」、「円型」という「型」を定義します。
メモリ上のデータがどの「型」に属しているのか、という集合論の話でもあります。
例えば、猫型のデータは、動物型という大分類に属する、という集合の話です。
オブジェクト指向プログラミングの「is-a関係」は、集合論に由来するメモリ上のデータ(オブジェクト)の分類の話です。
1. **条件式の曖昧さ**：JavaScriptでは、`if (value)` は `value` が「truthy」（真と評価される値）である場合にのみ実行されます。しかし、このコードは明確ではありません。`value` が何を意味するのか、どのような値が期待されるのかがコードからは読み取れません。`null` でも `undefined` でもないことを確認するには、より明確な条件式（例：`value !== null && value !== undefined`）を使用する方が良いでしょう。
2. **ログメッセージの不明瞭さ**：ログメッセージ `'null でも undefined でもねーわ'` は、`value` が `null` または `undefined` でないことを示しているようですが、これはコードの実際の動作と一致していません。`value` が 0、空文字列（`''`）、または `false` の場合でも、この条件は偽（false）と評価されますが、これらは `null` または `undefined` ではありません。
3. **コードの可読性**：コメントやより記述的な変数名を使用することで、コードの意図や動作を明確にすることができます。現在の状態では、このコードの意図を理解するのが難しいかもしれません。
JavaScript でさあ
変数 value が null でも undefined でもない事を確認するのに
if (value) { console.log('null でも undefined でもねーわ'); }
これほんとやめろって。
おかげで value に 0 とかが入ってる時に、このコンディションが false になるわけだ。
色んな会社さんのコード見てきたけど、このタイプのバグ本当に多い。
昨年は、世界的にも有名な会社さんのフレームワークがこれでバグってた。
でももう既にシステムの一部は本番稼働しててフレームワークはいじれない。
仕方ないので value には一旦文字列の '0' を渡しておいて if (value) {～} の中の重要なロジックを動かして
(めっちゃ幸運な事に、数値 0 のかわりに文字列 '0' でも正しく動くような、型について緩いロジックだったから)
その後で改めて value に数値 0 を入れなおすという、きったないハックで誤魔化した事もある。
自分がお客様だったら怒るね。「いやいや、全部理想的なコードにしてちょうだいよ。お金払ってんだよ？」って。
ITエンジニア達がこぞってクソコードの話をしている。他人様が書いたコードにいちゃもんをつけて悦に入ってるのだ。
書いてあるコードの変数名にいちゃもんを付けたり設計にいちゃもんを付けたりするのが奴らの生業だ。
Xでは今その話題で持ちきりである。クソコードだと揶揄するのは構わないが、ところでお前らはちゃんと風呂に入っているのか？
他人様にいちゃもんを付けているのにまさか、風呂に入ってない奴なんていないよな？
リモートワークだからと胡座をかいて、稀にある出社日に洗ってない犬のような匂いとカビ臭い服の匂いをオフィス中にプンプン漂わせてないよな？
くせぇんだよ。せめて風呂入って洗濯した服を着て出社してくれ。
コードの重複があるわけでもない状況で、コードを関数ごとに分離するメリットデメリットを知りたいという話ですよね。
コードの重複がある場合に関数などに切り分けていないと、同じコードを何度も書くことになり、不具合があった時にコピーされたすべての個所に変更が必要となるというデメリットがあるので理由がわかりやすいですが、重複が無いとその点が不明確ですね。
画面に収まらないサイズのコードは複数の関数に分割するのが一般的だとは思います。
理由は元増田も書かれている通り、長いと理解の限度を超えるからです。
コードは意味があるまとまりで短ければ短いほど理解がしやすいと思います。
グローバル変数を使わないようにすると、入力・出力が関数を読むだけで明確にわかるので、さらに理解がしやすいです。
また、関数に分けておけば、関数が仕様通りに動くかの確認するユニットテストも簡単に書けます。
ユニットテストでは関数がさらにほかの関数を呼び出している場合、呼び出される関数の代わりにテストダブルを用意することもあります。
分割して、複数の関数を呼び出すようにすることのデメリットは、
下手糞が切り分けるとなんでそういう切り分けになったかわからないところで切り分けられてかえって可読性が損なわれるとか、
関数の機能が拡張してより多く・あるいは少なくの情報が必要な時に関数インタフェースの変更が必要になることとか、
関数を置いているファイル内の場所を変えたときにバージョン管理システムが追っかけてくれないことがあるとか
くらいでしょうか。
いずれにせよ、分割するメリットの方がデメリットを上回ることが大半なので、大抵は機能ごとに分割して小さい関数を作り、それをメインからは呼ぶようにすると思います。
まず、関数の名前をやっている工程を表すものにすることですね。
「データの取り込み」 とか 「データの突合せ」とかを明示すると、それを呼んでいるということはそういうことをしてくれると思うので。
また、関数が何をしてくれるのかも関数のコメントとしてつけておくとよいと思います。
例えば、
filename引数で指定されたファイルからデータを取り込み、JSONフォーマットで返す
返値: JSONフォーマットされた取り込まれたデータ。例: [{'employee name': '山田 太郎', 'employee id': 1}]
例外: filenameを開けない場合はFileOpenError、JSONにコンバートできなかった場合はConvertError
みたいなコメントをつけておくと何をする関数なのかわかるので、その機能を調べたいとき以外は読まないでいいかなと。
あと、コードを連続で読みたい場合、ソースを解析してタグジャンプをつけてくれるツールやらIDEやらを使うことが普通だと思います。
これはどういう意味でしょうか？同じものを表すのに関数ごとに別の変数名を付けているとか？
もしそうだとしたら、使っているプログラミング言語の制約やプログラミング規約によるものなのでしょうか？
ある関数のローカル変数が他の関数のローカル変数に影響を与えることは無いはずなので、ローカル変数は大抵適当な名前が付けられるイメージです。
今時のプログラミング言語なら変数のスコープが関数の中にとどまるような書き方ができると思うのですが。
関数インタフェースを定義し、そこにいちいち引数を書くのが面倒というなら...まあ、それは必要税って感じがします。
そこに引数を書いておくことでこの関数が何に影響されるのかわかるので。
参考までに。
複数の機能で成り立っている長いコードを分割して実装することののメリット/デメリットを教えてほしいです。
「コードの分割」が指してることを大まかに言うと、「メインの関数は各機能を呼び出すだけで、実際の機能の部分はサブルーチンとしての関数(って表現が正確かも謎)に持たせ、サブルーチンを順次呼び出すことで総体としての機能を成す」ような方式にするってことです。
より具体的に言うと、1.データの取り込み2.取り込んだデータの突合3.帳票の出力の3手順を別々の関数とし、メインの関数から1,2,3の手順の関数を順次呼び出すという具合です。
上記の方法と、全ての機能を詰め込んだ一つの長い関数にする方法と、どちらが結局よかったのかなと思っているんですね。
今のところ私は自分のわかりやすさのためにコードを分割する書き方をしています。理由は、1機能1関数で分けておいた方がステップインじゃないですけど「ここまでは完走できた」の切り分けがしやすいのかなーと思うのが一つ。もう一つは単純に上下に長くなっていくとどの変数がどれでと特定していくのが辛いってのがあるためです。
ただこの方法にも問題があると思っていて、一番はメイン/サブ関数間で右往左往するので今やってる工程が何なのかがよくわからん、他人が読むならなおのこと、ってことです。一応の対処として、メインの関数は目次的に「総体としてこのような機能を持っている、また分割した関数の機能はそれぞれこうである」とコメントアウトし、サブの関数にも「この関数はここからここまでの作業をします」とコメントアウトすることにしています。
あとは関数ごとに変数をいちいち定義し直すのがだるいみたいなのもありますね。グローバル変数は後々の修正とかのために使わないようにしています。
自分では思いつけてない部分でコード分割することのやばみってあるのかなーと思ったので質問させていただきました。近々退職する予定なので、他人への引継ぎって観点からどうなのかなと思っています。
以下自分語りです。語彙とか概念のインストールが足りないと適切な調べ方ができなくて困るんですねー。あと問題があることを認識できなかったり効率悪かったり車輪を再発明したりとか。
私は無学のバイトなんですが、あるとき上長から「暇なら適当にエクセルでも勉強しといて」と漠然と言われて、このVBAっちゅうもんを学べばええんか？と勘違いしたのが始まりでした。本当はセルの結合とか別のセルを参照するとか、エクセル方眼紙的なものをある程度作れるようになってほしかったらしいです。折角なのでなんとか役に立つものをと思って、ある集計作業を自動化させたところ、今後も暇なときはよろしくということになりました。
いろんなものを作りましたが何をどのように作るかから、その後の運用保守までほぼ一任してもらって大変面白かったです。しかしなにぶん仕様や実装方法について相談できる方がおらず全ては私の泥縄式学習術によって成り立っているという恐ろしい状態でした。体系的な知識や組織の経験知みたいなものが一切ないので自分がどこにいるのか、努力の方向性が合ってるのかも結果が出るまでわからない。先達のあらまほしきことなり。
それは人によるな
俺はマルチプレイで嫌な思いすることがあるジャンルよりもソロプレイ主体のジャンルの方が好きで10年20年と続けてる
交流必須なやつは本当に若いうち(せいぜい30歳前半くらいまで)しかできん気がする
俺がインドアで対象がゲームで交流必須なジャンルは20代前後が多いせいだと思うが
むしろ一人でやりこめるゲームほど自分で効率とか計算して好き放題にめんどくさい遊び方ができるのが良い
べつにライトに遊ぶこともできるんだけどせっかくなら色んな要素を考慮してめちゃくちゃ複雑に考えながら計画立てて遊んだほうがやりがいあるだろ
めんどくさくなりすぎたら取り込む変数を減らしてガバ計算にするとか、ルーチンを省略するとかでライト寄りのプレイスタイルに修正すればいいだけだし
先日とある話し合いの場のような所に参加してきた。
そこは哲学的に議論しようというスタンスの集まりで、ある話題について色々と話したんだ。
どんなことを話し合ったのかは身バレしてしまうので詳しくは書けないんだけど、それでも話を聞いていて一つ思ったことがある。
x + 1 =
xは変数で、どのような数も入れることが出来る。このとき正確な答えを導き出すことは可能か？
当然、無理だ。
話を聞いていて、ふとそう思ったのだ。
そもそも答えのないものを哲学的と呼ぶようだし、人によって価値観は違うのだからxの数値は常にバラバラになってしまう。
それなら答えが出ないのも当然で、答えのない答えを求めたところで意味はあるんだろうか？
「技術的に何ができるのかは、仕様を考える上であまりにもインパクトが大きい変数です。それを考慮せずに仕様案を作ること自体が筋が悪い」
ここでもうわかってるんだけど、世の中よくあるように近視的になっちゃってその後が迷走してる
仕様案を作ること自体が筋が悪いんだからつまり仕様案を作っちゃダメなんだよ
普通に考えたらそれ以外ないじゃん
ユーザーのやりたい事は例えばここみたいなサイトなら「興味がある記事が見やすいとこに出る」とかであって、どこを太字にするとかどこに表示するとかどういう条件でやるとかなんならAIぶち込むかとかはエンジニア側で決める事
まあそれをやるには組織がフラットでエンジニア側の能力と給料と権限がPOと同等以上じゃなきゃいけないわけだけどおそらくそこが癌だろうね
オブジェクト指向とかかっこいい言い方をしても無駄だ。従来の構造化プログラミングから進歩したことなど一つもない。オブジェクト指向がなぜダメであるのか、それを今から話すぜ。
1. データと処理をまとめるという発想。
データと処理をまとめてクラスとして置くという発想がある。しかし、このようなことをしなくとも、モジュールという単位で利用データと処理の集合をまとめればよかったので、クラスを使う必要はない。しかもクラスはインスタンス化のときに、不要な情報まで持ってくるのでメモリ効率が明らかに悪い。コンピュータが進化しているからメモリのことはあまり考える必要がないとはいえ、必要ない処理をまとめて閉じ込めるのは無駄が多い。なぜクラスという名詞で概念分類できると考え始めたのかは不明だが、アルゴリズムとデータ構造という構造化プログラミングの手法を、クラスと型というパラダイムに変換することで型にうるさいC++馬鹿を生み出し、彼らが発狂することになってしまった。しかもデータと処理にわざわざ依存関係を持たせて、変更に対する柔軟性を失わせている。
2. 継承
継承によって既存の構造を持ってこようとする必要性が全く無い。それどころか、継承を使うことによってプログラムがスパゲティ化し、依存関係のグラフがややこしくなってしまう。継承など使わず、必要な情報はスコープの限られた共通の変数、または関数の引数として用意しておけば良い。もしクラスをどうしても使いたければ、共通のインターフェイスをもたせたほうがマシである。インターフェイスを使えば、クラス利用者が意識すべきpublicメソッドがなんであるか把握できる。
3. カプセル化
オブジェクト指向の中で役立つ概念はカプセル化だけである。しかし、カプセル化はクラスなしで構造化プログラミングの方法で実装できる。pythonでは、モジュールの中でアンダースコアから始まる関数を用意しておけば、それがprotectedやprivateと似たように機能させることができる。オブジェクト指向がなぜカプセル化が独自の概念だと言い始めたかは謎。
4. ポリモーフィズム
同じ名前のメソッドを、入力に応じて処理の内容を変える。このようなことはオブジェクト指向などと誇大宣伝をするほどのことでもない。構造化プログラミングで似たようなことができる。
https://jp.reuters.com/article/column-tetsuya-inoue-idJPKBN2WL053
「中央銀行が政策金利を上げ下げすると、企業や家計の設備投資や消費といったフローの経済活動に直接的な影響を及ぼし、総需要の変化を通じて物価動向に影響を及ぼす、というのが伝統的な金融政策の理解である。」
https://www.zenginkyo.or.jp/fileadmin/res/abstract/affiliate/kintyo/kintyo_2016_1_10.pdf
「理論的には、金融政策は、何らかの名目変数（例えば、マネーや名目金利）を操作変数として、名目総支出ないし名目総需要をコントロールする政策と捉えることができる。」
「中央銀行が通常用いる経済モデルでは、供給ショックで生じたインフレは一過性のものであり（供給が増加すれば解消する）、金利政策の目的は総需要の制御である」
