07/05/21 10:20:53
>>174
自動車をなくせば交通事故は無くなるんじゃない?
176:デフォルトの名無しさん
07/05/21 10:25:26
>>175
いいえ、自動車以外の交通事故は残ります。
→ケース問題を除く宗教戦争は残ります。
177:デフォルトの名無しさん
07/05/21 13:07:30
BASICって確か大文字小文字区別しないけど、
あの言語ってケース問題に関する宗教戦争ってないのか?
178:デフォルトの名無しさん
07/05/21 13:33:11
8bit時代のBASICならいざしらず、VisualBaiscとか今時のBASIC使ってるヤツで
「大文字小文字同一視だぜ」とか言ってるやつはみたことないな。
普通に大文字小文字区別して「どう書こう?」ってやってる。
179:デフォルトの名無しさん
07/05/21 13:51:21
Delphiが「大文字小文字同一視だぜ」なんだけど、
書籍やIT系サイトのチュートリアルっぽいコードで、たまに無茶苦茶なのを見かける。
一般向けに晒すコードなら、プロパティ名とかメソッド名はオンラインヘルプに記述されているとおりに書け。
# Delphiのヘルプは酷いから、そもそもオンラインヘルプで記述が統一されていないってのもあるが。
180:デフォルトの名無しさん
07/05/21 14:43:03
MSDN見習わせたらエラー処理はしないしファイル番号は固定だし……
ってのは兎も角。
>>178
VisualBasicは大文字小文字を区別できるんですか?
例えばdim aa as integer, AA as integer, Aa as integerみたいに?
私ゃ保存はされるけど区別はできないと思っていたのだが。
181:178
07/05/21 15:01:39
>>180
いや、区別しない。
>>178で言いたかったのは
「区別されないからAbcDefメソッドをABCDEFで呼ぶぜ」なんてやつはおらず、
VBでも「『AbcDef』がいいか『abcDef』がいいか(大文字小文字を意識して)どう書こう?」って
やってる、ってこと。
書き方悪かったかも。ごめん。
182:デフォルトの名無しさん
07/05/22 15:38:32
でも自動車を無くせば自動車事故は起きなくなるね
#こういう考え方はいかん
#エロサイトを封じれば性犯罪が減ると思ってやがる
183:デフォルトの名無しさん
07/05/22 19:08:06
>>182
コメントへの野暮なレスですまんが、
もとの「自動車を無くせば自動車事故は起きなくなる」に対応する
のは「エロサイトをなくせばエロサイトへの接続が無くなる」では。
# 縦読みを仕込みたかったが出来なかった。
184:デフォルトの名無しさん
07/05/22 20:21:39
エロサイトを封じたら、性犯罪は増えるんじゃないの?
185:デフォルトの名無しさん
07/05/23 00:14:54
>>183
エロサイトを封じればエロサイトの広告、迷惑メールなどが減る。
→でもその他の広告などは残る。
186:175
07/05/23 01:40:16
大文字小文字の区別をつけるか否かは、言語設計者が決めることだから、
その言語を使用する側が制御できることではないし、どうこう言うべきことでもない
と言いたかったのですが。
187:デフォルトの名無しさん
07/05/23 05:03:55
最近はCOMとか.NETとかスクリプティングとか言語設計者の都合だけでは
決められない要素も出てきた
188:デフォルトの名無しさん
07/05/23 06:51:31
COMは最近ではないと思うけど、まあそうだね。
189:デフォルトの名無しさん
07/05/23 13:52:32
機械語
190:デフォルトの名無しさん
07/05/30 08:01:29
そういえばスペースだけでコーディングする言語あったよね
あれなら宗教戦争はなくなる
191:デフォルトの名無しさん
07/05/30 08:23:20
ホワイトスペルマだっけ?
192:デフォルトの名無しさん
07/06/02 00:19:25
しばらく開発から離れた仕事をしていたうちにハンガリアンはあまり使われなくなったみたいですが、どういった理由でですか?
カーソルをあわせれば型が出るからですか?
自分はカーソルあわせるのが面倒なのでハンガリアンで書いてますが・・・
193:デフォルトの名無しさん
07/06/02 00:25:52
>>192
templateをゴリゴリつかったプログラミングなんかが流行ったこととかが関係してると思う。
ハンガリアンだと型を変えたときに名前まで変えなきゃならんしね。
↑これは型に対するハンガリアンのことであって、意味に対するハンガリアンは
いまでもそこそこ使われてると思うけど。
194:デフォルトの名無しさん
07/06/02 00:41:42
変数のスコープがやたらでかくなってないか、
関数でかすぎるせいでそうなってないか、
一回見直したほうが良い。
195:デフォルトの名無しさん
07/06/03 21:19:31
悪しきシステムハンガリアンが消えて
本来のアプリケーションハンガリアンを用いる人が増えただけ
196:デフォルトの名無しさん
07/06/20 05:09:57
ハンガリーってどこらへん?
197:デフォルトの名無しさん
07/06/20 11:45:17
X系はdoSomething、GNU系はdo_something
ディストリをメンテしているオレの戦いは今日もつづく
198:デフォルトの名無しさん
07/06/20 16:30:30
>>196
URLリンク(www.namamono.com) (02年3月上旬)
199:デフォルトの名無しさん
07/06/20 16:37:28
無駄に探す労力を割かす上につまんねぇ…
なんという糞レス…
200:デフォルトの名無しさん
07/06/21 20:07:08
>>199
おーrrらー
201:デフォルトの名無しさん
07/06/28 01:08:52
今までこう書いてたけど
変数 => 全部小文字/アンスコ
メソッド => 先頭大文字/キャメル
クラス => 先頭大文字/キャメル
定数 => 全部大文字/アンスコ
>>163さんと同じにした方がみやすいんじゃん
っておもた
でも先頭が小文字のキャメルは不自然に感じてしまう
202:デフォルトの名無しさん
07/06/28 01:33:07
C#だけど結局
プライベートフィールド・ローカル変数 :ローワーキャメル
名前空間・クラス・関数・プロパティ・定数 :アッパーキャメル
に落ち着いた。
フィールドにアクセスするときは必ずthis付けるようにしてるから
ローカル変数と混同することはないはず。
今MSDNのガイドライン読んだらプライベートメンバの
名前付けに関してはなんでもいいみたいだな。
203:デフォルトの名無しさん
07/06/28 23:17:56
>>202
構造体・クラス・列挙体にはリーディングタグつけないやっぱり?
C#だとやってる人ほとんどいないなどういうわけか。
enumはともかく、クラスと構造体の違いは勘違いしてると致命的になる場合が
あるから、つけた方がぜったいコード読みやすいと俺は思うんだけど。
204:デフォルトの名無しさん
07/06/29 00:11:27
MS的にNGな気がする。
205:デフォルトの名無しさん
07/06/29 01:18:09
>>163氏の命名法で
変換テーブル的に使う変数(例えば数値→文字へに使うようなmap型の変数)や
関数オブジェクトのインスタンスなら関数と同じような命名法である
>先頭小文字/キャメル
を適用したいのです
こういう類の変数で初期化時に設定してあとは殆ど変更しなかったり、
初期化部分以外での扱い方が関数的(mapの例だとmap[x]でxに対応する値の取得に使われる)たりで
メソッドとみなしてメソッドに対する命名法を適用しても問題ない気がするんですがどうでしょう?
それでも変数である以上変数に対するルールを出来る限り使用するべきでしょうか?
206:デフォルトの名無しさん
07/06/29 10:02:57
>>203
C# は結局、VS のインテリセンスに頼ること前提だから、
クラスと構造体の勘違いは気にしなくてもいいのかも。
207:デフォルトの名無しさん
07/06/29 12:44:20
P/Invoke以外で構造体作ったこと無いなー。
208:デフォルトの名無しさん
07/07/01 18:08:36
>201
Javaだと先頭小文字のキャメルってよく使うよ。
何せ標準ライブラリがそうなってるからな。
M$は先頭大文字キャメルLoveみたいだが。
209:デフォルトの名無しさん
07/07/01 20:11:36
.NETは、
名前空間名、型名、パブリックメンバ名はPascalCase、
関数の引数名はcamelCase
210:デフォルトの名無しさん
07/07/16 02:29:48
正直Camelで区別するのって、ハンガリアンと同じモノを感じるのは漏れだけですか。
211:デフォルトの名無しさん
07/07/16 03:07:50
ハンガリアンはハンガリアンでもアプリケーションハンガリアンは全然おkだよ
getXXXとかのgetのようなものも役目としてはこれに近いから同じように感じるのも無理はない
212:デフォルトの名無しさん
07/08/16 16:52:56
C#でLogというクラスを作ったわけですよ。で、ログの種別を
区別するための列挙型をLog.Typeと命名したんですね。
.NETのライブラリでもアッパーキャメル規約になってるっぽいですから。
で、メンバ変数としてType Log.typeを定義したのです。ここまでは
分かりますね。さらにLog.typeを外部から直にアクセスして欲しくないので
typeにアクセスするプロパティを定義すると。MS式の記法だと、やっぱり
Log.Typeが妥当かな?
型 'Log' は 'Type' の定義を既に含んでいます。
213:デフォルトの名無しさん
07/08/17 01:04:30
>>212
キャメル云々はそれでよいと思う。
名前が重複する件は、列挙型はTypeでよくて、プロパティの方は「○○のためのType」という
○○の部分をうまく補ってあげればいいんじゃないかな。
214:212
07/08/17 03:18:25
「○○のためのType」がこの場合、本当に「ログのためのType」としか
表現のしようがないのが辛いです。
列挙型はLog.Typeで、プロパティはLog.LogType…うーむ。
余談ですが、列挙型の識別子を“TYPE”と全部大文字表記
(長い場合はアンダースコア区切り)にすることも考えました。
しかしその方法でも内部クラスとかの命名になるとお手上げ…。
215:デフォルトの名無しさん
07/08/18 00:09:00
TypeIdとかTypeNoとか。
216:デフォルトの名無しさん
07/08/24 04:14:41
C++だけど、こんな感じで関数名と変数名がバッティングするときどうします?
class Ore {
public:
bool isNeet() const { return isNeet; }
// if (ore.isNeet()) { ... } とか呼びたい
private:
bool isNeet;
};
1. こういうの嫌だから関数を大文字で始めてるYO(isNeet()をIsNeet()に)
2. こういうの嫌だから変数にプリフィックスなどをつけてるYO(isNeetをm_isNeetやisNeet_に)
3. 変数名を変えちゃうYO(isNeetをneetとか……形容詞ならともかく名詞だと変な気が。
なんかもっといいネーミングとかありますかね)
なんかJavaだと↓で普通に通っちゃうんだけど。理屈はわかりませんが。
class Ore {
public boolean isNeet() { return isNeet; }
private boolean isNeet;
}
関数名が小文字で始まるほうがコードが柔和な気がするのでC++でもそうしたいんですが、
(メイヤーズ先生も小文字で始めてるし)
どうもここがちょっと引っかかって。
217:デフォルトの名無しさん
07/08/24 04:29:23
>>216
isNeet = false とかがキモイのもあって、 neetFlag とかにしちゃうかな。
m_neet もアリだな。
218:デフォルトの名無しさん
07/08/24 10:53:28
>>216
メソッド名を大事にしたいならフィールド名にちょっと引込んでもらうしかないのでは。
自分ならサフィックスにアンダーバーつける。
>>217
「isNeetを内部で保持するのはneetFlag」みたいなのって、頭使うの面倒じゃない?
まれにはそういう置きかえがピッタリいくこともあるけど、ほとんどの場合は
機械的に「プレフィックスつけてるっすー」とかの方が、余計なことに気を回す必要がなくて楽だと思う。
219:デフォルトの名無しさん
07/08/25 00:44:34
_*
m_*
がいいよ。
メンバ変数を他の変数と区別できるようにするのは、
CodeCompleteでも薦められてるようなよくやるパターンです
220:デフォルトの名無しさん
07/08/25 01:21:18
メンバ変数はname_にしてる。
221:デフォルトの名無しさん
07/08/25 01:27:52
>219
_FollowedByUppercaseLetterはコンパイラ&ライブラリ実装者用の予約語なので、
_nameも避けといた方が無難。
#double__underscoreもね
222:デフォルトの名無しさん
07/08/25 01:32:37
前にアンダーバー置くのはイクナイね。
223:デフォルトの名無しさん
07/08/25 01:35:48
某所で、初心者にえらそうに教えてるやつが、Cなのに構造体のメンバにm_をつけてた。
意味をわかってつけてるのか。
224:デフォルトの名無しさん
07/08/25 03:11:13
>>219
_name をつけるほど自信家じゃない
grepしたときやたらと似たようなのが引っかかりそうだし
それにエディタの行位置表示を下線にしてあるから、見えなくなる
225:デフォルトの名無しさん
07/08/25 03:16:23
>それにエディタの行位置表示を下線にしてあるから、見えなくなる
これが理由なら、阿呆だ。
226:デフォルトの名無しさん
07/08/25 06:17:51
>>223
member の m なら C の構造体でも間違いではないだろ。
227:デフォルトの名無しさん
07/08/25 09:51:01
>>221
たぶんそれ、グローバルな名前がそうなだけ
228:デフォルトの名無しさん
07/08/25 09:53:05
予約識別子だから、マクロ名を含めて、ソースコード中に出現してはならんよ。
229:227
07/08/25 11:29:28
すまん>>221は、_の後に大文字が来るのが最もマズいって言ってんのか
230:デフォルトの名無しさん
07/08/25 13:13:08
外からしか扱わないメンバに m_ とかつける必要は無いだろ。
struct Point { int m_x; int m_y };
Point p0 = { 0, 0 };
Point p1;
p1.m_x = p0.m_x + 1;
とか無意味。
scope の間違えようがない。
231:デフォルトの名無しさん
07/08/25 22:37:30
class Hoge {
private:
struct {
int x;
int y;
} m;
}
232:227
07/08/26 00:16:02
>>231
やめなさいw
233:デフォルトの名無しさん
07/08/26 01:06:27
>>231
とてもアリな気が今した!
234:デフォルトの名無しさん
07/08/26 20:47:53
>231
コレ継承先から継承元の変数見るのが面倒では…
あー、もしや変数は全部privateにしろって事?
235:デフォルトの名無しさん
07/08/26 21:13:48
>>234
>あー、もしや変数は全部privateにしろって事?
当たり前じゃん。
236:デフォルトの名無しさん
07/08/27 00:31:17
>>234
structなしでint m_x;とか書いたのに比べて、なにか不便になることってあるの?
237:デフォルトの名無しさん
07/08/27 00:41:08
2~3行増える。
素直にint x_, y_;にしとけばタイプ量も減る。
238:デフォルトの名無しさん
07/08/27 01:24:03
231のmをポインタにした感じのコードなら書いたことある。
例外にも強いしコピー・交換も楽で速いしなんて思っていたら、
どうみても劣化pimplです、本当にありがとうございましたというオチ。
239:デフォルトの名無しさん
07/08/31 23:34:42
>>237
タイプ量だけ?
>>234 の継承とかなんとかは関係ないの?
240:デフォルトの名無しさん
07/09/01 22:41:02
>>237
メンバ数が多いと、逆にタイプ数は減らないか?w
241:デフォルトの名無しさん
07/09/04 00:15:46
アフォな質問ですまん。
>231の例でx,yの初期化ってどうやって書けば良い?
242:デフォルトの名無しさん
07/09/04 00:38:14
>>241
普通にコンストラクタの初期化部で書けばよろしいかと。
243:241
07/09/05 00:12:31
>242
サンプルコードを書いて貰えませんか?
少なくとも漏れの知ってる書き方をみる限りでは、
>231の方法はやっぱダメだとしか思えませぬ。
244:デフォルトの名無しさん
07/09/05 00:47:14
structが無名だから初期化できないね。ま、コンストラクタで代入するってことで。
--
class Hoge {
struct {
int x;
int y;
} m;
public:
Hoge() {m.x = 0; m.y = 0;}
Hoge(int x, int y) {m.x = x; m.y = y;}
};
245:デフォルトの名無しさん
07/09/06 00:18:43
x,yがconstか参照で、かつコンストラクタの引数経由で
外部から初期値渡したい場合は?
それ考えると>231はやっぱ使い物にならん。
246:デフォルトの名無しさん
07/09/06 00:54:42
struct に名前を付けてコンストラクタ書けばいいだけの話じゃないの?
247:デフォルトの名無しさん
07/09/06 01:14:03
最早>231はどうでもいいがw
>x,yがconstか参照で、かつコンストラクタの引数経由で
>外部から初期値渡したい場合は?
条件後出ししていいなら、構造体に名前つけさせてくれ。
248:デフォルトの名無しさん
07/09/06 20:24:05
>246,247
structに名前付けるのはいいけど、
通常1回書けばすむはずの処理を、2回書かなきゃダメだよね?
そうじゃないスマートな書き方を知っているなら是非ご教授を。
249:デフォルトの名無しさん
07/09/07 13:03:53
>>248
2回って、何で? Hoge は InnerHoge に丸投げするだけでしょ。
250:デフォルトの名無しさん
07/09/08 00:21:38
>>249
Hogeのコンストラクタとその内部構造体のコンストラクタで
2回初期化を書かなければいけない(そしてそれがスマートでない)
と248は言っているのだろう。
251:デフォルトの名無しさん
07/09/18 16:57:12
あーの、Windowsでアンダースコア区切りの命名規則を採用している方に質問なのですが、
皆さんはWinMainの引数とかAPIのコールバック関数にもアンダースコア区切りで命名しますか?
それともWinAPIに関連する変数は例外的にハンガリアン+CamelCaseで命名しますか?
当方、先週Windows畑に飛ばされたばかりのへっぽこPGなんですが、
どうにも気になって気になって。。。
252:デフォルトの名無しさん
07/09/20 02:06:24
Gtk+なんかだとAPIそのもの以外は徹底的にアンダースコア区切りで命名してるな
253:1/2
07/10/05 00:49:37
なんか、コーディング規約で this を返すのは駄目っていうのをどっかで読んだんだけど
こういうのはどうなの?
(サンプルソースの意図は、oldTest() の if 文を無くして test() のようにシンプルにすること)
public class Test {
private static void oldTest(String[] params){
for (int i = 0; i < params.length; i ++) {
if (0 < i) {
System.out.print("," + params[i]);
}
else {
System.out.print(params[i]);
}
}
}
private static void test(String[] params){
Printer printer = FirstPrinter.instance;
for (String param : params) {
printer.print(param);
printer = printer.nextPrinter();
}
}
public static void main(String[] argv){
test(argv);
}
}
254:2/2
07/10/05 00:50:41
abstract class Printer {
abstract void print(String param);
abstract Printer nextPrinter();
}
class FirstPrinter extends Printer {
static final FirstPrinter instance = new FirstPrinter();
void print(String param){
System.out.print(param);
}
Printer nextPrinter(){
return SecondPrinter.instance;
}
}
class SecondPrinter extends Printer {
static final SecondPrinter instance = new SecondPrinter();
void print(String param){
System.out.print("," + param);
}
Printer nextPrinter(){
return this;
}
}
255:デフォルトの名無しさん
07/10/05 00:58:07
>>253
コード読んでないけど、駄目って言う理由がないんならどうでもいいんじゃね?
256:デフォルトの名無しさん
07/10/05 01:31:13
メソッドチェーンするのに便利だしthisを返しておいた方がいいと思ったんだけど、
駄目って言う理由はなんなんだろう。
257:デフォルトの名無しさん
07/10/05 01:58:23
>>256
ちょっとよくわからないで言うけど
this を返してもらった奴がこれを使うときにthisの実体がなくなっちゃてたりするケースってない?
258:デフォルトの名無しさん
07/10/05 03:18:25
>>257
だって呼び出している側がインスタンス保持しているのに、
なくなっているってことが通常ある?
259:デフォルトの名無しさん
07/10/05 03:53:45
>>257
コード見る限り Java だから、それはありえない。
260:デフォルトの名無しさん
07/10/05 05:18:48
入出力関係のオブジェクトだと閉じてる可能性はあるね。
261:デフォルトの名無しさん
07/10/05 15:25:15
まじわからないで言う、ごめん
インスタンスを持っているならthisを返す意味はある?
汎化という目的で独立性を高めるために他の処理でこれを使うことを考慮したら
インスタンスが失われることを考えてthisを返してはいけないとか
262:デフォルトの名無しさん
07/10/05 15:26:27
if を使ってる処理のほうが、「何をしているか」がよくわかる
263:デフォルトの名無しさん
07/10/05 19:00:26
>>261
instance.foo().bar().baz()
とかやりたいってことない? これを指してメソッドチェーンといったんだけど。
264:デフォルトの名無しさん
07/10/05 20:10:40
operator overloading なんかだと this を返さないと成り立たないけどねw
まあ、java にはないから関係ないけど
265:デフォルトの名無しさん
07/10/09 15:59:59
副作用がある場合はthisを返さないってポリシーはあるな。
266:デフォルトの名無しさん
07/10/09 20:15:56
>>253
シンプルどころか複雑怪奇になってる。
さらにメモリ使用量も増えてるし、速度も遅くなっていそう。
そして、return this;よりはreturn SecondPrinter.instance;の方がいいだろう。
最悪なのは、親クラスのクラス変数を子クラスで隠蔽しているところだな。
267:デフォルトの名無しさん
07/10/09 20:35:42
個人的に思ったのは、
「this を返すAPI を作るな」っていうコーディング規約は、
「メソッドチェーンを前提にした API を作るな」っていうのが本来の意図であって、
そうでなければオーケーなんじゃないかと。
>>266
今回はサンプルがはじめからシンプルだったために、結果的に複雑怪奇になってしまったわけで、
実際にはトレードオフで適用すればいいのだと思います。
>最悪なのは、親クラスのクラス変数を子クラスで隠蔽しているところだな。
親クラスで定義しているのは抽象メソッドだけで (つまり実質的にインタフェースといえる)、
クラス変数は存在しないはずなのですが・・・
>return this;よりはreturn SecondPrinter.instance;の方がいいだろう。
あー。確かに。言われてみれば。
ただ、今回は Printer をシングルトンで実装できたけど、
例えば任意のセパレータの文字を指定して CSV ファイルを構築できるように
Printer を改造したような場合は、各インスタンスが状態を持つようになるので
this を返すような実装になると思う。
まあ、この場合でも Printer をイミュータブルになるように設計して
Flyweight の getter メソッドを活用して this を返さないような仕組みにすることは出来るけど
そこまでやると冗長になる気がする。
268:デフォルトの名無しさん
07/10/23 19:22:00
保守代わりに転載。
C++0x 2
スレリンク(tech板:172番)
269:デフォルトの名無しさん
07/12/15 02:35:34
private:
bool isHoge_;
だけでなく、
private:
void doHoge_();
とか、
template<class Hoge_>
のように準ローカルな名前全てにアンダーバーを付けたくてウズウズしてしまうのですが、
そのようなコーディング規約が見付かりません。
常識的にあまり推奨されないのでしょうか?
270:デフォルトの名無しさん
07/12/15 02:39:55
>>269
どうして?
271:デフォルトの名無しさん
07/12/15 03:03:06
>>270
発端は、templateのタイプ名が外部の通常のクラス名と衝突してしまったため、
冗長にせざるを得ない場面があったからです。
ならばメンバ変数に習い、「末尾にアンダーバー」イコール「スコープ限定」にしてしまえば、
衝突も避けられるし、読む時にも迷子になり難いのではないかな・・・と。
272:デフォルトの名無しさん
07/12/15 03:44:57
>>271
そんな局所的な理由で規約になるわけないんじゃないの?
273:デフォルトの名無しさん
07/12/15 04:41:14
後ろにアンダーバーなんて始めて見たな。
前ならそうしてる人結構いるよ。
274:デフォルトの名無しさん
07/12/15 04:59:49
前につけるとすぐ予約名になるまたは予約名とまぎらわしいから、やめといたほうがいい。
275:デフォルトの名無しさん
07/12/15 07:12:05
>>271
つまりボキャブラリが貧弱なのを _ でごまかそうということですね
英語の辞書を買ったらどうでしょう
冗長といっても、いくら長くてもいいと思う
あとで別の人間が解析するときに、
grepをかけたら似た様なのがゾロゾロって
猛烈に格好悪い
276:227
07/12/15 07:45:38
>>274
これっていつから言われてるの?
昔は_ 前だったのに・・・
>>271
それってローカル側優先で処理されるよね?
TXxxx
とかにするってのもどうかね
277:デフォルトの名無しさん
07/12/15 09:53:59
>>276
> これっていつから言われてるの?
「言われてる」ってのが何のことかわからないけど、予約名の規定自体は
知ってる範囲では ISO C++98, C99 とかで決められてる。たぶんそれより前の
C89 からそんなに変わってないと思うから、少なくとも 10 年以上前から使っちゃ
マズイってことにはなってたはず。
278:デフォルトの名無しさん
07/12/15 10:26:40
>>276
MS-DOS の初期のころから内部の実装で使われていた気がする
279:デフォルトの名無しさん
07/12/15 11:02:48
>>273
オレは何度も見たことあるよ。
280:デフォルトの名無しさん
07/12/15 12:33:25
>>279
確かに、C の関数の場合は後ろに _ をつけると()と離れて絵的に悪くないかも知れないけど
いまひとつ _ を前後に使う意味がわからないな
_ があることでなにかを示すようには見えないな
もっと、適切な方法があるならそれを選んだほうがいいように思う
見てわかるような名称にするように文になっていたっていいと思う
昔の関数名なんか変なのあるよな
creat() なんて何を考えてるんだかw
'e' 一文字を省く理由がわからない
281:227
07/12/15 12:39:05
>>277-278
ごめ。
_ は前に普通に付ける時代があったんだけど(本とかで載っていた)
最近後ろに付ける勢力が急拡大している感じ。
いつからだろうと。
282:デフォルトの名無しさん
07/12/15 12:49:04
>>281
前につけることの問題を知らずに本を書いちゃうようなアホが淘汰されたんだろう。
いつからってこともないと思うぜ。
283:デフォルトの名無しさん
07/12/15 12:57:38
>271
利点、欠点を考えて判断すりゃいいんじゃない?
利点:ローカルスコープの関数・変数が一目でわかる
欠点:メンバー変数とメンバー関数のバッティングが発生する可能性がある(C++の場合)
-->別の命名規則で回避する必要あり
ぐらいかね?
ローカルスコープなんだし好きにすれば?という気もするけど。
284:デフォルトの名無しさん
07/12/15 13:28:58
>>282
_ 前に付けて問題になったことなど一度たりともないけどな。
メンバ変数なんてローカルだし。
__descspecとかのキーワードなんて __ だしな
285:デフォルトの名無しさん
07/12/15 13:56:19
>>280
creat()については名付け親がそうつけてしまったことを深く恥じているのだから、
もうそっとしておいてあげたらどうだw
286:デフォルトの名無しさん
07/12/15 15:40:04
釣りか本気か微妙な流れだw
287:デフォルトの名無しさん
07/12/15 23:55:12
>>284
__declspecはむしろ正しい使い方。
処理系予約の識別子なのだから。
288:デフォルトの名無しさん
07/12/16 00:04:35
>>287
?
いや、その通りだけど、>>284の趣旨は、「そういうのは"__"だから、"_"を前につけても問題が起こったことはない」でしょ。
289:デフォルトの名無しさん
07/12/16 01:34:46
ナイシフォロー
290:デフォルトの名無しさん
07/12/16 01:42:20
>>280
歴史的なもの
識別子に5文字しか使えなかったシステムで付けられた名前を引きずってるだけ
291:デフォルトの名無しさん
07/12/16 02:50:52
>>284
一度もないのは分かるけど、
規格で「予約」と明記されているものをあえて使う理由が分からん。
ローカル名については「マナー」程度なのかな?
他の言語だと「予約」だったりするんだろうか。
292:デフォルトの名無しさん
07/12/16 07:00:04
2重の__ は予約かも知れないが、
グローバルの_ はstdio.hとかのライブラリと被るので
~~~~~~~~~~~~~~~
注意ってことじゃなかったかって気がするんだが。
手元に資料がないから確認は取ってないが
293:デフォルトの名無しさん
07/12/16 07:04:09
あ、一つ思い出した。
そういやBUFSIZ ってシンボル使えないよなw
294:デフォルトの名無しさん
07/12/16 11:04:04
>>292
どっちも「予約」だよ。識別子の利用範囲が違うだけ。区別するのがメンドイから
自分とこで作るルールに書くときは一括でダメってことにするのが簡単。
295:デフォルトの名無しさん
07/12/16 11:26:03
URLリンク(www.alles.or.jp)
ちょっと見つけた
296:デフォルトの名無しさん
07/12/16 13:52:19
>>295
うーーー。意味わかんない;
ごめんオレ馬鹿すぎ。エロイ人教えて。
297:296
07/12/16 13:58:19
あ、泣くほど読んだらわかった;
298:デフォルトの名無しさん
07/12/16 13:59:11
>>296
>281-282 にある
> _ は前に普通に付ける時代があった
> 前につけることの問題を知らずに本を書いちゃうようなアホ
の例じゃね?
299:デフォルトの名無しさん
07/12/16 15:05:06
まぁ明日ARMでも読んでみるわ。
メンバ変数名は、
グローバルなネームスペースを汚してるわけじゃないしね
300:デフォルトの名無しさん
07/12/17 02:42:38
っ >168
301:デフォルトの名無しさん
07/12/17 02:50:17
なぜ予約語とぶつかる可能性のあることをしようとするのか
いまひとつわからない
たしかに、かっこいいかもしれないけど
_や__が予約語に多いのだから、他人が見たら、
これらは予約語としてみられる可能性があるということでしょ?
できるだけ、必然的であるべきだと思うのだけど
でないと後で見てわからない気がするんだけどな
名称を考えるのがめんどくさいだけに思えるのは、オレが世間知らずだから?
302:デフォルトの名無しさん
07/12/17 02:54:48
C/C++ の入門書や入門サイトがそういうインクルードガードを書いてたり。
そういうのを見て覚えた奴が自己弁護のために抵抗してるだけ。目的なんか無い。
303:デフォルトの名無しさん
07/12/17 08:01:37
_で始まる予約語に何があるか言ってみろよ
304:デフォルトの名無しさん
07/12/17 08:05:56
>>300
やっぱ答え出てるじゃないか。
メンバ変数はグローバルじゃねえ。
関数名とグローバル変数に問題があるだけだろうな
305:デフォルトの名無しさん
07/12/17 11:48:40
>>301,303 予約語じゃなくて、予約識別子ね。
306:デフォルトの名無しさん
07/12/17 15:58:27
>>303
_STDLIB_H_
307:デフォルトの名無しさん
07/12/18 00:11:07
>>305
それならわかるわ
検索してみたら、いいページ掛かったわ
308:デフォルトの名無しさん
07/12/18 06:32:30
結局 _ をつけたがるのは
自分の作ったのを予約語扱いしてもらいたい 「格好つけしー」 か
考えるのが面倒で、 _ でもつけとけの 「横着者」 のどっちか
でいいの?
309:デフォルトの名無しさん
07/12/18 08:17:39
>>308
_ のあとの小文字は問題ねーってよ
310:デフォルトの名無しさん
07/12/18 08:33:41
>>309
昔のDOS系、MSのLIBなんかは _ の関数だらけ
これを予約語といえるかわからんが
それと同列のものにしたいということだろ?
311:デフォルトの名無しさん
07/12/18 11:31:02
>>309
何が問題ねーの?予約識別子じゃないの?
312:デフォルトの名無しさん
07/12/18 11:46:38
_ のあと小文字は、グローバルスコープ(ファイルスコープ)のみで予約。以下 >294
313:デフォルトの名無しさん
07/12/18 12:17:43
>>168の短い文章を理解するのに一体何レス費やせば気が済むんだ?
314:デフォルトの名無しさん
07/12/18 12:21:59
「ある目的のために」とか、わかりにくい誤訳が入ってたからじゃね?
315:デフォルトの名無しさん
07/12/18 22:50:44
グローバルな名前空間でとわざわざ限定してくれてるからじゃん
316:デフォルトの名無しさん
07/12/19 05:46:36
「感染してますが、コンドームをつけてれば大丈夫です」と言われてもやる気はしないのと同じ
例えが、ちがうか;
317:デフォルトの名無しさん
07/12/23 23:54:01
( ゚д゚ )
¶ノ ¶ノ |
/ ̄ ̄ ̄ ̄ ̄\
./ (,) (,) ヽ
| | ̄| |
ヽ  ̄ ̄ /
| | | | |
.ノ .ノ ヽ ノ .ノ .|
(_ノ (_ノ .|
/ /  ̄/ /
< < .< <
ヽ ヽ ヽ ヽ
318:デフォルトの名無しさん
07/12/25 07:53:47
あ、そうそう そうすると
#ifndef _FILENAME_H
#define _FILENAME_H
はどんなシンボル名にしてんの?
#define H_FILENAME_H
とか?( ゚д゚)
319:デフォルトの名無しさん
07/12/25 10:30:28
FILENAME_HでもMACRO_OF_FILENAME_Hでもお好きなものをどうぞ。
320:デフォルトの名無しさん
07/12/26 04:02:28
MACRO_OF_*は却下
321:デフォルトの名無しさん
07/12/26 04:09:12
#pragma onceでいいよもう
322:デフォルトの名無しさん
07/12/26 04:10:30
せっかくポータブルな方法があるのに、
そうじゃない手段をわざわざ使うのは気が引けるよ
323:デフォルトの名無しさん
07/12/29 11:30:30
規律正しいおまいらなら
#ifndef
の使用はもうやめたんだろ?
324:デフォルトの名無しさん
07/12/29 13:41:22
両方使うのは意味があるのかな?
325:デフォルトの名無しさん
07/12/30 00:07:39
>>323
なんで ifndef はいけないと思うの?
326:デフォルトの名無しさん
08/02/19 01:14:20
皆さんのスタイルを、GNU indentの引数で表現するってのはどうでしょか。
俺は単純に
indent -kr hoge.c
です。
327:デフォルトの名無しさん
08/02/19 14:45:58
>>325
名前がぶつかるかも知れない恐怖が
328:デフォルトの名無しさん
08/03/16 18:09:35
ソースのフルパスをマクロ名に入れとけば無問題w
329:デフォルトの名無しさん
08/04/13 15:16:47
そんなにぶつかるのが怖いなら、GUIDでいいんじゃないか?インクルードガードなんか入力することなんかないんだからさ。
330:デフォルトの名無しさん
08/07/28 01:19:20
URLリンク(lolo.jp)
331:デフォルトの名無しさん
08/07/30 22:41:39
はてなで話題になってたが
URLリンク(d.hatena.ne.jp)
これを厳密に守るのはきついな……
332:デフォルトの名無しさん
08/08/07 15:47:21
これはJAVAを念頭に置いてるのか?
333:デフォルトの名無しさん
08/08/09 21:26:02
>>331
goto有害論並に偏りすぎてねぇか?
334:デフォルトの名無しさん
08/08/09 22:46:42
手続き型脳を矯正するには多少極端なくらいのショック療法が必要ってことだろ
335:デフォルトの名無しさん
08/08/25 00:22:16
OO厨だった学生時代はそういう病的に分割されたコードばっか書いてたな。
だけど、働き始めて周りの人間にソース追いにくいだのなんだの
不評だったせいでいつのまにか書かなくなったが。
336:デフォルトの名無しさん
08/10/01 21:55:22
C++でオペレータの宣言・定義するときにoperator=とかくのかoperator =とかくのかそういうのって決まってるの?
337:デフォルトの名無しさん
08/10/01 21:56:36
それは多分、インデントの量とか中括弧の位置なんかと同じテーマだと思うんだが。
338:デフォルトの名無しさん
08/10/01 23:43:18
>>336
検索しやすいように空けない。
339:デフォルトの名無しさん
08/10/02 00:07:24
operator\w= で検索すればおk
340:デフォルトの名無しさん
08/10/02 00:08:04
↑*追加しといて
341:デフォルトの名無しさん
08/10/02 20:45:35
\w じゃダメだろ。
342:デフォルトの名無しさん
08/10/03 01:01:52
じゃあ
operator\wktk=
343:デフォルトの名無しさん
08/10/09 08:01:21
elevaterⅡ
escalator⊿
344:デフォルトの名無しさん
09/01/09 01:29:10
あと、a,b,cで書いたなら、最後までa,b,cで通して欲しい。
a, b, cとか行に寄って記述が違うとイラッと来る。
345:デフォルトの名無しさん
09/01/10 21:16:17
>>344
コピペ製作だと思うよ。
346:デフォルトの名無しさん
09/02/08 11:22:25
C言語で複合代入演算子やインクリメント/デクリメント演算子の使用禁止って一般的なの?
for( iI = 0 ; iI < iMax ; iI = iI + 1){
とか泣けるんですが。iIって変数名も泣けるけど。
347:デフォルトの名無しさん
09/02/08 16:00:56
母国語が違うプログラマだろ
348:デフォルトの名無しさん
09/02/08 20:56:10
いや、コーディング規約なんだってば。ふつーそうなんだと言われた。
349:デフォルトの名無しさん
09/02/08 21:59:11
規約作った人の母国語が疑われる
350:デフォルトの名無しさん
09/02/09 00:02:37
VB使いしかいなかったんだろw
351:デフォルトの名無しさん
09/02/09 02:15:38
>>346
痛々しいな。
1を加算するのに++を使うのもみっともないが
1づつ増えていく値を表現するのに++を使わないのも、なんだかな
352:デフォルトの名無しさん
09/02/09 10:51:44
break continue 禁止 理由:分かりにくいから。
で、代替のサンプルがすごく分かりにくい。
353:デフォルトの名無しさん
09/02/09 15:12:23
重要なのは「読みやすく、書きやすい」なので、規則は場合に応じてでいいと思ってる。
ぱっと見で理解できやすいほうに改良していく感じで。
基本は固まりがわかりやすいインデント、改行+固まりの概要コメントってとこかな。
class A {
public:
int i;
354:デフォルトの名無しさん
09/02/09 15:13:48
途中で書いてもうた(^^;
class A {
public:
int i;
}
よりも
class A {
public:
int i;
}
のが好き
355:デフォルトの名無しさん
09/02/09 20:43:15
インデントや変数名なんかは後でどうにでもなるんで、別に構わない。
356:デフォルトの名無しさん
09/02/10 12:27:33
class A
{
private:
int i;
};
がすき
>>355
変数名はクラス間で衝突するのが当然だから後から置換するのは大変だぞ
357:デフォルトの名無しさん
09/02/10 19:13:10
コンパイラ相当の解析能力がある名称変更ツールってあったらいいなあと、たまに思う
358:デフォルトの名無しさん
09/02/10 20:36:18
>>357
JavaとかC#だと当たり前のように存在する。
359:デフォルトの名無しさん
09/02/10 20:39:51
>>357
何年前から来ましたか
360:デフォルトの名無しさん
09/02/10 21:25:10
Eclipseの入力補完とリファクタリングがなければ、もうコーディングできない体に・・・。
viでperlでCGIを書いていた時代には戻れない。
361:デフォルトの名無しさん
09/02/10 21:51:51
70年代から来たものですが、技術の進歩はすばらしいなw
eclipseを使って変数名変更やもっと高度なコードの書き直しができるみたいね
URLリンク(www.confrage.com)
(リファクタリングの項目)
こういう情報がまとまってるところってないものかな
362:デフォルトの名無しさん
09/02/10 22:25:03
VS2008でもリファクタリング出来ますよ
363:デフォルトの名無しさん
09/02/10 22:54:59
イマドキのモダンな開発環境なら大概できると思うが。
C++は構文解析の難易度高いんで発狂IDEも多いけどw
364:デフォルトの名無しさん
09/02/10 23:59:01
namespace の中はインデントする?
俺はしない。
365:デフォルトの名無しさん
09/02/11 03:25:36
基本はやらないほうだけど、
Java/C#では、IDEが勝手にやってくれるのでそのままやらせている。
366:デフォルトの名無しさん
09/02/11 15:14:16
いまだに、IDEのエディタよりテキストエディタを使ってる
名前変更は、grepで拾って一つ一つやる
そもそも名称変更をする時点で
設計がおかしいってことだし、そういう意味でコードの見直しにもなる
というオレは前時代の生き物だが、そうやって生き残ってきたから
この部分はそのまんまw
367:デフォルトの名無しさん
09/02/11 16:01:04
でも、若いのがIDE導入したいって言った時は、
前向きに検討してあげてね。
最近上司にO/Rマッパの話をしたら、
「そんなこと位、ケチらずにSQL書けよw
最近のはSQLも書けないのが多いってことなんかねー」
と言われた若いもんより
368:デフォルトの名無しさん
09/02/11 16:29:45
手間を減らすための手法は、使う側にメリットがあると感じさせなければただの余計な手間だからなw
369:デフォルトの名無しさん
09/02/11 16:36:56
Java+WebだとIDEなしは悲惨だぞ。
仕掛け上、膨大な数のファイルを取り扱うし整合性とるのだけでも大変だ。
370:デフォルトの名無しさん
09/02/11 19:04:31
SQL知らずにO/Rマッパー使いたがる馬鹿
371:367
09/02/11 20:56:18
>>370
どこからその発想が出てきたのか分かりませんが
そんな人がもしいたら馬鹿ですね。同意です。
372:366
09/02/12 00:35:22
>>367
いやいや、統合環境でもがつがつ組むときだけテキストエディタを使ってる
私は、フリーだし
誰かの面倒見るときでも、基本的には個人の自由と思ってる
373:デフォルトの名無しさん
09/02/12 07:55:52
>>371
お前のレスから出た発想に決まってるだろ低脳
374:デフォルトの名無しさん
09/02/12 08:14:58
おやおや
375:デフォルトの名無しさん
09/02/12 08:25:47
暇つぶしに煽ったら皮肉で返されて逆ギレっすかw
376:デフォルトの名無しさん
09/02/20 19:25:27
規約とはちょっと違うかもしれないけど、他に聞くとこないのでここでいいかい?
コードを管理するディレクトリ構成のことなんだけど、
ソースとヘッダーを同じディレクトリに入れてる人っているかな?
ライブラリのコードならヘッダーのディレクトリを分離しなきゃいけないだろうけど、
そうじゃなければ一緒にした方がやりやすいってやってるところもあるのかな?
377:デフォルトの名無しさん
09/02/20 19:54:54
好きなようにしたらいいと思うぞ。どっちにしても大した問題はないように思える。
378:デフォルトの名無しさん
09/02/20 20:12:40
いちいち分けないだろ
379:デフォルトの名無しさん
09/02/20 21:29:58
分けないのか?
380:デフォルトの名無しさん
09/02/20 21:33:59
IDEにおまかせ。
381:デフォルトの名無しさん
09/02/20 21:53:41
ライブラリでも配布時にヘッダ取り出せばいいし
必要とメリットに応じて。でいいんじゃない? 自分は分けてない
382:デフォルトの名無しさん
09/02/21 00:52:52
分けてない人多いのか
ところで今さらだけど、こんな記事あった
URLリンク(blog.scriptionary.com)
383:デフォルトの名無しさん
09/02/21 01:02:05
いや、多いかは知らないぞw 書き込んだ2人は分けてないってだけだからなw
384:デフォルトの名無しさん
09/02/21 01:08:30
分ける意味がわからん
385:デフォルトの名無しさん
09/02/21 01:15:42
ハンガリアン表記法はコーディングの手間になるから使わない
ただ、ポインタとグローバル変数にはpとかg_をつけてる。取り扱い注意的な意味で。
386:デフォルトの名無しさん
09/02/21 01:16:25
複数のコンポーネントからなるプロジェクトの場合は、コンポーネントごとにディレクトリを作って
なおかつ、共通で使うヘッダファイルのディレクトリも作る。
コンポーネント内部でしか使わないヘッダファイルは、コンポーネントのディレクトリに入れる。
387:デフォルトの名無しさん
09/02/21 01:30:43
ハンガリアン表記法ね
Cの時は使ってる、C++とかオブジェクト指向系の言語だと考えちゃうね
388:デフォルトの名無しさん
09/02/21 01:33:46
>>385
コーディングの手間になるから使ってる
意識する分だけ誤りが少ないし、検索するときユニークになりやすい
同じ意味で型を変換したい時には楽
389:デフォルトの名無しさん
09/02/21 01:33:57
コメントの書き方で
flag = true; //フラグを立てる
とかいうのは意味ないと思う。コードを見ればすぐ分かることを書くのは無駄。
コメントはある程度のまとまったコードに対して、どういう意味があるかを書くと、いちいちコードを解析する手間が省けるから役に立つ。
疑問があるのは、コメントにコードの変更日と変更者を記入してるタイプ。役に立ったことがないんだが、役に立つんかね
390:デフォルトの名無しさん
09/02/21 01:45:12
10年20年使われるコードでは役に立つときもある
391:デフォルトの名無しさん
09/02/21 01:46:15
80 名前:デフォルトの名無しさん[sage] 投稿日:2007/11/08(木) 19:23:34
昔も似たようなスレあったな
俺はシステムハンガリアンも有効だとレスした
IDEによる入力サポートとか、カーソルあわせての型情報とか一切無い環境もあるからな
ってか俺のとこそうだし
と書いても理解してもらえなかった。
多分ここでも理解してもらえないなw
この意見をどう思う?
392:デフォルトの名無しさん
09/02/21 01:47:50
>>389
納品した後の修正とかなら書くよ
393:デフォルトの名無しさん
09/02/21 02:00:33
>>391
まずはWindows APIみたいにバンバンtypedefしろ。
394:デフォルトの名無しさん
09/02/21 02:06:37
>>391
役に立つならそれはそれでありだと思う。
よほどチープな機材しかない職場なんだろうな。
395:デフォルトの名無しさん
09/02/21 02:11:41
>>389 には完全に同意だ
とくに
>疑問があるのは、コメントにコードの変更日と変更者を記入してるタイプ。役に立ったことがないんだが、役に立つんかね
には泣くほど同意見だ。
読みにくいったらないよ。
SCMがあるのになぜコメントで書くのか
396:デフォルトの名無しさん
09/02/21 02:15:24
>>389
>とかいうのは意味ないと思う。コードを見ればすぐ分かることを書くのは無駄。
まったく同意w
//このフラグはここでのみ立つので、~ほにゃらら
とか書くならよいのだが、やってることを書くのはほんとアホ
>コメントにコードの変更日と変更者を記入してるタイプ。
おれも役に立ったことがない、コードが読みにくいだけ
だれがどう変えたにせよ、今手を入れるのは自分なんだし
いまさら前任者を恨んでどうするって感じだわw
ファイルヘッダに履歴があれば充分って思う
397:デフォルトの名無しさん
09/02/21 02:15:29
バージョン管理なんて使わせてくれないところかもしれないだろ。
いや、SCMがあってもそういうのを書かされる話は聞くが。
398:デフォルトの名無しさん
09/02/21 02:41:39
>>395
> SCMがあるのになぜコメントで書くのか
どこにでもリポジトリがあるわけじゃありません。
399:デフォルトの名無しさん
09/02/21 02:43:12
あー、こいつが追加変更したところだから要注意だな、みたいなことはある。
400:デフォルトの名無しさん
09/02/21 02:54:24
いまどきソフトウェア開発プロジェクトでSCMを使わない以上の罪悪を探すのは難しいけどね
401:デフォルトの名無しさん
09/02/21 03:26:36
>>394
CodeWarriorというものがあってだな…
402:デフォルトの名無しさん
09/02/21 03:47:41
>>396
変更日・変更者コメントは、同時進行で進んでいるソース流用プロジェクトが、
流用元の最近の変更と自分たちの変更を区別するために欲しがっていたな。
403:デフォルトの名無しさん
09/02/21 03:53:56
>>401
組込のIDEには入力支援や型情報ポップアップがないって意味?
俺のとこではエディタとして別のIDE使ってたよ。組込の環境は使いにくいw
404:デフォルトの名無しさん
09/02/21 04:15:35
アセンブラだとメモリにどう入っているか分かるほうが楽
405:デフォルトの名無しさん
09/02/21 15:04:56
CodeWarrior のクソっぷりはなんとかならんか
406:デフォルトの名無しさん
09/02/21 17:25:27
>コードを見ればすぐ分かることを書くのは無駄。
アルゴリズムやデータ構造は知ってても、コードは読めんと言う相手と
連携しなきゃならん場合は必要だぞ。
具体的に例を挙げると、↓みたいなコードを、相手方にチェックしてもらうには
「読んで字のごとし」なコードもすごく重要。
・別言語で作ったアプリが吐いたデータを、整合性を崩さないように編集するコード
・ハードウェアを直接叩くコード
407:デフォルトの名無しさん
09/02/21 17:49:42
それは、「コードを見ればすぐ分かる」ことじゃない。
408:デフォルトの名無しさん
09/02/21 19:21:45
コードをみればすぐ分かるってのは、誰でも言語の知識だけでコードからすぐに読みとれること、と言い換えたら理解しやすいかもしれんな。
自分の知識ですぐ分かること、ではないぞw 言語以外の知識やその行付近以外の知識を必要とする時点ですでに「すぐ分かること」ではない。
例えばこういう感じ
*((volatile char*)0xF860) = 0; //&HF860番地にゼロを書く ←無駄なコメント
*((volatile char*)0xF860) = 0; //VDPリセット ←知識があれば分かることだが役にたつコメント
409:デフォルトの名無しさん
09/02/21 19:41:39
>>408
>*((volatile char*)0xF860) = 0; //VDPリセット ←知識があれば分かることだが役にたつコメント
これはコードをみればわかることじゃあないと思うな
0を入れるのか、リセットするのか、クリアするのかは、意味が少々違うからな
「文字」「文字値」「文字配列」「文字列」の違いみたいなものも結構気になる
410:デフォルトの名無しさん
09/02/21 20:10:39
>>409
コードを見れば分かる無駄なコメント に対する 役立つものの例として、という意味ね
「そこにゼロ書けばVDPがリセットされる」って知識がある人には、例の2つは同じ「コードをみればすぐ分かるコメント」に見えるかもしれない
でも、>>389で言っている「コードをみればすぐ分かるコメント」ってのは前者(ゼロを書く)であって、後者(リセット)のコメントの付け方ではないよ。
という説明のつもりだったw
411:デフォルトの名無しさん
09/02/21 21:15:41
#define VDP_ADDRESS (volatile char*)0xF860
#define RESET 0
*(VDP_ADDRESS) = RESET;
412:409
09/02/21 21:32:26
>>410
同意
>>411
そうそう、オレならそうする。
413:デフォルトの名無しさん
09/02/21 22:23:07
#define VDP_ADDRESS ((volatile char*)0xF860)
#define RESET 0
#define RESET_VDP() *VDP_ADDRESS = RESET
RESET_VDP();
414:デフォルトの名無しさん
09/02/22 01:06:49
マクロ地獄だな
415:409
09/02/22 01:09:28
>>411は、レジスタのアクセスだけなのがわかるが、
>>413だと、いくつかのシーケンスが内蔵されているように見えるね
該当のレジスタに他の値を入れることがたびたびあって、この行でリセットをしたいなら、明示的な>>411
該当のレジスタには、他でアクセスすることがなく、ここでリセットするだけなら>>413だな
416:デフォルトの名無しさん
09/02/22 17:45:00
皆さんのお知恵をお借りしにきますた
どっかの本かWEBで、ブーリアンの引数名にはNoとかNotはつけるな
ってあったんだけど、みなさんどう思いますか?
例えばbool NoScrollとか
417:デフォルトの名無しさん
09/02/22 17:57:32
>>416
賛成の反対で、これでいいのだw
418:デフォルトの名無しさん
09/02/22 18:08:30
>>416
本とか読んでる訳じゃないから、俺の感覚だと…
別にbool型なんだから
NoScrollにtrue入れるか、Scrollにfalse入れるかでしょ
それなら、コード中でどう使うかで使い分ければいいんじゃない
絶対に、NoScrollを主体で判断した方がいい部分で使われるのが分っているなら
NoScrollとすれば良い
それ以外で、Scrollという状態をtrue or falseで見る使い方なら
わざわざフラグを反転させる意味にしない方か良いと思う
419:デフォルトの名無しさん
09/02/22 19:02:30
>>418
どうもありがとうございます
その本だかによれば、ブーリアンは意味的に「~する」の肯定で統一したほうが混乱が少ない、みたいなことを根拠にしてました
そうやって統一すると、何かを「する」場合はtrue、「しない」場合はfalseを指定すれば良くなる、と
マァ自分的にも個々の使い分けでいいと思いました
420:デフォルトの名無しさん
09/02/22 19:22:24
>>419
直感的に、True(真)なのにNo(否定)っていうのが誤りの元にならないかってことだよね。
"できるだけ"避けるべきだとは思うなぁ
ちょっとオレが変かもしれないけど
電気ポットの注ぎ口なんかよくハッとする
「赤」なのに「出る」のが気持ち悪い
421:デフォルトの名無しさん
09/02/22 19:37:12
混在させるより統一した方がいいとは思うけどどっちでもいいと思えるほどの些細なことに見える。
422:デフォルトの名無しさん
09/02/22 19:49:32
>>420
赤=危険という風に見ればいい
423:デフォルトの名無しさん
09/02/22 20:23:15
>>416
否定後禁止ルールは、isとかcanとか三人単数ルールとかと併用しないと意味不明になりがちだと思う。
その場合ならCanScrollとかScrollsとか。
424:デフォルトの名無しさん
09/02/22 20:25:59
酷い日本語すみませぬ…。
×否定後 → ○否定語
×三人単数 → ○三人称単数
425:420
09/02/22 20:35:41
>>422
それはわかってるんだけどねw
出すことを前提に操作してるのに「赤」になるのがとてもアフォーざんす
426:デフォルトの名無しさん
09/02/22 22:22:51
なして?
427:デフォルトの名無しさん
09/02/22 22:55:00
信号機だと赤は停止の色だから?
428:デフォルトの名無しさん
09/02/22 23:15:36
・水は青、お湯は赤
・熱いから危険だから赤
429:デフォルトの名無しさん
09/02/22 23:22:32
>425
そこは「お湯を注ごうとしてる人」とは違うアクターを想像するんだ。
例えば「ポットを運ぼうとしてる人」とか。
430:デフォルトの名無しさん
09/02/23 00:52:59
>>429
わかっちゃいるんだけどね、例えば、車で
アクセルを踏むと赤いランプが点くとしたら、、、気持ち悪いよね
そんな感じ
431:デフォルトの名無しさん
09/02/23 01:06:41
そのつまんねー自分語り、いつまで続けるつもり?
432:デフォルトの名無しさん
09/02/23 01:19:19
>>431
レスがある限りw
433:デフォルトの名無しさん
09/02/23 02:49:40
>>431
2ちゃん歴浅いんか?
嫌ならお前が別の話題を振ればいい。
434:デフォルトの名無しさん
09/02/23 09:35:12
>>433
2ちゃん歴浅いんか?
気に入らないレスならスルーしろ。
435:デフォルトの名無しさん
09/02/23 13:06:16
おまえここは初めてか?力抜けよ。
436:デフォルトの名無しさん
09/02/23 13:28:14
420うぜーぞ
437:デフォルトの名無しさん
09/02/23 16:51:41
スルーしろといってる本人がスルーできてない
438:デフォルトの名無しさん
09/02/23 17:23:41
オマエモナー
439:デフォルトの名無しさん
09/02/23 20:53:40
,;:'';, ,;:' ';
,;'':.:. ';,,,.,.,.,.,.,;:' ';
、:´: . ':,
,':.:..:. . ':, ま、お茶でも飲んで休憩すれ。
';:.:.:.:.. / \ ':,
';::.:.:.:. . ● ● ;'
';:::.::.:. (__人__) ;'
'':;,:.:.:.:.:. . 、:' ( (
,;:'':.:.:. '::,,.,.,.,.,,.,,_ ヽ ヽ
,;':::: :: `()\; __O__ )ノ
,;' ;:.:. ;, .:.''_,.,,.,.,.,.,.,.,_,:'" \/= ̄ ̄ =ソ,フi!
,;' ;;:.:. ;, ;;'' {= = = = =イ .i!
;' ';;:.:. ;, ;:' ゙、_= = =_ノ i!
;, ';, ,; ;'  ̄ ̄ ┌―‐┐~
;, ゙゙''''''" ; { 茶 }
:; ;'''"゙゙'';: :; ヘニニノ
:; ; ;: ; || ̄ ̄ ̄ ̄ ̄ ̄ ̄||
':, ,; :; :; || ||
゙゙''''''''''" ゙゙''''''''''"
440:デフォルトの名無しさん
09/02/24 00:23:49
いや、俺はスルーしろなんて言ってないしなあ
命令しといて自分はやらない人につっこみ入れただけだしなあ。
441:デフォルトの名無しさん
09/02/24 00:26:10
レス乞食
442:デフォルトの名無しさん
09/02/24 00:30:51
呼んだ?
443:デフォルトの名無しさん
09/03/02 01:19:09
コメントに愚痴とかいいわけ書いてるやついるよなw
そういうヤツのコードは1関数1500行とかスパゲッティな依存関係とかすごく汚いコードだったw
そんな事書くくらいならコードの可読性をあげるコメントを書けと
444:デフォルトの名無しさん
09/03/03 01:33:42
パスカル記法ってただ頭を大文字にするだけ?
ハンガリアンみたいに詳細に説明してるサイトがないからそれしかわからん
445:デフォルトの名無しさん
09/03/03 10:05:24
>>444
>パスカル記法ってただ頭を大文字にするだけ?
そんだけ。
446:デフォルトの名無しさん
09/03/14 12:19:31
おまいらtypedefどう思う?
いちいちtypedefしてんじゃねーよカスが。
447:デフォルトの名無しさん
09/03/14 12:50:46
なんでもかんでもtypedefするカス
typedefしなきゃ書けないコードを知らずに全否定するカス
448:デフォルトの名無しさん
09/03/14 15:23:25
批判 [編集]
一部の人々は、typedefを広範に使用することに反対している。
ほとんどの議論は、typedefは単に変数の実際のデータ型を隠すだけであるという考えに集中する。
例えば、Linuxカーネルハッカーであり、ドキュメント作成を行っているGreg Kroah-Hartmanは、
関数プロトタイプ宣言を除いて、typedefの使用をやめさせようとしている。
彼は、typedefを使用することが、必要以上にコードを混乱させるだけでなく、
プログラマが巨大な構造体を単純な型と誤認識して使用してしまうことがあると主張している[1]。
449:デフォルトの名無しさん
09/03/14 17:34:56
>>448
どこからの引用なのか書けや
450:デフォルトの名無しさん
09/03/14 18:04:54
ここだな。
URLリンク(ja.wikipedia.org)
451:デフォルトの名無しさん
09/03/14 18:17:03
>>446
typedefはCとC++ではまったく事情が違う。
C++でテンプレートメタプログラミングするなら必須
452:デフォルトの名無しさん
09/04/19 16:03:42
そうかなあ
453:デフォルトの名無しさん
09/04/19 22:00:52
そうだよお