Cのマナーいろいろ

皆さんがCのコードを書かれる上で決めているマナーを教えてください．
例えば，コメントの書き方，関数の説明など．

　　　　　　　ﾘｰﾅｽ　　　　　　　　　　　　　　　　　　　　　　　ｼﾞｮﾌﾞｽ
　　　　　　　 ／⌒◆　　　　　　　　　　　　　　　　　　　　　 ◆⌒＼
　　　　　　　/　冫、）　　　　　　　　　　　　　　　　　　　　　（ ﾍ´ 　 ヽ
　　　　　＿/ 　` ∠_　　　　　　　　　　　　　　　　　　　 　　 ヽ´　 　人
　　　　イ　 ゝイノ　| ヽ 　　　　　　　　　　　　　　　　　　　　　冫y彳 (;⌒ヽ
　　　　|| ﾍ 　｡　　　| /|　　　　　　　　　　　　　　　　　　　　／　｡　　| 　/|ヽ
　　　　||　| 　｡　/　 |　|　　　　　　　　　ｹﾞｲﾂ　　　　　　　　|　| ｡　/.|　　 | |
　　　　|　 | 　｡ /　　|　|　　　　　　　　　　　　　　　　　 　 　|　| ｡ / .|　　 | |
　　　　|⌒|　 ｡　　　|　|　　　　　　　　　 ／⌒◆ 　　　　 　|　| ｡ ＿|　イ|　|
　　　　＼|｀　ヽ 　 ヽ／　　　　　　　　　/　冫、）　　　　　 ゞ |｀ヽ　|　　 |　|
　　　　／|＼人／＼|　　　　　　　　―/ 　` ∠_　　　　　　＼|＼人ヽ ／|冫
　　　　||　||　|　|　|　|　　　　　　　/|　 ゝイノ　| ＼　　　　 　ヽ|| |　|／　 |
　　　　||／|| |　|　|　|　　　　　　 / '|| 　 ｡　 　 || 　＼　　　 　 || |　||　 ／
　　　　　　|| |　|　|　|　　　 　 　/　/| 　 ｡　/　 |＼　 ） 　 　　 || |　||／　|
　　　　　　ヽ|　|　|　|.　 　 　┌|⌒|_| 　 ｡ /　　|/⌒/ |　　　 　|| |　|　|　 |
　　　　　　　ヽ|　|　|　　 　 　|| |　 | | 　 ｡　　 /　_/ | |　　　 　 ヽ|　|　|　 |
　　　　　　　　|　|　|　　　　　||　|⌒|＼人ヽノ|⌒| 　| |　 　　 　 　ヽ|　|　 |
　　　　　　　　| く__く　　　　　>> ￣＼＿＿　|￣ヾ.くく　　　 　 　 　>_ >　)
　　　　　　　　＼ 　　>.　　／ヽ.＿_/　　　　￣＼./￣/　 　 　 　 <　　 ／
　　　　　　　　　｀ー'　.　　￣￣　　　　　　　 　　￣￣　　　　　　　｀ー'

できるだけシフト演算を使う　って当たり前？

いまどきのコンパイラは最適化するだろ、そのくらい。

単発質問スレに回答をしてはいけません。他の厨に示しが付きません。
質問スレより単発スレの方が回答が早く付くという事例を作ってはいけません。
味を占めた厨が第二、第三の単発スレを生み出し、この板の秩序が崩壊します。
私たちのマターリ平和な板を維持するため、今こそ団結しようではありませんか！

自分の場合．

/***********************************************************
*
* 関数 hoge
*
**********************************************************/

/*----------------------------------------------------------
コメント
--------------------------------------------------------*/

　_________
/∴∵∴ヽ
|∵∴∞ヽ|　 ＿＿＿
|∴/= ♀=| <うるせー馬鹿！
＼| 　 ▽/　 ￣￣￣
　　￣￣

>>3
それは、パフォーマンス(スループット)上の配慮でしょうか？

>>6
コメントは//の方が無難ではないですか？
(今日び、大半のエディタでフォントの表示色を変更できるから、
あまり問題ないのかもしれませんが)

>>8
Cで//が使えるのは1999年の規格からでしょ

>>8
> それは、パフォーマンス(スループット)上の配慮でしょうか？
かっこいいから。

>>10
そうだな、かっこいい。

このスレそのものがコメントの中。 */

throw();

/*ここからすべてコメント

*/

つーかコメントだから何。

procedure TForm1.Form1Create(Sender :TObject);

>>17
Del房は黙ってふんどし

open/close、alloc/freeなど対で使うものは同じ関数内に書く。

とか?

>>19
通常当たり前では？

>>20
うん、そうだと思っていたけど、そうじゃない人を見たことがあって…。

えー、同じ関数内じゃないことなんてしょっちゅうだよ。
極端な例でいえば、malloc()とfree()のwrapper作ってしまえば、同じ関数内じゃ呼ばないし。

最近糞スレ多いなー。

Cのモナーいろいろ

愛し合う前に (Cのマナー)

・C はふたりの合意で行うもの
・C は「非売品」
・C にタブーはない
・セイフ C を心がけよう
・ふれあいは清潔に
・あせらず、相手を思いやる
・基本は愛情をそそぐこと
・要求はフランクに伝えること
・苦痛を感じたら無理をしない
・俗説に惑わされないで
・初体験に適齢期はない

C の新常識
人に聞けない疑問・不安・悩みを解消します

・初めての C は痛くて当たり前
・血が出なければ処女じゃないは，間違い
・初めての C で挿入できなくても大丈夫
・初めての C で「感じる」のはむずかしい
・オーガズムに定型はない
・初めての C で妊娠してしまうこともある
・ピルは今一番安全で確実な避妊法
・乳房は大きければいいわけではない
・乳首や性器の色は体質によって決る
・C 経験は体にでない
・毛深さは悩むよりお手入れで解消
・体臭は魅力的なにおいに変えられる
・ペニスは大きければいいの？
・包茎の手術は慎重に
・触られても感じないのは不感症？
・マスターベーションは自由

>>19
fopenって中でmallocするよね？
あれってfclose内でfreeすると思うんだけど。

C開発現場のマナー

新人のくせに、前橋のとんでも本か何かを読んで、分かった気になって、
「そもそも、ポインタとは．．．」とか言い出さない。

>>27
19も20もよっぽどでっかい関数を書いてるんだろうよ

>>27
ああいう完全にカプセル化されていて、必然性のある関数でそれが行われるのは良いでしょう。

mallocしたポインタを返すなら、直接freeを呼ばなくていいように、
専用の解放関数用意しておけば、だいたいOKでそ。

>>26
・フィニッシュで顔射しない

>>32
- Gスポットにこだわらない
- 「自分流」を押しつけない
- 「いったフリ」をしない
- マグロにならない
- オーラルセックスを拒否しない

>>3-4

シフト演算使う？コンパイラは最適化する？
厨房ですか？ハァ？

最近のCPUでは分岐予測出来なくなって、
逆に遅くなるって！

2chもﾚﾍﾞﾙがおちた。

>>34
せめてベンチマークくらい出してくれればねぇ。
2chで識者気取ってる奴のレベルも落ちた。

じゃあ、低レベルの 2ch には来ないほうが良いんじゃない。

Cのマナーいろいろ
http://pc3.2ch.net/test/read.cgi/tech/1029584140/

Cのマナー
http://pc.2ch.net/test/read.cgi/prog/1030001269/

>>35
信用できないならしなくていいよ。ばか。

>>36
おまえらがいなくなればいいだけ。

>>38
ちょっと叩くだけで一気に厨房に。
典型的パターンだ。

>>39
はいはい、しんでね。

お願いだから、上げないで。

あげてる奴は>>1とその仲間達

>>34=38=40
http://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/readres.cgi?bo=lounge&vi=1027870433&res=17&fi=no
やってみたが乗算、除算を使ったほうが遅くなっているような気がする。
どこがおかしいのか教えてほしい。
それとも俺のマシンのCPUが古いのか？

>>43
ステレオタイプって奴では？

>>43
http://www.intel.co.jp/jp/developer/design/pentium4/manuals/index.htm
の中の
インテル(R) Pentium(R) 4 プロセッサおよびインテル(R) Xeon(TM) プロセッサ最適化リファレンス・マニュアル (日本語 PDF ファイル: 3,277KB)
の2-11ページに書いてあるからよくよめ。
どうせ俺が言っても信じないだろうから。
つーか、おまえもし技術者だったら終わってるね。
しんだら？

そうかー、これ知らないと技術者として終わってんのかー
まいったなー
でも、いいやー
困ってないしー

>>46
あほ！
知らないから終わってるとか言ってんじゃないよ。
自分でちゃんと調べようとする気がないから、
終わってんだよ。
それくらいわかれ。ばか。

悪いけど、俺にとっちゃ、>>45 云々は優先度低いんだわー
もっと別なことを調べるために時間を使いたいね。

>優先度低い

もっと言っちゃえば、俺的にはどうでも良いんだわ、こんなこと。
やっぱり終わってんのかなー

結局ﾈﾀなわけだが．．．

よく分からんコードにこだわって何を作ってるんでつか？
射精スピード早くすんの？

わずかな演算スピードの差を気にするのはナンセンスだろ。

>>45
その中の、2-6に
乗算の代わりにシフトを使用する
とあるが。

つーか昔のム板って今よりレベル高かったの？

>>55
低レベルの彼曰く高かったらしい。

乗算や除算なんてあるプロセッサで開発してるの？
なんて贅沢なんだ！

>>57
Z80厨しね

○○もレベルが落ちた

