ベースになる別の言語からのコンバージョンを自動生成されているソースコードとか読む気が失せますよ。
また、チェーンメソッドを多く使ってなんかうまくやろうとしているのはいいけどみたいなコードも....。
１行でかっこよく書くのは初心者には読むのは相当つらいですよ。
たまにはだれかがコードメンテナンスをしてよりよいコードを目指すほうがよいかと。

中途半端にプログラミングを分かった気になっている人ほど、読みにくく分かりにくくバグが入りやすく改修が難しいコードを書きます。

例えば

• ある西暦（整数）を入力すると、それがうるう年か、そうでない（平年）か、を判定するプログラムを作成せよ。
• うるう年と判定する条件は、以下のとおりである。
  A: 4の倍数の年は、うるう年
  B: ただし、100の倍数の年は、うるう年ではない（平年）
  C: ただし、400の倍数の年は、うるう年

という命題に対して、

カルノー図を書くと条件が理解しやすくなるのではないかと思います。

と言いながら、

year = int(input())
if (year % 4 == 0 and year % 100 != 0) or year % 400 == 0:
    print("うるう年です。")
else:
    print("うるう年ではありません。")

こういうコードを書いてしまう。条件がそれ以上変わらない前提なんです。
それ、初心者向けの演習問題だから成立しているだけですよ、っていうところが分かっていません。

業務でコードを書いていれば、

• 2022/4/28仕様変更
  D: ただし30の倍数の年は、うるう年
  E: ただし、30と4の倍数の年はうるう年ではない
  F: D, Eは2025年より適用する
  　　　　　：

みたいな条件が後から足されてきます。
その時に

if (year % 4 == 0 and year % 100 != 0) or year % 400 == 0:

こういうコードが書かれてあると、拡張が非常にしずらい。バグも混入しやすくなる。
このやり方で条件を書き足していけば複雑怪奇になって行くのは目に見えています。

この記事の本文に書かれてある通りです。

• 拡張性が低く使いづらい
• コードの可読性が低く読みづらい
• 開発・保守のコストが高い

仕様が提示されたら、その仕様に沿ってコードを書くのは業務でコードを書く場合の鉄則です。
仕様を粉々に砕いてミンチにしてしまったら、元に戻しずらいのです。

ですから、普通に仕事をしていれば

def isLeapYear(year):
  if year % 400 == 0: return True
  if year % 100 == 0: return False
  if year % 4 == 0:   return True
  return False

for year in range(1900, 2101):
  if(isLeapYear(year)):
    print(year, "うるう年です。")
  else:
    print(year, "平年です。")
    

まともな人はこういうコードを書きます。

ですが、自分本位で趣味の延長でコードを書いている人は自己満足から

if (year % 4 == 0 and year % 100 != 0) or year % 400 == 0:

こういうコードを書いてしまいます。

そのことを指摘されると、発狂し始めます。@error_401とかね。
極めて基本的なコーディング手法である『ガード』すら知りません。

だから世の中のシステムは大体どれもこれも不具合だらけで『どうしてこうなっちゃうの？』というような謎の挙動をする物ばかりです。

多くのプログラマが身勝手で自分本位なために、『仕様』とは経時的に変更されていくものという当たり前の教訓が、何年経っても身についていかないのです。

まともな人の書いたコードの実例を見てみましょう。

private static bool IsLeapYear(int year)
{
    return year % 4 == 0 && (year % 100 != 0 || year % 400 == 0);
}

@ashworth さん
2022-04-27 23:56　の書き込みに対して

別記事のコメントで誹謗中傷を繰り返した挙句、別の方の記事にまで名指しで他人をバカにするコメントを書くのは人として問題があるとは思わないのでしょうか？

以下は個人的な感想
他人のソースを真っ当な人間は書かないとか初心者でもやらないという人がバカにするコードって何故かMicrosoftのコードにも普通に書かれてるやり方なんですよね
問題があるコードなら沢山の人のチェックを通ってると思われるフレームワークのソースに残ってるとは思えないんですけど
ちなみに僕が初心者でもやらないと文句を言われたコードは早期リターン＋ループ内でのリターンです
フラグで持ってメソッドの最後にリターンしろって言われました
フラグで持つのが嫌ならと提示されたのがメソッドの中身がelseifが延々と続ける形でした

先に記事とは関係ないコメントを書いてしまったので、こちらは記事に対しての感想です

仕様そのものが複雑なケース

