★★★コーディングマナー★★★

コーディングマナーを語りましょうYO!

個人的に("hello world"); → ( "hello world" );のほうが（･∀･）ｲｲ!

ｷﾓ

>>1
うわーきもい!

char *p1 = ("hello\n");
char x1[] = {"hello\n"};

char *p2 = ( "hello\n" );
char x2[] = { "hello\n" };

printf("%s", p1);
printf("%s", x1);
printf("%s", p2);
printf("%s", x2);
さて、エラーはどれ？

確かにそういうのは大事ではある罠

ま、１がキモイのは事実として

ぶつぶつ独り言言うな

>>1
じゃあ、それでいいんじゃない。

プロジェクトごと、あるいは会社ごとにコーディングルールは大抵異なっている。
そこに「世界全体の統一ルール」とか作って持ち込んだとしても、結局１ヶ月後には元に戻っている。
従って意味無し。

>>1
むしろ前者のほうがいい
っていうかこのレベルは一致させる必要も感じないが

これがマナーなの?

>>1のようなコーディングが、ルール内に入っている会社ってある？

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

>>11
正直、聞いた事無いよな。
「コメントを付ける付けない」とか「コメントの内容は」とか、「関数名、クラス名」とかの
ルールは良くあると思うが。

>>1
それが、括弧が複数であればわかるがひとつだけの場合はそこまで意識しなくても
ええと思ふ。

//スペースがないと読みづらい。
doMethod( ( 0.65356437664 + 547903984 * t ) * x + ( Math.log(a) - 1.4954 ),
　　　　　　　"Hello, world", "Hello,world" );

//そんなに読みづらくない。
doMethod("Hello, world");

//ちょっと読みづらい。
doMethod("Hello, world","hello, wold");

//少し読みやすくなった。カーニングやフォントの影響によって、
エディタによっては読みにくい。
doMethod("Hello, world", "hello, wold");

//読みやすい。
doMethod( "Hello, world", "hello, wold" );

//カンマの左にスペース入れても可読性は大して変わらない。
doMethod( "Hello, world" , "hello, wold" );

//短い引数に、そこまでしなくてもいい。かえって読みづらい。
doMethod( "Hello, world",
　　　　　　　 "hello, wold" );

>>14
＞//読みやすい。
＞doMethod( "Hello, world", "hello, wold" );
うちは基本的にこれ。
ところで、自動で清書するソフトってないの？

やたらスペースを入れられるのも、ちと困る。

doMethod(　　"Hello, world"　　,　　"Hello, world"　　)　;

おかしいな、と思ったら、プロポーショナルフォントだった。

>>17
プロポーショナルなら幅合わせしようということ自体おかしいよな。

list<char>::iterator p;　
　　　　と
list <char> :: iterator p;

どっちがみんな読みやすいかな？
俺は後者の方がいいんだけどなー　スペースとり過ぎかな