って言ってみたい年頃なんだろう (´ー`)y-~~

煽りもレベルが落ちた

決して「俺のレベルが落ちた」と言わない方々。

なんだ、そうか、すぱーくをしらないのかとおもた。

お　　ま　　え　　ら　　必　　死　　だ　　な　　(　　藁

俺もレベルが落ちた。

ほんとつまらん煽りだな。

＞57
Itanuim厨ｶｴﾚ

ふむふむ
あげ！

#include <_2ch.h>

int mona(void)
{
printf(" Λ＿Λ ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣\n");
printf("（ ´∀｀）＜ ぷぷp\n");
printf("（ ） ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿\n");
printf(" ｜ ｜| |\n");
printf("（_＿）＿）\n");

return いってよし;
}

とにかくかねかかり過ぎるのどうにかしてほしい

/**
　* 関数の説明
　*
　* @param arg 引数説明
　*
　* @retval 0 成功
　* @retval -1 失敗
　*/
void func(void* arg) {…}

$ doxygen
ﾏﾝｾｰ

ageてみよう。

1が言ってるのはコーディングスタイルであって、
シフト演算だと速くなるか遅くなるかはスレ違いではないかと。

>>72
マナーというかコーディングスタイルというか、
bit演算以外でシフトを使うのはよくないコーディングスタイルだと思うな。
シフトとか使おうが割り算掛け算しようが、
その辺はコンパイラが適当にやってくれると期待してもいいだろうし、
べつにそうなっていなくても大抵問題にはならない。
そんな小手先のテクニックで悦に入ってないで、
もっと別のことで速度を稼ぐべきだ(その必要があるなら)。

もちろん何事にも例外があって、

コンパイラがシフト命令を吐かない&&シフト演算の方が速い&&速度が最重要

って場合にはシフト演算を使うこともあるだろうけど、そんな機会は滅多にない。

>>73
そういう意見なら同意。
あくまでも速いか遅いかを議論するのがスレ違いではと思ったわけで。

カラアゲ〜〜〜!

コメントを書くと遅いので駄目です。

結局ネタなわけだが...

>>77
あなたがですか？

コメントを入れると速度が低下することを知らないヤシが居るとはおどろきだ

インタープリタのはマジ低下するよな。

Cのモナーいろいろ

Cのモナーうろうろ

>>80
する前に、まず互いに相手をやさしくなであう。

2つのファイルの間で相互参照が絶対に無いこと。
A.cがB.c内の関数を呼んだ時には、B.cはA.cの関数を呼ばない。
呼んでいる場合にはモジュール構成が間違っていると判断する。
循環的な相互参照もないこと。A.cがB.hをインクルード、
B.hがC.hをインクルードして、C.hがA.cのシンボルを見ていないこと。

/*
* これ以降コント

A: こないだボク、アレしたんですわ。

B: アレってどれやのん?

main()はintを返すようにするってのは？
今でもvoidにしてる人いるよな・・・

>>84
相互参照が何故悪いの良く判らないのですが。
C++ではクラス単位でファイルを分けることが多いから、
相互参照は当たり前なんですけど。

生でするときには、シーツにタオルを敷く。
終った後は、シーツを汚さないように慎重に！

今日ラブホで、DCのねえちゃんとエチしたとき、シーツをザーメンで汚して怒られますた。（ｗ

コメントは岡山弁で書く。

コントは大阪弁で演じる。

>相互参照が何故悪いの良く判らないのですが。
>C++ではクラス単位でファイルを分けることが多いから、
>相互参照は当たり前なんですけど。
依存関係の強いクラス同士は一つのファイルに入れるのが
普通だと思うんですが。
それに、依存関係が複雑化するのはクラス設計が間違っている
場合にも見られます(間違ってなくても複雑化することはある)。
テンプレートや仮想関数を正しく使ってますか？

>>89
ほっといてやれよ。
あわれすぎて>>84へのレスが思いつかないよ…

>>90
きみはﾁｪｯｸｱｳﾄの手続きを知らんようだが
そんなことで怒られたりしないよ

ファイル A.c や B.c においてテンプレートや仮想関数が使われた事例を知らないのだが

>>96
ﾃﾝﾌﾟﾚｰﾄはともかくCOMはCでも使えるぞ
おまえ仮想関数と関数ﾎﾟｲﾝﾀの違いは何だと思っている?

>>93
別に１つのファイルに入れる必要はないと思うが。
それには理由があるのか？

>別に１つのファイルに入れる必要はないと思うが。
>それには理由があるのか？
切っても切れぬ関係にある二つのオブジェクトを
二つのファイルに分割して保存する意味があるのか？
一緒に使わないと動かないなら迷わず一つに格納するのが正解だと思うが。

>>97
> おまえ仮想関数と関数ﾎﾟｲﾝﾀの違いは何だと思っている?

仮想関数は C では使えないものと認識しているが。

必要以上にgoto、グローバル変数、多重継承(C++)を使わない。コメントを書く。それぐらいの基本的なことだけだな。

84は、コールバック関数は不要といいたいらしい。

>84は、コールバック関数は不要といいたいらしい。
だから、相互でなければいいわけで。
コールバックを提供する側が、される側にexternするシンボルがなければ良し。
ポインタを渡すだけなら不要だろ？

つまり、シンボルの代わりにインターフェース(ポインタ構造体)を
使っておけば、相互参照してもええということか、、、

相互参照を目的にしてコールバックするなら NG だろ。

>相互参照を目的にしてコールバックするなら NG だろ。
意図としては、コールバックを提供する側でstructやextern宣言を
提供される側に見せると、ライブラリ間の相性問題の発生源になるので
やめようということ。インターフェースだけ見せるか、一つのモジュール
として全部隠してしまえば(つまり分割しないということ)、
相性の問題はない。

>>100
えー？　すっげーつまんねー
折角ちょっかいかけてみたけど
徒労だったよ

欝だ．．．

>>107
どういうちょっかいを出したつもりだったのか聞かせてくれ。

IP記録実験
http://qb.2ch.net/test/read.cgi/accuse/1042013605/

1 名前：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★ 投稿日：03/01/08 17:13 ID:???
そんなわけで、qbサーバでIPの記録実験をはじめましたー。

27 名前：心得をよく読みましょう 投稿日：03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か？

38 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:22 ID:rLfxQ17l
>>27
鋭いです。

73 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:27 ID:rLfxQ17l
＞ところで、IPが抜かれて何か今までと変わることってあるのでしょうか？
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。

>>4
ワラタ

変に訴えるよりも
だれか弁の立つやつを2chに潜り込ませて集団洗脳したほうがいいのにな。

記念的ｶｷｺ

>>291
確かに串使う意味がなさそうだな。

======2==C==H======================================================

　　　　　　　　　２ちゃんねるのお勧めな話題と
　　　　　ネットでの面白い出来事を配送したいと思ってます。。。

===============================読者数： 138720人　発行日：2003/1/9

年末年始ボケがそろそろ収まり始めた今日このごろのひろゆきです。

そんなわけで、年末に予告したIP記録ですが実験を開始しています。

「２ちゃんねる20030107」
こんな感じで各掲示板の最下部に日付が入ってるんですが、
20030107以降になってるところはログ記録実験中ですー。

んじゃ！

────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────

今回の議論に関して、IPが記録されることとfusianasan化されることと
ごっちゃにして騒ぎ立ててる奴も結構多いと思うんだが。

５７１の言いたい事が分からないので、もっと詳しく　　　　　　　

2

にげっと

>>606初めて　ひろゆきのお言葉を初めて拝見したよ

感動した！！！

2ch人口は確実に減ってるのによりいっそう使いづらくなってるな

祭りはもう終わりですか

>>704

「おはよう一直線」という番組で、生島ヒロシのでるやつ。
　http://www.tbs.co.jp/radio/format/ikushima.html
宮崎哲「2chでは嘘のことをネタというんですけどね、これはネタですね」
「あまり真に受けて騒ぐのもどうか」とも、

おまえらのスポンサーは真に受けてひろゆきに６億円も損害賠償請求して
るじゃん。とか思ったわけだけど

処女

さぁて、どうなることやら

質あげたいんだったら全部トマトにしちゃえばよかったのに

今朝ラジオで、生島と宮崎哲がこの話題言ってたな
で、スポンサーがＤＨＣなのは笑った。

「○○酒造が営利のために食品管理の工程で
　ワインに毒性の高い物質を入れている。」
と書き込みがある。
嘘だと皆から突っ込みが入り、書き込む人は小出しに情報を出してくる。

・味を良くするために不凍液を入れている。
・工場のある土地を特定して書き込む。
・醸造責任者の容姿や個性を挙げる。
・ワイン醸造のバッチ工程を書き込む。
・不凍液を入れるタイミングを書き込む
・私は仕事のない東北から来る日本酒配属の冬季の季節労働者だ。
　・
　・
　・


悪徳企業が書き込まれるおぼろげな情報から
自分の悪事が書かれていると悟り
裁判を起こすと負けるので慌ててその企業が暴力団に金を渡して
正規の手続きをせず、ひろゆこ氏へIPとリモホを出せと脅す。。。。。
山奥にひろゆこ氏が連れ出され遺体を埋める穴の横で
暴力団に尋問された場合、ひろゆこ氏は出すのかな？
出すだろうな。

173 ：名無しさん＠３周年 ：03/01/09 22:20 ID:FDWl1Tso
ひろゆきは自宅に押しかけた暴走族に土下座した人だよ。
暴力団に脅されたら山奥に連れ出されるまでもなく玄関先で二つ返事で請け負うんじゃない？

権力には抵抗するけど、暴力には滅法弱い、それがわれらのひろゆき

もともと２ちゃんの鯖所在地は、アメリカ国内ですが、何か？

312 ：ひろゆき ◆3SHRUNYAXA ：03/01/10 19:59 ID:jWxHxvti
全部にいれてみた。

http://qb.2ch.net/test/read.cgi/accuse/1042131034/312

======2==C==H======================================================

　　　　　　　　　２ちゃんねるのお勧めな話題と
　　　　　ネットでの面白い出来事を配送したいと思ってます。。。

===============================読者数： 139038人　発行日：2003/1/10

なにやら、連日メルマガだしてるひろゆきです。

そんなわけで、ログ記録実験ですが、いちいちサーバ指定するのが面倒なので、
全部のサーバに入れてみました。

重くなって落ちたりしてもご愛嬌ってことで。。。

んじゃ！

────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────

やったら評価7/10だった・・・・
2ｃｈやりすぎで色盲になるのかも
色盲テスト；
http://www.liquidgeneration.com/sabotage/vision_sabotage.asp

さーて、逮捕されそうな書き込み探すかなぁ。
訴えられそうな書き込みモナー

ひろゆきカマン。

この前さいたま行ったんです。
2ちゃんでは凄いバカにされてるからどんなに田舎かなと思って
私は新宿から埼京線で行ったんですがさいたま市に入って最初の駅武蔵浦和に
近付くと超高層マンションのが2つあり綺麗な街並みに人が沢山いました
この電車は高架を走っているので外の景色が良く見えます。住宅や色んな所に高い建物があって都会的な風景でした
北与野を過ぎると未来的な空間があり（さいたま新都心かな？）その向こうには自然界が広がっていて（見沼）綺麗でした
大宮に着きまず最初に駅の大きさにビックリ。24番線位まであるそうです。駅の中にコンビニがやたらとあった
西口にでると都会的で若者が沢山いてビックリしました。東口には昔の下町のようかカオスティックな街が広がりキャバクラが沢山あり繁華街の人通りが激しかったです
北浦和に移動すると若者が沢山いました。大学とか専門とかライブハウス、があるみたいですね。以外と賑わってる繁華街でした
浦和駅に着くと東口は開発予定で更地。西口は繁華街が広がって隠れた名店が沢山ありました。
今までのさいたまのイメージとは違いました。私の住んでる横浜より全然都会でした。

　前スレは、最後の方で、同一人物によると思われる意味不明の発言が
連続したためでは。

2chの解説本が出てました。たわいないです。

http://shopping.yahoo.co.jp/shop?d=jb&id=07107411
-----------------------------

「２ちゃんねるのウラオモテ超入門」

マイウェイムック、143ページ

監修・２ちゃんねる
発行・マイウェイ出版株式会社
発行日・2003年2月20日
値段・1429円

2ちゃんねるがアクセスログ記録を始めましたが、あなたの考えは?
http://newspolls.yahoo.co.jp/public/archives/2076384460/p-ne6-7?m=r

どうも、無責任体質が身にしみている方が多いようで。

っていうか同じ人でわ？

あーっはっは！
久しぶりに笑ったよ！

鬼女板ﾃﾞｽﾀ。

事情通X氏が、擦りガラス越しにテレビ出演する悪寒。。。

いまどきのコンパイラは最適化するだろ、そのくらい。

中年オヤジはこれだから困る
自分で書き込んで１人で笑ってるんだろうな

「確認はしてないが２ちゃんのどこかで誹謗中傷されてると聞いたんで探して削除しる！」
(^_^;)人はこれをデムパと言う・・・・

お疲れさまでした〜

>>143

>いまどきのコンパイラは最適化する
ここまではいい

>だろ
これは禿糞

自己虫な思い込みを裏切られたことのないﾋﾖｯ子
若しくは裏切るようなｺﾝﾊﾟｲﾗを棄てる自由が保証されているｱﾏ

（＾＾）

>>131
ﾜﾗﾀ

4ndってたぶんネタじゃなくて素の馬鹿だと思う

（＾＾）

C で OOP をしてはいけない。

>>149
メッサびびったぞ！！

153は境（サカエ）人っと

（＾＾）

＜血液型A型の一般的な特徴＞（見せかけの優しさ・もっともらしさ（偽善）に騙され
るな！！）
●とにかく気が小さい(神経質、臆病、二言目には「世間」、了見が狭い）
●他人に異常に干渉し、しかも好戦的でファイト満々（キモイ、自己中心、硬直的でデリカシーがない）
●妙にプライドが高く、自分が馬鹿にされると怒るくせに平気で他人を馬鹿にしようと
する（ただし、相手を表面的・形式的にしか判断できず(早合点・誤解の名人)、実際に
はたいてい、内面的・実質的に負けている）
●本音は、ものすごく幼稚で倫理意識が異常に低い（人にばれさえしなければＯＫ！）
●「常識、常識」と口うるさいが、実はA型の常識はピントがズレまくっている（日本
の常識は世界の非常識）
●権力、強者（警察、暴走族…ｅｔｃ）に弱く、弱者には威張り散らす（強い者にはへつらい、弱い者に対してはいじめる）
●あら探しだけは名人級でウザイ（例え10の長所があってもほめることをせず、たった１つの短所を見つけてはけなす）
●基本的に悲観主義でマイナス思考に支配されているため性格がうっとうしい（根暗）
●単独では何もできない（群れでしか行動できないヘタレ）
●少数派の異質、異文化を排斥する(差別主義者、狭量）
●集団によるいじめのパイオニア＆天才(陰湿＆陰険）
●悪口、陰口が大好き（Ａ型が３人寄れば他人の悪口、裏表が激しい）
●他人からどう見られているか、人の目を異常に気にする（「〜みたい」とよく言う、
世間体命）
●自分の感情をうまく表現できず、コミュニケーション能力に乏しい（同じことを何度
も言ってキモイ）　
●表面上協調・意気投合しているようでも、腹は各自バラバラで融通が利かず、頑固(本当は個性・アク強い）
●人を信じられず、疑い深い（自分自身裏表が激しいため、他人に対してもそう思う）
●自ら好んでストイックな生活をしストレスを溜めておきながら、他人に猛烈に嫉妬
する（不合理な馬鹿）
●執念深く、粘着でしつこい（「一生恨みます」タイプ）
●自分に甘く他人に厳しい（自分のことは棚に上げてまず他人を責める。しかも冷酷）
●男は、女々しいあるいは女の腐ったみたいな考えのやつが多い(例：「俺のほうが男
前やのに、なんでや！（あの野郎の足を引っ張ってやる！！）」）

（例え10の長所があってもほめることをせず、たった１つの短所を見つけてはけなす）
この部分は何度読んでも笑える。A型だけど。

（＾＾）

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

本日、嫁と昼休みに合流し、共に食事をするため店に入る。
そして席につくなり、お茶とお絞りが２人に出された。まあ、別に普通の光景だ。
が。

分からん。このお絞りというヤツは、一体何なんだ。
いや、別にこれで手を拭くことぐらいは理解できるのだが、何で拭かなければならないのか、さっぱり分からん。
だって箸があるじゃないか。
手掴みで食すならともかく、箸やスプーン、フォークなどを使う場合であれば、手を拭く必要なんぞあるまい。
もちろん、俺は食事の前に手を洗うという習慣も理解できない。
俺は阿呆なのだろうか。

お絞りで顔や首を拭く輩もいる。って、それは俺なのだが（ただし居酒屋限定）。
これは一般的には、あまり品のよろしくないこととされている。
しかし、俺はこっちの方が理に適っていると思っている。
だって、顔の油は手の汚れの比ではないぞ。
飲食を娯楽と捉えるならば、まずは気になる汚れを落としてリラックスするというのは大変理解できる。

とは言え、外で食事をする際は一応俺も手を拭く。
一体俺は何を気にして入るのか。人目か。おのれ。敗北者か俺は。
まあ、まったく気にしないよりはマシだ。多分。
しかし、完全に納得しての行動ではないことは言っておく。
体は許しても心は許してはいないという事か。良く分からんが。

ついでに言えば、お茶で口をゆすぐのを良しとしないのも理解できない。
カテキンの殺菌能力を、みすみす逃す理由が分からない。もったいない。
歯を磨く時間がない時など、非常に合理的な判断だと思うのだが。
日本の食事のマナーは、俺には理解不能なことだらけである。

◎人の嫌がることをズケッと言うのはこんな奴！
＜アスペルガー症候群（自閉症スペクトラム）←脳の機能的疾患（遺伝が要因）＞
●変化を嫌う
http://web.kyoto-inet.or.jp/org/atoz3/kado/book1/Williams-Asp.htm

●接し方のルールがわからず無邪気に周囲の人に対して迷惑なことをしてしまうことがある。人を傷つけるということには鈍感（相手の立場に立って考えられない）。
●パターン的行動、生真面目すぎて融通が利かない
　毎朝の通学電車では同じホームの同じ場所から、同じ時間の同じ号車に乗ることに決めていたりする。パターンを好むということは反復を厭わないことでもある。
●アスペルガー症候群の子どもは（大人も）感覚刺激に対して敏感。敏感さは聴覚、視覚、味覚、嗅覚、温痛覚などのいずれの感覚の敏感さもありえる（特に視覚が敏感）。
●アスペルガー症候群の子ども（大人も）は予測できないことや変化に対して苦痛を感じることが多い。
http://www.autism.jp/l-02-03-aspe3.htm

●独り言を言うことが多い（考えていることを口に出す）
●物事をいつまでも同じにしておこうとする欲求が強く、そうでないと非常に不安。いわゆる「こだわり」。
●自発的に行動することが少なく、興味の幅が狭い
●物まねをしているような不自然な言語表現
●自閉症スペクトラム全体としては一万人に91人（およそ100人に1人）。
http://www.ypdc.net/asuperugar.htm

★自閉症スペクトラムの考え方(アスペルガーに至らない気質の偏りもある（遺伝性））
http://www.imaizumi-web.com/030413.html　　
　　　
★アスペルガー症候群（自閉症スペクトラム）かどうかのテスト
http://twitwi.s10.xrea.com/psy/add.htm　
http://www.geocities.co.jp/Beautycare/5917/as/marksheetmake.html

これだけは譲れない…
if(　　)
{
　　　　if(　　)
　　　　{
　　　　　　　　if(　　)
　　　　　　　　{

　　　　　　　　}
　　　　}
}

譲れないとか言っちゃって自分のスタイルに固執するのはマナー違反

関数呼び出しと区別するため if・for・whileと () の間には必ずスペースを空ける
キーワードを太字表示するエディタ使ってるけどね

終わった後に必ずやさしく声をかける

(検査が)終わった後に必ずやさしく(軽く肩をたたきながら)声をかける

「このバグ今日中に直しておいてね(はぁと)」

163> 俺も譲れない…
if(　　){
　　if(　　){
　　　　if(　　){

　　　　　　}
　　}
}

一画面に表示できる情報を増やすために、無用に縦に伸ばしたくありません

http://homepage.mac.com/hiroyuki44/

if(　　){if(　　){ if(　　){ } } }
これ最強

Ｃのモナー

gotoは使っちゃダメ！
gotoは暗黒面に通じておる。

いきなりハードコードしないこと。
「最初からやり直してっ」って嫌われるぜ。ｗ

http://jbbs.shitaraba.com/computer/6765/

ちょっと冒険したい時は相手の合意の上で。
痛がったら、他の部分を愛撫するなどして気をそらしましょう。
それでも痛がるようならやめる。
もちろん愛情があってこその行為です。

>>173
俺はいつだっていきなりハードコード

関数と予約語の差を強調ためにifの後ろには空白、
関数名の後ろにはカッコを接近させる
returnの一番外側のカッコは付けない。

スクロールしながらザーっと目で検索するときに、
文の特徴を一瞬でも早く捉えたいから。

if (b) f(a, b, c)；
return (c) + x;

全角文字は使わない。

Cで作った成果物は、責任を持って面倒を見ること。
あと、なかなかできない時は、一人で悩んだり怪しい薬に頼ったりせず専門家に相談すること。あせってがんばりすぎても、精力を消耗するだけだよ。

/* エロ話にもっていきたくて必死になってる人がいるみたいですが */

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

（＾＾）

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

あ

ふん

Cのマナー
開発チームの誰が見ても一目瞭然なデータ構造。
新人でも国語の本を読める位には分かりやすいソースコード。
一人で泊まったときにオナニーしたら自前の消臭剤を使う。

>>187
競争原理のない場所に特有の狂った「マナー」だな
一番アフォを１人外すだけで飛躍的な改善ができたり
新人にもすぐできる程度のコードしか作ってない無能集団だったり
おえー想像しただけでめまいがしてきた

>>188
外したい一番ｱﾌｫなのが権限を持ってたりする。

藻まえらVBで縄でも結ってろ

その縄で吊ってろ

交通で言うと、安全に走るのは技術、気持ちよく走るのがマナー。

通常マナーと呼ばれるものの多くは、この意味では技術の範疇に入る。

char * getSystemCallsForCLanguage() {
}

>>177
>関数と予約語の差を強調ためにifの後ろには空白、
>関数名の後ろにはカッコを接近させる
>returnの一番外側のカッコは付けない。
そうなってないコードの方が間抜けなわけで。

商用パッケージを使ったプログラムの拡張作業をやらせるときには、
そのパッケージの情報も渡す。
名前しかわからないようなパッケージを渡すな。頼むから。

>>161
古い話にレスつけるのは気が引けるが、お食事処でおしぼりが出るのは、客に気持ち
よくなってもらいたいこともあるが、汚い手で食事され、それが原因で食中毒とかに
なると、面倒なので、出しているの。
スシやの、お茶、わさび、ガリなども、古くからの食中毒防止策。
昨今、衛生状態がよいからと、気を抜くとこれからの時期、やられることもある。

スレ違い、ご容赦を。

バグといえば、ムシだが、この虫も目に見えない。用心用心。

わかりやすく書くこともマナーのひとつだが、
幼稚園児みたいなアルゴリズムを使わないこともマナーのひとつだ。
せめて高校数学レベルのロジックで書け。

幼稚園児みたいなアルゴリズムの例

if(a==0)b=0;
else if(a==1)b=1;
else if(a==2)b=2;
else if(a==3)b=3;

こんな感じでプログラミングしてるやついないか？
わかりやすいのと幼稚園とは違うぞ！

LISP使いの憂鬱
if(　　) {
　　　　if(　　) {
　　　　　　　　if(　　) {
　　　　　　　　　　・・・}}}

あんただけだよ

なぜLisperが憂鬱するのか分かんないので解説宜しく。

>>199
Lisp 良く知らないけど、条件文のネストには cond があるから無問題では？

>>198
gcc で -O2 とか-O3 したら、 b=a みたいに
最適化されないかと思ってやってみたが、
さすがにならんな・・・

>>203
・・・ならんだろうねぇ。
なったら怖いような

ニーズがあれば最適化するだろうけどそんなコード書くやついないし

if (0 <= a && a <= 3) b = a;
となったわけか…

>>206
・・・ならんと思うぞ

>>206
そう、それをかなり期待したんだが・・・なったらおもしろいなと。

そのうち最適化がすすんで、『オイ！』って言ったら
ソフトウェアがほぼ完成するような状況になったらいいな。


俺なんて真っ先に首だろうけど、そしたら遊園地で働こッと。

『オイ！』って言ったら
ソフトウェアがほぼ完成するようなソフトウェアは
『オイ！』じゃ作れないんだろうなぁ。

おまいらよ、プログラミングのマナーはひとつだけだ。
オープンソースにしても恥ずかしくないコードを書くこと。
別にオープンソースにする必要はないが、いつコードを晒す事態になっても、社会的鑑賞に堪えるものを書けということだ。

ゐゑぽ

引数リストがなが〜〜〜〜〜〜〜〜〜〜〜〜〜〜いときは
見た目的に美しくないけど改行するぽ

>>211
バイナリにしてもアイコンも恥ずかしいお前のプログラムはry

>>213
引数を減らす努力はしないのか？

引数多いなら構造体渡せよ。

WINAPIのプロシージャだから

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPCTSTR lpszCmd, UINT nCmdShow)

↑うざいので、

__stdcall WinMain(i,p,c,s)

でＯＫ。
キャスト万歳！

>>218
そこ、うにモードでもうにじゃない文字列が来るからただのLPCSTRかLPSTRじゃないとだめだろ

>>198
>> if(a==0)b=0;
>> else if(a==1)b=1;
>> else if(a==2)b=2;
>> else if(a==3)b=3
混ぜ反すようで悪いが、こういう方が出来てくるコードが短いときがある。

大方は、switch() 文？　これは生成コードが長い。
それとも、
int b_array[]={0,1,2,3};
として、
b = b_array[a];
　　しかしこの場合、ものによっては、範囲チェックが必要。
まさか、
if (a >= 0 && a <= 3) b = a;
が、正解といいたい？
それとも関数とか数列の知識を使えって単に言っているだけ？
else if は何個まで許すとかありそうな気もする。

>>221
俺はこうする。
if (a == 0) b = 0;
if (a == 1) b = 1;
if (a == 2) b = 2;
if (a == 3) b = 3;

＞大方は、switch() 文？　これは生成コードが長い。
コードの長さがどうなるかは分からないけど
分岐予測しなくなって速度が遅くなることはありそう。

>>222
>俺はこうする。
そうかい・・・
一度、-S つけてアセンブラソース吐き出して比較して見れば？
else if にしたほうが、最適化もよく効いて良いことがよくわかるよ。

細かいことだけど、

char *p = (char *)malloc(aru_saizu);
if (!p){
/* err proc */
}

ってのより、

char *p = NULL;

if (!(p = (char *)malloc(aru_saizu))){
/* err proc */
}
の方が、コストも速度も良いと思われるけど、あまり見かけない。
どうしています？ 今や、最適化で差異はなくなっているのでしょうか。

>>224
私はこうしています。

char *p = malloc(aru_saizu);　/* いちいちキャストしない */
if (p == NULL) {　/* NULL = ゼロとはかぎらないので */
/* era- no tame no purosi-ja- */
}

ところでどうして>>224の後者の方がコストも速度も良いんですか？

>>225
残念ながらNULLはゼロなんだよ。
未だにこういう勘違いをしている奴は多い。
そのコメントさえなければ、きれいでいいよね。
244のコスト云々は単なる思い込みだね。昔はこうで、今はこうという問題でもない。

確かにNULLが0以外の場合なんてあるのか

コンピュータのアーキテクチャの話なら、あります。

>>227
そりゃ、誰かが
#define NULL 1
と書いちゃえば変わってしまうが、そんなことをしない限り、ゼロ。
ましてや>>225はヌルポインターの話なので、これはもう間違いなくゼロ。
しかしながら、内部表現の話を、ヌルポがゼロ以外の場合があると勘違いする奴がいる。

>>228
コンピュータのアーキテクチャにヌルポインターという概念はない。
ヌルポインターはCの概念。
そしてCの概念では必ず0。
惑わす発言はヤメレ。

NULLはｃの歴史始まって以来、ｾﾞﾛだ。NULLの値をを変えることなんぞ考えられん。
そんなことしたら、どのくらいのプログラムが動かなくなるかが想像出来ないほどだからな

ここでの問題は
if (!p){
と
if (p == NULL) {　
のどちらの方が「マナーとして良いか」という話では？
俺は、昔は後者が判りやすいと思っていたが、今は前者が判りやすい

>そしてCの概念では必ず0。
つまらん釣りだなおい。

C FAQ くらい読んでこい、って話ですよ。

>>224
const付けたいんで
const *p = malloc(aru_size)
if(!p)
{
 /* err proc */
}

>>229
ぬるぽは０でなくてもいい
if(ぬるぽ)がelseへ行けば実装はどうでもいい
calloc使いたがるアフォが恥をかくだけ

>>224
const付けたいんで
const *p = malloc(aru_size)
if(!p)
{
 /* err proc */
}

>>235
またおかしい奴が現れたよ(w

　 （　・∀・）　　　|　|　ｶﾞｯ
　と　　　　）　 　 |　|
　　 Ｙ　/ノ　　　 人
　　　 /　）　 　 < 　>__Λ∩
　 ＿/し'　／／. Ｖ｀Д´）/ ←>>235
　（＿フ彡　　　　　 　　/

>>225
関数の返り血がレジスタに返って来ると、変数に格納し、次の if で
またそれを load するけど、続けて書くと load が省略されるってのが、
以前はあったように思う。（なんせ cp/m 上がりなもんで）

しかし、このスレ、みんな見ているんだ。オカシイ。

>>224
てゆか、最適化されるだろ。

>>222
もし a=0 の時、１行目で bの値が確定しているにも
かかわらず、無駄な処理が３行も続いてるが？

NULLって\0であり0とは違うときいたことがあるのだが？と突っ込んでみたり。
スマン。

まあ、オレのC言語におけるマナーは「明示的に書け」
たとえば、こういうifの記述はやめて欲しいなあ。

#include <stdio.h>

#define TRUE 0

unsigned int var;
var = 1; /* zero or one */

if (var) /* (var == TRUE)とかしろよ */
{
printf("ex");
} else {
printf("ex2");
}

書いといてなんだが、あまり入門書に取り上げらていなかったりする。
おもにひとつの関数の機能切り替えに使われるもので
古いソースによく出てくきたりする。答えは実行してみればわかるけど
booleanだな。

貼っておきますね。
http://lagendra.s.kanazawa-u.ac.jp/ogurisu/manuals/c/C-faq/C-faq-05.html

>>242
TRUE = 0はヤメロ、数値ならenum使えってカニさんが言ってた気がする。

if(var)なら同意するけど、if(isdotdot)ならオイラは書かないほうが読みやすい。

>>242
NULLは空ポインタ。
\0をnullと呼ぶこともあるが、別物。


> if (var) /* (var == TRUE)とかしろよ */

俺だったらフラグとして使うから

#define VAR_TRUE (1<<0)

if(var&VAR_TRUE)

のような感じになるかな。
こうしとけば将来 var が拡張されるとしてもバグが出にくくなる。

頼むからstdbool使ってくれ

if (((var == TRUE) == TRUE) == TRUE ...)

bakadomo
ga

>>246
こんなのだったらどうする？
#ifndef __stdbool_h
#define __stdbool_h
#include<windows.h>
#define true TRUE
#define false FALSE
#define bool BOOL
#endif

貼っておきますね。
http://lagendra.s.kanazawa-u.ac.jp/ogurisu/manuals/c/C-faq/C-faq-09.html

>>246
C89準拠なソースを保守とか、混ぜて使うときってどうしてる？
新たに書いた部分だけでもstdbool.h使う？

チョウチン持ちするわけじゃないけど、「Ｃプログラミング診断室」とかいう
記述があり、なかなかのことが書いてあり、感心した。
思いつきだが、Ｃのソースを食わせると、はい何点なんてレポートを出す、ア
プリケーションなんて、ありそうに思えたけど、ないでしょうね。

lint

点数はでないな。カラオケみたいには。

enum BOOL{
TRUE, FALSE
};

うにっくすの薀蓄師匠が、けっこうこういうのにうるさいんだよな。

珍テクニックというのは、考えなしに生み出されるものではなくて、
まじめに考えたあげくに作られるものなのだなと、このスレを見て思った。

>>241
まずは可読性が第一。elseが無い方がすっきりしていて見やすいコード。
最適化はコンパイラに任せておけば良いし、最適化されなくてもそんなに遅くなる
わけじゃない。

すっきりしていて見やすいとか言ってるけど、ロジックが変わってるじゃん

>>252
やっている人がいるんですねえ。

身勝手な寡頭制とか言い出してロジックミスに気づかんヤシはクソグラマ

>>257
ﾜﾗﾀ
今年度最高の基地外だな

elseがないほうが可読性が高いって、可読性をすごい低いレベルでとらえてませんか?

たぶん、カラムが揃ってるとか、キーワードが少ないとか、そういうことを意図してるんじゃないかな。

普通に考えればこれで良いじゃないか。
if ((unsigned)a <= 3)
　　b = a;
高速化を狙うならこっちが良いかもしれない。
b = a | 3; /* 2進数での11*/

>>264
あんた、問題の本質どころか何が問題なのかすらわかってないね。

トリビアの種に応募して世界中のCのコーディングスタイルの平均を決めてもらおうぜ

>>257
elseがない方が意味が不明瞭になって可読性は下がるとおもうがな
プログラムの可読性ってのは
ただ単に「読みやすい」ではなく「分かりやすい」だろ？
メンテナンサビリティが第一だな、開発時効率ともいう
（要求を――性能要求も含めて――満たしているのは大前提としてな）

だいぶ前のオレのレスで軽く盛り上がってるな。
趣味グラマのオレは「ぱっと見きれいでいいじゃん」ってことで>>222にしてるわけだが。

elseつけないからって演算結果が変わるわけじゃないし。
分岐予測ががんばってくれるかもしれないし。
キャッシュの振る舞いがｺﾞﾆｮｺﾞﾆｮなって逆に速くなるかもしれないし。
速度なんて気にしてないし。

いいじゃん。

だからswitch使えよぼけ

>>268
書き込まないでよあんなコード。
参考にならないどころか害にしかならないから。

速度気にしてないなら、それこそセオリックに書けよとおもうが。

else使うところはelseを使って、switch使うところはswitch使えばいいじゃん。

「結果は同じだからelse消しました。きれいなコードになりました」
↑気のせいです。

一見，初心者ふうのこんなコードがあったとします．

if ( x > 0 ) a = 1 ;
else if ( x == 0 ) a = 0 ;
else a = -1 ;


　さて，コーディングレベルが上がってくると

a = ( x >0 ) ? 1 : ( ( x==0 ) ? 0 : -1 ) ;

（中略）

さらにレベルが上がってくると

if ( x > 0 ) a = 1 ;
if ( x ==0 ) a = 0 ;
if ( x < 0 ) a = -1 ;

　こう書いたりするのです．

ttp://member.nifty.ne.jp/yamazaki/doc/code_design/vol03.html

>>272
この人はデータ指向プログラミングという独自スタイルを貫いてるからいいのでは？

これがミソですとか言っちゃってるしｗｗｗ

>>272
ふつうはこうだろ？
a = (x <0) ? -1 : !!x;

>>275
え？

>>273
ﾜﾗﾀ
とんだ権威主義者だな。
見易さだけなら桁そろえればいいだけ。
if　　　　( x > 0　 ) a = 1 ;
else if　( x == 0 ) a = 0 ;
else　　　　　　　　 a = -1 ;
コメントなしにいきなり>>272みたいなコード書かれたら
バカなのか基地外なのか判断に困って迷惑なだけ。
確実に視点がそこで停滞する。

>>275
ふつうはこうです。
a = x < 0? -1: x > 0;

>>272
そしてさらにレベルが上がると、一周して

if ( x > 0 ) a = 1 ;
else if ( x == 0 ) a = 0 ;
else a = -1 ;

こう書くようになります。

皆さんがSTLというとまず思い浮かべるコードは

cout << "Hello\n" ;

のようなコードではないでしょうか．

Cのマナーいろいろ
1 名前： デフォルトの名無しさん 投稿日： 02/08/17 20:35
皆さんがCのコードを書かれる上で決めているマナーを教えてください．
例えば，コメントの書き方，関数の説明など．

>280
何をどう突っ込んでほしいんだ？

なあんだ、 Vol 6 か。

何で、こんなトンデモ野郎が奥村先生と共著で本書いてるんだ？

>>284
yz1作ったから

>>272
名前の上を見ると……

豪快な釣りでつか(´･ω･`)

