皆さんはプログラムどう書きます？

雷 · #1

他の人が読みやすいプログラムを書くのは難しいって聞いたことを思い出して…
********①************
void main(){
	printf("…");
}
********************
と
*********②***********
void main()
{
	printf("…");
}
********************
どっちが見やすく思いますか？

コメントはどの位置に付けますか？
どんな風に付けますか？
などなど、あると思いますが…（これだけしか思い浮かばなかったんだけど(^^;Λ

皆さんはどうでしょうか？
自分なりの規則を持っている方はいますか？

因みに僕は、、、、
①なのですが、①だと見にくいと思うときがあったりして、
最近ごちゃごちゃに使ってしまっているので、他の人はどうなんだろ？
って思いスレ立てしました＾＾

コメントは
**************************
一行の時：
//・・・・・・
printf("・・・・・");

複数行の時：
/*
	・・・・・・
	・・・・・・
	・・・・・・
*/
printf("・・・・・・");

forなどループを使う時：
for ( ; ; ){	//
	printf("・・・");
}
***************************
のような感じでやっています。
ただ、その時々によって変わってる感じがしますが・・・ｗ

ご意見よろしくお願いします！！
＋α：「これは勘弁！」と言うのがあったら教えていただけると、凄い参考になります＾＾

***********以下追加事項（6/16）**************************
自作関数と関数の名前の付け方はどうでしょうか？

僕は、長いのは先頭が大文字の英単語の羅列にしていますが、どうでしょうか？
短いのは小文字の
例：）Sample_game();　　Sanple_game;
      game();           game;

管理人 · #2

プログラムの書き方はホントに人それぞれですからねぇ・・。

void main(){
	printf("…");
}

void main()
{
	printf("…");
}

　
では私は上が見やすいんですが、私が見た中では下の書き方の方が若干多かったです。
あくまで私の周りはです。
if文の書き方も、「1行ならカッコをかかない」という人もいれば「どんな条件文でもカッコをかかないとわかりにくい」と言う人もいます。
私はコメントは大抵「//」で書きます。
というもの、途中に/**/があると、大きな範囲でコメントアウトしたい時に、中に/**/があると、それより大きな範囲から/**/がかけないからです。

＞これは勘弁！

勘弁というかやってはいけないことは、トライグラフを混ぜないことです。
これはJustyさんの受け売りなんですが、コメントアウトしたからといってその区間に何でも書いていいわけではないです。
これを実行してみてください。
・・・実行する前に、結果が何になるか想像してからコンパイルしてみてください。

#include <stdio.h>

int main(){
	int i,a=0;
	for(i=0; i<10; ++i)    //aの値は??/
	    ++a;
	printf("a=%d",a);
	return 0;
}

　
　
あれ？と思う結果になったと思います。googleでトライグラフで検索するとわかります。
とにかく半角のハテナを書くのは避けたほうがよさそうです。

趣旨から離れてしまいました。すみません。

プログラムの書き方は本当に人によって様々だなぁ、、と思います。
逆にそれを逆手にとって、
「友達のプログラムソースをコピーして提出している学生」
を発見するプログラムを現在作っています。類似度を求めて、学生のかくプログラムのくせを見つけ出し、コピーされたものかどうかを判別するシステムです。
そういう試みが出来てしまうくらい見てると人それぞれなんですよね。

コメントアウトの仕方は、１行ずつ全てにコメントアウトで説明つけるような場合は、
タブで全部同じ位置から表示されるようにすると見やすくなると自分では思っています。
例えばこんな感じ。

int cnt(){
	int i,a;		//iとaを宣言
	a=0;			//aを初期化
	for(i=0; i<10; i++)	//10回ループ
	    ++a;		//aをカウントアップ
	printf("a=%d",a);	//aを表示。
	return a;		//aを返す
}

管理人 · #3

もしかして、「ポインタの扱い方・・・？」トピで書いた私のサンプルのコメントがみにくかったですか？＾＾；

Justy · #4

＞どっちが見やすく思いますか？
　私は２です。昔は１でしたが、括弧の対応が判りづらいので２に変えました。
　世の中の括弧の付け方はソース整形ツールなんかのオプションを見ると、
他にもいろいろあるようですね。

　基本的に１人でソースを書く時は

・　論理構造を正しく表現する
・　表現に一貫性がある
・　可読性が高い
・　保守性が高い

　ような書き方になっていればどんな書き方でもいいかと思います。

＞自分なりの規則を持っている方はいますか？
　細かくルールを持ってますよ（ｗ
　しかも大体１，２年周期でプロジェクトが終わるタイミングで書き方を改善していっています。
（プロジェクトの途中で書き方を変えると全ソース書き換えが必要になるので、避けています）

＞「これは勘弁！」と言うのがあったら
　ん～括弧のつけかたとかコメントの位置とかは常識の範囲内であれば特にないですが、
その他の点ではいっぱいありますよ。

　幾つか挙げると

・　インデントがおかしいソース、或いはインデントにタブとスペースが混在しているソース
　インデントされていないとか、インデントの論理構造が破綻してるのは勘弁です。
　又、タブの数が環境によって変わるので、混在しているとソースの見た目が崩れることがあるので、
これも止めて欲しいですね。

・　１行に数百文字のコードが書かれている or 関数が長い
　昔は行８０文字までとか制限があったこともありました。
　今はそんな制限はないのですが、例えば if文の条件がたくさんある時など
１行にたくさんの条件文を書き連ねてエディタを横スクロールさせないと見えない、
なんてのは論外です。
　逆に横ではなく縦に長いのも勘弁ですね。

・　コメントと処理の内容・目的が違ってる
　混乱の元です。
　違ってるくらいならコメントは要らないです。

　とかとか。

＞「友達のプログラムソースをコピーして提出している学生」を発見するプログラム
　これは面白そうですね。
　最近はソース整形・リファクタリングツールも発達していますから単純な方法では
なかなか見破るのは難しいとは思いますが。

　複数の解析方法を使って多角的に解析したり、
各個人の癖もデータベース化すると精度が高められそうです。

　でも課題とかの場合、ある程度のソースが最初から提示されていたりすると
全員似たり寄ったりなプログラムになったりして厄介ですね。

組木紙織 · #5

括弧の表記表ですが、
自作関数の定義の場合
②を使い
ifやforループの場合には
①
を使うようにしています。
クラス定義や構造体の定義のときも②ですね。

コメントはコメントの意味のレベルに分けて４段階で使い分けています。

括弧の対応やコメントのつけ方だけでなく、変数の命名も読みやすく保守性の高いコードを書くには重要ですよね。
私の場合ハンガリアン記法を少し見習って接頭辞と接尾辞を使って変数の"意味"が分かりやすくなるように
しています。
ポインターやイテレータはp_で始めたりとか、
static変数はs_で始めたりなど。
カウンター用の変数はc_,
フラグはf_で始める
事などです。

一時期ハンガリアン記法を調べて、それにしたがって書いてみたのですが、
変数の型を変更すると書き直しが必要になったり、大文字と小文字が混じっていると読みにくかったので
結局はこの形に落ち着きました。

YuO · #6

波括弧について，私の場合は

・1行に書かれているif, else, for, whileおよびC++におけるtry, catchに続く複文の先頭は同じ行に書く
・1行に書かれているstruct, union, enumおよびC++におけるclassに続く{は同じ行に書く
・上記以外の{は次の行の行頭に，同一インデントで書く
・do文末尾のwhileはdoに続く複文の末尾の}と同じ行に書く
という感じです。たとえばif文なら，1行であれば

if (isFoo() && ifBar()) {

ですが，条件式をわけると

if (isFoo() &&
    isBar())
{

となります。

C#で書く時はこんなに細々したルールを一気に整理して，
・{は常に次の行
・do文末尾のwhileはdoに続く複文の末尾の}と同じ行に書く
になったりしますが……。

> コメントはどの位置に付けますか？

本当はコメントつけなくても意思が伝わるのが良いのですが……。

単一行なら//，複数行なら/* - */を使います。
ただし，C95で書いている場合は//は使いません。
開始位置は，コメントしたい物の直前で，コメントしたい物とインデントをあわせます。
つまり，「この複文全体」であれば複文の開始の{のインデントにあわせますし，
「この式文」であれば，その式文のインデントにあわせます。
ただ，式文につける場合で内容が短いと，式分の後ろに書く場合も多いですが……。

> if文の書き方も、「1行ならカッコをかかない」という人もいれば「どんな条件文でもカッコをかかないとわかりにくい」と言う人もいます。

私の場合，if文に関して，
・基本は複文をつなげる
・ifの条件式が簡易で1行におさまり，続く文も内容が簡易で複文でない場合は，ifと同一行に複文にせずに書く
としています。

if (x == 0) return;

> というもの、途中に/**/があると、大きな範囲でコメントアウトしたい時に、中に/**/があると、それより大きな範囲から/**/がかけないからです。

基本はプリプロセッサ使って削除ですね。

#if 0
...
#endif

> 私の場合ハンガリアン記法を少し見習って接頭辞と接尾辞を使って変数の"意味"が分かりやすくなるように
> しています。

アプリケーションハンガリアンは使おうと思っていますが，「どういうものか」をきっちり識別子に含めるとだいたい必要がなかったり……。
# 副作用として識別子の長大化がありますが……。

私の場合は基本的にprefix/suffixは使わないのですが，唯一，メンバ変数/フィールドに_をつけています。
基本はprefixなのですが，C++のみ末尾です。_ + 大文字だとライブラリの要求に違反しますので。
# _ + 小文字ならglobal namespaceのみ予約なので大丈夫ですが，面倒なので。

> 一時期ハンガリアン記法を調べて、それにしたがって書いてみたのですが、
> 変数の型を変更すると書き直しが必要になったり、大文字と小文字が混じっていると読みにくかったので
> 結局はこの形に落ち着きました。

システムハンガリアンですね。
基本的に，システムハンガリアンに意味は無いです。書くだけ無駄ですのでやめましょう。
# DLLのプロトタイプの名前くらいには使いますが……。

名前は基本的に駱駝式。C/C++は.NETにあわせています。
例外： 1単語の関数は全部小文字

あとは，無意味に実装依存動作に頼らないことですか。

雷 · #7

>管理人様

>途中に/**/があると、大きな範囲でコメントアウトしたい時に、中に/**/があると、それより大きな範囲から/**/がかけないからです。 
なるほど、確かにそうですね…これから注意してみたく思います。

トライグラフの例ですが、a=10　となり、何も問題が無かったのですが、何が起こるのでしょうか？
トライグラフは、三文字で記号を表すものと解釈しました。

>「友達のプログラムソースをコピーして提出している学生」
友達に教えた人がいた時、そのプログラムが機能することが無いと思いますがどうでしょうか？
友達に教える時にそういうのには注意した方がいいのでしょうか？…注意が出来るかどうかわかりませんが＾＾；

>趣旨から離れてしまいました。すみません。 
趣旨の中から全然離れていません。
むしろ、大歓迎です！


>もしかして、「ポインタの扱い方・・・？」トピで書いた私のサンプルのコメントがみにくかったですか？＾＾； 
違います。
先生が、
void main () 
{
	printf();
}
で書けと言っていたのに何で
void main() {
	printf();
}
で書くの？
って聞かれたからです・・・・・・・・orz
なので、他の人はどうだろう？と思い書いて見ました。

>Justy様
>・　可読性が高い 
とは、どの様なのを指すかが、凄く曖昧な気がするのですが、どうでしょうか？

>・　保守性が高い
申し訳ないのですが、良く分かりません。
説明お願いできませんか？

>細かくルールを持ってますよ（ｗ
>しかも大体１，２年周期でプロジェクトが終わるタイミングで書き方を改善していっています
Σ(゜Д゜
それは、メモ帳などに記載して、やっているのか、記憶を頼りにしているのかどちらなのでしょうか？
参考までにお願いできますか？

>インデントがおかしいソース
には、
void main(){
	printf("・・・・・");	//・・・・・・・・・・。
	printf("…");	//・・・・
}
は入ると思われますか？

>if文の条件がたくさんある時など 
>１行にたくさんの条件文を書き連ねてエディタを横スクロールさせないと見えない、 
>なんてのは論外です。 
なんと、出来る限り横に書いていくものだと思っていました。＾＾；

>組岸紙織様
なるほど、自分なりの関数の名前の付け方を決めておくと言うのも、かなりいいと思います。
ただ、ハンガリアンがあまり良くないそうなので、難しそうですが・・・。

>YuO様
文の長さによって色々と使い分けられているのですね。
凄いです！

>C95
とは、何なのでしょうか？
>基本はプリプロセッサ使って削除ですね。 
>
>#if 0
>...
>#endif
これにはどの様な意味があるのでしょうか？
ググったても、使い方すら理解できませんでした。
[プリプロセッサ　#if 0][プリプロセッサ]で検索をかけました。


質問文に、関数の名前の付け方も編集して追加させていただきます。
色々と参考になります。

Justy · #8

＞＞・　可読性が高い
＞とは、どの様なのを指すかが、凄く曖昧な気がするのですが、どうでしょうか？
　たしかに曖昧です。
　実際、その判断基準は個々によって異なります。
　
　でも、大まかに複数の人から見て、明らかに読めないとか、ありますよね。
　http://www0.us.ioccc.org/years.htmlとか。

　そういう極端な例はともかくとして、ぱっと見判りづらい、混乱させるようなのとかは
避けましょう、ということです。

　例えば、三項演算子とかなんか旨く使えば便利ですが、それが１つの式の中に１０も２０も出てきたら
もう読めません・・・。

　あと時々気付かずにやってしまうのが

[color=#d0d0ff" face="monospace]void sample(void)
{
    int n;
    if(....)
    {
        int n;
        
    }
}[/color]

　のように異なるスコープで同じ変数名を宣言してしまうと、書いている人はともかく、
読む人は結構混乱します。

＞＞・　保守性が高い
＞説明お願いできませんか？
　保守性とは機能の変更や追加、パフォーマンスの改善、不具合の修正などにおいて
変更の容易さを指します。
　これが高いということは簡単に修正ができることを意味しています。

　これについては書き始めたらもう掲示板では語り尽くせないほど多岐渡る話になるのですが、
よくある話としては「１行修正を入れたらそれに伴って複数の行に手を入れなければならない」ような
コードは保守性が悪い、と言うことができると思います。

　マジックナンバーやマジックストリングなんかは真っ先に潰すべきでしょうし、
同じ処理が何度も現れたら関数化してまとめるとかは基本的な事項となります。

　他にも意外なケースとして例えば、switch-caseで以下のように書く人がいたとしましょう。

[color=#d0d0ff" face="monospace]
switch(mode)
{
    case MODE_EXTREAM:      a++;
                            break;
    case MODE_ALT:          a+=2;
                            break;
    case MODE_DOUBLE_TIMES: a*=4;
                            break;
}[/color]

　ここで、case文に MODE_AAAAAAAAAAAAAAAAAAAAAAAを追加したいと思ったとき、

[color=#d0d0ff" face="monospace]switch(mode)
{
    case MODE_EXTREAM:                  a++;
                                        break;
    case MODE_ALT:                      a+=2;
                                        break;
    case MODE_DOUBLE_TIMES:             a*=4;
                                        break;
    case MODE_AAAAAAAAAAAAAAAAAAAAAAA:  a*=8;
                                        break;
}[/color]

　switch-caseの全行に対してスペースなりタブなりを入れて、a++とか breakの位置を
変更しなければなりません。
　見た目はいいんですけど、数が多かったり追加・削除の頻度が高いとこれは結構面倒です。

＞それは、メモ帳などに記載して、やっているのか、
＞記憶を頼りにしているのかどちらなのでしょうか？
　記憶というか、習性というか。
　平日は一日だいたい最低４時間、多いときになると十数時間はプログラムしてるので、
細かなルールを意識することなくもう惰性で書いてます。

＞void main(){
＞	printf("・・・・・");	//・・・・・・・・・・。
＞	printf("…");	//・・・・
＞}
＞は入ると思われますか？

　たしかに // の位置が２行目と３行目でずれていますが、
論理構造は合っているので、ここで言っているインデントの問題には該当しません
　
　インデントがおかしいというのはそのプログラムの論理構造に対して
おかしなインデントというものを指します。
　例えば

[color=#d0d0ff" face="monospace]    for(i=0; i<max; ++i)
        count++;
        printf("count = %d\n", count);
        if(count == max - 1){
            printf("abcdef\n");
    }[/color]

　とか。
　これは printfが count++と同じ階層にあるので、for文の対象になっている、と
勘違いさせやすいインデントになっています。

＞なんと、出来る限り横に書いていくものだと思っていました。＾＾；
　見やすさの問題で、例えば、

[color=#d0d0ff" face="monospace]    if(note == 1 || note == 4 || note == 6 || note == 9 || note == 11 || key == 1 || key == 4 || key == 6 || key == 9 || key == 11)[/color]

　とあるよりも

[color=#d0d0ff" face="monospace]    if(note == 1 || note == 4 || note == 6 || note == 9 || note == 11
    || key  == 1 || key  == 4 || key  == 6 || key  == 9 || key  == 11)[/color]

のように（if文だけに限らず）適度に改行を入れた方が見やすくなるかな、と。

　あとは横に長いと印刷したときに見苦しくなるというのもありますね。

Justy · #9

＞自作関数と関数の名前の付け方はどうでしょうか？
　C++で書いているときの関数（メンバ関数含む）は SampleGame()な書き方で書いています。

　ただ、Cですと（名前空間などが使えないので）意味を区切るために _ を使うとがあります。
　SampleGame_Start()とか。

＞とは、どの様なのを指すかが、凄く曖昧な気がするのですが、どうでしょうか？
　追加で補足
。
　紛らわしい変数名（関数も）とかも危険ですね。
　ll1、l11、l1lとか。

　発音が似ているのとか、意味が似ている別の単語とかも同様です。

組木紙織 · #10

最近みた変なコードの一部

if(){
    /*色々１*/
  goto label;
 }else{
    /*色々２*/
label:
   /*色々３*/
}

goto の意味が無いじゃないですか!

バグ · #11

色々３の部分をif文の外に出してやればいいだけの事ですね～（爆笑）

雷 · #12

返信遅れてすみません。

> Justy様

>異なるスコープで同じ変数名を宣言してしまうと、書いている人はともかく、 
>読む人は結構混乱します。
　確かに、気おつけなくてはいけないです。
自分でも後で見たら混乱しそうですし…

>保守性…（略）…が高いということは簡単に修正ができることを意味しています。
　関数内でしか使用しないものは、定義する必要は無いと取っても良いのでしょうか？

↓①
int Game(void)
{
	int n;
	…
	return n;
}

↓②
int Game(int a)
{
	int n,i;
	i = GameOut(n,a);
	
	return i;
}

　簡単に書いてますが、これが長く長く続く時、①はしても良く、②はしない方が良い
と解釈しましたがあってますでしょうか？

↓②'
int Game(int RPG)
{
	int name,i;
	i = GameOut(name,RPG);
	
	return i;
}
②→②’としておけばOK？


>他にも意外なケースとして例えば、switch-caseで以下のように書く人がいたとしましょう。
　では、↓の様な形でもいいのですか？

switch(mode)
{
    case MODE_EXTREAM:		a++;
				break;
    case MODE_ALT:		a+=2;
				break;
    case MODE_DOUBLE_TIMES:	a*=4;
				break;
    case MODE_AAAAAAAAAAAAAAAAAAAAAAA:	a*=8;
					break;
}

また、
{
    case MODE_EXTREAM:
    		a++;
		break;
    case MODE_ALT:
    		a+=2;
		break;
    case MODE_DOUBLE_TIMES:
    		a*=4;
		break;
    case MODE_AAAAAAAAAAAAAAAAAAAAAAA:
    		a*=8;
		break;
}
はよくないのでしょうか？

>平日は一日だいたい最低４時間、多いときになると十数時間はプログラムしてるので、 
>細かなルールを意識することなくもう惰性で書いてます。
　えっ！…流石にそれだけやると違うんですね…（汗

>あとは横に長いと印刷したときに見苦しくなるというのもありますね。
　確かにそうだと思います。
印刷はあまりしたことが無かったので、考えていませんでした。
しかし、

>if(note == 1 || note == 4 || note == 6 || note == 9 || note == 11
>|| key  == 1 || key  == 4 || key  == 6 || key  == 9 || key  == 11)

　これは、ifがとても見にくくなっているような気がします。
どうなんでしょうか？多く書くようになると、簡単に判断が出来るようになるのでしょうか？

if(note == 1 || note == 4 || note == 6 || note == 9 || note == 11
    || key  == 1 || key  == 4 || key  == 6 || key  == 9 || key  == 11)
{
	…
}
と、タブを一つ入れたほうが見やすくなると思うのですが、どうでしょうか？

>ただ、Cですと（名前空間などが使えないので）意味を区切るために _ を使うとがあります。 
なるほど、名前空間と言うものがあったんですね。(マテ
思わぬところで良い勉強になります。

>発音が似ているのとか、意味が似ている別の単語とかも同様です。 
　日本人なので…じゃ済まないんですよね…orz
ここで、英語が出てくるとは世の中はどこもかしこも英語が必要だと思い知りました。orz



>組木紙織
これから拡張を考えてるとか？ｗ

Justy · #13

＞　これが長く長く続く時、１はしても良く、２はしない方が良いと解釈しましたがあってますでしょうか？
　いえ、条件付きで２の方がいいです。
　２のケースで、GameOut()が１と同じように長い関数になっているのでしたら
どっちでも意味がなくなります。

　ですが、GameOut()も適切にモジュール化・関数化されているとするならば２の方がいいです。

　やっぱり１つの関数が長くなると覚えておかなければならない変数や細かな処理が
増えるので一般的には保守性が下がります。
　同じ変数に複数の意味を持たせて使い回しなんかされたら、もう最悪になりますね。

＞＞他にも意外なケースとして例えば、switch-caseで以下のように書く人がいたとしましょう。
＞　では、↓の様な形でもいいのですか？
　なるほどなるほど（ｗ
　ＯＫですＯＫです。

　このあたりの部分に関しては「桁を揃える」というその作業の手間を面倒と感じるかどうか、
手間をかけなくても見やすくかけるのではないかというところの問題なので、
結構個人の慣性に左右されます。
　実際には（揃えなければならない）数が少なければさほど問題視はされないかと思います。

＞　また～はよくないのでしょうか？
　こちらは特に問題はないと思います。

＞これは、ifがとても見にくくなっているような気がします
＞タブを一つ入れたほうが見やすくなると思うのですが、どうでしょうか？
　そうですね。
　個人的にはどっちでも有りです。
　まぁ、このあたりは好みの問題なので（＾＾

　ただ、この例は「横に長い式は途中で改行を入れる」という例だったので、
もっと見やすくするという意味で言えば、こんなにたくさんの判定式を１つの if文に
入れること自体がかなりナンセンスです。
　この判定自体を関数化（関数名が判定の意味・目的を表すように）してしまった方がより見やすくなりますね。

[color=#d0d0ff" face="monospace]    if(IsSpecialNoteKey(note, key))
    {
        ....
    }[/color]

YuO · #14

>> C95
> とは、何なのでしょうか？

ISO/IEC 9899:1990にISO/IEC 9899:1990/Amd.1:1995の改正分を反映させた物のことです。
注）ISO/IEC 9899は標準Cのこと。最新版 (唯一の標準C規格) は，ISO/IEC 9899:1999。

//によるコメントはC99 (ISO/IEC 9899:1999のこと) でC言語に導入されたので，それより前の規格のコンパイラでは本来通らない物として扱うべきなので，使わないようにしています。
# C++言語では昔からありましたが。元をたどるとBCPLにはあった。

>>基本はプリプロセッサ使って削除ですね。
>>#if 0
>>...
>>#endif
>これにはどの様な意味があるのでしょうか？

#ifはプリプロセッサによる条件分岐で，#ifのあとの条件文が真であれば，そのブロック (#elif, #else, #endifのどれかが出るまで) をコンパイルし，そうでなければコンパイルしない，というものです。

#define CODE 1
int printf (const char *, ...);

int main (void)
{
#if CODE == 1
    printf("Hello, World!\n");
#elif CODE == 2
    printf("Hello, C World!\n");
#else
    printf("Hello, Unknown world...\n");
#endif
}

というコードについて，CODEの値を変化させてみると，ある程度挙動が解るかと思います。

他のブロックを含むことができるため，コメントと違ってネストができ，通常コメントよりも推奨される書き方になります。
エキスパートになると，http://ml.tietew.jp/cppll/cppll/thread_articles/12899のようになるわけですが……。

> のように異なるスコープで同じ変数名を宣言してしまうと、書いている人はともかく、
> 読む人は結構混乱します。

スコープ中にあるスコープで，ですね。

{
    for (int i = 0; i < 10; ++i) { /* 配列をiで列挙していく */ }
    /* ... */
    for (int i = 0; i < 10; ++i) { /* 配列をiで列挙していく */ }
}

ならば，混乱することはないでしょうし。
# iのスコープについて正しい知識があることが前提ですが…… < VC++6が未だにのさばっているのでちょっと怖い……。

> ただ、この例は「横に長い式は途中で改行を入れる」という例だったので、
> もっと見やすくするという意味で言えば、こんなにたくさんの判定式を１つの if文に
> 入れること自体がかなりナンセンスです。
> この判定自体を関数化（関数名が判定の意味・目的を表すように）してしまった方がより見やすくなりますね。

私の念頭にあったのは，長い名前の関数2つを||で区切るような場合です。
C++/Java/C#では，論理値を返す関数／メソッド名がトータルで30文字とかがざらになってくるので。

Justy · #15

＞エキスパートになると，[cppll:12899] <tips> 自己解説型ディレクティブアウトのようになるわけですが……。
　昔の知り合いにいました、そういうふうに書く方が（ｗ

＞スコープ中にあるスコープで，ですね
　あ、そうですね。その通りです。

＞ならば，混乱することはないでしょうし
　それは全く問題ないです。

＞VC++6が未だにのさばっているのでちょっと
　NOMINMAXもそろそろ勘弁してほしいです。

＞C++/Java/C#では，論理値を返す関数／メソッド名がトータルで30文字とかがざらになってくるので
　そもそも変数名からして１０文字はざらにありますからねぇ。
　それに加えてメソッド名、引数と加えていくと・・・。

雷 · #16

>Justy様

個人の趣向がかなりバラける可能性があるんですね。

関数内に関数、関数内に関数、…
が多く続きずりると感じるのは何個ぐらい入れたときなんでしょうか？
20～30入れたらもう多いのでは？
と感じるのは大きなのを作ったことが無い僕の感覚なのでしょうか？

>if(IsSpecialNoteKey(note, key))
>{
> ....
>}

こんなことをしても良かったんですか！？Σ(> <)
if文の中に関数を入れてしまうなんて…
ありだったんですね＾＾；

>YuO様
#ifは便利そうですが…使いこなせそうに無いorz
コメントのつけ方は難しそうです＾＾；

>C++/Java/C#では，論理値を返す関数／メソッド名がトータルで30文字とかがざらになってくるので。
なんか、すごい事だと思います。

Justy · #17

＞こんなことをしても良かったんですか！？Σ(> <)
　関数の戻り値が、if文で判定できる物なら何でもＯＫです。

＞関数内に関数、関数内に関数、
＞が多く続きずりると感じるのは何個ぐらい入れたときなんでしょうか？
　私は特にそういう基準はないですね。
　むしろ、どう関数にまとめた（抽象化）のかが重要なので。

雷 · #18

なるほど、どうまとめるかを考えることの方が難しいと言うことですね…＾＾；

皆さんはプログラムどう書きます？

皆さんはプログラムどう書きます？

Re:皆さんはプログラムどう書きます？

Re:皆さんはプログラムどう書きます？

Re:皆さんはプログラムどう書きます？

Re:皆さんはプログラムどう書きます？

Re:皆さんはプログラムどう書きます？

Re:皆さんはプログラムどう書きます？

Re:皆さんはプログラムどう書きます？

Re:皆さんはプログラムどう書きます？

Re:皆さんはプログラムどう書きます？

Re:皆さんはプログラムどう書きます？

Re:皆さんはプログラムどう書きます？

Re:皆さんはプログラムどう書きます？

Re:皆さんはプログラムどう書きます？

Re:皆さんはプログラムどう書きます？

Re:皆さんはプログラムどう書きます？

Re:皆さんはプログラムどう書きます？

Re:皆さんはプログラムどう書きます？

		7月 2025
日	月	火	水	木	金	土
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31