我がコードは我流。我流は無形。故に誰にも読めぬ。

オレ流プログラマー腹立つ
何で公式で用意したものをすぐぶっ壊してオレ流にするの?

一緒にやるプログラマーは迷惑極まりないんだよ

協調性なさすぎるだろ

公式を尊重しろよ

https://anond.hatelabo.jp/20190903144842

うーん,それは公式とか協調性の問題じゃないと思う.


得てしてそういう人はスキルが低いだけなんだよね.だから他の人が書いたコードを理解できないし,学習しない,デバッグもできない.そのせいで一度覚えた自分のやり方を変えられない.

もちろんその逆で,その人の方がスキルが高いから,古い良くないやり方をよりよいやり方に修正してる場合もある.*1

「我がコードは我流。我流は無形。故に誰にも読めぬ・・・」

論よりコードに似ているようで全然違います、コチラの方はコードの可読性が限りなく低い!一体誰に保守させるつもりでしょうか。我流で書けるのは分かりましたから、次はコメントの書き方やデザインパターンを学んで、可読性の高いコードをお願いします。

2017年、今でもこうしたコードを見かけます。開発費をケチられたといっても、保守できないレベルのコメントしか残していないというのは開発者の矜持に欠けますよ。

https://blogos.com/article/216209/

という,迷言もあるくらいで,バラバラのコードは読みにくいものだ.


だが,それに対する反論が「(社内)公式だから」「オレには分からんから」「みんなと違うから」「なんかムカツク」と言ってるようじゃ二流.

そのやり方を理解した上で,どうしてそのやり方だと可読性や生産性が低いのか,なぜバグが出やすいのか,デバッグしにくいのか,なぜ標準として採用されなかったのか反論できなきゃ半人前.その「標準」の書き方だって,なにも最初から標準だったわけじゃないし,永遠に「標準」でありつづける訳でもない.

C++ Coding Standards―101のルール、ガイドライン、ベストプラクティス (C++ in‐depth series) リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) オブジェクト指向における再利用のためのデザインパターン オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

https://b.hatena.ne.jp/entry/s/anond.hatelabo.jp/20190903144842

  • id:rusemoly 全く畑違いなんだけど、とあるベテランが推奨とは違うやり方で仕事やってて、それを見てた大ベテランが新人の俺に一言「あいつは全部分かってて、あえて崩してる。君は身に付くまでは基本に忠実に」と。
  • id:rirukarinka そのままでもできるのにその通りに使わないのか、そのままではできないから手を入れざるを得ないのか、実計測の結果そちらの方が良いことがわかったからなのか。知識の差で見えてるものが違うこともあるから…
  • id:acc-3 日本の職場ではソフトウェア工学をちゃんと学んできていない人達が多数なので、それに沿った書き方をすると、そういう人達からオレオレ批判を喰らいやすい。多分ここの米もそういう人達が多いのではと予想。


  • id:fukken 程度問題だし、その「程度」が遅れすぎている現場の方が多い印象があるのでなんとも。統一は大正義だが、10年以上前のスタックに縛り付けられるのは非効率しかない。
  • id:kakei-akihiko その標準が、最新の標準か10年前の標準化で大きく事情が違う。標準、特に社内標準は一度決まったら変わらない。世間の技術が進んでも古いまま残る。それが高齢者しか扱えない技術や技術的負債になってしまう。
  • id:Kil これ言ってる側の方が現在のコーディングスタイルについてきていない場合もままあるからなぁ。「そうね、3年前のバージョンまではそれがスタンダードだったね」
  • id:k-holy PHP4時代の国産フレームワーク魔改造で作られた他社製Webサービスを託されて、今もメンテしながらPHP7で動かしてる私が通りますよ…大してお金にならないサービスなので、リプレイスも難しくて。正直、閉鎖して欲しい。
  • id:comitlog java8だったからlambda式やtry-with-resources構文使ったら、何使ってんのこいつみたいな目で見られたことある。標準てなんだろう。
  • id:zyzy 公式が入れた新しい機能を無視して過去のやり方にすがる人はどうしたらいいんですかね?
  • id:Seitekisyoujyo 同じ処理をもう二度と書かなくてもいいように、再利用性が高まるようにメソッドを細分化してクラス化してモジュール化したら、そんな事もしないような奴らから「オレオレだー」と抜かされる世知辛い世の中。

これもあるなあ.嫌と言うほど...

マスダの例だと,筆者の方が社内標準しかしらない老害で,「オレオレ」というのが現在のベストプラクティスの場合もしばしば見られるので,どちらがいいとは一概には言えない.


  • id:mozikeru 昔の職場で公式のライブラリ使ったら上司から「何故そのライブラリが100%信用出来ると言えるの?」と言われて全て1から自分で実装させられたクソ思い出。
  • id:z67kjh 「完全に理解した」を過ぎたあたりで発症すると思う。「なにもわからない」に達すると寛解するが「チョットデキル」に至ると再発する場合がある
  • id:tk_musik 今日もデファクトスタンダードとベストプラクティスを探していたら定時になったので帰ります。
  • id:mrpotas 先輩がループ用変数を再利用するプログラム書いてきて「メモリ節約!」とドヤ顔してきたときはどうしようかと思った
  • id:hdampty7 だってphpは公式の関数名が変だし、公式が意図してない使い方が標準だったりよく分からないんだもん!
  • id:mohno とりあえずC言語ポインターを渡すのを「参照渡し」というのをやめてほしい。/逆の話で、独自フレームワークでメッチャ作り込むのもやめてほしい。それ使うまでに時間がかかる上、一生懸命覚えても応用きかない。

*1:以前も書いたけど,憂鬱本Amazonレビューには,日本IT業界の闇が詰まってる.こういう人らがオブジェクト指向的なコードを見たら,きっと「普通」と違うコードだとケチをつけるだろう. http://javablack.hatenablog.com/entry/20180929/p1

憂鬱なプログラマのためのオブジェクト指向開発講座 (DDJ Selection)

憂鬱なプログラマのためのオブジェクト指向開発講座 (DDJ Selection)

「もやもやがスッキリ。」「“オブジェクト指向”を理解する最短の道」「読んで損のない一冊」「本質を理解できる。」どこがだ.