>>286
ちょっとうまい。
でもこの人「漁師プログラマ」改め「武蔵流プログラマ」って名乗るけど。

枠ピタXPで動かないし・・・

>>272
この人で印象的だったのは
「Javaには(C++のような)デストラクタがありません」
とサイトに書いていて、掲示板で
「それは間違いです、Javaにもfinalize()があります」
みたいなツッコミされて
「ごめんなさい、まちがえてました」
と謝ってたことだな。

Javaのfinalize()はC++のデストラクタの代わりには
ならないってことは、入門書でも読んでればわかる
ことだから、Javaがよくわかってないであんな文章
書いてたんだなとｵﾓﾀよ。

DeefFreezer愛用してます

yz2はどうなったの？

おまいらブロックの書き方で

if(){
}

と

if()
{
}

どっち？漏れは下、会社の都合なんだけどな

C#も後者だから後者

>>292
関数は
type function()
{
...
}

その他は
condition () {
...
}

if (...)
{
...
}
else
{
...
}

if (...)
{
...
} else
{
...
}
この2つだったらどっち？漏れは上だけど。

>>295
前者だな
キーワードと}を揃えるなんて汎用性がなくダサイ

if (...) {
...
} else {
...
}

こうですが！

スタイルがすでにあるコードならそれに従うが、
スクラッチで書く場合は
Cなら
if ()
{
}
else
{
}