>>19
あけすぎ
Apple ][のBASICを思い出すな。

ちゃんと中カッコを書いてもらいたい。
if (...)
　...
　　↓
if (...)
　{
　　...
　}

>>19 俺も読みやすくしたい派なんだけど　それはかえって読みづらい罠
list <char>::iterator p; ってしてる。　型はちゃんと確認しときたいもん

>>21 中カッコいらない時は
for ( i = 0; i < n; i++ ) cout << *p;
って横に書いてる　　読みにくいかな？

つーか、中カッコいらなくて、かつ後ろが長い時は、いい具合にインデント入れる。

for(i=0;i<n;i++)
　　if(i!=a)
　　　　b = c==a?d:e;
　　else
　　　　b = a;

...って、ここまで書くと、ウザい？(笑

>>24　いや、普通じゃないかな
if, elseを書く場合はfor文の横に書くよりはそうやって書くほうがいいね

コーディング規約で、{ } がいらないときでも、囲うようにする、
というひとはいるかな？

checkstyle必須のプロジェクトがあった。
バグとかいう前に、まずコンパイルしてもらえない。

>>26
うちはそうなってる。
中身が増減するときに、いちいち気にしなくてすむように、だそうな。

俺は>>24書くならこんな感じ。

for(i=0; i<n; i++) {
　　if(i!=a)
　　　　b = (c==a)?d:e;
　　else
　　　　b = a;
}

b = n - 1 == a ? a : c == a ? d : e;

>>15
indent

>>28
うちもうちも。
後でメンテするやつがバグらんように...(w

それで、ステップ数がとかほざくような所の仕事はやらん！

>>30神

ただし漏れは凡人なので>>28>>32推奨。

>>30
というか、こういうのが一番困るｗ

>>30
こういうのは、レビューで抹殺します
動きゃ〜いいってもんじゃない(w

>>30
これは良くやるけど、ifとかforとかは無条件で中カッコつける

>21
１行に書ける時はカッコなし、改行するときはカッコあり、だな。

ただPerlではカッコ必須なので１行で書くときも
if($hoge) { hogehoge; }
となってしまって格好悪い。
＃後ろに書けばいいという意見もあるだろうけど、あえて前に書きたいときもあるということで。

>30
３項演算子の中で３項演算子を使うのはちょっと自己満足臭がする。

>>30
そんな書き方、今まで考えたこともありませんでした
ありがとう

artistic style の開発は止まってしまったのだろうか・・・・

tempalate<typename _T >
class Hoge
{
public:
_T count;
};//class Hoge

void functionVoid( void ){

}//void functionVoid

void functionHogeHoge(
Hoge& hoge_out,
const Hoge& hoge_ in ) {

}//void functionHogeHoge


俺の場合こんな感じっす。
クラスの場合 { は 同じ行に書かない。なんでだろ？

>>41
> };//class Hoge
> }//void functionVoid
> }//void functionHogeHoge
ｷﾓｯ

>>41
閉じ括弧の後にコメントつけるのは、
インデントを自動的に正しく整えてくれないタコエディタ使ってた奴だろう。
emacsマンセー！

それと、最初に他の言語を覚えていてCに移った奴に多いような気がする。
厳密に言うと最初に覚えた言語と言うよりは
いわゆる母語（mother tongue）ってやつで、
その人のプログラミング時の思考方法に強く影響を与えている言語。
俺の場合最初に触れた言語はBASICで今はJavaだが、
母語は大学で使ってたCだと思う。

CまたはC++が母語の人間なら、{}の対応は無意識のうちにできることなので、
わざわざコメントつけて注意を引くほどのことではない。だからつけない。

ちなみに俺は今はEclipseマンセー派なので、
コードの整形はEclipse任せです。時々恐ろしいことになるが…

>>38
なんか足が臭そうに見えた

>>43
最初からc++ですが、何か？
つーか、インデントくらいそれってますが何か？

関数の終わりを探すのがたるいときあるんだよな。
だからつけてるだけ。

>それってますが何か？
そろえてますが何か。

>>45
あー、じゃこっちか。
>インデントを自動的に正しく整えてくれないタコエディタ使ってた奴だろう。

>>47
いやー、たこエディタはさておき、
画面スクロール２枚分くらいの関数を複数書いてるときに
スクロールグリグリやってるときに、いまどこの関数いじってんだっけ？
ってなったりしないか？

関数の始めに飛ぶショートカットとかつかえばいいだけなのかもしれんが。
あるのか、どうか知らんが。

>>48
41のような数行の対応にまで区別無くコメントつけるのがキモイ。

>>1
コーディング中は放屁しないこと

javaなんだけど
String str = new String("java");
str="hello";
でインスタンス生成の時は=の両端を空けるけど代入のときはくっつける。
このほうが見やすいと感じるのは俺だけか？？？

>>51
うん

>>51
両方空ける人がかなり多数派と見た。

見にくいよ馬鹿！

　　　 　∧∧Λ
ﾋﾟｭ.ｰ　(　゜∇゜ ）つ ＜ 　IDEのコードフォーマッターに任せるので
　　＝〔~∪￣￣〕 　　　　　入力時は入れないでやってる（゜∇゜）/ 　　「ウンマンコ」
　　＝ ◎――◎ 　　

ほとんどの演算子の間に空白は入れない。
俺だけだろうが、間に空白があると読みづらく感じる。

他人のソースを読むとき、無意識のうちに勝手に空白を詰めていって
そいつに怒られた時があった。あわてて元に戻した。

>48
スクロールしないと関数全体が見えないのは不吉な匂いがする。

ああああ、最近は改行の位置で困ることもしばしば。
1行130カラムとか結構あったりする。

最近は画面が広い環境も多いしな

>>58
いまだに、きっちり79桁で改行する人もいるけどな（ｗ

画面は800x600だけど？

800桁600行のディスプレイ

>>62
確かに一画面に収まるけど、人間の目が集中できる範囲はそれほど広くはない。
小説十ページ分を一画面に表示させて、一発で頭の中に入りますか?

こういうのダメでしょうか？
void Func (int x, int y); ←仮引数のカッコの前にスペース
それと
void Func( int x, int y );
どっちが読みやすい？

括弧の内側に空白は格好悪い

保守性が大事だYO!

void Func(int x, int y);

if ( 1 == x ) {.

}

というのは、個人的に嫌い。

>>68 なにが？

65はダジャレ

>>65=>>70

>>69
音読すりゃ分かる。

>>68
コンパイラにも嫌われると思われ。

結局1==xなんて書き方は誰からも嫌われる。

{の後の.。

if( a == b )
{
}

if (a==b){



]

#define begin {
#define end }

if (...
↑
ここスペースあける？MSはあけてるけど．．．

>>79
あけるなあ。

>>70
そんなつもりはなかったんだけど、言われてみると確かにだじゃれになっているね。

i=1;
while( i++ < 10 );
printf("あいうえお");
これも間違いやすいが
i=1;
while( i++ < 10 )
{
}
printf("あいうえお");
これも気持ち悪い

>>82
while(i++ < 10) { }
とかするかな。

printf("%s","あいうえお");

>>82
while (i++ < 10) {
　;
}
とかわざわざ書いてるかなあ。

あとそれとは別に、後置インクリメントはなるべく使わないようにしてるが。
(CならいいけどC++でiがユーザー定義型だとね・・)

昔よく優先順位まちがえた
if (a&0x03==0x01){
が
if ((a&0x03)==0x01){
かと．．．

>>85
あるある

>>84
while (i++ < 10) {
　continue;
}

とか。

なぜ俺は、
#include_<vector>
#include の後にスペース入れるのに
vectorの前後にスペース入れないのだろう？

結構スペース入れるほうなのに

int*
みたいなことだろ

と適当に嘯いてみるお年頃

>>88
#include_"_vector_"
とは、書かないだろ

>>88
別物になるから。

>>91
#include_<_vector_>

vc6でコンパイルできたよ。
そういうことじゃなくて？

VCが勝手に空白をとっちまってるなだけだろう。むしろそっちの方が変。

$ echo '#include < vector >' > a.cc
$ g++ -c a.cc
a.cc:1:20: vector : そのようなファイルやディレクトリはありません

while (i++ <10) {
　　/* do nothing */
}
…かな。

#include はヘッダのファイル名だからスペースを入れるのはマズい予感。

ところでおまいら、そんなに空ループって頻繁に書いてるんですか？

基本的に書かない。
ていうか、空ループ使う時って他の書き方で、より分かりやすくできるというのが持論なんだがどうか。

1.5ループのときくらい。

関数/メソッド「呼び出し」だけ括弧の前にスペースなし。
func(1, 2);
なので定義はスペースあり。
void func (int a, int b) { 略 }
しかし宣言が格好つかないのがちとネック(汗
void func (int, int);

変数名の頭に
unsigned long ulHonyarara;
とか付ける？
スコープを表したもの(m_等）は、解析時間が減るといった事例は
聞いたことあるが、型まで明示するのは利点ある？
(HDC hDcのhなどは付けるが...)

>>99
あまりないと思うけど、なれちゃうとやってないのが
変な気になってくる。それだけ。

>>99
メンバとかよく使うものならこうするかな、
typedef unsigned long honyarara_type;
honyarara_type honyarara;

めんどくさいときはてきとー。

型まで明示するとあとで型変えたくなったときに色々めんどくさいんでやめますた。
ハンドルとかコンテナとかポインタとかならつけることもある。

利点はごめんなさい、知りません。

>>99
ハンガリー記法だっけ？
関数スコープならやらない。

せいぜい
ポインタにp
グローバルにg
位かな

m_hoge とか g_piyo はやるけど p_fuga はしないな
最近ポインタいじってないし

オブジェクト指向がわかれば接頭詞なんてナンセンス

分かってようが分かってなかろうが、接頭詞自体がナンセンス。

朝から晩までチンポーネント思考です

衣斡茜稲衣斡

保守性が大事だYO!

>>105
なぜですか？

名前空間があれば接頭詞なんてナンセンス

接尾詞があれば接頭詞なんてナンセンス

関数名のあとにスペースを入れるのはどうか。
(により区切られているのにさらにスペースというのは区切り文字が重複してるじゃないか。

なにが

つまり見た目が気に喰わないと

>>113
貴様はこんなプログラムを書きたがるのか。

#include<stdio.h>
int main(int argc,char**argv){printf("Hello, World.");}

中括弧を改行後に挿入するのウザいな。
if (...)
{
    ...
}
無駄に行数食ってるし。

>>116
関数名のあとだけだろ
main ()
main()

Cの流れ組んでる言語でも、言語ごとに中括弧の使い方
変えてる人とかいる？

//C/C++
... ...(... ...)
{
　　if (...)
　　{
　　　　...
　　}
　　else
　　{
　　　　...
　　}
}

//java
... ...(...) {
　　if (...) {
　　　　...
　　} else {
　　　　...
　　}
}

みたいな感じで

>>119
なんかいいことあるの？

（＾＾）

環境が自動生成する方に合わせないと後々欝になる

>>122
環境ってIDEのこと？

>>119
Emacsのmajor-modeまかせ。

>>119
なるべくその言語でベーシックなスタイルで書くように心掛けてるけど。

// C は k&r スタイルだけど。

>>122
GENERATION GAP を使えば環境が自動生成するソースなど一度しかみない。

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

最近は画面が広い環境も多いしな

ノートで開発とかしてると画面が狭くてなける。

>>129
おすすめ ttp://www.apple.co.jp/powerbook/index17.html
これも。 ttp://www.dell.com/jp/jp/dhs/products/model_inspn_3_inspn_8600.htm

>>1
個人的にはと言った時点でハイさようなら
それはオナニー、赤の他人にとって付き合う価値がない

スタイルの本質は協調
自己主張を制御できないおこちゃまは邪魔なだけ

> 自己主張を制御できないおこちゃまは邪魔なだけ

他の人にあわせると効率が落ちるんです。
もう再利用とか何にも考えてないコードなんです。
今、短期的な生産性が求められてるんです。

それでも駄目？

>>132
何の効率だ？　実行速度か、それとも翻訳時間のことか。
まさか自分ひとりの作業能率のために全体を合わせてくれってことではあるまいな？
それはお主だけではなく同僚たちにも言えることだが、
作業能率のために性能を落としているようなスキル不足はスタイル以前の問題だ。
生産性が欲しければ、文字通り「論外」な奴は研修受けさせるか左遷する必要がある。
被害状況のレポートを作って人事権のある人に相談するのが正道だ。

>短期的な生産性

ﾌﾟ

>>131
そのスタイルは、何を根拠に決められたスタイルなのか？

コーディング中にオナラやゲップをしない

なんつーか、
indent使え

それで済む程度のような馬鹿な話はするな

http://www.apple.co.jp/powerbook/index17.html
http://www.dell.com/jp/jp/dhs/products/model_inspn_3_inspn_8600.htm

> もう再利用とか何にも考えてないコードなんです。
思うにこーゆーところでほんまに考えないｺｰﾄﾞ書くﾔｼってのは
再利用性云々語るときでもそんなｺｰﾄﾞかいてそうな気が汁。

コーディングスタイル統一用にはツールを作って使ったほうがいいと思うんだよな。
クセが変わると開発効率が落ちるのは事実で、だからっちゅーてバラバラスタイルでもやっぱりまずい。
んで、とりあえず自己流で書いておいて、後でまとめてスタイルを合わせるようにしているのだが
こんな機械作業に時間を取られるのもばかばかしい、と自分は思っているのだけれど
他にも居ない？

開発開始時の一番最初の仕事にコーディングスタイル統一用ツールの作成を押したいです。

C には indent があるとして、
C++ , Java はなんかツールないかな？

年配PGが書いた糞フォーマットはEclipseで整形して終了。
新人PGが書いた糞フォーマットは当人に整形させて終了。

そんなことよりも得意げにキーボードバシバシ打ったり、Enter押したあとにポーズつけたり、クチャクチャ音立ててガム噛むのやめてほしい。
口あけたまま噛むなって幼稚園で習うことだろ。

Enter押した後のポーズは誰でもするだろ

たしかにそうかも。
よし、ポーズは許すことにする。
でもどうせならもっと激しいポーズをキボンヌ。

>>143-144
すまんが、なんでポーズをとりたがるのかマジで教えて。

漏れの周りにも同じような人がいるんだけど、いまいちその気持ちがわからんのです。

牛乳飲む時は腰に手を当てたくなるのと同じ生理現象のためです。

コーティングモナーのAAキボン

糞長いシンボルとGNU式のインデントを強制されると
if (abz_hogehog_processing_with_abcdef(adfaa_xkaj_zjvouu,
　　　　　　　　　　　　　　　　　　　adf_i,
　　　　　　　　　　　　　　　　　　　dfdajfk) = abc_def(abc_def,
ghqi)) {

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

糞長いシンボル？
強制される？

Enter推した後のポーズって？
小指で弾くようにEnterを押す事の事？

だとしたら俺たまにやるけど、リズム取ってると思っていただければ。
調子のいい時はリズムに乗ってるのよね。

>>145
腕全体を使って勢いよくフォロースルーする。

追っかけリーチかけるときみたいに。

>>150くらいのはいいが、>>151みたいのはやめてくれ、頼むから。

プログラマが自己を表現する数少ないチャンスなのにそれを潰そうとするな

コンパイル始めたらぐっと背中をそらして伸びをする。
そのあと椅子を一回転させるのだ。
んでコンパイルとおったら「おし！」と一声。

…鬱陶しいか？

鬱陶しいかも。
Unitテストがすべて通って「おし！」なら気持ちが分かるけど。

>>154
漏れとは逆だね。
コンパイルがこけるたびに周囲半径3m以内にいる人を呪詛する言葉を吐いています。

コンパイルが通るのぐらい当たり前なのにいちいちリアクションするのか・・
漏れはコード編集中にVS.NET2003の統合環境が死んだときには
騒いでるが・・(そしてエラー送信)

age