ソースコードを分析してその著者を特定するシステムが開発される 53
ストーリー by hylom
コード品質判定システムなんかも作れるかも？ 部門より
コード品質判定システムなんかも作れるかも？ 部門より
insiderman 曰く、
Drexel Universityとthe University of Maryland、the University of Goettingen、Princetoの研究者らが、ソースコードを分析し、その記述スタイルからその著者を検出する「code stylometry」なるシステムを開発したそうだ（Slashdot）。
実験では著者が明らかになっているソースコードを自然言語処理や機械学習といった技術を使って分析・学習するシステムを開発。250人の著者、1人の著者当たり平均630行のコードを学習させたところ、95％の成功率で「匿名のコード」の著者を見つけられたという。
また、学習に使用したソースコードの著者数を30人に減らし、また1人あたりのソースコード量を1900行に増やしたところ、成功率は97％に向上したそうだ。
何となくわかる (スコア:4, 興味深い)
火消し専門の仕事を担当していた時に色々なC言語コードを見たけど、その人が「どんな本で勉強したか」「どんな性格か」は何となくわかったっけなあ。
それが「こういう人は、こういう書き方するよね」ってコード解析する上で重要なファクターだった。
Re:何となくわかる (スコア:2)
Re: (スコア:0)
if文を7段もネストしてるんですね。
Re: (スコア:0)
性格や参考書はともかく、
「この辺のコードはxxxさんが組んだっぽい。あの人はyyyyのミスをしがち。ほらやっぱり!」
つーて人を推定して未発覚の潜在バグ引きずり出すのはけっこう経験したなw
# 逆にあの人が組んだパートなら信用できそう、って詳細に踏み込まないで
# ざっとチェックして済ませた部分もそう外れなかった。
Re: (スコア:0)
「誰もが何かしらのバグを仕込んでいるものだ」と仮定したら
その粗探し手法そのものが結論を内包してたのかもしれませんね。
見つかりそうな人ばかりを念入りに探す、観測選択効果。
自慢にならないけど (スコア:3)
ありがち (スコア:1)
「コメントに俺の名前入ってるけどこんなコード書いてない」
「こっちは社名が違う」
「この日付に僕はこの会社に入社してないんですけど」
Re:ありがち (スコア:1)
自分が書いた数行のコードがあって、その数日後……
全く知らない人物から「◯◯さんのアレ、少し書き足して××で登録しました」とかメールが来たことがあった
確認してみたら、コメントに自分の名前が入っているけど、使うべきでない部分（詳細は書けない）が書き足されていて……
訴えようと思ったが、オリジナルのコードをオープンで公開することで不正改造の方を下げさせることに成功した。
３年くらい前だったかな、今では懐かしい思い出。
Re: (スコア:0)
「この会社の仕事したことないんですけど」
「その言語で書いてないんですけど」
なんでそのまま持って行くのかねぇ。。
Re: (スコア:0)
「コメントにあいつの名前入ってないけどこんなコード書いてる」
「こっちは社名が正しい」
「この日付にあなたはこの会社に入社してないんですけど」
クソコードを書いたヤツ (スコア:1)
特定して業界追放して欲しい
Re:クソコードを書いたヤツ (スコア:1)
糞コードを書く人にはコピペしまくる人も少なくないから、
分析したらどこかの有名なオープンソース開発者の名前が
ずらずらと列挙されるという結果になるかも。
Re: (スコア:0)
ブラック企業を社会から追放するのが先じゃないかな
Re: (スコア:0)
単純に、レビューしないのが悪い。
Re: (スコア:0)
残念だが、それで超劣化させられることが多い。
レビュアーやるなら言語知識くらい持てよと。
英語読めないのに英文添削するようなことがまかり通っている。
Re: (スコア:0)
別のツリーに杓子定規がなんとかと書いた人か、
あれ、郡司さんの採点だと9:5くらいでレビューアー有利だが。
次にコードを別の誰かが変更したときに問題が起きる可能性を下げる、という点では理に適っている。
Re: (スコア:0)
残念。別人だよーw
杓子定規は「次にコードを別の誰かが変更」する必要性や異常値入力の可能性を
正しく評価できず一律に適用しておく、てのが問題。つーかうざい。
レビューで劣化させられるのはレビュアーの質が悪いケース。
ヒープソートが理解できないのでバブルソートに描き直させられたみたいな話でそ。
Re: (スコア:0)
そして誰もいなくなった。
とはいえ (スコア:0)
「三日たてば自分も他人」というしな。。。
Re:とはいえ (スコア:2, おもしろおかしい)
つまりいつ書いたかも特定できる。
「これはyy年mm月dd日にccさんが書いたコードです」
Re:とはいえ (スコア:2)
「ccさんが書いたコード」
バイナリをレビューするのか！
Re: (スコア:0)
バイナリーを吐くのはasさんじゃないかと
Re: (スコア:0)
記憶にございません
みんな、勝手な書き方しやがって… (スコア:0)
コーディング標準が設定され、守られていればそんなことは起こらないはずだ。
簡単な推理だよ、ワトソン君 (スコア:1)
「見たまえ。
メソッド名にm000001、m000002、m000003という名前を付けてるだろう？
これはＱ社で80年台から96年まで使われていた規約なんだよ。」
「ということはこれを書いたのはＱ社のプログラマーだと？」
「いや、ここのコメントに注目したまえ。
『変数i00001に３を入れる』『変数o000002にc000001型のオブジェクトをnewする』。
このようなコメントはR社で現在も使われている規約だ。
そしてこの部分。
『追加１９７６年○月Ｘ日』『追加１９８２年○月Ｘ日』『削除１９８４年○月Ｘ日』『追加１９８５年○月Ｘ日』『追加１９９６年○月Ｘ日』
『バグ修正１９９６年○月Ｘ日』『追加２００１年○月Ｘ日』『BUG FIX ２００５年○月Ｘ日』．．．
一見すると1970年台から２０００年台になるまで使い続けられている、S社のコードのようにも見える。
しかしこれは犯人の偽装だ。というのもＳ社では２００４年に規約が変更され、その際にコード修正した
場合はバグ管理番号とＶＳＳのコミットIDとコード修正の内容をそこに記載することが義務づけられたんだ。
だからこんなに完結にコード変更履歴が書けるわけがないんだよ。」（以下省略）
＃じょ、冗談れすよ。こんな糞な規約を使ってる会社があるわけ無いじゃないですか（棒
Re: (スコア:0)
一糸乱れず全員が同じようにコードを書くのが最も良いプログラミングなのだ
Re:みんな、勝手な書き方しやがって… (スコア:5, おもしろおかしい)
一糸乱れず全員が同じようにコードを書くのが最も良いプログラミングなのだ
マネージャー「ようし、心の用意はいいか。まず「i」に右手薬指を載せろ、そして右手人差し指は「n」だ。
左手人差し指は「t」だ。「int」を1秒で打ち込むぞ。準備できたか。
・・・・そこ！mainはvoidじゃない！ ああ、お前も、includeを書くのは後からだ！
誰がemacsを使っていいといった！」
Re: (スコア:0)
> マネージャー「ようし、心の用意はいいか。まず「i」に右手薬指を載せろ
アッシは右手中指を乗せていました。
間違っていたのか。不安になってきた。
Re: (スコア:0)
プログラム終了時のfreeなんか不要と言い出す奴が出てきて暴れるに一票
Re: (スコア:0)
あまり杓子定規なのも困り者。
例えば静的解析ツールで特定のワーニングは0件にせよ、とか
単体テストで全分岐の組み合わせ必ず通せ、だの。
ツールや標準は決まりきった使い道や特定範囲の入力しかない
(今後増える見込みもない)モジュール内の特定用途の下位関数と、
他モジュールや人間とのI/F絡んでかなり異常値入力を警戒すべき
関数の意味の違いを理解してくれない。
やれelse節やswitchのdefaultがないだの引数NULLチェックしろだの
金輪際使用されない予定の死んだコードを大量にソースに投入することで
かえって見通しが悪くなったりバグ混入の機会が増えたり速度が遅くなったり
バイナリサイズが膨れ上がったり...
Re:みんな、勝手な書き方しやがって… (スコア:2, すばらしい洞察)
×杓子定規
○金科玉条
しかし、あんたが書いた内容ならレビュアーの言ってることの方が正しい。
すくなくとも、職業プログラマーが企業システムを作るなら当然のことばかりだが。
個別にいちいち指摘はしなけど、
switchにdefaultがない、と言われたら、
throw new Exception('これが出たオレはプログラマーやめる’）;
とでも書いておけ。
（すぐやめることになると思うし、とっとと辞めた方がいい）
指紋を変えてしまうのだ (スコア:0)
入手できたサンプルコードに合わせて
スタイルが変わってしまう私には「資格」もとい「死角」が無かった。
Re: (スコア:0)
変数名から足が付くケースも‥
Re: (スコア:0)
はーい僕もでーす
Re: (スコア:0)
コピペがばれないように変数名やスタイルは徹底的に修正するのが真のコピペプログラマーだ。君もまだまだだな。
Re: (スコア:0)
俺はこっちだなぁ。
いや、別に、コピペがばれないようにしてるわけじゃなくて、何でも自分のスタイルに書き直さないと落ち着かないだけだけど。
書き直しつつ、ロジックを検証したりとか最適化したりとかね。
# そして著者が俺だとバレるわけだ。
# ちなみに、コピペしたときは堂々と「ここは○○からのコピペ」とコメントに書きます（笑）。
ものまね (スコア:0)
コードスタイルものまねとか流行ったりして・・・
Re: (スコア:0)
ゆうちゃんのコードはコピペが大量に含まれてて、参照元のサイトが割り出せてるのもあったね。
Re: (スコア:0)
家で一人で書いてるコードも、割とバラバラなんだけど。
いや、1プロジェクト内は一緒だけど別のプロジェクトを見ると違ったりする。
モノマネしてるわけではなく。
木乃花二葉のように (スコア:0)
コードマスターJが書いたコードも見分けられるのだろうか？
嫌な空目をしてしまった…… (スコア:0)
code hylometry...
遠いかどうか分からないが、未来の世界では (スコア:0)
AC が誰の書き込みだったり、おもらしがなくても、2chの書き込みが誰なのか分かったりするんですね。
匿名が無意味になる世界は、果たしてユートピアなのか、それともディストピアなのか。
Re:遠いかどうか分からないが、未来の世界では (スコア:1)
なるほど、だから情報元URLを貼るだけのタレコミがあるんだな。
犯人捜し？ (スコア:0)
業務システムの古いコードは、行毎に著者が異なる場合があるが判定できるのか？
#一方SEはVCSを使った。
Re: (スコア:0)
記事を読むかぎりでは著者数を増やすほど精度が下がるようですし、
名も無き末端コーダをズバリ特定できるような代物ではないのでしょう。
Re: (スコア:0)
追加した部分を明示されるならそれなりの確率で当てるのでは。
単にベイジアンフィルターだから。
このシステムに、Linuxカーネルのソース全部を喰わせたら (スコア:0)
さて、誰が「作った」ものと判断するだろうか。
Re: (スコア:0)
色つきで部分表示するんじゃね？知らんけど。
判定すべき著者数を事前に登録しておくシステムらしいから
関わったメンテナのコードをちゃんと学習させておけば
ブロック単位で案外正確に判別されるかも。
面白いけどどのような目的だったのかな (スコア:0)
面白い着眼点で実行してみたというのはいいと思ったけれど
これ何か応用を目標として研究してみたとかなのかな
もしかしたらコードは著作物であるという考えを検証してみるとかの政治的主張だったりするのかしらん
Re:面白いけどどのような目的だったのかな (スコア:1)
研究者の意図は知らないけれど、たとえば大学の課題なんかで提出したコードや、
就職活動で自分で書いたというコードを提出してくる応募者がいた時なんかに、
提出されたコードをこのツールに食わせて、「この人が自分で書いた」という結論が出れば本物。
「特徴が異なるので別人によるもの」或いは「複数の特徴が混在していて、誰が書いたか不明」という結論が出れば偽物。
という使い方は出来るかもしれない。
＃筆跡鑑定程度の信頼性かな。
＃「ここにあるコード」と、「以前Ａさんが書いたとされるコード」の特徴が一致するかしないか。
＃いずれは偽造の専門家も生まれて、ジェバンニが一晩でやってくれるようになるかもしれないけどさ。