Java or C++なら
if () {
}
else {
}

でも Cの場合の↓はなんとかならないかといつも思ってる。幅取りすぎる・・・。
}
else
{

あと、switch内のcaseのインデントはいつも悩ましい。。。

if () {

} else {

}

でしょスタンダードは。

>>278
ふつうはこうです。
a=(x>0)-(x<0);

if(){}else{}
に決まってるじゃん。
じゃないと、七行に収まらないって

>>301
;までを一行とするならif-elseは2行絶対消費する

>>302
きっと半角80文字（改行文字含む）が1行でしょう。

>>299
自分は逆派だから、なぜわざわざ括弧の高さをずらして書くのか分からない。
昔は表示領域が小さかったから、小さく書くためにそういう書き方をしていて、
表示領域が広くなった今でもそのままその方式を使っていると聞いた事はあるが。
これなら分かるんだけど。
if () {
　　hoge();
　　foo(); }
else {
　　test(); }

Pythonを見習え。

>>304
制御構文と他の文がごっちゃになってるからヤ。

/*やっぱりラベルはインデント無しで
一番左だろ？*/

int main(int c, char ** v)
{
　switch( c ){
case 0:
　　break;
case 1:
　　break;
default:
　　break;
　}
　return 0;
}

>>307
俺はswitchと合わせたいんだけど、

switch( c ){
case 0:
　　break;
case 1:
　　break;
}

VCのIDEがやたら下げたがる・・・
switch( c ){
　　case 0:
　 break;
　　case 1:
　　　　break;
}

switchがネストしてたら、わけわからんな。

switch(c)
{
　case 0:
　　break;

　case 1:
　{
　　int a;
　　break;
　}

　default;
　　break;
}

これ以外のインデントは一貫性に欠け、
非論理的であると思われます。

制御文を goto だけで書く

>>311
現実的に無理。条件分岐ができない。

if位認めてやりなよ

switch(a)
{
　case 0:
　{
　　hoge(0);
　}
　break;
　case 1:
　{
　　hoge(1);
　}
　break;
　default:
　{
　　hoge(0);
　}
　break;
}

>>312
関数ポインタ

switch(a) {
　　case 0:
　　　　hoge(0);
　　　　break;
　　case 1:
　　　　hoge(1);
　　　　break;
　　default:
　　　　hoge(0);
}

こうですが！

int x = 0;
switch (a)
　case 1:
　　x = a;
hoge(x);

構造体のバウンダリ調整用のfillerメンバって、やっぱマナーなのか？

そんな処理系依存なのはマナーどうこうじゃないだろ

>278
こうだる。
値の変換するなら関数にしてほすぃ。

a = sgn(x);


int sgn(int x) {
if (a > 0) return 1;
if (a == 0) return 0;
return -1;
}

あ、マナーの話忘れてた。
このふたつはやめてほすぃ。

if (a == 10) {
/* 何もしない */
}
else {
/* 処理 */
}


if (a == 10) {
/* 処理 */
}
else;

それもやまざきさんがやってなかったっけ？

a == 10をa != 10にしただけで脳に負担がかかる人間は正直プログラマには向いてないと思うよ。

判定文に一貫性を持たせるためです。

>>323はプログラマには向いてない

俺は否定演算子が必要最小限になるように調節するな
デ・モルガンまんせー

>>321
修正した結果として /* 何もしない */ ことになった場合、
前者のように残しておくことが多かったりする。

デ・モルガンってはじめて聞いた。
ド・モルガンだろ。

>>327
残しておこうが、消そうが、コンパイルされると、jump が入ると思ったが。

>>328
あは。俺やっちゃったｗ

やめてほしいこと。

ソースファイルを編集したあとに、古いコードを #if 0 〜 #endi やら /* */ で
括って残しておくこと。

cvs diff しても #if 0 と #endif の行しかひっかからない。

>>331
ソースは書く時間より読む時間の方が圧倒的に長いですから
なるべく読みやすくして欲しいですよね。
このコードなんやねんってサーチしたら、結局どこからも呼ばれてなかったってのは
勘弁して欲しいっす。

まあコーディング規約とかが別会社で決まっててどうしようもないこともありますが。

自身がないからって過剰に( )つけるのやめれ。
おめえら演算子の優先順位と結合規則くらい覚えろや。

>>332
そこで問題です。「読みやすさ」って何?

if ((x == a) || (y == b)) { /* ゆるす */
　　z = (c * x) + y; /* 勘弁して */
}

>>334
その答えは十人十色

>>335
それは過剰ですか？

>>334
問題も何もコメントアウトしたコードが大量にあると読みにくいって話でしょ。

#ifdefのネストやだ

>>335
(*printf)(("%d\n"), (("\n"),((x)*(y))+(a)));

if ((x == a) || (y == b)) { /* ゆるさん */
　　z = (c * x) + y; /* 小学校からやりなおせ */
}

if ((x == a) || (y == b)) { /* まあいーんじゃない？ */
　　z = (c * x) + y; /* まあいーんじゃない？ */
　　return(0);　　　　/* 帰れ */
}
switch(hoge) {　　　/* 空白あけろぼけ */
　　case(1):　　　　　/* 殺す */

hogeとか書いてる奴死ね

>>343
つまりあんたのことだね

>>344
わらた

if (...)
みたいに制御文のあとにスペースを入れるのってなんで?
関数と見分けがつきやすいからって理由なら、どうでもいいやって感じだけど。

ここで聞いたら
C言語なら俺に聞け! Part 85
http://pc5.2ch.net/test/read.cgi/tech/1089136366/

>>341
マヂレスしちゃうけど最近の子供って、
加減乗除で何が優先されるのか知らないのが結構いるよ。

そもそもなんで乗算が優先されるの？
それによって何か論理的に有利なことがある？

>>342
今、D言語スレでcaseラベル問題が議論される。
case(1)
とかいう書き方だとミスを減らせるので、
むしろ推奨すべきじゃないか？
俺としてはアリだと思う。

出たよ俺理論・・・
350はif(0==a)とか書いてそうだな

>>351
割とかくよ。そういう書き方。
少なくともaがポインタなら絶対に
if(a)とかとは書かないな。
趣味プログラマだから世間のルールはしらない。
おかしいかな。
ソース公開してるけど、指摘を受けたことはないなぁ。
（誰も見てないんだろって言われるんだろうな…
　多いときには１日に数千件のアクセスはあるんだけど。）

>>352
そういう意味じゃないだろ？
if(a==0)じゃなくて
if(0==a)って書くだろって意味。

>>352
一人でコード書いてるなら何でもいいよ。

Cの麻奈

>>353
そっちか。
定数を左側にするのはあたりまえだと思ってたからスルーしてた。

>>354
そうだね

定数を左側にもってくるのって少数派だよな。

>>357
だって変数同士の比較だとその手段は使えないから。
それに最近は制御式の中で代入しようとするとウォーニングを出してくれるコンパイラも多いし。

"="と"=="をtypoする奴は私刑

>>350 が趣味グラマで、本当に良かった…ﾎｯ

mytype_tみたいな型名のコーディングスタイルってどっかにまとまってないですか？

caseについては>>342を見てイイと思っただけで、
やってたわけじゃないよ。
実際、あんまり見たこと無いからそれほどいいもんじゃないのかな。

定数を左に書くのは好みとか規約の問題であって、
一概に否定できるものじゃないと思う。
実際至るところで論争になってるから、
必ずしも少数派ではないだろう…　と思うんだけど。

http://www.google.com/search?q=%E5%AE%9A%E6%95%B0%E3%82%92%E5%B7%A6&ie=UTF-8&hl=ja&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=

>>362
定数を左に置くことで防げるバグなんて実質存在しないんだけど。
（警告が多すぎて見逃す危険性があるなら別だけどそれなのは論外）
害はないけど意味もない。

>>362
＞必ずしも少数派ではないだろう…　と思うんだけど。

引っかかってる19件を見たけど、左に置くのがよいって無条件に薦めてるのは
やっぱ少数派じゃん。

Javaのページで、定数を左に置くのがよいって薦めてる。

http://www.alles.or.jp/~torutk/oojava/codingStandard/writingrobustjavacode_p2_c2.html#id_590_
＞以下のコードを考えてみる。パッと見は両者はどちらも等価だが、
＞左側のコードはコンパイルできるが右側はコンパイルできない。

コンパイルできないなら、なんで定数を左側におく必要があるんだろ。
コンパイル段階でバグが発覚するなら問題ないはずだけど。

わかった。
代入を = じゃなくて := にすればいいんだよ。

a := x + y;

ばっちりだね。

>>365
お前、オレよりアホだろ。

しまった、釣られた。

俺は
void A(){
}
より
void A()
{
}
の方が好きなんだがどう？

またスペースだが
void B( int i );
より
void B( int i);
の方が好きなんだがどう？

>>369
上は普通。関数の { は改行するのがマナー。
引数内は空白入れるなら両方空けるのが俺は好き（マナーかどうかは知らん）

>>370
＞上は普通。関数の { は改行するのがマナー。
そうなの？
殆どのサンプルコードは前者だったりするから
それが主流だと思っていたが。

ループすてますね
すまそ

>>367
なんでだよ。

制御文と関数とではブロックの扱いは変えるもんだと思われ。
メンバ関数なら分からんが

俺は空白はめったに入れない派。
あるていど詰まってた方が自分的には見やすい。
だがそれを他人に押し付けたりしない。

自分のスタイル、つまりは価値観を他人に押し付けない、これこそ真のマナーじゃない？

行は詰まってた方が見やすい。

if (hoge == 1) {
  n++;
  foo(); }  //こういうのだけは勘弁して欲しい
else
  bar();

一貫してればなんでもいいよ。
ここで大騒ぎするほどスタイルが生産性に与える影響はない。
というかほとんどまったくない。

>>373
左を定数にする理由を理解してないから。
結果的にどっちがいいかを押し付けるつもりはないけど、
いまさら「なんで」とか言ってるのはスレを読めてない。


とか書くと「お前が読めてない」とかレスがつくんだろうな…

>パッと見は両者はどちらも等価だが、
>左側のコードはコンパイルできるが右側はコンパイルできない。

俺も一時期このスタイルをとっていた。同じように
コンパイルエラーによって実行時のバグをつぶせるという理由で。

でもやめた。

理由１
　たいていの場合、知りたいのは「aは1か?」であって「1はaか?」ではない。
だからif (1 == a) よりは if (a == 1)のほうが自然である。

理由２
　最近のコンパイラはif (a = 1) のようなコードにwarningしてくれる。
もし、意図的にそのようにしているなら、if ((a = 1) != 0) とすればよい。

if(!(a=1))

>>379
そこまで言うなら説明してみろよ。
わかってるふりするだけなら、誰でもできるだろ。

古い（公開の LSI-C の）コードをみていて気づいたのだが、
昔は、スペースの入れ方が少なく、１行に複数の命令を書いていたように
思う。640 x 400 の画面とかの影響が大きいのではないか。
タブも２バイトというのがある。

>>383
＞タブも２バイト
＞タブも２バイト
＞タブも２バイト
＞タブも２バイト
＞タブも２バイト

>>383
その画面だと50行にできるんだけどな。
43行にも。

Java では、整数値をbooleanに変換することはできないので
if (x = 0) { ... }
は、もともとコンパイルできない。
= と == を間違えれば、即エラー。

640x400の問題じゃなくて80x25の問題だろ。

>>386
で、何が言いたいのだろう?

Ｊａｖａは凄いよ、革新的だよ…て所だろ？
だからＪａｖａ廚は嫌われるのさ

違うだろ i-- が出来ないよという不便さを愚痴ってるんだと思われ

>>387
そうかもしれない。
しかし、まあ、矢印キーやJKLだかでカーソルを移動するのは、今思えば、
ご苦労なことだった。

>>388
>>365 のリンク先書いた奴はアホ、と言いたいんでは？
(確かにアホだとは思うが)

>>362
>定数を左に書くのは好みとか規約の問題であって
いや、指しゃぶる癖のある奴が常に指に絆創膏巻いてるようなもんだろう。

>>382
まだ解ってないのか君は…

俺が最近困っているのは
変数の型名に何を使うかだ。
どれを使うのがジェントルメンなのか・・・

WORDやDWORDってどうなんだろう？最近の流れだとUSHORT・ULONGっぽいが・・
unsigned longは長すぎて使う気しないし、どうすりゃいいんだぁ〜！！

BOOLってどうなんだろう？これって4Byteも使うんだよな・・
TRUEとかFALSEも非標準って感じがするし、やっぱboolにするべきだよなぁ・・
ああ！！しかしそうすると他はFLOATとかHRESULTとか大文字ばっかなのに
boolだけ小文字だっ！どうすりゃいいんだぁ〜！！

typedef bool BOOOL;

>>393
> まだ解ってないのか君は…

結局わかってないって繰り返すだけか。
説明できないなら逃げとけばいいのに・・・

>>394
stdint.h, stdbool.h使っとけ。なけりゃどっかから拾ってきてそのコンパイラで使えるようにすればよし。

>>393
言いたいことがあるならはっきり書け。と流れを読まずにｶｷｺ

> >>394
> stdint.h, stdbool.h使っとけ。なけりゃどっかから拾ってきてそのコンパイラで使えるようにすればよし。

>>396
Java は (>>386 によると) 違うらしいが、C で条件式書くところで
関係演算子 == をうっかり代入演算子 = と間違っても
コンパイルエラーにはならず
(処理系によっては警告くらいは
出るかもしれない) しかし実行結果は思った通りにはならない。
そういう些細なミスに因るバグで時間を潰すくらいなら、せめて
定数との比較のときは定数を先に持って来るようにすれば
コンパイル時に検出出来る。

…というのが「定数を先に持ってくる」意味なんだが、そういうのが
>指しゃぶる癖のある奴が常に指に絆創膏巻いてるようなもんだろう。
または
「ひとりでトイレ出来なくてオムツをしている人」
に見えるわけさ。

といっても、別に否定してるわけじゃない。
「早くオムツが取れるといいね」 とは思うが、「オムツが俺のスタイルだ！」
とか「ウチのプロジェクトでは、全員オムツをすること」とか言われると
先ずトイレの訓練しろよ、と思ったりする次第。

>>398 は、それ自身が「馬鹿レス」って事かな？

>>394
環境にあわせるのがﾁﾞｪﾝﾄﾙﾒｰﾝてモンでしょ。
Win API ブリブリ呼び出してる部分は MS の定義した型で。
環境に依存しない部分は ANSI で。
bool は、C99 なら stdbool.h 使う。そうでなければ
typedef char bool
#define true 1
#define false 0
としとけば、いずれ C99 になったときに変更が少なかろ。

>>399
ﾜﾛﾀ

>>400
> なけりゃどっかから拾ってきて

>>400
キモいから列挙子つかえよ

typedef enum bool{
　true,
　false,
}bool;

if(NULL==(fp=fopen("file","r")))

こう書く奴は定数を左に置く理由を理解していないな。

>>399
Javaで定数を左に置くことを薦めているページがあるけど、
もともと、そんなものは無用なんじゃないか。
(Javaでは比較と代入を間違うとコンパイルエラーになるから)

↑という意図の書き込みをしたら、バカとかなんとか
レスされたので、どこが間違ってるか説明を求めたのだけど、
説明は無しで「解ってない」と繰り返すだけ。

その絆創膏とかオムツとかの説明を読むと、俺が定数を左に
おくのを肯定してると勘違いしてるようだけど、どこを読めば
そう思えるのか。

コミュニケーション不全症候群

>>403
true が0ってものキモイな。

>>399
== を = と書いちゃうのはおもらしというよりもタクシー車中ゲロに近いと思う。
つまり、体調によっては誰でも犯すミス。なので、防止策として定数を左におく
対策の比喩としては「オムツをする」ではなく「バケツを首にぶら下げる」が妥当かと・・・。

なぜそこまで頑強に警告を見るのを拒否しますか

>>408
どっちにしろみっともないので
そんな事しません。

>>408
いつの間にここはネタスレになったんだｗ
せめて「ゲロ袋を常備しておく」くらいにしておけよ。

>>411
最初のほうはネタスレですが。

>>393>>399>>408
うまいこと例えてるな。

>>397
拾うほどたいした中身でもないぜ、旦那。

たとえ話で、あーでもない、こうでもないと言い合うのってバカらしいよな?

>>404
なんかマズいの？

>>416
そもそも定数を左側に置く理由は比較と代入を間違えてもエラーにするため。
fp=fopen("file","r")
けどここを==にしてもコンパイラはエラーも警告も出してくれない。

っていうことだと思う。

if((fp=fopen("file","r"))==NULL)

こう書いても良いって意味なんじゃないの?

>>417,418
そんな順番をきちんと考えてから書くやつが=と==をtypoするなんて考え難い。

ていうか=,==間違えて実害こうむった奴なんていないだろ。
そんなの東京でアルカイダのテロにおびえるようなもんだ。


と混乱させてみる。

おまえら、==を=と書くバカの心配をしているのか？
バカはそんなに甘くないぞ。

俺のところには!=を=!と書いたバカがいた。

if (a =! 0)

こう書いてもエラーにならないことに初めて気がつかせてもらったよ。

>>421
何か置き換えが出来そうな勢いだな

テンプレ

------------------------------------------------------------
おまえら、==を=と書くバカの心配をしているのか？
バカはそんなに甘くないぞ。

俺のところには○○を××と書いたバカがいた。

if (a ×× 0)

こう書いてもエラーにならないことに初めて気がつかせてもらったよ。
------------------------------------------------------------

○○と××を埋めよ。ってことか? >>422

おまえら、==を=と書くバカの心配をしているのか？
バカはそんなに甘くないぞ。

俺のところには<=を->と書いたバカがいた。

if (a -> b)

こう書いてもエラーにならないことに初めて気がつかせてもらったよ。

>>416
if((fp=fopen("file","r"))==NULL)をif((fp=fopen("file","r"))=NULL)
と書き間違ってもエラーになるから。
定数を左に置く理由を理解していない証拠。

>>425
その前に定数を右におく理由を考えたらどうだ?

>>426
その方が自然だという理由しかないが。
それになんか勘違いしているようだが、俺は定数を左に置いたりしていないぞ。

if (a == b)
で、a, b ともに変数として
aとbどちらを左に右にするんだ?

>>428
バッキャマラドゥ！頭使え、頭！

if(1== (a == b) )


できましたー

お前らバカ

俺が目をかけてる変数が左
その秘蔵っ子と見比べるのが右

こんなの常識

>>425
>if((fp=fopen("file","r"))==NULL)をif((fp=fopen("file","r"))=NULL)
>と書き間違ってもエラーになるから。
だから>>404の様にしたいんでしょ？

それが理解できると、
何故、「定数を左に置く理由を理解していない証拠」
になるのでしょう？？

>>431
>>425　じゃ無いけどお前もうちょっとよく読めって

if((fp=fopen("file","r"))=NULL)はエラーになるんだよ？

>>431
うっかりif(a==1)をif(a=1)と書いてもエラーにならない。
でもif(1==a)と書いていれば、もしも==を=と書いて(if(1=a))しまったときにエラーになって素早く検出できる。
これが定数を左に置く理由。

でもif((fp=fopen("file","r"))==NULL)の場合は==を=と書き間違えればエラーになる。
わざわざ定数(ここではNULL)を左に書く意味はない。不自然な形にするだけだ。

だからこう書く人は定数を左に置く理由を理解していないというわけ。

>>432
その場合はでしょ
でも統制をとる為に、あえて左に書いてる人も
何故、「定数を左に置く理由を理解していない証拠」
になるのかと・・・

すなおに、「aはbと同じか?」ならa == bにすればいいだろ?
「bはaと同じか?」ならb == aだ。

「aはbより小さいか?」ならa < bだし、
「bはaより大きいか?」なら b > aだ。

結果的に同じかもしれないが
結果あっての意図ではなく意図があっての結果だ。

お前の意図をそのまま表わせ！
どっちなのかわからねぇって言っているやつは
自分がコードに何をさせたいのかわかっていない証拠だ。

設計をもう一度考え直せ！

>>433
ああ、君が言いたい事がわかったよ
右に置いてエラーがでるのが分かってれば、極力右に置け、と

>>433
>素早く検出できる。
警告とエラーで検出速度はまったく変わらないわけだが。

ちなみにC++だとif((fp=fopen("file","r"))=NULL)は通るんだよなぁ。

わざわざNULLを書く奴はバカ

FAQ読みたて厨が湧いてるようで（笑）

if(!(fp=fopen("file","r")))

>>439
ここはCのテクニックを語るスレではないんだぞ。マナーを語るスレだ。
整数でない場合は型を分かりやすくするために書くのは普通だ。

NULLがわかりやすいと思ってる奴はバカ

狭い範囲の条件で定められたルールがないと
コーディングに不安な人たちが集まっているスレはここですか？

>>444
ルールじゃない！
マナーだってのがまだわからんのか！
コノヤロウ！

>>445
マナーがなってない香具師ﾊｯｹｿ。

↑「俺マナー」でしかないと思うが

>>445は俺マナー

K&RやBSDスタイルとか、GNUコーティングガイドライン辺りの
デファクトスタンダードに合わせとけ

つかVC7、if文の中で代入しても警告でねーし

レベル4にしたら出たけど、他のも鬼のように出た。
"引数は関数の本体部で 1 度も参照されません。"ってのが大量に出るウゼー

それに"条件式が定数です。" っての、wchar.hでも出てるし。手ー出せん。


みんなどうしてるの？

>450
気になるならif文中に代入文書かなきゃいいじゃん。
俺は気にしないが。

if括弧内の条件式に代入があるか判定するプログラムでも作れば？（笑）

いや、if文の中で比較と間違えて代入したら警告出るとか言われてるけど、レベル上げないと出ない
レベル上げるとどうでもいいような警告が大量に出るんだけど、ソコラへんをどうしてるかを聞きたいわけなんですが

#define is ==
#define isnt !=

if (a is X)
やったら、殺す。

>>452
こんな低次元な議論しかできない連中に
んなもん作れるわけないだろ。

>>454
じゃあ氏ねよ

Ans = 455 && 連中

lint使えよ
バカども

>>452
すでにあるよ。もちろん機能はそれだけじゃないが。

ｱｯｿ

その程度の問題は、普段日ごろ注意力で片付けられる問題だろ？
ツールなんかに頼らなくても。

不注意なヤツはいくらツールや仕組みに頼っても
ツールや仕組みを破る方法をいくらでも編み出してくる。

だから、そんなことをしても無意味。
それよりも、注意深くコーディングするとかK&Rを読破するとか
そういうことに時間をかけたほうが有意義。

無意味とか、有意義とか、そういう問題じゃないよ
おまえら、てすとふぁーすと
って知ってますか？

>>458
lintクリーンソースはウンコソース

あなたが気づけばマナーは変わる。

コメントはきちんとつけろよ。
返り値もわかるようにな！
残念！

ウンコとか言う奴は消房

>>466
おとなはうんこそーすのかわりにどんなひょうげんをしたらいいですか？

クソース

コードとは設計の反映なんだよ。
設計意図を無視して、右辺にあるべきものを左辺に置くのは本末転倒だ。
それに、その程度の問題はちょっとした注意力で防げる問題だ。

なにがてすとふぁーすとだ。
ちょっとはやっているキーワードならべりゃいいとでも思っているのか？
設計が反映されていないコードをテストしたって意味がねぇだろ。

(´д｀)なんかこう、C関連のスレって週に一度くらい、どこかのスレがとんでもないバカな話題で急激に伸びるのな

おまえら>>351の辺りからずっとやってんの？

HSPすれはいつもばかなわだいでのびてるようなのでこっちもがんばらないとだめだとおもいました

>>356
ワラタ

女っ気がなくてとんがっている雰囲気だな。昔の軍隊ならたまには繰り出そう
なんてなったんだが、今はなんだ、合コンしようかかな。

>>472
低いほうのレベルに合わせて対抗するようなﾔｼは
このスレから出て逝け

で、結論は? やっぱ定数は左?
早く出してくれないと、週末までのコードが間に合わないんだけど。

なんで「やっぱ」なんだ？
定数は右が常識。

>>476
コードとしてのフォーカスが当たってる方が左。
＞が大なりで＜が小なりって呼ぶでしょうが。

右か左かは定められない。意味から判断する。

意味を判断できなくて、どうしても定められなくては困る人向けに言うと
「変数は定数と同じか」をテストしている場合がほとんどなので
左辺に変数、右辺に定数を置く。

なんだ結論が出たじゃないか。めでたしめでたし。

==と=なんていうほど間違えんぞ？
ＶＢ帰りだと時どきそう打っちゃうけどすぐに気づくし。

不等号は特に明示的な理由がなければ＜を使う。
数直線のイメージと、
効率から（こちらはＣ++の話でＣには関係ないけど）。

左辺値は左辺へ、右辺値は右辺に置くよろし

>>481
左辺値どうしは？右辺値どうしは？
と脊髄反射してみるテスト。

補助輪を馬鹿にしてはいけない。
必要な人には必要なんだから。

補助輪を与えるまえに、自転車の乗り方をマスターさせましょう。
おそらくいつまでも補助輪がとれません。

そんな情けない状態が長くつづくのは
本人にとってもチームにとってもよくありません。
レベルの低い人に合わせていると、きりがありません。
どんどんチームのレベルが下がります。

みんながチーム開発をやっているとは限らない。
中には純粋な趣味で開発をやっていてなおかつコストパフォーマンス度外視して
珍妙なコーディングスタイルに凝るという楽しみ方をしている人間だっているんだ。
アメリカのように一方的に自分の正義を押し付けてはいけないな。

マナー＝デファクトスタンダードだから、珍みょらまーにはいってもらわんと。

>>485
同様にみんなが、そんな楽しみ方をしている人間とは限らんよ。

別に自分の正義を「押し付けている」わけではない。
俺が言ったことを守らないと生活や命にかかわるのか？
ぜんぜん無視する事だってできるぞ。それでも押し付けか？

人には意見がある。その意見を言うのはかまわんだろ？
あなたにも意見があるだろう。当然、言ってかまわない。

コーディング規約に従う従わないはマナーとは関係ないでしょう

if (0<a && a<10)
if (0<a && 10>a)
if (10>a && a>0)
if (a<10 && a>0)
どれも一緒だけど、判りやすい書き方すればいいんでない？

(´-`).oO（if (!a) は if (0==a) とイメージしてしまうんだけどね）

警告レベルは４、警告をエラーとする。

コメントに遺書を書くのはやめてください
夜中に発見したのでもの凄く怖かったです

>>491
/* 僕はぐっすり眠れる世界へ行っています */
とか？
労災認定できんかな。

>>491
ﾜﾛﾀ

保守してるソースに
/*　後で削除するにょ */
とか書いてあるのも萎える

「にょ」か…

/* 以下のコードスタイルは私の責任ではありません　*/
ってのがあった。

>>496
スケープゴートにされて切れたんだな

コメントも宮大工なみだな。

宮島大学工学部？

>>499
goo で４件出てくる。

「返り血」と「戻り値」どっちが好き？

返り血は人を切った時
戻り血は献血した時

別にハの字に置いたかて、ウェイターさんは勝手に回収してまいます

>>503
ウェイターにもマナー教育が必要ってことだな。
だからといって客にマナーが必要無いってことにはならないけどね。

古いネタだが、○orry って人のページを見たら、
if (定数 == 変数) ... のパターンばかりだった。
このスレ見ていたお陰で、驚かずに済んだ。それと、
catch(...){...} って、一杯並べてもいいことを初めて知った。

>>505
実際にはあまり並べなくてすむように、
例外はひとつのクラスから派生させる。

って、今更なんだけどこのスレはＣ＋＋もあり？

C++は最上位クラスが無いのが糞
C++は最上位例外クラスが一般化して無いのが糞
糞糞糞

最上位クラス
void *

マナーのスレなのにビロウな語り口だ。

age

VC++のときだけは
void main(void)
と書く

>>511
なんで？

コメントは英語

/* I'm not good at English, so I write comments in Ro-maji */

以下のレスも英語で↓

↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑

→

まいん（）｛
ｐりんｔｆ（”へっぉをｒｌｄ！”）；
｝
これで動く

コメントの話。仕事柄、人のソースの手直しをすることが多いんだが、
その際にどうしようもないソースがあると「indent -kr」してとりあえずインデントをつけてから見ている。
(注1：indent -krしたソースでコケることがある、コメントのせい等)
(注2：とりあえず知らない人は使っておこう。オレはK&R派、他色々はman参照のこと)
で、思ったんだが最低限のマナーとしてコメントは分かりやすく作ってほしいんだよな。
例1：
/* ループカウンタ */
int i=0;
コメントを付ける位置が一律右上になっている、まぁそういう人も居るんだろうが、同じ列に書ける時まで右上に書くか？第一分かりきったことを書くなよ…
必要ないコメントはうんざりだ。ついでに意味の無い初期化もどうか？
例2：
/*
*
* 指定のObjectを描画処理とConnectする。
*
*/ ret = srcdspcnt() ;
突っ込みどころ満載。まず1行コメントを5行の箱型コメントにする必要はあるのか？指定とか描画とか処理とか抽象する言葉を多用するな(使うなとは言わん)。
カタカナ英語を何でも英語にするな、英語かぶれか？もちろんプログラマとして英語を多用するのは大いに結構だが一般的な日本語で書け。他色々あるけれどうんざりだ。
例3：
何が何でも必死に関数や処理の右にコメントを書きつめるヤツ。
右を見ながら左の処理を見れば分かるように書いたんだろうが、150カラム目と0カラム目を同時に見るような研ナオ子の目はしていない。研ナオ子もびっくりだろう。

ちなみにオレは大まかな数行の処理は
/*************************************/
/* (1)●×ファイルのインデックスを */
/* なんだらかんだらでんがなまんがな */
/*************************************/
と処理の上に書いておき、細部または1行コメント等を処理の右に書いている。みんなはどうしているんだろう。

商用ソースのコメントにぬるぽと書かれていた

死ね

>>521
http://2chart.fc2web.com/2chart/warai.html

ドレン、貴様も言うようになったな

>>521
君には農薬バリバリに使った形のそろった野菜が似合う。

>>519
>指定とか描画とか処理とか抽象する言葉を多用するな(使うなとは言わん)。

コメントで抽象語を多用しない処理ってのは、
要するにその処理の「抽象度が低い」というだけの話であって・・・

コピペのオンパレードのコードに付けるコメントならば、
確かに殆ど抽象語を必要としないんだけどな。

>>525
抽象度の高いコードは普通一目でわかるのでそんなにコメントつけないと思う。

>>526
>抽象度の高いコードは普通一目でわかるので

貴方はプログラミングの神ですか？

>>527
>>抽象度の高いコードは普通一目でわかるので
>貴方はプログラミングの神ですか？

たとえば「指定のObjectを描画処理とConnectする」
なんてのはresult = onConnectInputAdd( FileObj , displayLoopWord , titleTable[ i ]->display() , titleTable[ i ]->argument[ 0 ] ) ;
とか書いていればコメントなしでもいい気がする。
もっとも、この関数がトリッキーだったり変数の値や名前が一意で無い場合はコメントをつけるべきだろうが。

>>528
コメントってのは実装方法じゃなくて仕様を記述するのは当然。
（当然ってのは言いすぎ？少なくとも最近の一般的な流儀。）
だからその場合に関してはコメントを書かなくてもいいのは当たり前。
そうじゃなくて、そのばあいを例にとって言えば、
onConnectInputAddの仕様（引数やら返値の意味とか）を
書くか書かないかってことだ。
その場合に内部的なデータ構造などについて説明を必要とするなら、
それは抽象度が低いといえる。

コメトンはASCIIで書けよ

「コメットさんは？」という問題を見たら
「大場久美子」って書けよ

>>522
AAにしてください

>>529
オレが意図を誤解しているかもしれないが、その点については悩ましいと思っている。

抽象的な関数とは機能が多岐に分かれているマルチな関数であり、
具体的な関数とは関数の用途が一意に決まっている関数と考えさせてもらう。
仕様という言葉でインターフェイス(I/F)と言い表すと、
設計という言葉で表すべきはその関数の使い方だろう。

I/Fの抽象度が高いほど、関数の使い方は多岐に別れて
冗長するが、関数の数は減り1関数の処理を追うのが容易になる。
(もちろんグローバル変数やgetsetの乱立等するとさらに厄介だしメンテが困難だ)
この場合コメントに頼る面が多くなりがちだ。

onConnectInputAddの仕様(I/F)を入力のみの4つの引数が
何かと接続する処理とした時に、接続する最低条件とマッチしている、
またはこの関数の動くシステムで一般的であるならコメントは不要だが、
4つの引数が不明瞭・説明不足ならばそれは抽象的でも具体的でも無く、
仕様ミスと言える。

抽象度が高いI/Fとは、
例えばメンバの多い構造体や子孫の多い構造体ををI/Fにするような事、
引数の多い物(多すぎるのは考え物であるが)となり、時に仕様と設計の説明が必要になる。
抽象度が低い＝具体的な場合とはその逆とすると、仕様と設計の説明が不要になりやすい。

結局、何が言いたいかというと
・抽象せず具体的にコメントを書いて欲しい
・コメントに頼るのでなく設計をコンパクトにして仕様を具体化した関数を作成したい
ということで。

PS:抽象化してコメントがある事がけして悪いとは言わない。
設計が明確ならそういう関数も産まれることだろうと思う。

う、すまん。なんか日本語おかしい。他のプログラマのことを言えないので切腹。
辞世句の代わりに「悪い…と思うコメント例4」を掲示

/* 20５0mSec先のアドレスがOutＰｕｔする秒数 */

1.半角全角の英数字を織り交ぜないでくれ…ブサイクじゃないか？
見栄えだけでなく、検索する時に使いにくい。

2:mSecとは何だ？SI 単位ではミリ秒の事をmsと書くのだが。
変数関数に単語に大文字を混ぜるのは使い勝手上、必要と
思うが書類やコメントでこの表記は無いだろう。

3:OutＰｕｔする＝出力するでは？
前述にかぶるが、
他にもOpenする＝オープンする、FloppyDisc(誤字)＝FloppyDisk＝フロッピーディスク
等と、このソースでは見た。

4:mSecと書いた上で秒数と書く、かぶっている。

>>529
>内部的なデータ構造
構造と内部的がかぶっている。

>>533
>抽象的な関数とは機能が多岐に分かれているマルチな関数であり、
>具体的な関数とは関数の用途が一意に決まっている関数と考えさせてもらう。

普通、抽象的な関数と言えば、汎化された(generic な)関数だろ？
STL 内のメソッドみたいに。

機能の豊富さとは何の関係もない、つーか、
一般的には、より「単機能」である事のほうが多い。

STL 内部のコメントでも、抽象名詞を使うの禁止！
なんて言われたら、STL 実装者は逃げ出すぞ・・・

びみょーに、双方の論点がズレている……

GenericsもオーバーライドもCには無いので関係ないな。

私が言う抽象・具象の区別

・抽象的＝インターフェイスと機能だけ分かってれば使える
・具象的＝内部の事柄まで明かさないと使えない

直接的なデータを隠蔽してハンドルとしてやりとりしたり、
実装にかかわらず複数種類のデータに同じインターフェイスを与えるのが抽象化の代表例。
ＳＴＬは抽象化の典型的な例。

>>537
ハンドルによって実際に処理に使われるデータを隠蔽するのも抽象化と言える。
もちろんＣ＋＋ほどにまでは抽象化は無理だけど。

[コメントのありようについて]
>>535
あぁ、日常的に抽象的な関数ってよく使用されている・・・のかな。
UNIX系でC言語が主なだけなので知識不足でした。
失敬ｍ（＿）ｍ

STLのメソッドは
ttp://www-ise2.ise.eng.osaka-u.ac.jp/~iwanaga/programming/stl/methods.html
こういう感じのヤツのことね。

オレの論点・マナーとしてあげたかったのは、C言語において、コメントを有効に使う。
という点でした。
”抽象”(反語として”具体”)という言葉を使った為に妙な展開にしてしまったかもしれぬ。

コメントははっきりと分かりやすく意味のある文章を書く方がいい。と思っている次第。

>>536 サンクス

[抽象的？具体的？具象的？]
>>538
論点のズレとして内部(関数の中身)と外部(外観・インターフェイス)の違いがあったのかなぁと思った。

オレは外観のコメントというイメージだけで上記を書いていたんだけれど、
引数の中身(型が整数・実数・ベクトルetc、構造体の違い)についての
コメントを書く事もあるんだよな。

オブジェクト指向言語におけるコメントの書き方はCのような汎用的な言語での
コメントの書き方とはまた違うんだと思うんで知らないが、構造体の説明をする場合ならC言語でもありうる。
その場合、構造体の名称だけという大雑把な説明で良い場合もあるだろうし、正確な説明でもいいと思う。

マナーという意味でいうなら、C言語は具体的であるべきなのかなぁと思う。
C言語ではそのSTLのように変数という概念だけでなく、双方向リストとか可変長配列等、型に囚われない手法ではないんで、
一意に関数が定義されるから。

高度なプログラムをしていくにつれて型の抽象化や関数の抽象化をさせると、
より良いプログラムができるとはおもうんだけれど、
C言語ではムリ。なのでインターフェイスを抽象的・具体的に分けると
抽象的：(機能が多岐に分かれている)キーが複数あったり、大きい構造体を含んだりする
具体的：機能が一意、その為引数も少ない。多くてもそれぞれの引数がはっきりしている。
というイメージを持った次第。

業務上ではよく「簡潔に具体的に報告しる」と言われるが、
そういう意味での「具体的な」関数を作ると
C言語のソースは見やすくなると思うのでマナーたりうると思う。

最後に、抽象的っつーと大雑把、具体的というと正確にというイメージなんだが、
具象的というと…文盲なんで良く分からね。

キムコ。

マジレスでくさくしすぎたんで、最後に簡単なマナーの提起。
int messageFlag;
BIT16 bitFlag;
long hantenFlag;

Flagとか一々付けなくても、変数がフラグなのは見てすぐわかるんだから名前には要らない。
特に、最後のlongでhanten(反転)って何だ？

マナーの話題かどうか分からないけど、今まで、COLORREF rgbColor の
中を見るときには、
int R = GetRValue(rgbColor),
G = GetGValue(rgbColor),
B = GetBValue(rgbColor);
としていたけど、
typedef struct{
BYTE R; BYTE G; BYTE B; BYTE A;
} RGBREF;
として、
前記の R の参照は、((RGBREF *)&rgbColor)->R とすると、コンパイル後の
コードも短くなり、速度も上がるような気になったが、読み難くなった。
皆さんはどっちを取る？

>>543
その struct(RGBREF) で R が最下位バイトになるって、規格で決まってるんだっけ?
COLORREF と RGBREF のビットイメージって一致する?

それはともかく、僕はマクロを使った方が読み易いかなと思う。
#define GET_RED(colorref) ((colorref) & 0xff)

>>543-544
GetR/G/BValueはちゃんとマクロになっている。
だからそのままGetR/G/BValue使え。

int R = GetRValue(rgbColor);
int G = GetGValue(rgbColor);
int B = GetBValue(rgbColor);
でいいと思うんだが。

みなさん、レスを有難うございます。
細かいことだけど、気になったのでテストしました。
DWORD rgbtest(COLORREF rgb){
int R = GetRValue(rgb), G = GetGValue(rgb), B = GetBValue(rgb),
rr, gg, bb;
rr = R; gg = G; bb = B; // 最適化抑止のためのダミー
return RGB(rr, gg, bb); // 実行コードがないとダメのようだから
}
というルーチンを用意して、もう一つは、Get?Value() を先の RGBREF
を使ったもので、1,000,000 回繰り返し呼んで見ました。333Mhzで。
Get?Value(): 60 ticks コンパイル後asm 10 steps 24 bytes
RGBREF : 54 ticks 8 steps 26 bytes
でした。Get?Value() はサイズが小さいのを再認識。

おいおい、テストする前にGet{R|G|B}Valueの定義読んどけヴォケ

>>543
スレタイどおりに話に戻すとノーマルバージョンと最適化バージョン併記して
#ifdefで切り替えられるようにしておく。
局所的な高速化だけなら>>544のようなマクロでラップはしないかもしれない。
こういうのはあまりソース管理ツールには任せないことが多いな。

スペースのインデントかタブのインデントかはっきりしろい

>>550
タブ

Cの麻奈

椎野麻奈

>>553
ﾊｧﾊｧ

保守。
ｉｎｄｅｎｔコマンド使いからのお願い。中確固は省かないで；；

確固

Cに限らない話だけど、
誤解を恐れずに言うと、「コメントを書かない」

コメントが無いと不安になるコードは、ロジックを見直すようにしてる。
でもまだヘタレなので結構コメント書いちゃうかも。

関数名の命名規則と引数の順番に一貫性を持たせる。

然るべき場所で構造体を使う。

ここからは好み鴨

インデントは原則tab
変数・関数名の長さでインデントの深さが変わるような場合だけスペース使ってる。

構造体はポインタ型を大文字で始まる名前にtypedefする。
typedef struct hoge_t *Hoge;

構造体をクラスとみたときにそのメソッドにあたる関数を作ったら、
第一引数はその構造体のポインタ型で、名前は this にする。
void Hoge_Destroy(Hoge this);

>>558
> 変数・関数名の長さでインデントの深さが変わるような場合だけスペース使ってる。
最悪

意味の無い typedef を使わない

> (注1：indent -krしたソースでコケることがある、コメントのせい等)

たいがいは#ifdefの裏側がコンパイル通らないせい。
コメントの問題でエラーになることはない。

> indentコマンド使いからのお願い。中確固は省かないで

こいつぼけ。1行になるような場合に中括弧を書かないのは当然。
indentコマンドが何か困るわけではないし。

>>562
ぼけとか当然と言われると、煽りたくなるんだけれど、さらっとやんわりと。

マナーとしての話だと>>556はマナーたりうるかということだが、

全ての1行で済む文を中括弧を書かない事に徹して困る人は居ると思う。
(例えば、2行に増やしたい箇所が多い場合は中括弧を書かなくてはならない、
1行に書くとその1行にコメントを付けにくい心境もあるのではないだろうか。
また、if1行のネストと各ifに対応するelseの場所を一目で直感的に判断しづらい。
中括弧があれば秀丸なり、VIなりエディタの特性で対応する位置は分かりやすい)
中括弧を付けておいて行数が増えるのが見づらいと言う人も居るとは思うが増えても1〜2行。

Pythonのような中括弧を付けないタイプの言語を使用していると、気にしないんだけれどね。

ちなみに私は必ず中括弧を書く。ちなみにDoCoMo、NECソフトウェア?のコーディングルールも中括弧を置くように指定している。

indentコマンドで中括弧の無い文を試してみたが、
別にindentコマンドで中括弧が無い文を間違える事はない。
ネストしていたりコメントが入っていると狂うのかな。そこまで調べないけれど。

>>563
はいはい、それはよかったね。

>>558
コメントは対人に納得してもらう為のマナーとしては要ると思われ。
「このプログラムは正しいです。バグはありません」と言っても、
システムが変更される日は来るかもしれない。その時、他人はメンテしやすいか否か。
関数名変数名が良くても限度はある。

インデントのタブとスペースは環境の問題もあるのでこれは割愛。

(関係はあまりないが、米国のGtkやＸのオープンソースを見ると、
インデントが3文字とか、2文字とか、酷いのになると5文字でタブとスペース入り乱れ等があった。
日本は4文字インデントが多いけれど、4文字をインデントにするのは
暗黙のルール？それともマナー？)

大文字の使用方法は千差万別コーディングルール任せ。マナーとしてただ一つだけ言えるのは
int *hogeHoge, HogeHoge, hoge_hoge ;
等、各種様々な書き方をすると思うが、マナーとして関数・変数名の区切り方法は統一した方が良いのでないかと。

typedefはマナーで同意。

C言語でthisキーワードに見立てる行為はマナー…なのかな。マイナーだし、Cで擬似的にクラスを作る人は少ないから。

気づいたので2点、マナーに提案。
・引数の並びは、(入力、入力、出力、出力)のようにする。入出力のあるポインタの場合は出力に準ずる。
・構造体型名には_tを、列挙型名には_eをサフィクスとして付ける(これもマイナー？)

>>564
えっと…負け犬？

>>565
そうかそうか、よーくわかった。

>>566
えっと…リアル厨房？高校生？精神が幼稚な大人も増えてるがまあ大学生くらいか？

・引数の並びは、(出力、出力、入力、入力)のようにする。

typedef enum {false, true} boolean_e;

これ使いにくいな

_tとかC覚えたてのころは使ってたけど、今では激しく使い肉い

_tは未だに使ってるなぁ。つーか、メインがC++に移行しちゃったから、
他人への公開用に用意していると言った方が正しいかも知らん。
わざとらしい例を挙げるとtypedef std::complex<double> dpoint_t;とか。

>>571
Cの場合_tで終わる名前は将来の言語仕様拡張のために予約されてるから、
あんまり使わない方がいい(現状では使用しても問題ない)。

ビタミンC飲まなあかん。

_tって言語予約だったのか。つけない方がいいんじゃねーか
やっぱstructはuppercaseだな

size_t

> _tって言語予約だったのか。
正確にはPOSIXで予約されてる、ということらしいです。

time_t

size_tってどうよ？律儀に使うもん？

>>579
使うよ

>>579
つかうもんよ。

>>579
使ってくれ。
サイズを全部intやlongで済ませる奴らUZEEEEE!!

サイズがサイズだってわかるのが重要なんだよねsize_t := size_t | size_t * intみたいな感じ(?)で、intと厳密に区別してコンパイルエラー出てほしいくらい。

俺も
typedef int position_x_t;
typedef int position_y_t;

position_x_t x;
position_y_t y;
ってやってるよ。

>>584
方向性は正しいが、話の流れからはちょっとずれてる気が。

>>583
サイズを厳密に区別しようとすると、たとえば配列のインデックスもsize_tに
しなきゃいけなくなりませんか？
size_t s = 10;
double array[s];
for (size_t i = 0; i < s; i++)
array[i] = 0.0;
みたいな。

size_t s = 10;
for(int i = 0; i < s; i++)

これはコンパイルエラーだね。

>>586
配列のインデックスはintでいいんじゃない?
添え字アクセスってポインタ演算のsyntax sugarだしね。
double d[10]
で d[i] とするのは *(d + i) と同じだけど、
d + i == (size_t)d + sizeof(double) * i
なわけで。
型がサイズを覚えてくれているから、普段はintを使えるですよ。

そうじゃない場合、例えば malloc の引数には size_t を渡すけど
double *d = malloc(10 * sizeof(double));
で、 10 は int で、sizeof(double) は size_t で、かけたら size_t。
sizeof(double) を掛け忘れたらコンパイルエラーになってくれると、ちょっとうれしい。

size_t と int を無条件で比較してる場合もエラーになってくれたらうれしい。
size_t / size_t が int になる、というルールがあれば、

int a[10], i;
for (i = 0; i < sizeof(a) / sizeof(int); i++)
を
for (i = 0; i < sizeof(a); i++)
と書き間違えるのを防げるしさ。

支離滅裂スマソ

>>588
> 型がサイズを覚えてくれているから、普段はintを使えるですよ。
あの、そういう話じゃなくて、size_tは処理系ごとにulongとかuintにtypedef
されてるわけでしょ？配列のサイズをsize_tで宣言しておいて、iをintとかで
決め打ちしちゃうと、sizeof(size_t) > sizeof(int)の場合にアクセスできな
い範囲が出てきちゃう可能性があるのはまずくないのかな？ってことです。
特にコードを違うプラットフォームに移植する場合とかね。

それは、配列の要素数はintで指定すれば問題なくない?
それでもって、添え字アクセスもint。

配列を宣言するときって、サイズ(バイト数)じゃなくて要素数だから、
size_t じゃなくて int でいい気がする。

あと、size_t は size_t か size_t * int のいずれかだ、とか
size_t / size_t は int だ とかいうルールは
typedefだけじゃたぶんどうしようもないので…
言語そのものへの不満ってとこでせうか。そろそろスレ違いか

抽象的、は断じて「大ざっぱ」ではないと思う。
抽象的かつ厳密なものってあるじゃない。
ただ、日常生活すべてに数学が適用できないから、
多くの物事に共通する事実を述べようとすると、結果的に大ざっぱになることが多い、
それだけのことだと思う。

>>591
そうかそうか。よーくわかったぞ。

俺は配列のインデックスにsize_tを使うよ。
strlenだってsize_tを返すし。callocの要素数を指定するほうの引数もsize_tになっているし。

>>588
sizeof(a) / sizeof(int)はマクロにすれば？

>>593
いや、588や590を読んでわかったんだけどsizeof()の返り値の型がsize_tなんだよね。
つまりsize_tはいわゆる「バイト数」を示す型だってことなんだろう。
それからすると配列のサイズ指定や添字にsize_tを使うのは(char[]を除いて)おかしい、
って話になるんだと思う……

と思いかけたんだが、callocのnmembがsize_tなのを見ると、やっぱりそういう
簡単な話じゃないんだろうなあ。やっぱ配列のサイズも添字も両方size_t
なのが一番「お行儀」がいいのかな？

ポインタ演算との等価性を考慮すると ptrdiff_t が一番行儀いいんじゃない？

callocの場合
・1byteのものをsize_t 最大分だけ
・size_t 最大byteのものを1個分だけ
のどちらも可能なように、あえてああいう引数になってるんだって。

>>595
K&Rに、例題のstrlenの返り値の型として「より慎重を期すのなら(ptrdiff_t
よりも)標準ライブラリにならってたぶんsize_tを使うだろう」とあります。

>>596
なーる。するとやっぱりsize_tは「バイト数」を表わす型ってことですかね。

>>565
引数の最初は第一目的語だろうな。
FILE*fdや、int fdや、pthread_t threadとか。
strcpyもmemcpyもdstだし。
結局、OUTなのかもしれんが。

構造体は、それを使う側に構造体を意識させる
(メンバを見せる)ならtypedefしない。
そのまま sturct hogehogeにする。

ついでに言うと、構造体の定義は(仕様として)構造を見せてはいけない。
メンバの紹介はいいが。
#どうしてもバイト列になっている定義がないと気がすまない人がいるが必要か？
#んなことするからエンディアネスを気にしないといけなくなるんだが。
#型とメンバ名と意味の羅列で十分だと思うんだが。

構造体を意識させない(つまり内部は秘密)なら、typedefする。
その場合のtypdef名は hogehoge_t とする。
実態の構造体タグ名はあくまで内部的なもので外部仕様にしない。

ってのが標準じゃないのか？
posixやiso/ansiを見ているとそんな感じなんだが。

教育age

>>565
>>558
typedef については同意できない。むしろやってはいけない。
構造体をtypedefし"struct"を無くすことについては賛成(C++ではもともと必要ないため)だが、
構造体のポインタを新たな型とするのはまずい。例えば
int func(Hoge a)
としたときこの関数を呼び出すとき引数として渡される変数はコピーされ呼び出し側では
影響しないと考えるのが普通だろう（Call by Value）。しかしHoge型がポインタ型である場合、
呼び出し側の変数を破壊してしまうかもしれない（Call by Reference）。
変数の特性は文法をもって把握したいよ。

>600
何のために C の文法に const があるの？

>>600
>>558は、構造体については(すべて)そのポインタ型を大文字で始まる名前にtypedefす
る、って言ってんだから、問題ないんじゃないの？

構造体へのポインタと、構造体自身と、両方が大文字で始まる名前にtypedef
されてると>>600の言うような心配もわかるけどね。

> 変数の特性は文法をもって把握したいよ。
これについては>>601が言い尽してるね。

>>602
>>600の見解はともかく、>>558 の
>typedef struct hoge_t *Hoge;
はMS流にconstモノもちゃんとtypedefした方が良いような気がする。
ついでにstruct自体もtypedefすることにして、

typedef struct hoge_t Hoge, *PHoge, const *PCHoge;
みたいに。

>>601
const性を強制・明示するためだよね。確かに例の場合constを付ければ話は解決。
だから変数の特性を明示できるように、ポインタに限らず、constもtypedefで隠蔽しないでほしいんだ。
ポインタをtypedefしちゃう人は>>603のようにconstも含めちゃう気もするし。
#601には意見を否定されたのか、補足されたのかよくわからない。
#例が悪かったのかもしれん。

>大文字で始まる名前
自分ルールよりはできるだけ言語仕様を活かしてほしい。

typedef で*,const,volatile,&,配列などを含めてしまうと、
宣言時にその特性がわかりにくくなってしまう。
だからMSのコードは必然的にハンガリー記法を使っている。
自分はハンガリー記法または、それに類する記法を強制されかねないライブラリは嫌いだ。
#・・・別にハンガリー記法が好きなら、なにも言えないけど。

ところで当のMSはconstポインタのtypedefを〜STR系にしか使っていない。
RECT/LPRECT/const RECT *のように構造体の場合constポインタはtypedefせずに使っている。

>>604
> 自分ルールよりはできるだけ言語仕様を活かしてほしい。
>
> typedef で*,const,volatile,&,配列などを含めてしまうと、
> 宣言時にその特性がわかりにくくなってしまう。

そんなこと言い出したら struct を typedef でくるむのだって、
宣言時に本当の型が何なのかわかりにくくなってるんだが。
typedef って単なる別名だし。

>>605
msdnでRECTひくと↓みたいな定義が出るので、門外漢がこれだけ見るとそう思うかもしれないけど、
typedef struct _RECT {
LONG left;
LONG top;
LONG right;
LONG bottom;
} RECT, *PRECT;

実際にはconst * 版のLPCRECTは各種interfaceのI定義で結構使われてますよ。
↓ソース
http://www.google.co.jp/search?as_q=LPCRECT&num=10&hl=ja&btnG=Google+%E6%A4%9C%E7%B4%A2&as_epq=&as_oq=&as_eq=&lr=&as_ft=i&as_filetype=&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=msdn.microsoft.com

確かになんでもかんでもconst版があるわけではないけど。

>>603
その調子で
volatile バージョンもちゃんと typedef した方が良いような気がする？
C++なら参照型も typedef した方が良いほうが気がする？

アフォか。

純粋に struct,enum,union を省くためだけの typedef 以外は邪魔。
前方宣言も効かないしエラーメッセージとも照らし合わせにくい。
初心者やライブラリユーザーがディープコピーとシャロウコピーを
間違えてしまう可能性も増える。
それに比べ得るほどのメリットがあるとは思えない。

>>608
個人的には
>純粋に struct,enum,union を省くためだけの typedef
ってのも、どうかと思うけどな。

>struct,enum,union を省く
C++があるから、違和感なく感じるんだろうけど、
純粋なCではあまり歓迎されることではないんだろうか？

>>610
C++ 以前はよくやってた手よ。
typdef struct {hogehoge} TypeName;
って。

>>610
それは >>608 の言ってる「省く」とはちがうだろ。
↓これに引っかかるんじゃね？
> 前方宣言も効かないしエラーメッセージとも照らし合わせにくい。

アンカーミスった
× >610
○ >611

>>608
>前方宣言も効かないし
不完全型宣言って、知っている？

>エラーメッセージとも照らし合わせにくい。
その前に照らし合わせにくい名前をつける方が
どうかしているかと思う。

>初心者やライブラリユーザーがディープコピーとシャロウコピーを
>間違えてしまう可能性も増える。
何か、>>608 のほうが大きな勘違いをしていそうな気がする。

>>614
「前方宣言」と「不完全型宣言」ってどうちがうの？
「不完全型宣言」を使うと LPCRECT に対して型の宣言のみができるの？

照らし合わせにくい名前については、
使う側には LPCRECT を使わせておいて、
エラーメッセージは const strcut _RECT が出るのが不味いって言う話だろ。
_RECT ならまだマシだが、どうせ typedef するからって
本当のタグ名をいいかげんに決める奴も多い。

>>615
簡単な例だけど

class clsA;
class clsB {
　　・・・・
};

class clsC {
clsA *pA;
clsB pB;
};

この場合、clsCのなかのpAはclsAを先に不完全にクラスであるとだけ宣言しても
使用することが出来る。なぜならポインタのサイズが分かっているから。
この場合を「不完全型宣言」といいます。

clsCのなかのpBはクラスのインスタンスそのものですから、clsBの完全な定義が
pB定義以前になければならない。最終的なclsCのサイズも決定できません。
この場合を「前方宣言」といいます。

失礼、Cのスレというのを忘れてC++で書いてしまいました。
Cで書けば

struct strctA;
struct strctB {
int a;
};

struct strctC {
struct strctA *sA;
struct strctB sB;
};

こんな感じです。
ちなみに、strctAの不完全型宣言ではtypedef宣言は出来ませんが、strctBではできます。

>>616-617
無知、思い込み。晒しage。

>>618
具体的な指摘を聞きたいね。

>>619
厚顔無恥。晒しage。
http://www.google.co.jp/search?hl=ja&q=%E5%89%8D%E6%96%B9%E5%AE%A3%E8%A8%80

(　´д｀)

struct strctA;
struct strctB {
int a;
struct strctA *sA;
struct strctB sB;
};

リテラル文字列のポインタはconst char*とすべし

あげあげ〜すれあげ〜！

>>623
そうかそうか。それは素晴らしいマナーだな。うん。感心したぞ。

時と場所に依るが俺はconst char *constにすることもある。

>>626
そうか。うーん、なるほど。それは素晴らしいアイディアだ。

そもそもリテラル文字列はマクロ定義するね
オレは

>>628
俺もそうなんだが。旧い流儀だって言われるｗ
確かにconst char * の方が小さくなるんだけど

旧い流儀かどうかって言うより、「リテラルならマクロ」っていうやり方がいかにも頭わるそ

つーか、今のコンパイラならリテラルの共有くらいできるだろ?

なんかもう、>>4が全ての答えだなｗ

>>631
処理系依存の機能に頼るところが
一番頭悪そう。

マクロとか最適化とかそういうことじゃないだろ
char*じゃなくてconst char*にするってこった

何もしないことを明示したいときにやる

ごめ、635 はとんでもないとこにレスしてた。

>>633
C++とかインライン展開最適化されることを前提に作ったりしませんか？

しません

最適化等の環境･処理系依存を前提に組むのは、それだけだと問題があると思うが

其れによって効率良くコーディングを進め、バグの少ない物を作れるのなら、「ある程度」のコンパイラ依存は容認しては･･？

意味もなくポータビリティを損なう奴と
意味もなく常に最大限のポータビリティを確保しようとする奴はｱﾌｫ

ポータビリティを確保すること自体に意味がある

意味があることなんて幾らでも有るけど。
必要かどうかはそれとは別。

ネーよ、
それなら、JAVA仮想マシンとかで十分

>>301
手塚治虫の吹き出しかよ！

終了直前に free() しまくるのはやめて。

>>645 このネタも危険だなぁ。

test

h

<stddef.h>なんて滅多に使わないよな。

<hoge.h>

>>617
strctAの不完全型宣言でもtypedefできるだろ。
ようは使う時ポインタなら問題ない。

>>651 １０ヶ月も前のバカを今さら煽ってどうするよ。

１０ヶ月も前のバカよりもバカなんだから仕方がない。

#include <stdio.h>
int main(){
int *pa[500],*pb[500],*pc[500],*pd[500],*pe[500],*pf[500];
int i;
for(;;){
for(i=0;i<500;i++){
*pa[i]=5;
*pb[i]=5;
*pc[i]=5;
*pd[i]=5;
*pe[i]=5;
*pf[i]=5;
printf("%d,%d,%d,%d,%d,%d\n",*pa[i],*pb[i],*pc[i],*pd[i],*pe[i],*pf[i]);
}
return 0;
}
return 0;
}
↑みたいなプログラムを安易に張りつけないｗ

#include <stdio.h>
int main(){
for(;;){
int *pa[500],*pb[500],*pc[500],*pd[500],*pe[500],*pf[500];
int i;
for(i=0;i<500;i++){
*pa[i]=5;
*pb[i]=5;
*pc[i]=5;
*pd[i]=5;
*pe[i]=5;
*pf[i]=5;
printf("%d,%d,%d,%d,%d,%d\n",*pa[i],*pb[i],*pc[i],*pd[i],*pe[i],*pf[i]);
}
return 0;
}
return 0;
}
だったorz;

(´^ิ ౪ ^ิ)

（￣Ψ￣）

このスレに適した話題として
無限ループを作る時、for(;;) while(1) おまいらならどっち使う？

俺は for派。
2個目の式（ループ継続条件）を省略した場合の言語仕様は何のためにあると思う？
whileだとlint（と同じことをするツール）に文句言われる場合があるのも鬱陶しい。

>>659
全面同意。

議題：インデント幅

俺は4。

>>661
俺は2だけど、
周り見てると4が多い。

幅よりも、タブか空白かの方が盛り上がると思う。

俺はタブの方が好きだけど、現実には空白を主に使うようになっている。
実際には空白だけど、カーソル移動はタブの如く動いてくれる機能が自分の使っているエディタに欲しい。
或いはファイルへの読み書き時に自動で変換してくれるものでも良し。

俺はハードタブじゃないと気持ち悪いなぁ。
空白にするメリットって何？

>>664
ユーザーやアプリケーションのタブ設定によって表示が変わらない。

ツール一発で変換できるからあんまり気にしてない。
とはいえ、同じソースファイルで、インデント幅が違ったり、空白とタブが混在してるのは許せん。

　　　　　　　　　　　　　　●　細木数子 × 恫喝 × 島倉千代子の弱み

細木数子のブレーンが必死だ。 親しい芸能関係者を呼んで、「 お金はいくらでも出すから
島倉のスキャンダルを教えてくれ 」 と頼んでるらしい。 細木と島倉といえば、 マスコミでは
島倉の危機を救った命の恩人のようだが、実際は細木が島倉を食い物にしたと噂されてる。
その真相を島倉にしゃべられたくないため、 先日、 羽田空港で二人がばったり会った際に、
島倉に「 余計なことをしゃべるな 」とクギを刺したようだ。細木といえば、若い頃は暴力団の
幹部の女だったとか、いろいろ黒い噂のある人物だ。たいていのスキャンダルなら「 力 」と
「 金 」で封じ込めると思うが、何か焦ってるのだろうか。

細木の話によると「 島倉千代子はかって１２億円の借金があったが、その借金を細木がマネｰ
ジャーや送り迎えをしながら協力した 」そうだ。それなのに「 借金を返済したとたんに事務所を
移転して音沙汰なし 」とか。 これが本当であれば島倉千代子も恩知らずといえそうだが、これ
に対しては逆に 「 細木数子が島倉千代子から金を騙し取っていたので 島倉側は細木数子に
対して怒りを覚えてる 」 という情報もあるようだ。 いつまでも返済できない借金を所属レコード
会社のコロムビアに借金を肩代わりしてもらうことで、別の事務所に移籍して細木数子の魔の
手から逃れたとか。細木数子といえば、実弟のマルチまがい商法疑惑やら悪徳霊感商法疑惑
やらの黒い噂も流れている。 たたけばいくらでも埃の出る身だろうが、 視聴率を稼いでいる今
は大丈夫かもしれない。

http://www.nazotoki.com/obatyan.html