根がミニマルなもので開発に際して必要のないツールは極力排してやってきました。とはいえ新しいプロジェクトを本格始動するにあたって一度見直してみてもいいかもしれないと思い、Prettier というコードフォーマッターを先日試してみたんです。 Prettier は自らを “An opinionated code formatter” と称していて、ここでの “opinionated” とは「一家言ある」ぐらいの意味かと思いますが、意図して融通が利かないといえば伝わるでしょうか。あるいは、信念に基づいて柔軟性を排除している。 まだわかりにくいですかね。たとえば僕は視認性至上主義者なので括弧の内側に必ずスペースを置くんですが: Prettier を通すと下のようになります: 最初これを見たとき正直「うわっ」って思いました。詰め過ぎ。美しくない。で、こういうのはオプションで変更できるに違いないと思ってドキュメントを確認したんですが、そういうものはなく、その日は結局、Prettier はどうも自分には合わなそうだからやめておこう、と一応の結論を出して寝ました。 翌日になっても何かどこか引っ掛かっているような感じがしました。視認性が悪いだの美しくないだのぐずぐずあげつらったけれど、そんなのは自分の主観に過ぎないし、どうせ他の開発者と意見が合うことなんて一生ない。普遍的に美しくて正しいコードの書き方を追求して合意形成することに意味はあるのか? 考えてみたら実にくだらないことに頭を使っている。 これこそが Prettier が終わらせたかった「自転車置き場の議論」なのでは? そんなこんなで俄然好きになり、今後新しいプロジェクトで WordPress に関係しないものには Prettier を採用することに決めました。 で、ここからが本題なんですが、Prettier は “opinionated” なので利用できるオプションが限られており、今後増えることも原則ありません。なんか、こういうのいいな、って思ったんですよ。 Contact Form 7 なんか見てもらったらわかると思うんですが、僕が作るプロダクトのモットーは「シンプル」「柔軟性」「拡張性」です。シンプルはそのままでいいと思うんですが柔軟性とか拡張性ってそんなに無条件に評価してよい善ではないような気がしています。 例を挙げると、Contact Form 7 ではフォームのテンプレートを自由に編集できるんですが、これは裏返せば、間違ったフォームでも自由に作ることができる、ということでもあります。フォームのフィールドに適切なラベルを (<label> 要素で) 付けないで、プレースホルダーをラベルの代用として設定する、みたいな典型的な間違いも可能にしてしまいます。 それが Contact Form 7 の良いところだ、と好意的に評価してくれるユーザーが多くいるのは承知していますが、果たして本当に良いことでしょうか。なんか違うんじゃないの? という気がするんですよ。 後方互換性も大事にしたいんで今さら Contact Form 7 の仕様を大幅に変えようとは考えていませんが、今後開発するプロダクトに関しては “opinionated” で行くかもしれません。つまり柔軟性拡張性を意図して捨てる。 ソフトウェア製品を扱うのが人間であることが前提だった時代では個々人の好みに合わせて自由にカスタマイズできることが美点になりますが、そこに […]
根がミニマルなもので開発に際して必要のないツールは極力排してやってきました。とはいえ新しいプロジェクトを本格始動するにあたって一度見直してみてもいいかもしれないと思い、Prettier というコードフォーマッターを先日試してみたんです。
Prettier は自らを “An opinionated code formatter” と称していて、ここでの “opinionated” とは「一家言ある」ぐらいの意味かと思いますが、意図して融通が利かないといえば伝わるでしょうか。あるいは、信念に基づいて柔軟性を排除している。
まだわかりにくいですかね。たとえば僕は視認性至上主義者なので括弧の内側に必ずスペースを置くんですが:
Prettier を通すと下のようになります:
最初これを見たとき正直「うわっ」って思いました。詰め過ぎ。美しくない。で、こういうのはオプションで変更できるに違いないと思ってドキュメントを確認したんですが、そういうものはなく、その日は結局、Prettier はどうも自分には合わなそうだからやめておこう、と一応の結論を出して寝ました。
翌日になっても何かどこか引っ掛かっているような感じがしました。視認性が悪いだの美しくないだのぐずぐずあげつらったけれど、そんなのは自分の主観に過ぎないし、どうせ他の開発者と意見が合うことなんて一生ない。普遍的に美しくて正しいコードの書き方を追求して合意形成することに意味はあるのか? 考えてみたら実にくだらないことに頭を使っている。
これこそが Prettier が終わらせたかった「自転車置き場の議論」なのでは?
そんなこんなで俄然好きになり、今後新しいプロジェクトで WordPress に関係しないものには Prettier を採用することに決めました。
で、ここからが本題なんですが、Prettier は “opinionated” なので利用できるオプションが限られており、今後増えることも原則ありません。なんか、こういうのいいな、って思ったんですよ。
Contact Form 7 なんか見てもらったらわかると思うんですが、僕が作るプロダクトのモットーは「シンプル」「柔軟性」「拡張性」です。シンプルはそのままでいいと思うんですが柔軟性とか拡張性ってそんなに無条件に評価してよい善ではないような気がしています。
例を挙げると、Contact Form 7 ではフォームのテンプレートを自由に編集できるんですが、これは裏返せば、間違ったフォームでも自由に作ることができる、ということでもあります。フォームのフィールドに適切なラベルを (<label> 要素で) 付けないで、プレースホルダーをラベルの代用として設定する、みたいな典型的な間違いも可能にしてしまいます。
それが Contact Form 7 の良いところだ、と好意的に評価してくれるユーザーが多くいるのは承知していますが、果たして本当に良いことでしょうか。なんか違うんじゃないの? という気がするんですよ。
後方互換性も大事にしたいんで今さら Contact Form 7 の仕様を大幅に変えようとは考えていませんが、今後開発するプロダクトに関しては “opinionated” で行くかもしれません。つまり柔軟性拡張性を意図して捨てる。
ソフトウェア製品を扱うのが人間であることが前提だった時代では個々人の好みに合わせて自由にカスタマイズできることが美点になりますが、そこに AI が関与する時代では事情が違ってくるんじゃないか、という理由もあります。AI がおかしな動きをしてもリスクが限定的になるように、そもそもカスタマイズの自由が最小化されているほうが今後は好ましいと評価されるようになるのかもしれません。
「融通が利かない」が褒め言葉になる時代が来ます。たぶん。🫠
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | Жертвы чистого кода | 0 | 7 | 10-07-2026 |
| 2 | Жертвы чистого кода | 0 | 7 | 10-07-2026 |
| 3 | オープンソースコントリビューション尊重宣言 | 0 | 5.8 | 18-07-2026 |
| 4 | HTML バリデーションの不整合 | 0 | 11.3 | 24-05-2026 |
| 5 | WordPress as the text of the web | 0 | 4.62 | 13-08-2026 |
| 6 | バリデーションロジックの考え方 | 0 | 9.81 | 17-05-2026 |
| 7 | Vibe-Coding für Anforderungen – geht das? Wie Prototypen das Refinement retten, bevor es peinlich wird | 0 | 8.6 | 21-07-2026 |
| 8 | 文字列を数える | 0 | 10.41 | 07-06-2026 |
| 9 | KI schreibt keinen guten Code – oder doch? | 0 | 6.87 | 04-07-2026 |
| 10 | Alles ist relativ – vor allem in der Softwareentwicklung | 0 | 5 | 30-06-2026 |