はてなキーワード: 命名規則とは
GitHub Copilotは変数名やメソッド名をちゃんと規則立てて付けてるとめちゃくちゃ優秀に機能する
boolean open
みたいに付けてると微妙なこともあるけど
boolean isDialogOpen
他にも、createDataDayっていうメソッドがあって似たようなcreateDataMonthとかが乱立してるときに実装を共有化したいって思ったときなんかは
function createDataBase
ぐらいまで打ち込むと共有部分だけ抽出してくれる
命名規則だけじゃなくて実装のアルゴリズムがちゃんと整理されて設計されているとこっちがやりたいことを把握して実装してくれる
この辺は例が難しいけれど、なんかCopilotがまともなことを返してこないな、と思う時はこっちの実装が微妙な場合が多い
整理しなおして分かりやすい状態にしておくと綺麗に動いてくれる
Copilot使えねーって言ってる人のソースはほぼ100%こういう最低限のことができてなくて
20年ぐらいプログラミングやってるっていう40代の人とペアプロしてるんだけど
変数はほとんどがグローバル的な扱いで独自の命名規則で宣言しるし
その命名規則も全然守られてないしスペルミスも多くて読んでてイライラしてくる
根本的な作り方が無茶苦茶でちゃんと動いてるのかバグがあるのかも分からん状態
PR出てくる度に打ち合わせして、そもそものデータ構造とか機能分割について指摘してるんだけど
この前ふと
「そういやJavaで書いたことありますか?Javaだとこんな感じですよね」
って話したらJava知らんと言われた
で、聞いてみたらオブジェクト指向言語で書いたことないし勉強したことも無いとのこと
JavaなりC++なりオブジェクト指向言語で書ける必要は無いけれど
ぶっちゃけ社内ルールなんて最低限の規則さえ決まってればそこまで影響ないと思ってたけど、違ったわ
フォルダの命名規則が統一されてないから同じジャンルでもあっちこっちにあって死ぬほど探すし、過去の資料もフォーマットがバラバラだから単純に比較できないし、っていうかID,Passとかエクセル、メモ帳、スプレッドシート、サイボウズ、よくわからん自社開発アプリのどれでもいいから統一せえや!そこから担当に聞かなきゃ始まらないってしんどいわ
こういう会社に限って色んなツール使いたがるのも何なんだろうなあ…
実際、これ5年もやってるのにマニュアルもないんですか…?ばっかりやんけ
今までいた会社って最低限は「できる子」だったんだなあ
ましてや優れた人から教えて貰うことでもなく
ただただプログラミングを好きになってモノづくりに熱中することだ
小さい子供がプログラミングに向いているのはモノづくりが好きだからであって
これは大人でも当てはまることであって
何かのモノづくりをするという目的の元に手段としてプログラミングが選ばれ
それに熱中することでいつの間にかプログラミング能力は向上していくのだ
上司から命令されてプログラミング講座を会社の金で受講するとか
Googleを目指して学生時代にプログラミングに打ち込むだとか
そんなのは全然上手く行かないのに定年退職したジジイがラズパイ使ってロボ作りとか始めると上手く行くのはそのせいだ
GitHubが発明したPull Requestはこの楽しみを徹底的に阻害している
「ちょっとこの辺は微妙だけど他のことやりたいから適当に済ませよう」
こうした行為はモノづくりからはほど遠く必要無いものに見えてしまい
「早く動いているところを見たい」
やがて開発者はプログラミングそのものに従事して嫌いになっていくのだ
以前からプロの現場ではもっと厳しい品質管理がなされていたという人がたまにいる
PRによってアジャイルの現場に品質管理がもたらされたと主張するのだ
命名規則やコメントの書き方などルール化できるものは別にレビューなど必要無くツールで弾くことができる
バグがあるかどうかはテストで担保すべきであってレビューで見るべきではない
この手のレビュワーが好んで使う言葉として「技術的負債」というものがある
技術的負債を残さないためにもPRで品質を保つ という主張である
一方で技術進歩は止められるわけが無く10年前に必死でクラス設計したJavaのシステムは
またはレビュワーの考える言語化できない「品質」のために今日もPRはリジェクトされる
人はプログラミングを嫌いになっていくのだ
この議論には相互性がない。あなたと同じように、相手のほうも相手でメインルーチンを走らせており、時にあなたを含む他者をサブルーチン的に利用しているのだから。
つまり、あなた側の視点だけで関わり合いのある他者を機能的に命名してしまうと、あなたというドメイン内での局所的な命名のような命名が、同時に動作しているメインルーチン数だけ存在することになり、命名管理のコストが爆発する(というか、事実上、できない)。他者(あなたにとってのサブルーチン)が、あなたが定めた局所的な命名規則によって呼び出されることを保証できないのなら、それはプログラム的な意味での「呼び出し名」として成立していない。
よって、一意性がある命名を用いて、どのようなドメインからでもおおむね目的のサブルーチンの呼び出しを可能にしていることには、合理性がある。増田のような視点で言えば、会社の役職である「総務課長」や「営業主任」などは、相手が司る機能性に着目した命名とも言えるが、そうした役職は同時に複数存在しうるので、個別のインスタンスを指定して呼び出すには、やはり一意性がある命名を利用することが合理的だ。
また、他者の「機能」は自分との関係で変化する。機能が変わるごとにサブルーチンとしての他者の呼び方を変更することは、両者がドメイン(たとえば家庭)を共有している場合は低コストで可能だが(たとえば子供ができたあとに互いを「パパ・ママ」呼びするなど)、そうでない場合は、機能が変わるたびに命名を変えるのは、メインルーチン側から見ても合理的でない。
人間が他者との相互通信のコストを最小化するには、「他者を機能で命名して、変更があった場合は頭の中でテーブルを書き換える」より、「お互いにユニークに定められたマシン名を直接叩く」ほうがよいのだ。
例えば、護衛艦のレーダーは「OPS-14」、ソナーは「OQQ-21」とかなので、やはり「O」で始まっている。
海上自衛隊の電子機器の型番はアメリカ軍の軍用電子機器の命名規則におおむね基づいているが、一文字目のみは米軍式では「S」がつけられるべきところを、「お船」(Ofune)ないし「艦載用」(On Board)を捩った「O」とされている。
「お」を付けていいんだったら、船じゃなくてもいいじゃん。
なんなら、「おにぎり」の頭文字で「O」しにてもいいじゃんって思った。
On Boardにしたってそう。
「On ○○」の形にすれば、やっぱり船でなくてもいい。on trainとかでもいい。
命名規則のなんかだと思った
「ドリアン」という匿名で音声投稿できるアプリを開発しています。
ユーザが自分の名前を決められるのですが名前が結構独特だったりします。
学校をモチーフにしたサービスなので所属する架空の高校名を決めてもらうことにしています。それがユーザ名となります。
理由はよくわかんないです。