「引数」を含む日記 RSS

はてなキーワード: 引数とは

2024-11-20

こういうのってどうすれば汎用化できるか?

引数として最適化母数をとれば、母数をとってくることはできる

モデル関数の形を引数にするわけにいかない

選択肢にするか?

異なる関数を組み合わせている場合はどうするか?

2024-09-19

リファクタリングして、理解不能バグが起こって、そのたった一つの修正に30時間以上かけた

FUCK

途中で他のとこのバグ修正もかなりできたのが救いではあるが・・・

わかりやすくするために無駄にrefするのやめようと思って引数からrefキーワード外していたのが原因だった

2024-09-16

DIかいらんくない?

どこで必要になるのか

仕組みが複雑になってるだけ

いつか使うかもで必要ないもの作るのはやめとけって何かの原則みたいなのにもなかったか

 

使える場所なんてテスト時くらいだ

しかテストアプリ動作必須ものでもない

そういうものだけのために追加のものを導入はしたくない

テストしか使わないならテストツールフレームワークが側でどうにかすればいいこと

言語によってはモジュールコンポーネントモックすることで密結合になってるモジュール差し替えできる

 

それ以外の用途クラス差し替えたいなんてめったにない

どころかまるでない

仮にあったとしても普通に引数関数に渡せば十分だ

例えばReactではコンポーネント引数として内部で使うコンポーネントを渡している

これで十分で不満に思ったことはない

変更の必要なければ渡さなくてよくてその場合規定クラスコンポーネントが使われるだけだ

この場合は複雑な仕組み等は一切不要

変な仕組みがないということは初見にも優しい

2024-09-04

anond:20240904093219

ああ、いいじゃん

これならいいよ

引数が多いのがシンプルになったってレベルじゃなくて回帰で綺麗にできてる

2024-09-02

anond:20240902122304

お前の職場(嘲笑)

最初は2つだったんだが、要件が増えていく時に徐々に増えていってめんどくさくて引数に新しいのを追加するだけ

anond:20240902121938

任意の数なのにたくさーん引数でいいでしょを**にしたから偉いでしょって

お前のコード本当に任意の数ハンドルできてるか?

あげてみなさい、特別にタダで見てあげるから

anond:20240902121826

最初は2つだったんだが、要件が増えていく時に徐々に増えていってめんどくさくて引数に新しいのを追加するだけにしてたらしいんだよね

それじゃおかしいだろっていって*argsとか**kwargsを使ったほうがマシって話

元々が「悪いもの改善する」って話なんだから、筋は通ってるだろ

anond:20240902121529

まさか任意の数なのにたくさん引数作ればええやろ!でたくさんabcとかやってたの?

仕事でやってる方ではないよね?

anond:20240902120531

大体お前さー

引数が多い時点で設計ミスとか

多いなら構造体にするとか

料理でいうなら米を洗剤で洗うなレベルのことを優しく言われてるのに(俺ではない)

逆ギレして差別用語罵倒とかさあ

もう2度と書くなよここに

anond:20240902120124

アスペか?3つで書いたのは単に便宜上であり、実際は可能性のある入力の個数は複数りある。すべての通りに対応するために引数をその個数に合わせるより*argsか**kwargsにしたほうが効率が良い。

anond:20240902113934

一見シンプルに見えるのが可読性高いわけじゃないんだよ

全部まとめちゃってそもそも中身をみないと何が来てるのかわからないのは、全くの素人シグネチャだけみたら簡潔に見えるかもしれないけど

実際には可読性かなり下がってる

他の人が指摘してるように

引数無茶苦茶ふえてるのがそもそも問題だし

クラスにするというのもそのとおり

もう一つ付け加えると引数名前見て何だか全くわからない

anond:20240902113308

その引数群を特定関数しかさないのなら辞書化する意味いかな。

複数箇所で使うなら構造体(pyhtonならdataclass?)かクラス使うかな?

引数多すぎ問題についてはケースバイケースだと思う。

再利用しない処理なら変に分割せずに一つの関数にまとめるのもアリだし。

[] 引数が増え過ぎたら辞書化する

粗結合性から見るとアンチパターンだが、コードの見やすさは上がる。

#改善def honya1(a,b,c,d,e,f,g,h,i,j,k,l,m,n):
     (処理)

#改善def honya2(**kwargs):
     (処理)

追記: 文脈がわかってないようなので書く。これは、どこかの計算で使われた集合を複数個(a,b,c,d,e,f,g,...)引っ張ってきて直積にする算術最初は2つだったので良かったが、徐々に必要直積が増えていき、その分だけ引数定義していた。しか任意個なのでNoneを与える部分もあった。*argsか**kwargsを使えばもっと簡単にかけるはず。

2024-08-24

javascriptの連番配列生成どれが好き?

そこまでシビアな速度は求められてなくわかりやすさで比べた場合

Array.from({ length: 5 }, (_, i) => i);

Array.from({ length: 5 }).map((_, i) => i);

Array.from(Array(5)).map((_, i) => i);

Array.from(Array(5), (_, i) => i);

Array(5).fill().map((_,i) => i);

[...Array(5)].map((_, i) => i);

  1. Array.from
  2. Array(n).fill
  3. [...Array(n)]

MDNArray.from({ length: 5 }, (_, i) => i); 派だった

そもそもArray(5)の要素が空だからmapできないのが直感に反する

2024-08-20

ソースコードコメントはいらない

昔の慣習に倣ってコメントを丁寧に書く人がいまだに居るけれど

