![yuu_j](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="48" height="48"><rect fill-opacity="0"/></svg>)
時代は令和ぞ、何を書いとるんや
転職してきた若いプログラマが変なコード書いている。
どうやら前社の社内研修で教わったとのこと。
さて、老害は何を教えたのだろうか。
※一応TypeScriptで書きましたが別にC#とかPythonでも言えることです。
１．変数名が雑
クラス、関数、変数、どれも命名は難しいものです。
大体が英語で大変です。けど頑張ってわかりやすい名前つけてください。
本読んで勉強してください。Google翻訳使ってください。
10行程度の短い関数ならretでもdataとか適当な名前でもいいけど
長くなるようならちゃんと名前つけてください。
// Goodってなんやねん！なにがGoodやねん！
public isGood : boolean { return true; }
public Piyo() : void {
data = this.getData();
// 十行以上のコード
// このデータなんやねん！ちゃんと名前ついてないからわからん！
if(data.result){
}
}
２．無駄な省略
これも命名なんですけどね。
古い習慣なんですかね。
意味わからんからやめてね。
countをcntとか、managerをmgrとか、meetingをmtgとか
日常のメールとかに書く分には好きにしたらええけどプログラムには書かないでね。
特に関数内のちょっとした変数ならともかく、
クラス名になんてしないでね。
public Hoge() : void {
// は？dtってなんやねん、DateTimeか？童○か？
let dt = this.getData();
// 以降なんかの処理
}
３．無駄に()つけている
※この項は批判も多く、個人の考えによっているところがあります。
正しいことを述べているのではなく、そのような意見もあるのだな程度に受け取ってください。
if文で無駄な()が多いと読みにくいです。
C++とかではそんな書き方推奨なんですか?
// このhogeとかpiyoの周りかっこいらんよね？
if((hoge == 'Hoge') && (piyo == 'piyo')){
// なんかの処理
}
可読性を気にして、そんな書き方するぐらいなら
一回変数で受けたほうが読みやすいです。
※上記の例程度なら変数で受ける必要もないので、無駄な()だけ消してね。
const isHoge = hoge == 'Hoge';
const isPiyo = piyo == 'piyo';
if(isHoge && isPiyo){
// なんかの処理
}
４．変更するときに昔のコードをコメントアウトして残す
これは、そのまんまですね。
コード管理にgitなりSVNなり使っている職場でコメントアウトして
残すとかやらないでね。
gitもSVNもなく、差分管理してないような職場なら転職考えてね。
public commentOut() : void {
const foo = new Foo();
/* 2021//02/18 yuu_j HogeではなくFooを使うようになったので変更
* const hoge = new Hoge();
* 昔の処理
*/
}
５．必要以上に広いスコープで変数宣言する
変数の宣言する場所考えてますか？
CとかC++とかは関数の最初に宣言するんだっけ？知らん。
とりあえず必要最小限のスコープで宣言してね。
public getPrice(fuga : boolean, piyo : boolean) : number {
let price = 0;
if(fuga){
price += 100;
// ここでitem宣言する必要ある〜？
const item = this.getItem();
if (piyo){
// このif文の中でしかitem使ってないよね？この中で宣言しようね？
price += item.Price;
}
}
return price;
}
６．ハンガリアン
変数の宣言時に変数の頭に型がわかるように書くやつです。
個人的にはそこまで嫌いじゃないけど令和の時代に書いてたら笑われるで。
// number型だからnから始めるw
const nCount : number = 0
// string型だからsから始めるwww
const sName : string = ''
７．ヨーダ記法
定数をif文の左側にかくやつです。
読みにくいのでやめてね。
ヨーダ記法 - Wikipedia
//アンチパターン
public badSample(price : number) : void{
// 定数を左側に書くな！！
if (0 == price) {
// なんかの処理
}
}
//推奨パターン
public goodSample(price : number) : void{
// 定数は右に書け！！
if (price == 0) {
// なんかの処理
}
}
８．言語として用意されている機能を使わない
これに関しては新人の勉強不足や、勉強しろ。
特殊な外部ライブラリとにある機能ならともかく
デフォルトで用意されている機能使おうね。
C#ならLinqを使うとかPythonでmathを使うとかね。
private _numbers : number [] = {1,2,3,4};
// アンチパターン
public badHasNumber(targetNumber : number){
for(n in _numbers){
if(n == targetNumber){
return true;
}
}
return false;
}
// 推奨パターン
public goodHasNumber(numbers: number[], targetNumber: number){
return numbers.includes(targetNumber);
}
９．goto
いや、ほんま何を教えとるんですか。
教えた人は引退して、どうぞ。
TypeScriptではないんやね?
とりあえず、どのgoto必須の言語以外でgoto使おうなんて考えないでね。
C#で使ってたりしたら、ふざけてるとしか思わないからね。
最後に
この記事が新人プログラマがクソ習慣、クソ環境から抜け出す一助になればいいなと思います。
あとQiitaで表現されたコードってVS Codeとかで見るよりなんか見やすい気がしますね。フォントの問題？
追記：2021/2/20
この記事を書いたときはかなり感情的になっていて失礼な表現が多々あると思います。
気分を悪くされた方には申し訳なく思います。
すみませんでした。
個人的に言いたかったのは経験豊富で知識豊富なエンジニアに対して、
あらゆる言語に、自分の経験豊富な言語の習慣をそのまま持ち込まないでほしいということです。
各言語には各言語らしい書き方があると思います。
各言語に合わせて、もしくは時流に合わせて変われないのであれば、
それは老害でしかないと今でも思います。
私自身、未熟で学習中の身でございますので、見当外れな指摘もあると思います。
納得できる、もしくは一般的に批判されている部分だけでも
若いプログラミングを始めたばかりの方の参考になればと思う次第です。
![kai_kou](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="73" height="73"><rect fill-opacity="0"/></svg>)
演算子の優先順位で自明なところへの無駄なカッコの使用を勧めてくれる C++コンパイラはありますね。
prog.cc: In function 'void piyo(bool, bool, bool)': prog.cc:4:16: warning: suggest parentheses around '&&' within '||' [-Wparentheses] 4 | if (a || b && c) hoge(); | ~~^~~~https://wandbox.org/permlink/ZjsWEv2G1JJDkuTC
自分もこの場合無駄でもカッコを使用したほうが良いと思います。
TypeScript界隈では老害扱いされる書き方なんでしょうか?
@fujitanozomu
ご指摘いただきありがとうございます。
TypeScript界隈のことは存じておりませんが、
個人的には、そのあたりは好みの問題だと思います。
or条件とand条件を併用する必要がある場合は私もそのようにカッコをつけます。
個人的には↑のカッコも悪いと思わないのですが
カッコの有無がルールを明文化できないところでの個人の嗜好で良し悪しを論じている程度のものであるならば自由で良いのでは? 変な縛りを設けたところで若い人を委縮させるだけじゃないかと思いますね。
@fujitanozomu
そのあたりはC++文化で昔はそうだったんだなぁといった感想です。
C#の経歴が主ですが、VisualStudioを使って開発しており
そのような無駄なカッコを見かけることはありませんでした。
でも実際どうなんでしょうね？
新しめの言語、VS Codeとか多機能なIDEを使っている環境でも
無駄なカッコあった方がいいんですかね？
個人的にはない方がいいと思っているので書かせていただきました。
あった方がいいとは思わないので。
若い人を萎縮させるかどうかはコミュニケーション能力の問題だと思います。
追記：
私もTypeScript、JavaScriptは勉強中なのですが、
下記のサイトの例を見る限り
@fujitanozomu さんがはじめに挙げられているorとandが混在する例ではカッコをつけろって
ってなってます。それ以外の例ではつけてないですね。
https://github.com/airbnb/javascript
下記の記事から上記サイトを参考にさせていただきました。勉強になります。
Webエンジニアが勉強できるGit Repository 10選
さぞや経験を積まれてる方なのだろうと思いますが自分が見たことがない ⇒ 悪という判断は危険ではないでしょうか
https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/inside-a-program/coding-conventions#layout-conventions
あと、
挙げられるべきは無駄なカッコが悪い書き方であるという記述では?
ヨーダ記法と無駄な括弧に関しては組み込み系で使われているイメージがありますね．
万が一にでもテストから漏れると人が死ぬ可能性がある（自動車とか工場とか）性格のものは読みやすさはある程度犠牲にするみたいです．
指摘してる人もいますが、その記法に意図なり意味があるのを全否定されてもね
うちの職場で使わないってだけの話を一般論にされても疑問しかないですね
「藪をつついて蛇を出す」を地でいく事例ですね。プロジェクトの規約でこうしろと定められている場合とか、部署のコーディング規約とか、チーム内の取り決めとか、現実に直面する
「個人ではどうしようもない制約」
が存在することを知っていれば、同じ指摘でも今回のような表現にはならなかったはずだと思います。
＞「さぞや経験を積まれている方」
という突っ込みがありましたが、これはいわゆる「慇懃無礼」な物言いです。この一言を歯に衣着せずに表現するなら
「なに指導者ぶってんだよ素人が」
になるでしょうね。己の力量とか業界の悪しき風習について理解を深めておくことも技術者として大切なことですよ。
コーディングルールはeslintで指摘するべきで、人間が見ているのは前時代的では？
私 ハンガリアン、めっちゃ使ってます
Visual Basic から入ったからかな？
むかし、ハンガリアンを拒否したい人が、
「接頭語の n や s の１字入力が積もり積もれば無駄な時間が増える」
と謎の反論してた
個人的には悪い例を「おじいコード」と呼んで侮辱的に表現している点がもっとも罪深いと考えています。その思想は記事のすみずみに現れており、高所から見下すような表現が多く見られますね。
コードの良否と書いた人間への感情的な評価を同一にしてはいけないでしょう。
それはハラスメントにつながります。
自分は仕事のスタイルとして色々な会社を大体半年～１年単位で転々としているのですが、ここで語られているような事が仕事場ごとに規約の微妙な異差として常に付きまといます
そして自分の経験の中だけで語るなら、「マイクロソフトの規約に準じる」とかでない限り、「この会社とこの会社は同じ規約だ」というのに出会ったことがありません。同じ会社内でもプロジェクトによって違うことすらあります
それに関していつも、（クセとして付いた部分を次の職場に合わせる）対応を迫られるわけでして
それ自体はどうとでも対応出来るのですが、ただ移る度にそこの職場の人間がさも自分の所で取り入れている規約を全ての人に通じるこの世の唯一真理のように語り、それを守れていない人に対してまるで人の道を外れている人を見るかのような胡散臭げな目で見るのに嫌気がさしている次第です
ここで語られていること、例えば、単語を略すかどうかに関して、「一般的な単語なら略してもいいよ」としている所もあれば、どの単語に限って略せるかを明確に規約に盛り込んでいるところもあれば、「とにかく絶対に略すな」という事を規約に明確に取り込んだ結果、グローバルの変数名や関数名が長くて１００文字を越えるような状況になっていてみんなうんざり、みたいな職場もあります
また、職場によって「１つの関数が○○行を越える（要は１画面に収まらない）なら、分離する」ような事を盛り込んでいるような規約もあり、それが徹底している職場ならローカルの変数名を略す事に懸念されるような害はさほど発生しないのではないかと思えます（むしろより見やすくなるかもしれません）
詰まるところ、どちらがいいということではなくどちらがその現場に適しているかという話になるわけで、ならば本質的な所として「（現場として略すべきではないのなら）それが規約に記載されているか」「（言わなくても常識だろ、ではなく）それを守らせるための周知教育が徹底しているか」という所を考えるべきように思えます
vscodeのqiitaテーマが見やすいのでよく使ってます。
https://github.com/increments/vscode-qiita
変数名はできる限りわかりやすいほうがいいし、
無駄な省略は論外だと思ってますが
dtとか「慣習的であるもの」については、文脈上問題がない限りそっち派かなぁ。
dtいっぱい出てくるとかならxxxPeriodFromとかにすべき事もあるけど…
そうなるとスコープによって慣習的な名前と説明的な名前が入り混じっちゃうから気持ち悪いのか
@fujitanozomu
個人的に無駄なカッコはいらないと思っていますし、
無駄と思っている無駄なものを使用するほうが非合理的に思います。
けどC#の規約ではそうなっているんですね。
ありがとうございます。勉強になります。
@Yt_kb さんがおっしゃられているような環境で使用されるのは大変理解できます。
勉強になります。ありがとうございます。
@pff01632
おっしゃるとおりです。
正直に申し上げて深夜のテンションで書いていて、失礼な表現があると思います。
個人的な思いを正直に書かせていただくなら、古い習慣にとらわれて
新しいことを学ばない、変わらない年配のエンジニアに対する怒りが漏れています。
今更、記事を修正をしませんが、技術的な記事に個人的な感情を持ち込んで
失礼な表現になってしまったのは私の落ち度です。
気分を悪くされたかたには申し訳なく思います。
すみません。
例えばですね・・・
と書かれるよりかは、
のほうがまだ読みやすいと思いますよ。前者使いたかったらCOBOLでもやってろ！！って話です。
その言語として用意されている機能に致命的なバグがあった場合や、計算量が非効率な場合はその機能を使わないことはあるはずです。これは言語ではなく標準ライブラリでの例ですが、まあ僕が知る限りでは、Golangで標準ライブラリで用意されている
math/bigはFFTを使っておらず、Karatsuba法を用いていたはずです。この場合、FFTよりも計算量が多くなるため、ライセンスが許す限り、gmpのフロントエンドを利用することにしています。これはアセンブリ言語の名残り(と言うべき何か)ですね。今でもコンパイラが行わないようなパフォーマンスハックを敢行するときに使ったと思います。つかDBMSの開発とかだと未だにgotoは現役ですね。
ヨーダ記法に関してです。
記事のwikiのリンク先の通りヨーダ記法は左辺に定数を入れることで、条件式を書くつもりで代入文を書いてしまうを防ぐことを目的としていると思います。
可読性を犠牲するデメリットより、上記の間違いを防ぐメリットの方が大きいと考えも間違いではなく、無条件に否定はできないかな〜と思います。😅
もちろんC#のようにif文の条件に条件式しか書けない言語ではヨーダ記法をする意味はないかなと思います。
歴史の長い言語ではif文の中で代入文が書ける言語も多いですが、その文化を条件式しか書けない言語に持ち込むな、という主張は理解できます。
ダメ🙅♀️な理由が書いてあると良いなと思いました。
皆さま言われてるので内容については語りませんが
おじいコードといい見下す姿勢も、経験を振りかざして強要する人の行動とあまり変わらないという印象を受けました
良いコードという言葉は場所によって形を変えるので、経験のあるなし関係なく、先入観のない目線でこのコードが今の自分たちにとって適切なのか？を考えて、よりよい書き方を目指して欲しいと思います。
例えばプロジェクトのコーディングルール一つとっても、例えば過去発生したインシデントを防ぐために取り入れられた等、背景があったりすることも多々あります。
ただその場のコードの書きっぷりだけを批判しても始まらないので、なぜそんな書きっぷりを採用したのか？等に踏み込んだ上で、無駄な慣習であればより良い慣習をチームで作り上げるよう努めるのがよいのではないかと思います。
JavaScript ではラベル付き文というのが使え、多重ループからの脱出等には便利そうな機能ですが、これ要は使用方法を限定した goto ですね。
同様に、C のような比較的原始的な言語でも、goto を限定した用途に限り使用を可とするコーディングルールを採用しているところは結構あると思います。
goto というだけで頭ごなしに否定されてるのは教条主義に見えます。
老害世代より上の老々害世代です。
３．無駄に()つけている
老いた脊髄反射で
と書いて欲しいと思ってしまいます。（黙ってOKしますけどね）
こういう単純なケースでも、変数に代入する時は明確な意思を持って誰でも判るようにした方がベターと感じます。
これなら判るだろうと誰もが考えますが、指に癖を付けておくというのも悪くない選択肢です。
if文が長くなってカッコを多用するのは、そこに至る考え方に問題があるケースが多いようです。
そういう意味ではおっしゃるように、カッコを避けてシンプルにすると言うことはメリットは大きいです。
ご存知とは思いますが、短絡評価などの影響も考慮する必要がありますの外部に出す場合には慎重にする必要がありますよね。
本筋から外れて申し訳ないです。
９．goto
おっしゃるように安易に使うのは反対です。特に初心者のgotoは酷い物です。
しかしながらエキスパートのgotoには頭が下がります。
昔から文句をいわれつつC#にも存在するという事は何か存在意義があるのでは無いかと思います。
様々な書き方にはメリットとデメリットがあり、絶対的に正しいというものが存在しないので「コーディングルール」というものを用意して良し悪しの線引きを行うわけですが、@yuu_j さんはその点誤解されてる気がします。正しい書き方というものが存在していて自分はそれを理解している、外れているものは間違いであり老害であると考えられてる様見受けられます。
その若いプログラマさんにコードを書かせる前に @yuu_j さんのところのコーディングルールは提示されましたか? そうでないところでの「変なコード」だの「老害は何を教えた」だの言われてるのであればパワハラ案件ではないかと思いますね。
8番､typescriptでこの処理なら言語で用意されている
_numbers.includes(targetNumber)を使うのが普通では?(NaNが絡むときの挙動が変わるがそれが仕様に盛り込まれていたとも思えないので)
無駄と判断する理由が規約なのか好みなのか原則なのかみたいな観点はありそうですね。
3についてはちょっと言い過ぎだと思ったので議論になるの納得。
7の定数の表記はconst宣言とかで記載しない理由あるのかなあ。
3に関して、こんなのありました。
https://github.com/airbnb/javascript#comparison--no-mixed-operators
@fujitanozomu
私も自分が理解しているとは思っていませんし、古い書き方にとらわれないようにしようね程度のことを行ったつもりです。
若いエンジニアの方から2人で食事に誘っていただけるなど、意見の言いやすい関係を築けていると思っています。
パワハラだとその方が思えば、会社に相談窓口もありますので相談されると思います。
何分当方も経験に乏しく、私よりも経験のすくない方に対して書いたつもりでございます。
経験豊富で知識豊富な@fujitanozomu さんには頭が下がるばかりでございます。
稚拙で目に余る箇所も多々あると思いますが、何卒、ご容赦いただければと思います。
おおよそ自分も思うところが書かれていて、個人的には共感度が高いです。
これについては善し悪しはあると思います。場合によっては優先度を明示的にしたい場合もありますし。
それにしてもこのqiitaの文章が80文字以内程度で改行されているような感じはなんだか全世代的な感じがします。wrapでもなんでも環境（ブラウザ等）がやればいいので...
eslintやprettier入れれば人間が干渉しなくてストレス減るよね的な話が繋がる気はします。
自分が正しいと思い込んで突っ走るタイプですかね。
いろいろな人を見てきましたが、そういう人は後々危ういので気を付けたほうがいいです。開発途中で来なくなったりする人に多いです。
毎日コードインスペクション（死語？）ばかりやらされて頭にきている人なんでしょうか？
好きに書けばいいとは言いませんが、あなただけが書いているのではないし、偏差値70のプログラマーより偏差値60とか55とかのプログラマーの人数のほうが圧倒的に多いです。私は今でも可読性重視（60～55の人にわかる）が最重要だと思っています。
『各言語に合わせて、もしくは時流に合わせて変われないのであれば、それは老害でしかないと今でも思います。』
これ撤回しないですか？これは森会長に言ってください^^)。食うために一生懸命書いている人にかなり失礼だと思いますが。
還暦プログラマーより
こんだけ伸びてるのに「まず
==じゃなくて===使え」ってツッコミがないことに驚き。TSが題材なのに記事内に「ちゃんと厳密に型使えやオラァ！」ってのが無いのも驚き。
筆者の現場だとしっかりTSらしく厳密に型使ってるから不満が出ない感じなのかな。だとしたらだいぶ幸運だと思うけど。
無駄括弧は、ESLintのno-extra-parensの有効化で感性に頼らず強制ができますね。(7のyodaも同様)
ESLint強制となっている現場も多いと思いますし、機械的な修正も便利です。
https://eslint.org/docs/rules/no-extra-parens
私は長くなったら括弧をつけることも多いですが、大勢がno-extra-parensならそれに従うと思います。
確認してみたところ、TypeScriptでは基本省くのが一般的な雰囲気はありますが、TypeScript本体の中とかにも無駄括弧ありますね。airbnbやstandardなどの著名なESLintルールセットもデフォルトで無効のようです。まずは有名所にissueで提案してみてはいかがでしょうか？
https://github.com/microsoft/TypeScript/blob/c7fa6e015496c3f3f78a2d5406dd9a3fe53bc96e/src/tsserver/nodeServer.ts#L375
プログラミング初心者です。
仕事で事務業務の自動化などに使ってますが、独学で周りに聞くことができる人がいないため自己流です。
元記事に対する批判的な意見も多いですが、初心者(正確には35年前の中学生の時にBASICで遊んでました。
おじいコード
言語は時とともに変わるので、今流の書き方(ルール)が明確になっていると助かります。参考にするWebサイトやYouTubeなどにより書き方の方言が異なるため、最初はすんなり読めなかったり、読み違えることが多かったですね。プログラミング言語自体への理解が深まると、徐々にわかるようになりましたが。
変数名、無駄な省略
プログラミング始めた頃は、長い記述が逆に読みにくいと感じるため、このようにしていました。
コード全体が長くなるにつれ、今度は省略しすぎると全体が見渡せなくなり、極端に省略せずに書く様になりました。
今は、個人的なプログラムでも極端な省略は止め、後で意味が判る様に心がけてます。仮のテストでの使用に留めるべきと思います。
逆に数行程度のループや関数内でローカル変数として使用するときは、意味がわからない変数名(i,x,_)などを使う様にしています。(他で間違って再利用しない様にするため)
GoTo ※誰か教えてください。
昔、BASICやってた名残で、どうしても使いたくなる様な構成になってしまいます（笑）
今、Pytonで書いてますが、どのような構成にすれば良いのか…
長いIf文やFor、Whileを多用したり、同じような記述を何度も登場させてしまったりして、自分で見ても、カッコわっるい(非効率的、非合理的、これが「おじいコード」かと)コードになってしまいます。
なんとなく、機能ごとに関数で定義してあげて、呼び出して使えばいいんじゃないかと思ってますが、もう一歩足りないような。
たっけて〜
自分で書くときは気にするけど、コーディング規約守る以上のことは他人に期待しないほうがいいですよ
唯一指摘してもいいかなと思うのは、自分の中ですらコーディングルールが一貫してない人
途中でルールを変えられるのが一番読みにくい
「無駄な省略」に関しては、countやlengthみたいな単語は、グローバルに予約される心配が出てくるので、スコープが狭い時にあえて存在しない短い単語にしたい時もありますね。
@andrewlatimers
私も可読性を重視することが大切だと思います。
ご指摘の通り自分が正しいと思いがちな節がありますので気をつけたいと思います。
今回多くのご指摘をいただき、参考になることも多くありましたで
反省する機会にしたいと思っております。
私が社会人になったばかりの頃に会った当時、還暦近くの管理職の方が
『俺なんてじじいだけど、今でも毎日勉強してるからな。エンジニアはいくつになっても最新の
情報を取り入れていかなければいけない』
とおっしゃっていたことが、私も常に学習しなければと思う一因になっております。
私はそのような考えのもと、仕事をする上で学習をやめて変化できないことを批判している次第です。
ご指摘のほとんどは、名著『リーダブルコード』の内容とかぶりますね！
各会社の新人研修に、リーダブルコード（読みやすいコードの書き方）を取り入れてほしい！
タイトルにTypeScriptと入っていないからか、コメントで「こういうケースもある」とTypeScriptでは当てはまらないような例を提示されている方がちらほらいるようですね。
たとえば、ヨーダ記法を使わずともnullishな変数のプロパティに対するアクセスはTypeScript自体で、条件式における意図せぬ代入はESLintで防げます。
なぜ？って理由も考えと共に書いたほうがいいし、教えたほうがいいと思う。
この文章だけみると賛否両論ある内容を全否定する面倒なレビュアーって感じられそう。
コードだけ見て全社の人を老害っていうのもなんだかな、、
他人に対して「クソコード」って言ってるやつら、裏で自分も「あいつもクソコードやん」って陰口言われてるよ。
エンジニアはいつまでも謙虚に生きていこうな、ブーメラン刺さってる人多いよw
人を呪わば穴二つ
昔同じことを思ってたけど、4,5,6,8あたりはコーディング規約でNGされてたのを思い出した。
コメントについては下手に消す範囲を間違える対策もあったのかなと。バージョン管理の時代の名残でしょうね。
ヨーダ記法については場合によって使ってるなぁ。
毎日数時間の動くバッチで想定していないものが入ってきてもとりあえず
処理は継続させることを優先されるために使ってました。とにかく止めないを求められてた。
最後チェック処理で想定外に追加されたデータなどは洗い出すって感じの作業手順になってた。
1,2については若干耳が痛いところもあるなと思いました。
3が微妙なのと、指摘方法が雑すぎてどうかというのは確かだけど、このコメント欄はひど過ぎる。
ここのノウハウ実践して逆に支障が出る言語環境の割合考えれば、一般論で通していいし、このレベルだと強硬に言うのも止むなし。
賛否両論どころか大体の環境で絶対善だから、穏健派、日和見主義の類も完全に悪だね。
上の人らが初心者が増えすぎて嫌だとzennに逃げ出すわけだよ……（呆）
深夜の変なテンションの時に書いた記事にそこまで反応しなくてもいいんじ
ゃないのとは思いますけどね笑
@yuu_iさんは、自分の信じている宗教の熱狂的信者で、その教義がどれだけ
優れているか、熱く語っているに過ぎないわけで（アイドルヲタが推しについて
語っているようなものですし、他人から見れば何言ってんの？となりますわな）。
「経験豊富で知識豊富なエンジニアに対して、あらゆる言語に、自分の経験豊
富な言語の習慣をそのまま持ち込まないでほしい」
との事ですが、私だったら、なぜそのように書いたのかなど、詳しく聞いて、自
分の知見を広めるように努力しますけどね（だって面白いじゃないですか？）。
世間一般のトレンドとか関係なく、それが合理的な内容であれば、自分のやり
方に取り入れれば良いだけです。
自分と意見や考え方が異なる人々（自分の宗教しか認められない人々など）と
も強調しながらその時々の最適解を見出し、より良いものを作ろうと互いに努
力する姿勢が重要なのだと改めて思いましたね。しょうもねー記事書くなカ
ス！なんて言っちゃダメですよ。
老害プログラマーより
「３．無駄に()つけている」
演算子の優先度をいちいち暗記はしてなくて、適当に行ったらバグっていた、というのを自分で書いたり人のバグを直したりしている経験から、無駄と思われる条件比較のカッコでも、読みやすさのために残す場合が多いです。
コンマ何秒かがそれで読むのが早くなるなら書くときの労力はさほど問題にならないです。「３.」以外は納得いくものがばかりです。
「６．ハンガリアン」
@kyotoisalsosnownight さん
Joelは、古典といえるかもしれませんが、不変な良書なので無料だし、コード書く人なら全員読んでおくべきかなと思います。
TSでは型があるのでnValueとかはいらないです。
間違ったコードは間違って見えるようにする - The Joel on Software Translation Project
https://web.archive.org/web/20190723080235/http://local.joelonsoftware.com/wiki/%E9%96%93%E9%81%95%E3%81%A3%E3%81%9F%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AF%E9%96%93%E9%81%95%E3%81%A3%E3%81%A6%E8%A6%8B%E3%81%88%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%99%E3%82%8B
(Joel on Softwareより) ハンガリアン記法の本当の意味 - 本当は怖いHPC
https://freak-da.hatenablog.com/entry/20070424/p1
Joel on Software 日本語訳インデックス InternetArchive WayBackMachine | プログラミングアカデミー ゼロプラスワン
https://zero-plus-one.jp/program-general/joelonsoftware-jp-index-archive/
「８．言語として用意されている機能を使わない」
推奨パターンの例文も、関数内からいきなり関数外の_numbersを読み込んでいるので苦しいです。
参照透過をふまえて、こうすべきじゃないかなと。
「おじいコード」
たしかに、 何人ものコメントにあるように、おじいコードといって年配をどうこうはやめておいた方がいいと思います。
私も、おじい的な年齢ですが、たしかに頭の固い人もたまに同世代でみかけますが、そういう人は淘汰されていって減ってます。
基本的には若く経験が浅い(経験10年未満とか)人のほうが、コードは下手です。体力なんて関係ない業界ですから熟練者の方が出来がいいのは当たり前の話です。
実際に思い上がりが著しい若者、かつ、コードが下手くそなのに自覚のない、すごい人、幾人かに「あなた老害」的な判断されてけっこう仕事の邪魔されたことがありました。参りましたね。相手さんの方がだいぶいまいちなのは見えてましたが、なかなかご理解いただけなく。
結局のところ、今回の記事の事例で登場した下手くそなのは、若いプログラマなのですから
おじいのいうことを理解して咀嚼できなかった新人の方がわるい、ことになるような気がします。
新人を見下してください。..ww..ジョークです。
@gart_gmq さんのコメント、私も同じなのですごくよくわかります。
最近は比較的人にあわせるのも上手になったし、万人受けするコードを書きながらも
自分が効率よいと思われるスタイルを徐々に浸透させていく、
というお仕事のやり方が上手になってきたかなと思ったりです。
@jun1_pira さん
Gotoは、早期リターンで、けっこう消えると思いますよ。
リーダブルコードとか、おすすめです。
@standard-software
丁寧なコメントをいただきありがとうございます。
というところから勝手に推測させていただくのですが、
長いご経験の中でスタイルの変更も会ったと思います。
standard-softwareさんのように豊富な経験がありながらも
学習を続け、その知識を周りに広げれる方というのは私の目指すところです。
上記のような記述が一概に年配の方を批判しているように捉えられ、私が尊敬し目指している像に合致するstandard-softwareさんのような方にも不快な思いをさせてしまったことをひどく恥じます。すみませんでした。
タイトルの方も修正させていただきます。
@HydryHydraさん、@standard-softwareさんにご指摘いただきました内容を記事に反映させていただきました。ご指摘いただきありがとうございます。
括弧については
(((a == b) && c) == d)
ではないよということを明示するためにつけてますね。
cがどんな型であれ基本的に真偽値が取れてしまうC/C++ならではの慣習かもしれません。
が、C/C++以外の言語書いてても真偽値が取れるかどうかとか演算子の優先順位について言語仕様を確認するくらいなら括弧で対処してしまします。