命名的問題 vs 構造的問題

技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編）

技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（後編）

記事の内容は「メソッドの名前がおかしいが実装わかりやすいコード」と「メソッドの名前は問題ないが実装がややこしいコード」の2つを50人ほどのJavaプログラマーに解読してもらい、メソッド名と実装のどちらを先に修正すべきかというものです。

統計結果を見る前に思ったのは、メソッド名を先に直すべきではないかということ。理由は記事中にある

構造的問題は局所的に起こるが、命名的問題はコードのどこにでも出てくるものがあるため

「命名的問題」があるとコードが信じられなくなる

などです。そして上記記事でも「命名が不適切なコードの方が読解精度が低い」という結果が出ました。

また実際の開発現場でも、命名が不適切なコードの方が読解精度が低い」という結果ですが、コードリーティングの際に実装がややこしい場合は「何だこれ？」と思って注意して読み進めるのに対し、命名が不適切な場合はメソッドの役割を勘違いしたまま開発を進めてしまう可能性があるので命名的問題のほうが深刻だと考えています。

プログラミング言語の省略表記について

 ちょっと前にPythonを滅ぼそうやない会とかいう記事が投稿され、それに対するアンサー記事も投稿されるなどまあまあ賛否両論だった記憶があります。

個人的にはシンタックス云々に一部同意する部分もありつつ、でも英語の語順的にまあそうだろうなーというアンサー記事に同意する部分もありつつ、でも英語話者以外が使うことも考えてくれよなーと思いつつというどっちつかずの状態です。

個人的ついでに書くと、三項演算子やラムダ式などの省略記法は基本的に書きません。リストの内包表記も使いません。理由はあとで自分がすんなり読める自信がないから。

「そんなもんも読めないお前のスキルが低いだけ」と言われたら返す言葉もないんですが、とはいえ大抵のプログラマーは数ヶ月前、いや数週間前に書いた自分のコードが理解できないという状況を経験しているはずで、なるべく平凡な書き方のほうが大抵の人が理解しやすいでしょう。

Pythonに限らず、他の言語でもあまり省略記法やシンタックスシュガーは使わない傾向ですね。例えばJavaScriptのオプショナルチェーンとかも使いません。

JavaScriptといえば、個人的には互換性を数十年引きずっているあの言語仕様はなんとかならんもんかと思ってます。とはいえ上澄みをすくおうと頑張っているAltJSが生まれては消え、スーパーセットを謳っているTypeScriptが事実上のデファクトスタンダードという現状を見ると、これが市場の意思なんだと納得するしかないですね。JSConfの運営ボランティアにも入っていながらこんなこと言うのもアレなんですが。

結局何を言いたいのかよくわからん記事になってしまいましたが、要するに自分は平凡なソースコードを書いてるよという極めて平凡な内容しか書いてないですね。

Software Design 2023年9月号が発売されました

 先日、「Software Design 2023年9月号に寄稿したよ！」という記事を書きましたが、その9月号が予定通り8月18日に発売されました。

寄稿部分がこれ。

うん、Twitterってなってるね。

確か、ちょうど校正あたりの時期にTwitterのサービス名が𝕏に変わるとかどうとかの騒ぎがあったんですが、校正＆コロナでてんてこ舞いになっていて、ここの修正まで頭が回りませんでした。別に致命的なミスではないので許してください。

sedで簡易URLエンコード

需要がどれだけあるかわかりませんが、使えたら使ってください。POSIX sedでもGNU sedでも動作します。

sed -r \
	-e 's/%/%25/g' \
	-e 's/\$/%24/g' -e 's/\(/%28/g' -e 's/\)/%29/g' -e 's/\*/%2A/g' -e 's/\+/%2B/g' -e 's/\//%2F/g' -e 's/\?/%3F/g' -e 's/\[/%5B/g' -e 's/\]/%5D/g' \
	-e 's/!/%21/g' -e 's/#/%23/g' -e 's/&/%26/g' -e "s/'/%27/g" -e 's/,/%2C/g' -e 's/:/%3A/g' -e 's/;/%3B/g' -e 's/=/%3D/g' -e 's/@/%40/g' \
	-e 's/ /+/g'

関数化すれば、シェルスクリプト内でパイプ的に使えるのでまあまあ便利かも？

function urlencode() {
	sed -r \
		-e 's/%/%25/g' \
		-e 's/\$/%24/g' -e 's/\(/%28/g' -e 's/\)/%29/g' -e 's/\*/%2A/g' -e 's/\+/%2B/g' -e 's/\//%2F/g' -e 's/\?/%3F/g' -e 's/\[/%5B/g' -e 's/\]/%5D/g' \
		-e 's/!/%21/g' -e 's/#/%23/g' -e 's/&/%26/g' -e "s/'/%27/g" -e 's/,/%2C/g' -e 's/:/%3A/g' -e 's/;/%3B/g' -e 's/=/%3D/g' -e 's/@/%40/g' \
		-e 's/ /+/g'
}
echo "a*a + b*b != c*c" | urlencode