これに対しては自分が使いやすいツール、テキストファイルでもExcelでもなんしかその作業ができる環境でインストール可能なソフトやツールの中からその使用を整理するのに分かり易いと感じたものを利用して整理することが大事かと思います
極端な話、他の人が分からなくても自分さえ分かればいいんです
勿論、そのあとで他の人にもわかるように整理し直した資料を作っておくと他の人に展開できるし、後任も理解の助けになるでしょうから人が見てわかる仕様を整理した資料は大事ですけど、まずは自分が理解しないと話にならないので
その上で、次は

前提が誤っており、間違ったまま進めた結果、コードが複雑になってしまうケース

とも重なりますが、仕様を整理した内容であってるかどうかの確認もしないといけません
ようは、「～ってXXってことですよね？」って確認ですね
これが漏れてると、これとこれ一緒じゃね？と判断してまとめたのが、実は勘違いからくるものだったら仕様が一つ飛んでしまうことになります

なので、新人の時は「このくらい訊かなくても判るだろって」言われても、あるいは言われそうだと思ってもこまめに聞くことが大事です
これはエンジニアとしてはベテランになっても、新しいプロジェクトに参加したらそのプロジェクトの仕様に対しては新人なので同じ様に確認が大事だという事です
もしも隣に誰か座っているのでしたら、考えをまとめる際にその人に聞いて貰うというのも手です
結構、それで解決した人も多いので

そして、この記事に書いてある「ソースに対して常に疑問を持つこと」はソースに限らず自分が使用を理解しようとしてまとめた考えにも本当にあってる？この場合は考慮の入れたけど、他の場合でまとめたパターンからだと漏れるケースはない？ってことを念頭に置いておくと比較的マシになるかとは思います

記事の見出しそのものについて
コードが複雑になってきたとか膨大になってきたと感じたら、仕様を元に処理を細分化して、ここではこれをするだけ、ってな感じで切り分けて作るかな？
例えばif文の条件が複雑化してきたと考えたなら、そこをメソッドに切り出して、ここはXXの判定処理として、細かい条件は仕様書から引っ張ってきた日本語でコメントに書いておく

ってな所かな？

@lensouko

別記事のコメントで誹謗中傷を繰り返した挙句、別の方の記事にまで名指しで他人をバカにするコメントを書くのは人として問題があるとは思わないのでしょうか？

どうしてそうやって歪めて捉えます？　性格悪いんですか？

「バカにする」って何ですか？　それ、あなたの主観ですよね。
わたしは「こういうコードは迷惑なので辞めてください」としか言ってないです。

他人のソースを真っ当な人間は書かないとか初心者でもやらないという人がバカにするコードって何故かMicrosoftのコードにも普通に書かれてるやり方なんですよね
問題があるコードなら沢山の人のチェックを通ってると思われるフレームワークのソースに残ってるとは思えないんですけど

ん－と、どこから突っ込んだら良いのかわからないんですが、
Microsoftのソフトウェアがおかしな挙動する物ばっかりなので、あなたが何を主張したいのか良く分からないです。
バカにされたようなコードが満載だからMicrosoftのソフトウェアは挙動がおかしいんじゃないですか？って。

ちなみに僕が初心者でもやらないと文句を言われたコードは早期リターン＋ループ内でのリターンです
フラグで持ってメソッドの最後にリターンしろって言われました

へー。ならその人は私にもそう言うんでしょうね。
多分その人、今頃仕事無くなってるから言えないでしょうけど。

@Zuishin

日本語、読めますか？

こういうコードを書いてしまう。条件がそれ以上変わらない前提なんです。
それ、初心者向けの演習問題だから成立しているだけですよ、っていうところが分かっていません。

初心者向けの演習問題を晒して

まともな人の書いたコードの実例を見てみましょう。

とか。

とても、頭がまともな人のセリフとは思えませんね…。
というか、いつまで粘着してるんですか？　本当に迷惑行為ですよ。

まともな人はこういうコードを書きます。

def isLeapYear(year):
  if year % 400 == 0: return True
  if year % 100 == 0: return False
  if year % 4 == 0:   return True
  return False

for year in range(1900, 2101):
  if(isLeapYear(year)):
    print(year, "うるう年です。")
  else:
    print(year, "平年です。")

に対して以下の条件

2022/4/28仕様変更
D: ただし30の倍数の年は、うるう年
E: ただし、30と4の倍数の年はうるう年ではない
F: D, Eは2025年より適用する
　　　　　：

