「引数」を含む日記

はてなキーワード: 引数とは

2020-12-01

■anond:20201201171157

（追記）

まず簡単なのはここに書いてある。

ttps://agk.saloon.jp/how-to-jp-series

結論をいうと対象のソフトが下記を満たすかどうかで難易度がかなり変わる。

1. 表示テキストが外部ファイルになっている or exe内部のリソースファイルから読み取られる ↔ プログラム埋め込み

2. 内部のテキストエンコード方式がUTF-8 or 16 or 32 ↔ ASCIIなど

3. フォントはシステムにあるのが使われる ↔ 外部ファイルになった画像フォントが使われる

すべてのソースが公開されていない限り、この条件を満たさないものは基本的に日本語にできない。

例えば、自分でC言語でprintfだけのHello world!プログラムを作ってみて、それをソース無しで、外からテキストを変更できるかためしてみればいい。

これは１に反するから多分簡単には出来ない。よしんば出来たとしても、Hello world!より文字数が多いテキストに変えるのはそれなりに面倒である。

こういう表示をさせるやり方としてはprintfに渡すデータを実行時にすげ替えればいい。具体的にはprintfの直前で別の箇所にジャンプさせて引数のレジスタに書き換えたいアドレスを渡して、またprintfまで戻ってくればいい。

これ以上に面倒なのが、2と3が合わさったもので、欧米はアルファベットしか使わないため、ソフトの内部コードがASCIIやCP12XXだったりする。さらにそのソフトに用意されているフォントの文字はその範囲しか存在しない。これらはどう頑張っても普通には日本語を表示することは出来ないので、かなり強引に改造するしか無い。俗に中華パッチと呼ばれているものがそれである。

具体的にはソフトのどこかで、表示させるテキスト配列から文字を１文字取得、１文字からコードポイントに変換、フォントファイルからそのコードポイントのグリフデータを取得、グリフデータを画面に表示させる処理があるため、そこに割り込む。１バイト取得している箇所を２，３バイト一気に取得して、それをなんとかしてコードポイントにして、そのコードポイントをグリフ取得の処理に回せばいい。

この方法にしても、技術的に難しい点は存在せず、技巧的であり、Cの本を読めば誰でもできる処理である。

Permalink | 記事への反応(2) | 20:03

2020-11-16

■anond:20201116050134

虎の威を借る狐のごとく他人に言われたことを鵜呑みにして自分の頭で解釈しようとしない愚図の三下には答えられるはずもないので、私が代わりに応えよう。

だったら「返り値と引数チェックにしか型チェックを使ってないC言語は問題は起きないはずたが現実はどうよ？」「Ruby と Python は動的言語だけど、強力な型付けのされた言語とは言えないのか？」という疑問に答えられるはず。

ひとつ前の人が言っていたのは、型チェックとテストの仕事のバランスの取り方だ。

型チェックの仕事をテストが奪うな、ということ。

でももっと悪い事態として、仕事を放棄する場合もあり得る。C言語の例はそれに当たる。

C言語の弱い型の中で提言に則りベストを尽くしても型チェックにできる仕事は少ない。

だからテストコードを書かざるを得ないが、テストコードを書くことをサボってしまえば問題は起きる。それが現実に起こっている。

Ruby と Python は強い型付けの言語だ。だが型システムは十分に整理されていない、と思う。

テストコードが膨れ上がるのがその証拠だろう。

実質的に、型システムは言語側にビルトインされたテストコードだ。末端ユーザーが書いていたテストをリファクタリングして共通化し、上流に巻き上げてコンパイラに組み込んだのが型システムと言える。

貧弱な型システムの元では末端ユーザーが個々に努力して不足を補う必要があって、言語のユーザー全体のコード総量は大きくなる。洗練された型システムを使うユーザーはテストコードを保守する責任を持たないので末端ユーザー間のコードの冗長性は少なくなり、ラクになる。アプリケーションのバージョン毎に特殊化されたテストコードは少なければ少ないほうがよい。品質が保たれる限り、なくしていくべき。

