アカウント名:
パスワード:
int FuncA(int);int FuncB(int);int FuncC(int);...int (*Func[])(int) = {FuncA, FuncB, FuncC, ...};...rc = Func[State](Param);
なんてコードは、新入から「このコードは複雑で何をしてるか分からない。switchの方が分かり易くて簡単だ。」なんて言われます。256個のcaseが並んだswitchには驚かされますね。(関数と変数は異なるもので、関数の配列は考えられないといった思考のようです。)
どんなコードが「複雑なコード」に思えるかは人によって違うので、「複雑なコード=悪いコード」と固定することは出来ませんね。
# switchでは実行速度にばらつきが出て修正となりました。# この件では、私「複雑なコード=悪いコード」、新人「複雑なコード≠悪いコード」だったと。
/* typedefを使う */typedef int (*Func)(int);int FuncA(int);int FuncB(int);int FuncC(int);.../* 適切な名前をつける(関数の配列は関数ではないため、"Func"は不適) */Func DispatchTable[] = { FuncA, FuncB, FuncC, ... };.../* DispatchTableの中身の型と意味を明示する(DispatchTableの宣言と離れている場合) */Func func = DispatchTable[State];/* 関数ポインタであることを明示 */rc = (*func)(Param);
複雑さの問題ではなく、単純に書き方の問題では。
実際にはそれらしい名前をつけてますし日本語コメントや全体の資料も付けてます。さらに説明もするのですが、関数と変数を分けてしか考えられない新人(自称C言語経験者)には「関数のポインタ」の存在が分からないため複雑で読めないコードになるようです。私の周りだけでこれまで数人いましたので、全体的には結構な人数居るのでは?
他にも再帰処理とかを読ませて、「理解できない人=先がない人」「理解できた(しようとする)人=教育する価値がある人」と考えるようにしています。(私の基準です。)
# 以前、ググって見つけたコードを繋ぎ合わせるしかできない新人には降参でした。# 言語仕様すら学ぼうとしないので、「関数が呼べないので見て欲しい」と頻繁に聞いてきた。# 完成したコードにはsample...,hoge...なんて名前が大量にあり難読なコードだった。
>関数と変数を分けてしか考えられない新人(自称C言語経験者)には「関数のポインタ」の存在が分からないため複雑で読めないコードになるようです。
関数ポインタを使わなければどうにもならないような場面に遭遇した経験が無ければ新人が分からないのは当然と言えば当然でしょう動的に処理を切り替える必要があるような例題を使って教えてあげれば問題ないんじゃない?
関数のポインタがわからないようではデータのポインタもわかっているかどうか怪しいよね。
それで「C言語経験者」言い張るのはビミョーだなあ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
複雑なコードとは? (スコア:2)
int FuncA(int);
int FuncB(int);
int FuncC(int);
...
int (*Func[])(int) = {FuncA, FuncB, FuncC, ...};
...
rc = Func[State](Param);
なんてコードは、新入から「このコードは複雑で何をしてるか分からない。switchの方が分かり易くて簡単だ。」なんて言われます。
256個のcaseが並んだswitchには驚かされますね。(関数と変数は異なるもので、関数の配列は考えられないといった思考のようです。)
どんなコードが「複雑なコード」に思えるかは人によって違うので、「複雑なコード=悪いコード」と固定することは出来ませんね。
# switchでは実行速度にばらつきが出て修正となりました。
# この件では、私「複雑なコード=悪いコード」、新人「複雑なコード≠悪いコード」だったと。
添削 (スコア:0)
/* typedefを使う */
typedef int (*Func)(int);
int FuncA(int);
int FuncB(int);
int FuncC(int);
...
/* 適切な名前をつける(関数の配列は関数ではないため、"Func"は不適) */
Func DispatchTable[] = { FuncA, FuncB, FuncC, ... };
...
/* DispatchTableの中身の型と意味を明示する(DispatchTableの宣言と離れている場合) */
Func func = DispatchTable[State];
/* 関数ポインタであることを明示 */
rc = (*func)(Param);
複雑さの問題ではなく、単純に書き方の問題では。
Re: (スコア:1)
実際にはそれらしい名前をつけてますし日本語コメントや全体の資料も付けてます。さらに説明もするのですが、関数と変数を分けてしか考えられない新人(自称C言語経験者)には「関数のポインタ」の存在が分からないため複雑で読めないコードになるようです。
私の周りだけでこれまで数人いましたので、全体的には結構な人数居るのでは?
他にも再帰処理とかを読ませて、「理解できない人=先がない人」「理解できた(しようとする)人=教育する価値がある人」と考えるようにしています。(私の基準です。)
# 以前、ググって見つけたコードを繋ぎ合わせるしかできない新人には降参でした。
# 言語仕様すら学ぼうとしないので、「関数が呼べないので見て欲しい」と頻繁に聞いてきた。
# 完成したコードにはsample...,hoge...なんて名前が大量にあり難読なコードだった。
Re: (スコア:0)
>関数と変数を分けてしか考えられない新人(自称C言語経験者)には「関数のポインタ」の存在が分からないため複雑で読めないコードになるようです。
関数ポインタを使わなければどうにもならないような場面に遭遇した経験が無ければ新人が分からないのは当然と言えば当然でしょう
動的に処理を切り替える必要があるような例題を使って教えてあげれば問題ないんじゃない?
Re:添削 (スコア:0)
関数のポインタがわからないようではデータのポインタもわかっているかどうか怪しいよね。
それで「C言語経験者」言い張るのはビミョーだなあ。