を足した場合に、

頭がまともじゃない人が書いたコードはこうなるらしいです。

def is_leap(year):
　flag = False
　if year % 4 == 0:
　　flag = True
　　if year % 100 == 0:
　　　flag = False
　　　if year % 400 == 0:
　　　　flag = True
　　　　if year >= 2025:
　　　　　if year % 30 == 0:
　　　　　　flag = True
　　　　　　if year % 30 == 0 and year % 4 == 0:
　　　　　　　flag = False
　return flag

知能指数の低い人にコードを書かせてはいけない理由が良く分かりますよね。
ちなみに、5chによるとミジンコという人が書いたコードらしいです。

余談ですけど

フラグで持ってメソッドの最後にリターンしろって言われました

なんとかフラグって、アンチパターンで真っ先に上がってくる奴ですよ。
必要も無いのになんとかフラグが山のようにあるプロジェクトって、
大体コードがスパゲティになって炎上しています。

良い先輩に巡り合えましたね♪

こういうコードを書いてしまう。条件がそれ以上変わらない前提なんです。

うるう年の条件が変わるわけないじゃないですか。

@Zuishin

うるう年の条件が変わるわけないじゃないですか。

条件が変わらないコードしか書けない方には最適な命題ですね。
Zuishinさんは、変化に弱いから。

@Zuishin

だから汎化の意味も分からない。

これを見ただけでも、フラグが如何に害悪か、早期にリターンしないとどのようにコードが腐るのか、
一目瞭然ですよね。

def is_leap(year):
　flag = False
　if year % 4 == 0:
　　flag = True
　　if year % 100 == 0:
　　　flag = False
　　　if year % 400 == 0:
　　　　flag = True
　　　　if year >= 2025:
　　　　　if year % 30 == 0:
　　　　　　flag = True
　　　　　　if year % 30 == 0 and year % 4 == 0:
　　　　　　　flag = False
　return flag

えっと、一度汎化の意味を調べたほうがいいと思いますよ。
誰でも知ってる言葉を間違ってイキると、後でかなり恥ずかしい思いをしますから。

@Zuishin

ええと、日本語で使用している漢字って表意文字なので、
一文字一文字に意味があるので、
その文字の意味を組み合わせて言葉というのは出来ていて、
その意味を組み合わせることで日々新しい言葉が生まれているんですけど、

汎化

と言われて辞書に載っている事しか意味が分からないなら、
それはもう、日本人じゃ無いんじゃないですかねぇ？

さすがにここまで頭が悪い人だとは思ってもみなかった…。

それ、話の主題と全く関係ないじゃん…。
話と全く関係なくても、ちょっとでも噛みつければOKな人だったのか…、@Zuishinって人は…。

@Zuishin

なんだかよく分からないけど、
あなたは「汎化」が辞書に載っている用法かどうかで争いたいんですか？
頭大丈夫ですか？
本気で意味、分からなかったんですか？

あなたが汎化を知らず二文字の漢字から意味を想像して書いたというのが伝わりました。

@Zuishin

汎化を知らず

って…。

それ、あなたの事でしょ？　知らなかったから調べて悦に入ってる。

わたし、言いましたよね？

漢字って表意文字なので、
一文字一文字に意味があるので、
その文字の意味を組み合わせて言葉というのは出来ていて、
その意味を組み合わせることで日々新しい言葉が生まれている

って。

意味分からなかったのかな？
分らないんだろうな、線路に沿って走る事しか出来ない機械人間には…。

言葉ってね、創り出していくものなんですよ？
あなたみたいに杓子定規のロボットには分らないでしょうけどね。

あなたは勝ち誇っているつもりらしいけど、哀れです。

@Zuishin

なんで哀れだと思うか分かっていますか？

あなたが必死で食いついているそれ、

話の本題と、まーったく関係ない事だからです。

あなたただ、あなたのくだらないプライドの為だけに食い下がってますよね？

あなた、哀れなロボットですね。

あなたが新しい言葉を生んで自分だけで使っていることは伝わりました。

@Zuishin

なんだか良く分からないけど、あなたはそれで納得した、と。

で、本題は？

まさか、ほかのスレまで来て本題と全く関係ない「汎化」の定義に拘っていたなんて事はないですよね？
本題については何が言いたいんですか？？？