Permalink | 記事への反応(1) | 18:12

■anond:20201116044801

おっ、売られた喧嘩は買ってやる。だったら「返り値と引数チェックにしか型チェックを使ってないC言語は問題は起きないはずたが現実はどうよ？」「Ruby と Python は動的言語だけど、強力な型付けのされた言語とは言えないのか？」という疑問に答えられるはず。

Permalink | 記事への反応(1) | 05:01

2020-11-15

■anond:20201115125745

こういうことを教条主義的に言う奴はみんな型をちゃんと使ってないし、t_wadaはRubyを手放さないでTDDをやれと言い続けるし、果てにはテストコードがドキュメントだとか言い始める奴も出てくるから本当に厄介

型システムで保証出来ない事前条件事後条件を引数チェック、表明を使って行うことは正しいし、テストコードを書くことも正しいが、

型システムで保証できるものを引数チェック、表明、テストコードで保証するのは、コンピュータに出来ることをプログラマがやっていることになり、これは害しかない。

また、コードの品質に大きく関わるのは設計能力でありテストコードとプロダクトコードとを書く順序ではないし（全く関わらないとは言わない）、

プログラマの意図はテストコードとは独立に自然言語でドキュメントに書かれているべきだもちろん適切にコメントを使う必要もある

Permalink | 記事への反応(1) | 17:24

