「 いいコーディング規約、悪いコーディング規約？」2019年版 140
ストーリー by hylom
新たな言語の登場で変わったことはあるかも 部門より
新たな言語の登場で変わったことはあるかも 部門より
Anonymous Coward曰く、
2008年の記事「いいコーディング規約、悪いコーディング規約？ 」より
本格的なソフトウェア開発企業で働くとき、最初の頃にまずコーディング規則や慣習などのガイドラインに目を通したかと思う。基本的なガイドラインとして、gotoは原則使用禁止だとか、インデントにはスペースではなくタブを使用すべきであるとか、またはその逆などがあっただろう。ひょっとしたらcontinue禁止や、複数リターン値禁止など、ちょっと変わってるように思える慣習や、あまり直感的とは言えないルールといったものもあったかもしれない。
可読性を高めたり、メンテ性を向上させるには、どんな規約が有効だっただろうか？ ドキュメント上では一見良さそうに見えたが、実際はイマイチだったものなどあるだろうか？
SlashdotJ諸氏が実践してきたコーディング規約で特に有効だったのはどんなものだろうか？ 逆に規約のせいで問題が起きてしまったケースなどあるだろうか？ ほかにも、使える「自分ルール」などもあれば是非。
元々のストーリーからは十余年経過してますが、新たな「いい/悪い」は現れただろうか？
見直してよ・・・ (スコア:4, 興味深い)
②1関数は50行に収めろ
③1ファイルは200行に収めろ
②③で超えさせたい場合は理由を添えて申請しろ
※どんな言語でもこれ適用
Re:見直してよ・・・ (スコア:1)
1はlambda式とかfluent interfaceとかずらずら書く方式を使ってるとキツイね。
まあ適当に改行入れれば回避できる。それで行数が極端に増えるってことはないだろう。
2, 3は上限の数字云々よりも、「大きくなりすぎたら機能を分割できないか見直そう」っていう哲学から来てると思う。
機能を詰め込むとテストしづらくなってバグの温床となる。
Re:見直してよ・・・ (スコア:1)
関数に分けることの最大の目的は、処理に名前を付けること。
例えば、池袋から梅田に行く方法を説明するのに、
JRの○○改札を抜けと20メートルほど先に進み、右に曲がったあと7番ホームへの
階段を上り（中略）新幹線を降りたら、右手に進んで階段を降り、まっすぐ進むと
右手に京都線ホームへの階段がある喉（以下略）
みたいな説明されるより、
1. 山手線で品川まで行く。
2. 品川で東海道新幹線に乗る。
3. 新大阪で京都線に乗り換える。
4. 大阪駅で降りる。
山手線で品川まで行く方法は...
のように説明される方がわかりやすい。一回しか使わないから関数化
する必要ないなんて馬鹿はこのことを理解していない。意味のない
関数名を付ける奴も同様。
Re:見直してよ・・・ (スコア:2)
名前をつける効果より
ローカル変数のスコープを最小限にするためとか
使用する変数を最小限に絞る効果のほうが大きそう。
Re:見直してよ・・・ (スコア:1)
Cloud9＋Lambda なので「ファイル」がありません……
Re: (スコア:0)
画面が640*480時代とかcobol時代の悪い面がレガシーで残ってるような規約だね
Re: (スコア:0, 荒らし)
Re: (スコア:0)
①1行は80桁に収めろ
普段から何となく感じているのだが、これは人間が頭を使ってやる作業ではないと思うし、
80桁強制は可読性でデメリットがある(ケースがある)。
桁は制限せず、ビュー側のツールで何とかするとかが良い気がする。
整形表示モードを切り替えられるとか、マウスオーバーなりのアクションで展開表示されるとか。
Re: (スコア:0)
①②は（この規則を破る例外が許容されているならば）まあ分かるけど、
③はないわ。少なすぎ。
Re:見直してよ・・・ (スコア:2)
80はいやだなぁ
今見ると横180文字ぐらいのエディタウィンドウが横に3つ並んでもまだ画面余ってるし、
画面買えば解決できる話かなと
Re:見直してよ・・・ (スコア:2)
いつもノートだから狭いんだよと言われると仕方ない感ありますね
80桁でに横2画面ぐらいになっちゃうし
老眼についてはわかり味が深いですが、自分はメガネを画面の方にチューニングしてます
どんな時に困るかって言うとオブジェクト3段ぐらい辿る時とかですね
変数名が長く取れるのも好み
ハイビジョン見ると昔のテレビが汚く見えるようなもんで
広いのに慣れると狭いのは勘弁してもらいたくなります
テレビと同じでしばらくたてば馴れるのかもしれないけど
嘘を嘘と見抜ける人でないと(C言語を使うのは)難しい (スコア:2, 興味深い)
#define TRUE 0
#define FALSE -1
Re: (スコア:0)
それこそまさにコーディング規約が悪い． 次のように書くべきだ！
#define TRUE 0xffffffff
#define FALSE 0x00000000
Re: (スコア:0)
いきなりエンバグするバカのルールには従えねえ
Re: (スコア:0)
bool型使え、と言いたくなるな。
未だC99すら使えない環境があるのも事実だが。
Re: (スコア:0)
bool 型云々ではなく、C言語の標準関数の中に、成功時に 0 を返す関数群と、成功時に 真(非0) を返す関数群があるから、こんなことが起きるという話では？
Re:嘘を嘘と見抜ける人でないと(C言語を使うのは)難しい (スコア:2)
今のIDEなら、あんまり気にならないような気もする。
関数概要が簡単に読めるのなら、仕様自体は難しいものではないし。
昔はほとんど覚えないといけなかったからねえ。
Re:嘘を嘘と見抜ける人でないと(C言語を使うのは)難しい (スコア:1)
dotnetにSafeHandleZeroOrMinusOneIsInvalidという楽しい名前のラッパークラスがあって感心したことかあるね。
Raymond Chenに言わすと、File HandleとかはWin16の失敗時に-1を返していた動作を継承してて、Win16時代になかったThread系はNULLを返すようになってしまってワヤやわ、みたいな話だそうだが
インデントをタブだのスペースだの何文字幅だの言うのは (スコア:2)
インデントはツールの自動整形に任せとけ、って空気になりつつあるな。
エディタがリッチになったのも影響してるし、
どうせ納品物はトランスパイルして整形されちゃうし、というケースが増えているのもあるか。
Re: (スコア:0)
インデントに限らずコーディング規約みたいなものはほとんど自動整形に任せても良いぐらいまできてない？
Re:インデントをタブだのスペースだの何文字幅だの言うのは (スコア:1)
確かに。今のツールは整形レベルだけじゃなく、リファクタリングもしてくれるし。
Re: (スコア:0)
コーディング規約書というドキュメントそのものが形骸化の元凶だな
かぜ薬の説明書並になってる
悪いコーディング規約なんて存在しない (スコア:2)
悪いコーディング規約なんて存在しない
あるのは悪い現場だけだ
Re: (スコア:0)
pushしてretしてたら自殺コード書いてたヤツに文句つけられた。
こいつも大概だと思った。
COBOL (スコア:2)
EVALUATE禁止
外PERFORM禁止
ADD等禁止（COMPUTE使用）
変数はプログラム名＋連番（台帳管理）
TOはxx桁（忘れた）に揃える
長さや速度やら物理量を扱うときは (スコア:1)
変数名やら関数名に、cmとかkmとかkmphとかmpsとか単位を入れておくと
単位換算ミスを防ぐことができる
Re: (スコア:0)
本来のハンガリアン記法ですね。
Re: (スコア:0)
長さや速度やら物理量を扱うクラスを作成してそれに隠蔽する。
単位はそのオブジェクトが知っている。
Re:長さや速度やら物理量を扱うときは (スコア:1)
日本国内だけ対象にしてると恩恵があまりないけど、海外まで展開しようと思うと必須になってきますね
命名の際に英単語の省略をしない (スコア:1)
ここ10年で使えるようになった規約っていうとこれかな。ぱっと見で元の単語が推測できないような省略は基本的にしないルール。
エディタの補完がまともな速さで動くようになって、長い識別子の入力が苦じゃなくなったので。
＃ 関連ストーリー [developers.srad.jp]
Re:命名の際に英単語の省略をしない (スコア:1)
一方で、意味のない1文字変数名はラムダ式で復権しましたね。
抽象化としては意味がないことに意味があるのですが。
10年経ってもVCS導入無し (スコア:0)
・修正で追加行には必ず修正日・修正者をコメントに記載する事
・修正で削除行はコメントアウトして残し、修正日・修正者もコメントに記載する事
・修正が完了したら「project名_日付_aから始まるアルファベット」という名のディレクトリにまとめる事
30年前ならともかく、なんて21世紀にもなってこんな仕事をしてるのやら…
Re:10年経ってもVCS導入無し (スコア:1)
前職がこれでした
理由は、海外のカジノマシンのコードだったので
審査機関(GLIやNGCBなど)にビルド可能なソースコードと実行バイナリをセットで
提出する必要があり、修正箇所はコメントアウトの上で修正理由を英文で記載する
必要があったためです
＃CIOがクラウド利用とサーバ構築禁止してたせいで辞めるまでCIもGitも入らなかったのでAC
Re: (スコア:0)
単にVCSを使ってないだけならまだいいんですが、
VCS (subversion)を使っていながら、
上記のようなルールを採用してるところがあるんですよね・・・
話に聞いた限りでは、VCSの知識が皆無な非IT系上司が、
「紙に印刷したときにわからないから」と余計なルールを
追加したそうで・・・
いまさっき調べたら、その上司の方は、誰でも知ってるレベルの
IT系企業のそこそこお偉いさんになってました。
Re:10年経ってもVCS導入無し (スコア:1)
100歩譲ってVCS導入していないならわかるけど、VCS導入しているのにコレやられるとdiffがまともに取れなくなるんで害悪にしかならない。
いくら訴えても「ルールだから」で検討すらしない。
Re:10年経ってもVCS導入無し (スコア:1)
> 誰でも知ってるレベルのIT系企業
GAFAMくらいしか思いつかないが、さすがにそんなことはないだろう。
なお、
NTTデータ：誰でも知ってるは言い過ぎ
NEC・富士通：あんなん「IT企業」ではない
Re:10年経ってもVCS導入無し (スコア:1)
「誰でも知ってる」のハードルは結構高いよ。
https://news.careerconnection.jp/?p=20699 [careerconnection.jp]
ANSI C で書け!! (スコア:0)
C99 や C11 なんて認めない。
(言語指定の話なので、これをコーディング規約というかどうかは知らんが……)
/* さすがに K&R で書けと言われたことはない。 */
Re: (スコア:0)
組込の世界では珍しいことではない
ARMだとかはともかく、8bit/16bitの非力なプロセッサでは最新の規格に準拠したコンパイラが無いこともある
LinuxやWindowsでバリバリ開発やってる人が、中小企業や個人が販売してる組込プロセッサ向けのコンパイラを使ったら発狂するだろう
そういうコンパイラはプロセッサ（ハードウェア）に特化した独自の仕様拡張も多い
Re: (スコア:0)
ANSI Cも C99になってるから、ANSIだと言われても C99は使っていいはず。
いいコーディング≠収入？ (スコア:0)
コードのインデントにスペースを使う開発者はタブを使う開発者よりも高収入という調査結果 [developers.srad.jp]
一昨年のこれ思い出した。
ハンガリアン記法 (スコア:0)
やめてくださいおねがいします
Re: (スコア:0)
どうしてですか？
Re:ハンガリアン記法 (スコア:1)
Microsoft系で一時期非常に広がっていたシステムハンガリアン記法のことでは？
あれは害悪でしかないので、当然やめるべき。
Microsoftも最終的に心を改めて、非推奨にしたはず。
同じくMicrosoftで生まれたアプリケーションハンガリアン記法(こちらが元々のハンガリアン記法)の方は
有用なので、やめる必要はないですね。
システムハンガリアン記法とアプリケーションハンガリアン記法の違いについては
Joel Spolsky の間違ったコードは間違って見えるようにする [joelonsoftware.com]が詳しいです。
Re:ハンガリアン記法 (スコア:1)
アプリケーションハンガリアンにしても、本来は型システムで解決すべき問題なのでは？
そもそも今時あんまり見かけないのは同じですし。
1人の人が一度アプリケーションハンガリアンならOKと言ったからと言って、
いかなる場所でも永久にOKと言う話になっているのに違和感を感じる。
Re:ハンガリアン記法 (スコア:1)
そのためにいちいちプレフィックスを作って規約作って覚えてハンガリアン記法にしろ、と言うのは過剰ではないと言っていますか？
あと、doubleで済むってのは実際両者を試して比較した上での感想？
いやよく老害が使う論法なので念のため確認。
Re:ハンガリアン記法 (スコア:1)
元 AC ではないけど、似たようなことをやろうとして大変な思いをしたことはある。
型の追加は影響が大きいので、目的がコードのミスを目立たせたいだけなら労苦に見合わない。
パフォーマンスに与える影響も心配だし。
そのうちこれも推論で解決して廃れるんじゃないかな。
Re:ハンガリアン記法 (スコア:1)
型の追加でコードのミスを目立たせたい？
そんな話は出ていませんが。
出ている話は、
ハンガリアン記法でコードのミスを目立たせたい、
型の追加でコードのミスがエラーになるようにする、
の二つですよ。
あと、C++でやるならパフォーマンスに与える影響は０にするのが普通でしょう。
ほかの言語でもたいていはかなり最適化できるはず。
まあ心配するかどうかについては、確かに個人の自由ですが。
なお、型の追加ですべての場合について解決できるとは言ってないので誤解のないように。
でも試行錯誤は続けるべきではないかな。
元の話からの流れを再確認するならば、
ハンガリアン記法を再普及させることに対する対案なので、
それよりは現実的だと思うんですけどね。
Re:ハンガリアン記法 (スコア:1)
いや無理があるでしょ。何言ってるの?
はずとか思うとかで問題は解決しないんだよ。
Re:ハンガリアン記法 (スコア:1)
元ではないが、ハンガリアン記法使うと、変数の型が変わると変数名も変える必要がでるから、
ハンガリアン記法はオレもやめて欲しい。
これが、グローバル変数とかクラスの変数とかだったりすると、修正が多岐に渡り過ぎて嫌になる。
グローバル変数とかクラスの変数の型を変えるなら、使ってる関数も直す必要があるのは分かるが、
全ての変数名なんか変えてられんし、変数名変えたら関数の中にも影響するし。