Scribble at 2025-06-18 08:17:36 Last modified: 2025-06-18 08:28:17

添付画像

Linuxのソースコード内に「fuck」「クソ」「まぬけ」などの暴言がどれだけ含まれているかをグラフ化、2018年を境に「fuck」の出現頻度が激減

この記事そのものは下らない。グラフを見れば一目瞭然だが、たかだか40個の頻度が20個に減ったくらいで「激減」などと言ってる NHK 並の人間に統計を語る資格はない。なので、僕の話をしよう。

ご存知の方もおられると思うが、かつてソース・コードのエンコーディングをテキスト・エディタに自動で検出させるための「美乳コード」なるものが出回っていた時期があった。いまでは多くのプログラミング言語が i18n の推進などもあってディフォールトでユニコードのエンコーディングを想定するようになっているので(ASCII だったとしても、ASCII で扱われていた文字は全てユニコードでは1バイトで表現される区画に含まれているサブ・セットであるため、ASCII でエンコーディングされているテキスト・ファイルをユニコードとして扱っても支障はない)、もう使われていない。というか、コーディング規約としてエンコーディングを揃えることなど、いまや富士通の5次請けとしてコードを書いているクラウド・ワーカーでも知っていることだ。既にエンコーディングの話は10年以上も前に過去のものとなっている。なので、僕もかつては PHP や JavaScript のコードで冒頭にエンコーディング判定用の文字列を挿入していた頃があって、もちろんクライアント側のエンジニアが納品検査なり検収工程としてソース・コードを眺める可能性があるから、「美乳」(つまり「美」と「乳」という漢字でユニコードのエンコーディングであるかどうかをテキスト・エディタのパーサが判定できたと言われていた)なんて文言は、事情を知らない人だと不審に思うだろうから書けないので、

「時々京の方向に幅が細くて美しい線が入った飾りを持つ雀が往く」

「男は傷の拳で美しく印刷された一冊の書を持ち憎い相手の笑いに応じた」

といった、エンコーディングの判定に使えると言われている漢字を散りばめたオリジナルのフレーズを使っていたわけである(これでも不審に思う人はいるかもしれないが、ちゃんとエンコーディングの判定用の文字列であることは一緒に明記している)。ちなみに、これらの文字列は GitHub で公開しているが、GitHub で公開するようになったのは使い始めてから何年も経過した後のことなので、もっと古い時期のコードにも同じような(たぶん多くの人には意味不明というか趣旨のわからない)文字列が見つかるだろうと思う。あと、いつか書いたと思うが、納品した後に僕のコードをコピペして使うエンジニアがたくさんいて、特に入力値の validation, sanitization を定義するクラスはよくコピペされたらしく(というかクラス・ファイルのまま転用する事例すらあった。弊社の社名と僕の名前も記述してあるから、僕が関わっていると勘違いした電通あるいは博報堂から「なんでこの案件に加わってるの?」と問われることすらあった。もちろん著作権や知財の対象としては考えていないが、上場企業や大企業の案件でも、それなりに杜撰なことをしている)、皮肉なことにそういうコピペが理由で僕や弊社の名前を知っている方もおられるだろう。まぁ、そんな事情で知ってるようなカスどもに有名となったところで、俺には何の徳もやり甲斐もないがね。

といったわけで、もちろん僕が書いているコードに "fuck" だの「クソ」だのと、ここでふだんから書いているような罵詈雑言は書かれていない。僕は、自慢ではないが仕事で書いたコードにクレームや皮肉などの否定的なコメントをタイプしたことは一度もない。僕は偽善者だし、いちど決めた方針は改善や修正の余地がない限りは冷徹に従う人間なので、僕のコードには例外なく罵詈雑言は書かれていない。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る