■もうじき40代なかばを迎えるプログラマーの遺言（少し追記）(もうちょっと 追記）(さらにもうちょっと 追記)

世の中にはプログラマー35歳定年説というものがあった。昔からそんなのはないという人と、あるという人がいた。40代も半ばになったときに「あぁ、これが35再定年説の根拠か」というものがなんかちらほら見えるようになってきたので書いてみようと思った。

世の中にはものすごいプログラマーというのはやっぱりいる。なんなら死ぬまでプログラミング書いていられるという人たちもいる（ブラック的な意味ではなく）。そんな彼らからしたらプログラマー35再定年説とか意味がわからない都市伝説にしか映らないだろう。

だが、普通に職業プログラマとして生きている俺のような人からすると、この35歳定年説はかなりの真実味を帯びている。

だが、そんな俺でも40代半ばまで延命できたのはやはり技術革新のおかげかもしれないが、結局平均寿命が伸びただけとも言えるだろう。

まず、技術に対する姿勢が変わる。正直言うとプログラミングとかもうしたくなくなる。というか、そもそも一生プログラミングを仕事にしたいと思う最初の頃は好きだと思っていたが、仕事にしてしばらく経ったら大して好きでもなかったな、と思うようになる。

大して好きでもないことを仕事にし続ける体力はやはり年とともになくなり、体力がなくなった分「自分が本質的にしたいと思うこと」が見えてくる。そしてそれはプログラミングではないため、ギャップがきつくなっていく。

おそらく、この辺が35歳くらいのあたりに来るのではないだろうか。35歳定年説と言ったら35歳ピッタリしか想像できないのが離散数学の世界で生きているプログラマらしいといえばらしいが。

そんな感じでやってても、20年もやればそれなりにスキルも身につく。さすがにGoogleの一線で働くような大天才たちと渡り合うことはできないが、もしかしたらGoogleの片隅で働ける程度のスキルはあるかもしれないが、正直もういいっす、っていう気持ちのほうが大きくなる。

次に、自分がどうにか身につけてきた知見というものがなかなか広まらない。コンセンサスが取れない、という状況にも苦しくなってくる。

自分がやってきたプロジェクトでこういうことをやったらうまく働いた、というような知見は共有するが、なかなか価値観が共有できないことに気がつく。若いうちは「だったら俺が全部やりますわ」くらいの気合を見せられたものだが、年を取ってくると「あ、そうですか・・・」となってしまう。純粋に体力も気力もなくなっていく。

プログラミングをやっているだけありみんな論理的な思考が大変上手だ。「皆さんホント論理的でいはりますなぁ」と言いたくなるわけだが、悲しいことに自分たちの振りかざす論理が、単なる正論、飛躍、極論、屁理屈、と言ったものであることに気づけない人も結構多い。こういうのを各個撃破するのも疲れる。

これからプログラミングを仕事にする人たちに言っておきたいことがある。もしこの世界で長く働きたい、定年までコード書いていたい、と思うなら、常に勉強をしなくてはならない。もしあなたがFラン出ているなら、他の人の倍努力しなくてはならない。できないならそこそこで転職したほうがいい。この世界にいるといかに若いうちの勉強が大事だったかを日々痛感する。

実務の上での俺の感じていることを書く。DDDだとかクリーンアーキテクチャだとかも大事だがもっとそれ以前に俺が根源的に重要だと考えているポイントだ。この辺をないがしろにしたらDDDもクリーンアーキテクチャも絶対に崩壊する。

コードを書くときに重要なポイント

まず、心得てほしいのはどんなにすごいプログラマでも意図の通じないコードは本当の意味で直せないということだ。

まず、引数チェック、状態チェックは必ずやれ。コードが語る、というようなことを言ってやらないやつが昔は多かったが、今もいるんだろうか。悲惨なバグやメンテナンス性の低下はそういった自分の意図の表明を横着したコードから起こり始める。「俺はこれをやる、だからこの機能を呼び出すならこういう状態にした上でこういう情報を渡せ、じゃないならやらない」とはっきり言え。もしこの辺を冗長だと考える同僚がいるならもう辞めたほうがいい。

引数チェックや状態チェックのコードで画面の半分が埋まったならそのコードは設計がおかしい。一旦手を止めてよく考えろ。一つの機能を動かすのにそんなに引数がいるのか、そんなにチェックする状態が多いのか、そしてそれらは本当に必要か検討しろ。

テストコードは絶対に書け。テストコードが書けない技術は絶対に使うな。意味のあるテストが書けないならやめたほうがいいという輩もいるが、とにかく意味があろうとなかろうと書け。引数にこれを入れたらこうなる、こういう状態でこういう事したらこうなる、というお前の意図はとにかく示せるだけ示せ。

だいたいこの辺を横着したやつは翌年酷く後悔するか、そこのメンテを担当した同僚を攻撃している。

就職活動するときに重要なポイント

コードが書けなくても大丈夫、という会社は、コードが書けたほうが有利な会社ではなく、本当にコードを書かない会社だというこは肝に銘じておけ。身につくスキルはEXCELの方眼紙を最低限の手数で作れるようになることか、本気でやればビジネスを理解できるかもしれないが、お前の技術者としてのキャリアはそこで止まる。

仮に憧れのスーパーハッカーがいる会社を目指しているとして、彼らがそこでどう働いているか、なにが泥臭いのかを想像できない、聞くことができないならやめておけ。浮かれ過ぎだ。

仮にGithubのURLを教えろという会社を目指しているとして、そこのリポジトリを飾り立てようと考えたならやめておけ、そういう会社はGithubにアウトプットすることを日常的な趣味として苦ではなくやり続けられる人を求めている。

年収をその会社の選択基準にしているならそこはおまえには分不相応な会社だからやめておけ。仮に入れたとしても馴染めることはまず無い。これは年収が低くても同じだ。

人間関係の重要なポイント

嫌いな人がいるならその会社はやめていい

少しだけ追記

コメントを観てこの「最小且つ単一の論理でなにか否定できた気になる」という輩への対処が一番疲れる

もうちょっと 追記

一晩立ってみたらこんなにブクマついててびっくりした。気になったブコメもあったのでちょっと追記しておく。

いきなり視点がミクロに、と言うやつなんだが、結局若いうちにこういうのできてないやつはあとで苦労するが、最初のうちは体力でカバーできている。体力でカバーできなくなったときに本当の意味でつけを払う羽目になるという意味で言ったり、あとオレみたいなおっさんが大変つらい思いをする、という意味でも言っている。

Fラン関係なくねっていうやつだが、昭和世代のステレオタイプかもしれない、ごめん。勉強する習慣もなければ大してやってきてもいないやつはこの業界だと倍苦労する羽目になるというふうに言いたかったと思う。どんな業界でもそうだとは思うが。

返す刀で結論づけしたがる人々がやっぱり現れるな、君たちはそう思わない人なんだろうし議論する気もないが何かしら言いたい人なんだろう。別にそれはそれでいいよ。お仕事頑張ってね。

「俺は大して辛くないけどなー」っていう人もやっぱり現れるな。辛くないんだったらいいことだと思う、お仕事頑張ってね。

4K モニターでものすごく細かい文字を読んでいる若者を見た、という人、俺も同意する。もう見ていられないんだよね。

関白宣言っぽいな、というのは俺も思った。

結局の所、プログラマ35歳定年説は俺も打ち破りたいと思っていた口なんだが、打ち破れる人とそうでない人がいる、ということで、俺は後者だった、ということだ。当然50過ぎてもプログラマやっている人は見かけるので、数学的な真理というわけではなく、統計的な傾向なんだろうと思っている。

若いうちから、いい環境で働かないと、気持ちのほうがどこかで先にギブアップする。いくら大好きで転職だと思う仕事だとしても、体力や若さで捻じ曲げていることはなかなか気づかない。色んな本を読んで客観的な指標で判断したほうがいい。

遺言とか言って書いておいて追記したら俺はソンビか亡霊なんだろうか？

さらにもうちょっと 追記

びっくりした。こんなおっさんの愚痴みたいなエントリーがこんなにブクマされるとは思ってなかった。いくつか気になったブコメがあったのでやはり書いてみたくなったので書く。

まず、この遺言を最後にいなくなるのかという話だが、おそらくいなくなる。ゾンビで居続ける体力ももはやない。

次の準備はすでにしている。それは俺が本質的にやりたかったことに近いことだと思うのをピックアップしている。

本質的にやりたかったことって何かという話なんだが、まず俺が感じるプログラマーという仕事は「良き作り手であり続けること」が根本的なモラルだと思っている。若手で右も左もわからないような状態でも、それこそやっとフィズバズが理解できたような状況でも今持っているレベルで最大限にできうる一番いいものを模索し続ける仕事だと思っている。初心者にはチェックコード書け、意図はできるだけ込めろというのはそういう意味でもある。これを真正面から受け止めてくれる職場を探したほうがいいというのは追加しておきたい。

プログラム論とかそういう話がしたいんじゃないということだけは言っておく。

俺も体力があるうちは良きつくり手を目指していたのだが、本質的にやりたいこと、もうちょっと言うなら、俺のモラルの軸は作ることにではなく使うことにあった。プログラミングというアクティビティを挟んでこっちにつくり手がいてあっちに使い手がいる。仕組みを理解して作るのがプログラマーなら、作ったプログラムを理解してよりよい日常を模索するのが使い手、と言ってもいいかもしれない。いいフィードバックループのあっちとこっち、と言ってもいいかもしれない。俺は「良き作りてが使ったものを使う良き使い手でいたい」ということに気づいたので、遺言を書くことにした。少なくともこれに気づいた時点でプログラマーとしての俺は死んだ。

まだ直感的なものでしか無いので、うまく言語化できていないのは申し訳ないんだが、今後10年位はそれを模索していくのではないだろうか。

Permalink | 記事への反応(40) | 12:57

■anond:20201115004233

名前付き引数という仕組みはこの問題をかなり筋良く解決しているように思う。

例えばSwiftで

func set(hoge: Int)

を呼び出す時は

obj.set(hoge: 42)

と書く。

メソッドのオーバーロードも名前単位で可能なので、func set(fuga: Int)も定義できる。

Swiftでアクセサメソッドなんて書くことはないというのはともかく。（例なので）

名前付き引数があるとかなり関数の命名が変わり、hogeFromFuga(int fuga)やfooWithBar(string bar)が単にhoge(piyo: Int)やfoo(bar: String)になる。

Permalink | 記事への反応(0) | 04:57

2020-11-06

■コードを共通化するな

プログラミングできる気になった自称中級者は、ソースコードに共通のパターンが現れると決まって、その処理を関数などに共通化したがる。

たしかに、そうすることでソースコードは短くなるし、一見して保守性が上がったような気になるのだが、それは間違った作法だから止めろ。

細かいこと言っても伝わらない自称プログラマが読んでることを想定して、先に結論を簡単に書いておく。

お前は絶対にコードを共通化するな。

共通化してはいけない理由

なぜコードを共通化するのがいけないのか。理由は簡単だ。要するに、コードが似ているのは単なる偶然であって、それらは別の処理だからだ。

別の処理だから共通化するのはおかしいし、もし共通化した処理の一方のみ仕様が変わった場合、その修正は他方にも影響してしまう。つまり、保守性が下がっている。

たとえば、同じプロジェクトの中に、10%の消費税を加える処理と、10%の金利を加える処理があったとする。この2つの処理はともに元の金額を1.1倍する処理であり、全く同じ処理であるが、共通化してはいけない。

これらを共通化してしまうと、たとえば金利が8%に変更になったとき、金利計算の処理だけではなく、消費税を計算している箇所すべてを変更しなければならなくなる。

実際のアプリケーションでやりがちなのは、複数の処理の「事前処理」「事後処理」などを1つの関数にして、呼び出し毎に細かい挙動を引数で制御するようなパターンだ。

これは結局、改修を重ねる度に「事前処理」「事後処理」の内容が使用箇所によって全く異なるものとなり、それに対応するために

引数の数が膨大になる
引数にフラグを渡して、同一関数内で処理を切り替える

といった悲惨な設計に陥る。

他にも、GUI アプリでユーザーの応答を待つDialog クラスなんてものを作って、使用箇所ごとにメッセージやボタンに割り当てる処理などを切り替えることがある。

これも間違いなく、プログラムが成長するにつれて破綻する。たとえば、ある場所のダイアログは、表示するメッセージがテキスト形式のみではなくなり、脇に画像を表示するかどうかのフラグをコンストラクタに渡したり、Dialogを継承させて表組みを表示するTableDialog サブクラスを作ったりすることになる。ボタンが「OK」と「キャンセル」の2種類の場合じゃなくなって、表示するボタンの数をコンストラクタに渡したり、ボタンに割り当てる処理をリスト形式で渡したりし出す。

こうして、最初は良い設計に見えたDialog クラスはどんどん複雑になる。こうなった原因は明らかで、本来は異なるものを共通化したからだ。おかしな色気を出さずに、素直に別々に実装しておけばよかったのである。

処理に名前をつけろ

プログラミングをする上で「コードを共通化する」なんてことは意識しなくていい。それよりもプログラマがすべきことは、処理に適切な名前をつけることだ。そのプログラムにおいて「単なる変数の操作」を超えた意味のある処理には名前をつけろ。そして、同じ意味の処理なら同じ関数を使うし、違う処理なら違う関数を使う。それだけだ。コードが共通化できるかどうかなんて全く関係ない。

変数、関数、クラス、名前空間等が再利用のための機構だという先入観は一旦捨てろ。それらの真の意義は、「関心の分離」にある。つまり、実装を隠蔽し、その意図を抽象するために存在する。たまに勘違いしてる奴がいるが、別に1回しか使われない関数とか、1行しかない関数はあってもいい。というか、この原則にしたがって設計すると、ほとんどの関数（or メソッド）は数行になる。

上の消費税の例で言えば、「消費税を加える」「金利を加える」処理は、明らかに単なる算術演算以上の意味のある操作だから、関数化する。そして、それぞれの実装は当初の仕様では奇しくも全く同じになる。消費税を加える箇所では前者の関数を呼ぶし、金利を加える箇所では後者の関数を呼ぶ。

これはこう言い換えることもできる。消費税を加える関数を変更するのは、消費税の計算処理が変わったときのみであり、金利を加える関数を変更するのは、金利の計算処理が変わったときのみである。つまり、すべての関数は、それを変更する理由がただ1つになるように設計しろということだ。

こういうアプローチでプログラムを書くと、ソースコードはあたかもそのアプリケーションのドメイン特化言語で書かれたかのような見た目になる。

また、一つ一つの関数は小さく、理解しやすく、テストやデバッグも容易になる。そして、結果として再利用もしやすくなるし、プログラムの変更も容易になる。

Permalink | 記事への反応(5) | 22:48

2020-10-30

■anond:20201030201448

関数の引数に渡すと、一次元配列が二次元配列に変わるというのが凄まじい

Permalink | 記事への反応(0) | 20:22

■お願いだから、センスの無い人はプログラマにならないで下さい

プログラミングはセンスです。センスの無い人がプログラマになると、他のすべての人に迷惑がかかります。だから、センスの無い人は絶対にプログラマにならないで下さい。

プログラミングのセンスが無い人や、プログラミングをやったことの無い人は、知識を得たり経験を積んだりすれば、誰でも「良いプログラマ」になれると思っているようですが、無理です。

というのも、センスの無いプログラマの問題は、知識や経験の不足ではないからです。センスの無いプログラマの救いようの無い問題は「頭がおかしいこと」なのです。

題材は何でもいいのですが、具体的なコードを見た方がイメージがつきやすいと思いますので、とりあえず以下の問題を考えます。

問題

住民のリストが与えられるので、背の低い順に男女ペアにしたリストを作って下さい。ただし、男女の数は同数であるとします。

コード例

ふつうの人は、難しく考えずに以下のようなコードを書きます。

const makePair = (persons) =&gt; {
  const males = persons.filter(person =&gt; person.sex === MALE)
  const females = persons.filter(person =&gt; person.sex === FEMALE)
  const compareHeight = (a, b) =&gt; a.height - b.height
  males.sort(compareHeight)
  females.sort(compareHeight)
  return males.map((male, idx) =&gt; [male, females[idx]]) // 男女の数は同数
}

この例はJavaScriptなので高階関数を使っていますが、仮にそういう機能が無かったとしても、

リストを男女に分ける
各々のリストを身長で昇順にソートする
2つのリストを合わせる

というコードの構成は大きく変わらないでしょう。

一方、センスの無いゴミプログラマは、以下のような名状しがたきコードを書いてきます。

function pair(psns) {
  var i = -1;
  var cnt = 0;
  var flg = psns[0] &amp;amp;&amp;amp; psns[0].sex;
  var j = -1;
  var tmp = null;
  for(i = 0; i &lt; psns.length; i++) {
    //console.log('■■■■■■■■■■■■■■■■■■■■ BEGIN ■■■■■■■■■■■■■■■■■■■■')
    //console.log(psns, 'i=' + i, 'cnt=' + cnt, 'flg=' + flg);
    if(psns[i].sex == flg) {
      //console.log('cnt: ' + cnt + '-&gt;' + (cnt+1));
      cnt++;
    } else {
      j = i - cnt + 1;
      //console.log('swap ' + i + '&lt;--&gt;' + j);
      tmp = psns[j];
      psns[j] = psns[i];
      psns[i] = tmp;
      i = j - 1; // &lt;- 理由は分からないが、i = jだと上手くいかない（by XXXX）。
      cnt = 0;
      flg = flg == MALE ? FEMALE : MALE;
      while(j &gt; 1) {
        if(psns[j].height &lt; psns[j-2].height) {
          //console.log('swap ' + j + '&lt;--&gt;' + (j-2));
          tmp = psns[j-2];
          psns[j-2] = psns[j];
          psns[j] = tmp;
        }
        j -= 2;
      }
    }
    //console.log(psns, 'i=' + i, 'cnt=' + cnt, 'flg=' + flg);
    //console.log('■■■■■■■■■■■■■■■■■■■■ END ■■■■■■■■■■■■■■■■■■■■')
    //console.log('')
  }
  for(i = 0; i &lt; psns.length; i++) {
    //console.log('■■■■■■■■■■■■■■■■■■■■ BEGIN ■■■■■■■■■■■■■■■■■■■■')
    j = Math.floor(i / 2);
    //console.log(psns, 'i=' + i, 'j=' + j);
    tmp = psns[i];
    if(!(i % 2)) {
      psns[j] = [null, null];
    }
    if(tmp.sex == MALE) {
      psns[j][0] = tmp;
      psns[j][1] = psns[i+1];
    } else {
      psns[j][0] = psns[i+1];
      psns[j][1] = tmp;
    }
    i++;
    //console.log(psns, 'i=' + i, 'j=' + j);
    //console.log('■■■■■■■■■■■■■■■■■■■■ END ■■■■■■■■■■■■■■■■■■■■')
  }
  psns.splice(psns.length / 2, psns.length);
}

こんなコードのメンテナンスは御免被りたいです。一見して配列の要素を入れ替えていることが分かるだけで、実装を全て読まなければ（いや読んでも）処理の意図が全く分かりません。また、たとえば「i = j - 1」が間違って「i = j」などと書かれていてバグを起こしたとしても、原因を突き止めるのは困難を極めます。

さて、このコードは具体的に何がいけないのでしょうか。長すぎることがいけないのしょうか。変数名が分かりにくいのがいけないのでしょうか。引数を破壊的に変更しているのがいけないのでしょうか。不要なコメントが残っているのがいけないのでしょうか。よく見ると、ソート処理で車輪の再発明をしていたり、「j」や「tmp」などが場所によって意味が違うカメレオン変数になっていたりしますが、それがいけないのでしょうか。どれも正しいですが、それらを逐一直したところで、本質的な解決にはならないでしょう。

後者のコードはもはや「ここを直したら良くなる」とかいうレベルを超えています。たしかに、問題を具体的に挙げることはできます。このコードの致命的な問題が、凝集度の低さと、単一責任の原則(SRP)違反にあるのは間違いありません。しかし、後者のコードを書いてくる人に、

「住民リストを男女に分ける処理や、リストをソートをする処理、2つのリストをまとめる処理は、この問題とは独立して意味のある操作だから、別の関数として抽出しましょう。その方がコードの見通しがよくなるし、一部の処理を修正したときの影響も小さくなるし、単体テストも書きやすくなります」

なんて言ったって聞く耳を持たないでしょう。

そもそも、こういうコードを書く人は、この処理自体を「pair」なんて関数に抽出すらしません。まだこの問題では入出力のフォーマットが明確に定義されているので、他人が1から書き直せますが、実際のプロダクトでは、無数の副作用を起こす数千行のコードの迷路を彼の脳内フォーマットのデータが通るわけです。もちろん、テストコードなんてありません。

つまり、指摘をしても絶対に直らないのです。いくら言語の優れた機能やベストプラクティスを紹介しても、馬の耳に念仏。それらの利点を理解できるだけの脳みそが足りていないのです。

どうして、同じ処理を実装するのに、ここまでの違いが生じるのでしょうか。

これは、プログラミングの技術の問題ではありません。既に述べた通り、ふつうの人なら、特定の機能の有無とか知識の程度にかかわらず、ふつうのコードを書くのです。なぜなら、ふつうの人にはそちらの方が楽だからです。つまり、前者のコードは別に何か卓越した技術を身につけた結果書けるようになるものではなく、まともな感覚さえ持っていれば、プログラミング初心者にとっても前者のコードの方が書きやすいのです。