99%の場面でコメント必要無い

以前のコードコメントアウトしているようなソースは論外として

例えばメソッド関数の頭にそれが何をする関数なのかを書いている人が多いけれど

メソッド名や引数名、戻り値の型をキッチリ付けておけば分からないことなんて無い

それ以上の複雑な処理をするなら機能分解するべきだし名前を付けにくい処理の場合そもそも設計おかし

昔は便利なIDEが無かったので変数関数名前に長い名前を付けると実装が大変で

仕方なくx1だとかval2だとかを使って実装してたのでコメントに書いておくようなこともあったけれど

Copilotを使える時代コメントを書く必要なんて皆無だし

仮に意味が分からないコードがあってもCopilotに聞けばいいのでやっぱりコメント必要ない

コメントがあった方が良い場合は「この実装はこのアルゴリズムに基づいて実装している」とURLリンクを貼ったり

「この規則があるのでこういう実装をしている」とRFCを貼ったりするとかはあるけれど

それもほとんど変数名だとかで解決できるし、あっても1行で終わるレベル

そういう実装全体の設計に関するような話はReadmeに書けば良いのでソースコード内のコメントとしては必要無い

「それでも無いよりはいいでしょ?」みたいに言う人いるが逆に問題になることも多い

コメントバイアスされてソースコード確認が疎かになったり

コメント内容と実装が違う場合にどっちが正解なのかが分からなくなったり

ソースコード修正に対してコメント修正されていなくて後々で揉めたりする

当然ながらコメント部分にはLintが効かないので(ChatGPT使えば作れそうな気もするが)

チェック内容も増えるし良いことがほとんどない

ヤバいJTCとかは「各行にコメントを書いて下さい」とか言ってきて正気の沙汰じゃ無い

まぁそういう案件が来たらChatGPTに丸投げするとは思うけれど下手すると「Copilot禁止」とかも言い出しそうだな

書いたところで誰も読まないのにアホすぎる

2024-07-16

[] 設定は外部化

たまに設定を引数で全部与えるようにしている人がいるが、それだけでは対応力がない

技術畑の外側の人にも設定できるようにするぐらいでないと

で、その方法が「外部化」ね

要は、設定できるあらゆる項目は、わかりやすく簡易化した上で、jsonで保存できるようにする

こうしておけば、例えばセールス業務人間が「こういう広告設定をしたい」といってjsonへ設定できるようになる

ただし、設定内容が正しいかどうかを簡単にチェックする機構をつけるともっといい

2024-06-27

プロ機械学習もやってないやつのコード

プロ機械学習系のクソコード・クソジャークっぷりが取り立たされてるけど、クソコード・クソジャークっぷりは何も競プロer機械学習er専売特許ではない。

自分経験したやつを以下に列挙する。

組み込みerC言語)のクソコード・クソジャークっぷり

フロントエンドerのクソコード・クソジャークっぷり

インフラerのクソコード・クソジャークっぷり

VBAerのクソコード・クソジャークっぷり

2024-05-28

anond:20240525203850

新卒COBOLerは大変だよな。なんせ一般的IT技術が全く身につかない。

順編成ファイルをJCLで一括ロードからSQLも分からないし、戻り値引数ブロック変数何ぞそれのレベル環境特殊からサーバ構築も当然できない。

スキルがないから他の案件に行けない経験詰めないでキャリア選択肢が狭まっていく。

ただ、品質管理だったり複雑なデータ連携整合性を考える論理思考だったりは一生役に立つ唯一の宝だな。

ワイも20年前は元増田と同じ境遇で悩んでたわ。その選択絶対に正解だと思うよ。

何はともあれ若者よおめでとう!新天地無限可能性を広げてくれ。

2024-05-09

https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa

リファレンス記述

To run a batch file, you must start the command interpreter; set lpApplicationName to cmd.exe and set lpCommandLine to the following arguments: /c plus the name of the batch file.

バッチ ファイルを実行するには、コマンド インタープリターを起動する必要があります。 lpApplicationName を cmd.exe に設定し、 lpCommandLine を /c にバッチ ファイル名前を加えた引数に設定します。

今回問題になった実際の挙動

lpApplicationNameバッチファイルパスを設定するとCreateProcessは暗黙的にcmd.exeを起動しバッチを実行しま

lpCommandLineもcmd.exeに渡されます

2024-05-07

SQLを滅ぶべしを見て何も分からなくなった

https://www.docswell.com/s/hoxo-m_inc/Z4Q8NL-2024-05-06-203800#p11

出力が先に来ることが分からないって言ってるけどプログラム書くとき殆ど言語においては出力が先に来ると思うんだけどそれもわからないんだろうか

public String test(String args){

return args;

}

大抵戻り値(出力)が先で引数入力)が来て処理が来ると思うんだけど違う?

プログラムを書くときって出力の要件を元にして処理と入力が決まると思うんだけど違う?

シーケンスとか書くと確かに入力が元に来るんだけどプログラムの当初設計をするときは出力が先で出力を得るための入力と処理が決まる物だと思うんだ

入力を決めて処理と出力を考えてたら考慮漏れ発生して手戻り発生しない?

補完がやりづらいからっていうのはわかるけど、そんなんFROM句先にかけよで終わると思うので

出力が先に来ることが分からないって言ってるのがプログラム的にも普通出力が先じゃ?って頭が混乱している

ログイン ユーザー登録
ようこそ ゲスト さん