  |
はてなキーワード: 変数とは
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
「理論的には、金融政策は、何らかの名目変数（例えば、マネーや名目金利）を操作変数として、名目総支出ないし名目総需要をコントロールする政策と捉えることができる。」
「中央銀行が通常用いる経済モデルでは、供給ショックで生じたインフレは一過性のものであり（供給が増加すれば解消する）、金利政策の目的は総需要の制御である」
米雇用統計が予想より弱い結果になったことでドル安が進んだが、金利が雇用統計に影響を及ぼすまでに相当な時間がかかるわけでこの結果は相当前の金利の影響と考えられる。
様々な変数かつ複合的な影響があるためいつの金利操作が原因かを特定することは不可能と思われるが、ここで雇用統計が多少下がったところで金利政策に影響することはないのではないか。逆に強ければ急いで利上げをする必要があるので今後の安心材料とは考えにくい。
サービス部門PMI購買担当者景気指数も予想より弱く50.6となったことも裏付けか。ISM非製造業景況指数も51.8と弱い。
全体としては減速したもののマイナスに落ち込むほどではなく絶妙なバランスではないだろうか。少し先行きを見ないと判断しにくい。心配なのは放置すると一気に不景気に陥るのではないかという点。指標が出てからでは遅すぎる。
中立金利r*をどこにFRBが設定しているかは当然明かされなかったがどこかの時点でそこに向かう必要がある。
パウエルは市場との対話を少しばかり重視すぎではと思うところもある。金利操作が表れるまでに時間差があることは十分認識しているはずなのに市場や実体経済へFRBが示すサインとしての金利政策を使っているようにみえるというか。やや危険に思う。
俺は気象予報士試験は一般は通って専門は15問中一問分ボーダーに届かなくて落ちた経験がある人間だが、そんな人間が気象大学校の学生が教材として使ってる気象庁ホームページで公開されてるテキストの理解を試みてみたところ、さっぱり分からないという始末になった。
https://www.jma.go.jp/jma/kishou/know/expert/pdf/textbook_meso_v2.1.pdf
これの14ページ（資料下に印字されてるページ番号としては8ページ） なのだが
dVc/dt=αVsという式が成り立ってて、この式は気圧傾度力が考慮されてるとも書いてあるが、まず一体どういう力の作用の構図を想定してるのかが分からない。
左辺はただの時間変化を微分として表現したもので、右辺もまた中層風と下層風の単なる速度差だから、これが気圧傾度力が考慮されてる式だとしたら、αの一文字が気圧傾度力を表してるって自動的に解釈されるというか、それ以外に解釈の余地が見当たらない。
一方、傾度風や地衡風について立式するとき速度（ベクトル）にコリオリパラメータを掛けそれに気圧傾度力（と遠心力）を足し引きしたような方程式になるわけで、そうなる理由も予報士試験の参考書に力の作用関係の図示付きで書いてあったし理解してるつもりなのだが、だからこそなぜベクトルに「掛けてる」のが気圧傾度力でそれが速度の時間変化に等しくなるのか全くぴんと来ない。
そもそも左辺が速度の微分なのに右辺も速度の定数倍になってるのも理解が追いつかない。なぜ加速度でないのか？
Vc=aVl+bVmについて大気の密度が小さくなると速度が大きくなるのでa+b>1となるとも書いてるが速度が大きくなることからどうその不等式が成立することが導かれるのかもわからない。もっといえばなぜ密度が小さくなると速度が大きくなるのか…ときりがない。
おそらくこちらにとっては天下り式で説明が足りてないように見えるテキストも、気象大学校に入れる学生から見ればあれだけの情報から私が分からないと言った理由も十分読み取れるのだろう。
それはなんというか、少なくとも高校までの履修内容の理解の完成度が全く質的に違うことがこのような差をもたらしてるんだと思う。
たとえば逆に俺でも先に成立する理由が分からないと言った微分方程式が正しいことを前提としてなら、その下に書かれているのがそれを解いた式であることは納得できる。俺でも高校のうちに初歩的な変数分離法は身に付けてるからだが、人によっては同じ理系でも化学系の学部に入る人とかで大学入試を終えた直後の段階で大学レベルの教養数学を学んだ経験が皆無な状態だとただの変数分離で解かれた式にすらぴんと来ないってことはあるかもしれない。
そして気象大学校に入る人たちはこんなのよりもさらに奥深くまで見通しよく高校までの内容を理解してるのだろう。うまいたとえかわからないが、数学の白黄チャートしかやってこなかった人間が赤チャートを見たら同じ単元でも全く別物の内容を学んでいるんじゃないかってぐらいのものに感じるような感じだろうか。気象大学校の入学者も高校段階の知識でもはや私とは全く異なるような理解を持っているのだと思う。彼らから見れば私が分からないと言ってることは変数分離が分からないことが不思議になるぐらい当たり前のことなのだろう。
ただ5chの気象予報士試験対策スレで質問しても、独学で合格したけどここで聞くより予備校で聞いた方がいいぐらいさっぱり分からないと言われた。
気象予報士だって合格したら割と誇れる資格なのにそういう人でもさっぱり分からないって、もう気象大学校の学生は私や予報士とは住む世界が違うような頭の良さを持ってるんだと思う。
そういう人たちでやっと気象災害の対策に責任持てる仕事をする資格が持てるんだなーとある種納得と途方のない挫折感。
地震が起こると毎度同程度の地震が数週間起こる可能性があるとか同じようなこと言ってるなあろか馬鹿のしてる場合じゃなかった。
