TWO == イラッつとするコーディングスタイル

臭いものに蓋っつか、必要じゃない警告は止めてかまわんだろう。
態度のことを言うなら逆に、どういう内容の警告なのか考えず
一律に「出るからダメ」的な態度をとるほうが問題のような気が。

コンパイラオプションで止めてしまったら、
必要な箇所も必要でない箇所も一緒くたになってしまうだろ。

>>932
だから姿勢だっつーのに頭悪いな

アプリケーションの要件や適用分野を考慮して、
コーディング規約を作って、コーディング規約に従って
ワーニングオプションを設定するというのは、
そんなに間違った態度とは思えないんだが。
無関係のワーニングの中に、重要なワーニングを埋没させてまで、
すべてのワーニングを表示させることがそんなに立派な態度なのかね？

まてまて。警告を表示させる事それ自体が目的の奴はいなかろうｗ

うちはJava一本だからか、警告は全て潰せで済んでるんだけども。
スレ読む限りどうしても消せない警告があるとか、警告通りに対処するとむしろ害がある場合があるって事のようだし
なんかしら事情があるなら、ワーニングオプションと規約による対処はもちろん妥当だと思うよ

register教信者にイラッ☆

register int hoge;
register int fuga;
// ...10個くらいregisterが続く
register int piyo;
register int piyopiyo;

get(&hoge); // アドレスを取る・・だと！？

まだregisterってあったのか

>>937
っていうか、コピペで意味知らずに使ってるんじゃね？

似たようなのにinline教がある
そして邪教__attribute__

#pragma 最強

#ifndefだらけのソースを今だに書く老害がいる

普通にインデントしたら100行位になるコードを一行にずらああああっと書くクソゴミ

生クエリを1行で書きやがったか？ｗ

多重ネストさせた三項演算子とか

50行ほどの同じようなコードを数ブロックコピペしてある
よく見ると変数が一つだけ違ってる

そういうのに限ってpublic staticとか

プロパティなら許すん

クラスメンバー変数に「m_」を付けるスタイル、
最初は気持ち悪くて仕方なかったが、
今ではすっかりこれ無しじゃダメな体になちゃった・・・
人が作ったクラスにも全部付けちゃう。

きもいな
なんか利点あんの？

俺はアンダーバーは付けないタイプだなー

利点としては、ローカル変数との見分けがつくくらい？
ほかにはハンガリーなんて使わんが、メンバ変数だけには付けるな

>>950
ローカル変数や引数と名前が重ならない。
逆にローカル変数にはthe, 引数にはin/outをつけて区別するというような
風習もあるけど、それやるくらいならメンバ変数に接頭語つけた方がいいと思う。

一行120文字くらいのクソ長いコメント書くのやめて欲しい。
視線移動を考慮してないので読みにくい。

メンバ変数にtheなら昔見たことあるけど、ローカル変数に
接頭辞付けるルールってほとんど聞いたことないな。

ハンガリアンコーディングは本家MSもやめたんじゃなかったっけ？
Java ならメンバ変数は、this つければ見分けがつくから、
メンバ名自体を変える必要を感じないな。

thisつけなくても使えてしまうから区別したいわけでしょ。
まぁ、JavaならEclipseなんかで見分けてくれるけど。

スレの趣旨的には、プリフィックス云々より、
this つけないコーディングの方がイラッとくるな。

>>955
今はハンガリアン記法使うなって以外にも命名するときには略すなって言ってるな
徹底できてるのかどうかは不明だが、英語できない奴はイラッとしてそうだし、英語できないプログラマにイラッとしてる奴も居そうだｗ

booleanだけは「b」付けたいなぁ。
bSuccessみたく。

あと参照渡しで結果を期待する引数には
「ret」付けたい。retErrorとか。

>>959
いまどきのbooleanはisHoge/hasHogeだろ

わかりゃいいんじゃね？

変数名が英単語として意味をなさないものになるのがなんか抵抗がある。
論理値は「〜ble」とかでいいんじゃね？

flgHoge は何故かよく見る

furaguHogeだろ

flgOreta
flgTatta

flgEnableFlag

flgとflagが混在してるとイラっとする

「flgとflagとfuraguは用途が異なるので違う名前にしています」

boolean YuukouFlag;
boolean YuukouFlagInvalidFlag;
long YuukouFlagInvalidFlagNoYuukouKigen;
boolean YuukouFlagInvalidFlagNoYuukouKigenNoUseFlag;

変数名／関数名ネタはどうしてもuwariteと比較してしまう

>>966
これはあるあるだな

関数の中で被らないように長い名前にしてるのは分かるんだけど、ちょっとイラっつとする事はあるな。
実際 data とか名前付けて被ってておかしな動作した事はあるんだけどもｗ

それも居るな
tempとか安直な変数宣言して複数のロジックで使い回して
微妙にスコープがかぶってるところで
特定のケースでのみ値上書きするようにしちゃって
みょーな挙動させてイラッつとさせるコード書くヤツ

英単語2〜3つ続ければ大体かぶらない

FirstTemporaryData
SecondTemporaryData
ThirdTemporaryData

dataだのtmpだの安直な奴はメソッドの中で定義していても多様されるとイラッつとするレベル
逆に広域定数かつ使用頻度の高い変数名がやたら長いのもイラッつとする
例えば整数を直接書くなというコーディング規約が生み出すConst hogehoge_zero = 0;やらConst hogehoge_one = 1;の事
最近は見てないけど、整数を直接書くなっていうのはマジ簡便だわ、どうせそこら中にif(foo != PublicData.hogehoge_zero) { return bar; }だの何だのがはびこって結局保守性変わらない
整数とか使用頻度高すぎだから、結局一箇所一箇所hogehoge_oneとかで書き直さなきゃいけないの目に見えてるから

oneとかzeroとかいう名前にする意味が分からない
どうして列挙型を使わないのか

×
Const hogehoge_zero = 0;
Const hogehoge_one = 1;
○
Const SUCCESS = 0;
Const ERROR_HOGEHOGE = 1;

zeroだのoneだのの意味が無い名前はダメ

>>97
const int kErrWrite = -2;
const int kErrOpen = -1;
const int kOk = 1;

数値の0を表すconst変数をzeroにしたことはあるな。

>>977
「定数は必ず別に定義する事」
みたいなルールがあるとたまに見かけるなｗ

#define KANRI78493_00
#define KANRI78493_6464
#define KANRI78493_256256

char temp[KANRI78493_256];

助けて・・！