プログラミングの原則：構造化テキストを文字列結合で作らない、置換でいじらない - Uzabase for Engineers

こんにちは、ソーシャル経済メディア「NewsPicks」のむとうです。 先日から『Ghost of Tsushima』の開発者が書いた『ルールズ・オブ・プログラミング』という本をちょっとずつ読み進めていて、プログラミング熱が高まっています。この本は大きな指針を示すだけで具体の話をするものではないのですが、読み物として面白いので私も似たようなことをやってみたくなりました。 何年もこういう仕事をしているとバグが入るパターンというのが見えてきます。そしてだいたいどこに行っても何の仕事でも似たようなことをすることになるのですが、今回の話もその一つです。 構造化テキストを文字列結合で作らない、置換でいじらないというのはこれだけみると何のことか分かりづらいかも知れませんがSaaS Product Team セキュアコーディングの啓蒙 第2回 （SQL インジェクション編）の内容とある面では同じ話です。

[masa_edw]

書きました。自前で文字列を頑張って何かするのはそれを専門にやる場合以外はやめましょう。

[ockeghem]

同意。文字列結合しなければエスケープ処理もいらない…という趣旨のことは https://blog.tokumaru.org/2021/12/php.html で書いた

[hinaloe]

location.href+='&hogefuga'すると実は#がもとのURLに入ってたときに死ぬみたいな話か(ｳｯ

[sin20xx]

id:xlc 具体的にどうすべきか書かれていると思うけども？言語別に個別の記述方法の議論であればそれは無限にあるわけで。書かれている解決策を読めば、個々の言語で対応可能。それがわからないなら入門書から読むべき

[nakag0711]

プログラムをちゃんと書けば書くほど文字列型というものの使用頻度は減っていく

[Phenomenon]

わかるーと思いつつURLとか手軽なので文字列結合やりがちだわ

[s_hiiragi]

ファイルパスも文字列結合でミスが起きることある

[xlc]

ヘタクソを指導したいなら「これはダメ」ではなく「こうやりなさい」と具体的に言わない限り上手くいかないと思うけどな。

[manaten]

加えて、構造化テキストを用意された安全なライブラリで扱えるよう、なるべく自前の文字列表現を爆誕させずにJSONなどの汎用の構造化テキストに仕様を落とし込みましょう、というのもありそう

[mmuuishikawa]

JSON文字列をカンマで分割してn番目の文字列を取得する糞コードを作り逃げした糞PG。おかげである日突然動かなくなったシステムがあったな

[glass-_-onion]

フロントエンドの経験が浅いからかURLの組み立てを文字列結合でやっちゃうことが多い。この記事読んだ後いくつかのプログラムを急いで直したw

[tmatsuu]

せやな

[a-kuma3]

現場では、いまだに日時のようなインスタンスを文字列で持ち運んでいるコードは割りと見るレベル。こないだ見たのは CDATAセクションの先頭が実体参照になってるやつ。DOM使えよ、ですら、正しく通じてない

[matarillo]

「普通そうする」と言いたくなるかもしれないけど、シェルスクリプティングってこれの塊になりがちで。

[shingo-sasaki-0529]

URLとかXMLとか主要なものについては枯れたライブラリを使いましょうで済むけど、ドメイン固有の、文字列だけど構造のあるものについては自らデータ構造を作ってそこを経由するって設計が大事そう。

[shinji]

理解した。でもワレワレのゲンバのコードレビューとかで気づけるかどうか。SQLはみんなわかっているけど、それ以外でこの意味を理解できているのはいるのだろうか。

[tekimen]

そうですね、処理系から文字列処理を実装してる身としては身が引き締まる思いであります。

[a235]

SQLとかHTMLとかにはちゃんとそういう仕組みがあるんだけど正規表現にはそういうのがなくてだいぶつらい。誰か発明してほしい。

[n_231]

まぁ、専用ライブラリを使いましょう→外部ライブラリの利用には承認が必要です。セキュリティ上のリスクを挙げた上で開発責任者から〜　みたいなのもよくある

[at_yasu]

ちゃんとパースして構造データにしてやるのがいいよねー（）

[natu3kan]

文字列の操作雑にすると生きた制御文字とかコードが混ざったりしたりしがちだよね。

[yarumato]

“ではどうするか。大きく２つ。1. テンプレートに安全に値を埋め込む　2. 対応するデータ構造を作り、データを加工し、再度文字列化する（jsならURL.append()、JSONならいったんobjにしてから再度serialize）”

[tattyu]

文字列結合で作らないとか最初何言ってるのか分からなかったけど、値を変えるなら一旦構造化（プログラムで扱える形）してやれって事ね。というか普通そうしない？。

[troter]

何度も文字列結合でURL作ってその度にバグって痛い目見て覚えていったなー

[yudukikun5120]

当たり前

[onesplat]

言いたいことはわかるんだけどまぁやりたくなることもあるよね

[rAdio]

UNIX Shellを常用し、ほとんどそこに定住している身からすると、それくらいの切り替えが必要なんだな、と思わされた。ついつい何かの開発をやるときにもスクリプティングによる環境設定のつもりでやらかしがち。

[srng]

string不変系言語は弄る度にヒープに新しくオブジェクト作るからやりたくない、という話ではなかった

[cl-gaku]

それな

[doko]

与えられたSQL文を実行するのではなく、文字列として処理して必要な値を取り出して、別途SQL文を文字列生成して実行している現場はみたことある

[kkobayashi]

言いたいことはわかる。面倒臭がってJSONをそのまま文字列置換で処理したりね

[mag4n]

だいじ

[hiroshe]

ちゃんと融通の利くクラスがあればそれ使うけどね。秀丸でHTML書いてFTPでアップしていた世代としてはついやってしまうよね。

[aike]

この原則を知っていることは大事で、初手はアクセスAPIを調べること。ただ原則が適用できない場合も多くそのときはリスクを理解した上で結合する。遠因はアクセス仕様が言語を超えてシンプルに標準化されていないこと

[dlive1]

『Ghost of Tsushima』の開発者が書いた『ルールズ・オブ・プログラミング』という本

[ppppchan]

Unix shellは使うなということか🤔

[otchy210]

ぐ、挙げられてる例のうち、正規表現だけはやる事があるな。

[masaru_al]

URLもその正式な仕様を知ると、とても文字列処理でお手軽にいじれる代物じゃないことがよく解る／この原則をわきまえているかどうかが初級中級の境目かな

[altar]

「ある変数が不正な状態を取れてしまうならカプセル化して正常な状態空間しか取れないようにしろ」に近い話だと思うけど、悪い例が「文字列結合」なせいでそこに引きずられてる人がちらほらいるような。