制御文字やASCII範囲外の文字には対応していないので限定的にしか使えませんが、場合によってはまあ使えるんじゃないかと思います。

ちゃんとしたものが必要なら、JavaScriptなりPHPなり専用の関数を備えた言語で書くのが確実です。

POSIX sedとGNU sedの両方で動かすテクニック4種盛り

POSIX sed（macOS標準）とGNU sed（Linux標準）とで微妙に書き方が違うので、どちらでも動くようにシェルスクリプト等を書きたい場合の注意事項をちょっとまとめてみました。

縛りプレイとして、sedコマンドだけで対応するものとします。つまり、パイプやリダイレクト、他のコマンドとの併用などは行わないものとします。

以下の内容は、macOS（POSIX sed）とLinux（GNU sed）の両方で動くことを確認済みですが、どちらも割と新しいバージョンで確認したので古いバージョンでは使えない可能性もあります。ご注意ください。

文字列にはシングルクォートを使うべきかダブルクォートを使うべきか

文字列はシングルクォートとダブルクォートのどちらで囲うべきか、ときどきコーディングスタイル論争に上がりますね。もちろん、JavaScriptとかPythonのようにどっちを使っても文法上問題ない言語に限ります。CやJavaでは必ずダブルクォートを使わなければいけません。

今回のテーマは、そんな今更感あふれる話題です。

GitHub Actionsでシェルスクリプトからrsync over SSHしたい

背景はこうです。

• GitHub上でウェブアプリケーションを開発している
• GitHub ActionsでCI/CDを設定している
• 何らかのトリガー（リリースタグの作成等）で、開発環境や本番環境にデプロイしたい
• デプロイ用シェルスクリプトを自前で用意している
• シェルスクリプト内でSCPやrsync over SSHなどを実行している

このとき、SSH鍵がGitHub Actions側にないとデプロイができないよね、という話。

粛清しないソート

少し前、ソート業界ではスターリンソートというO(n)のソートではない何かが話題になっていたようです。

繰り返しますが、これはソートではない何かです。

というわけで、O(n)のちゃんとしたソートについて、アルゴリズムの概要と実装例をまとめてみました。

いろいろな制限（主に値の範囲）があるので汎用的なものではありませんが、定義域が特定の値に絞られているという状況はかなりあるので、場合によっては役立つものです。

多項式の計算アルゴリズム

数学的なプログラムを作っていると、多項式の計算が必要なことがありますよね？

どうやって実装しますか？

あ、ちなみにこれ割と有名なやつなんで、アルゴリズムが好きな人なら大抵知ってるネタです。

範囲が重なっているかどうかの判定法

直線上に2つの範囲AとBがあったとき、この2つが少しでも重なっているかどうかを調べたいときってありますよね。ありますよね？

例えば、1:00-2:00のような時間帯の情報があるとして、2つの時間帯AとBが重なっているかどうかを調べたい場合。
Aが1:00-2:00、Bが1:30-2:30だったら重なっている、Bが2:10-2:40なら重なっていない…といった具合です。

重なっている例
       01:00    01:30    02:00    02:30
         |        |        |        |
A        <----------------->        |
B        |        <----------------->

重なっていない例
       01:00    01:30    02:00    02:30
         |        |        |        |
A        <----------------->        |
B        |        |        |  <------->

この「重なっているか否か」を判断する方法について解説します。

これからドヤ顔で解説しますが、別に本邦初公開でも何でもありません。
「そんなもん知っとるわボケ」と思っても優しく見守ってください。

Web APIのパラメーターはキャメルケース？スネークケース？

…という話を先日社内でしました。

https://example.com/api/search?user_id=1
https://example.com/api/search?userId=1

↑どっちを使う？という話です。

個人的には、GET/PUT/POST含めて統一さえされていればどっちでもいいんですが、それで終わってはつまらないのでちょっと語ってみます。

もう一度いいますが、個人的にはぶっちゃけどっちでもいいです。

タブ＋オールマンのすすめ

今回はコーディングスタイルの話です。

意外と反響が＆新章追加

先日Qiitaに公開した「読みやすいコードを書くために」が意外と好評だったようで、約2週間で500(・∀・)ｲｲﾈ!!を突破しました👏🎉

読みやすいコードを書くために

…という記事をQiitaに投稿しました。

読みやすいコードを書くために