いえ、独自の言語を使う方には説明しにくいので大丈夫です。
そもそも私の最初のコメントでほとんどの人は理解できます。

@Zuishin

何を心配しているのやら…。

私はあなたと違って漢字の一文字一文字の意味が分かりますので、
あなたが「日本語である」と考えている言葉なら何を書いても大丈夫ですよ？

それとも、怖くて書けませんか？　あなたはロートルだから怖くて仕方ないのも分かりますけどねぇ。

そもそも私の最初のコメントでほとんどの人は理解できます。

あなたが、「条件が変わらないコードしか書けない方には最適な命題ですね。」の意味が分かっていないからこのように話がこじれているんじゃなかったでしたっけ？w

@Zuishin という人は本当に杓子定規しか出来ない方だな…。

というか、もう寝る寸前だったのでめんどくさかったから適当にあしらっていましたけど、
『言わないか？』と思って検索してみたら普通に使うじゃないですか。

学習時に与えられた訓練データだけに対してだけでなく，未知の新たなデータに対するクラスラベルや関数値も正しく予測できる能力．

用法も字で書いてある通りだ。

「学習用の簡易な演習問題に対してだけなく、広範な新たな問題についても正しく解決させる事」

使い方としても何の違和感もないでしょう。

普通に使っていたけど前に機械学習を勉強した時に自然に覚えていたんですね。
まぁ、知らなくても日本人なら漢字を見れば普通の人は意味が分かるはずですけど。

逆に言えば、@Zuishin さんは機械学習を知らないんだ。
漢字を見ても、意味が分からないんだ。

…凄いな、@Zuishinさんの日本語能力。いろんな意味で…。

@Zuishin

あなたが新しい言葉を生んで自分だけで使っていることは伝わりました。

違いましたね。残念でした。

5chで、全く関係ない話題の中で下記のコードが笑い話として提示されていました。

if(a >= 8 && b != c && a == b && !b || a == 0){
    if(!(a != d || c <= 0)){
        正常処理
    }
}

この記事『あなたのコード複雑怪奇になっていませんか？』を地で行くコードです。

よく似ているでしょう？

if (year % 4 == 0 and year % 100 != 0) or year % 400 == 0:

あと、2回くらい仕様変更が繰り返されたら全く同じスメルを放ち始めますよ。
仕事としてコードを書いていれば、まともなエンジニアなら普通はこういう嗅覚が育ってくるものだと思いますけどねぇ…。
@lensouko @Zuishin

汎化
オブジェクト指向プログラミングの分野では、様々なクラスやオブジェクトに共通する性質をまとめ、それらの共通の親クラス（スーパークラス）として定義することを汎化ということがある。

パターン認識や機械学習の分野では、既知のパターンから特定の分類に共通する性質や法則性、規則性などを抽出して、未知のパターンの認識や分類に応用できる形にまとめることを汎化ということがある。
-IT用語辞典より

汎化
広い範囲に共通して適用できるようにすること。一般化。普遍化。
-weblio辞書より

閏年に適用されないので、共通部分がないんですよ。
汎化するには、まず閏年だけで説明できないとだめです。

「閏年を計算する関数」は、「仕様変更のない関数」「関数」「暦に関する関数」などのように汎化できますが、「仕様変更のある関数」に汎化することはできません。
それは汎化ではなく、すり替えと言います。

@Zuishin

閏年に適用されないので

「何が」ですか？　Zuishin さんは主語が欠落した文章をしょっちゅう書いていますが、日本語が不自由なんでしょうか？

あなたが、他人の言った事を全く聞いて居ない事は良く分かりましたが、
何度も申し上げた通り、一般的に、

if (year % 4 == 0 and year % 100 != 0) or year % 400 == 0:

こういう風に、論理演算子でずらずらと繋げて書かれると後の人が困りますので、迷惑ですから辞めるか、
一人だけでプログラミングしていてください。
あなたが職業プログラマではなくて、ただの趣味グラマなら止めません。

ゴールデンウィークも今日を入れればあと3日くらいありますから、
この記事のタイトル『あなたのコード複雑怪奇になっていませんか？』を10回くらい暗唱して、
『どういうコードが将来複雑怪奇になっていきそうかなぁ…』と、
漠然とでも考える機会を設ければ、すこしはメンテナンスのしやすいコードというのがどういう物になるかのヒントくらいは掴めるのではないでしょうか。

まあ頑張ってください。

いや、おまえがな…。

何主張なんだろう？