アカウント名:
パスワード:
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...なんて名前が大量にあり難読なコードだった。
くだらない。お前も大したレベルじゃないんだろ。自己顕示欲だけはすごいよな。
こういう時に毎回書くけど、君の一方方向からでた情報になんの信頼性もないからｗ
新人叩きではなく私の経験と考えを書いただけです。一部の新人のことですし、当の新人には教育を行った結果、自らの不向きを理解させた上で職種を替えてしっかり働いています。
＞お前も大したレベルじゃないんだろ。
はい。大したレベルではありません。独学の組み込み系なので、かなり古く低レベルだと思います。
＞自己顕示欲だけはすごいよな。
？なぜそう取られたのでしょうか？
＞君の一方方向からでた情報になんの信頼性もないからｗ
当然です。信頼性なんて求められても困ります。信頼性なんて求めてたら、このようなサイトは成り立ちませんよ。信頼できないなら違う意見を書き込めばいいだけです。そうすることで議論が活発になり良いサイトになると思います。
小さな企業では新人の向き不向きを早期に判断し、適切に配属しないとやっていけません。育つ見込みがない者を、本人が望むからと言うだけで教育し続ける余裕などありません。最初にコードを書ける書けないは重要ではないのです。書けなければ学べばいいのですから。学んだ結果、問題の少ないコードを書ければ良いのです。しかし、「学ぼうとしない」、「他の意見を受け入れない」、「考えようとしない」人にコードを書かせることは、会社にとっても本人にとってもマイナスでしかないと考えています。問題が多いコードをいつまでも書き続けるなら、使えない人材と判断するしかありません。業務としてやる以上、仕方のないことです。
すごい向上心のある人だと思ったんだけど、そんなにすごいのなら大きな企業に転職してみてはどうでしょうか？
独学の組み込み系なので、かなり古く低レベルだと思います。
誰がうまいこと言えと
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
複雑なコードとは？ (スコア: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...なんて名前が大量にあり難読なコードだった。
また新人叩きかよ (スコア:-1)
くだらない。
お前も大したレベルじゃないんだろ。
自己顕示欲だけはすごいよな。
こういう時に毎回書くけど、
君の一方方向からでた情報になんの信頼性もないからｗ
Re:また新人叩きかよ (スコア:1)
新人叩きではなく私の経験と考えを書いただけです。
一部の新人のことですし、当の新人には教育を行った結果、自らの不向きを理解させた上で職種を替えてしっかり働いています。
＞お前も大したレベルじゃないんだろ。
はい。大したレベルではありません。
独学の組み込み系なので、かなり古く低レベルだと思います。
＞自己顕示欲だけはすごいよな。
？
なぜそう取られたのでしょうか？
＞君の一方方向からでた情報になんの信頼性もないからｗ
当然です。信頼性なんて求められても困ります。
信頼性なんて求めてたら、このようなサイトは成り立ちませんよ。
信頼できないなら違う意見を書き込めばいいだけです。そうすることで議論が活発になり良いサイトになると思います。
小さな企業では新人の向き不向きを早期に判断し、適切に配属しないとやっていけません。
育つ見込みがない者を、本人が望むからと言うだけで教育し続ける余裕などありません。
最初にコードを書ける書けないは重要ではないのです。書けなければ学べばいいのですから。学んだ結果、問題の少ないコードを書ければ良いのです。
しかし、「学ぼうとしない」、「他の意見を受け入れない」、「考えようとしない」人にコードを書かせることは、会社にとっても本人にとってもマイナスでしかないと考えています。問題が多いコードをいつまでも書き続けるなら、使えない人材と判断するしかありません。業務としてやる以上、仕方のないことです。
Re: (スコア:0)
すごい向上心のある人だと思ったんだけど、
そんなにすごいのなら大きな企業に転職してみてはどうでしょうか？
Re: (スコア:0)
独学の組み込み系なので、かなり古く低レベルだと思います。
誰がうまいこと言えと