| 前のトピックを表示 :: 次のトピックを表示 |
| 投稿者 |
メッセージ |
リセット
登録日: 2013.06.17
記事: 24
|
 日時: 2013-06-17(Mon) 23:30 記事の件名: Arduinoでオーディオ機器コントロール！ |
 |
|
初めまして、リセットです。
リモコンが付いていないオーディオ機器にIRリモコンやBluetoothコントロール、
Wifi経由でのコントロールなど、色々な事をやっています。
よろしくお願いしますー |
|
| トップに戻る |
|
 |
senshu
Site Admin
登録日: 2009.06.01
記事: 2988
|
| 日時: 2013-06-18(Tue) 08:39 記事の件名: |
|
|
リセットさん、おはようございます。
Arduinoを使って試作を行っている件、了解です。
ただし、Arduinoボードはそれなりの価格になので、機器に
埋め込むのは得策ではありません。
ISP方式のAVRライタがあれば、可能性は拡大すると思います。
AVRライタは1台あれば通常は十分ですから、その後の進展をお知
らせいただければ幸いです。 |
|
| トップに戻る |
|
|
リセット
登録日: 2013.06.17
記事: 24
|
|
| トップに戻る |
|
|
senshu
Site Admin
登録日: 2009.06.01
記事: 2988
|
| 日時: 2013-06-18(Tue) 22:37 記事の件名: |
|
|
リセットさん、今晩は。
具体的な取り組みの紹介をありがとうございます。
Arduinoをベースに、これほど凝ったものを製作される方がいるとは思い
ませんでした（ISP用のコネクタが見当たりませんが、、、）。
こうした報告を拝見すると、ツールの提供し甲斐があります。
ところで、 Apple REMOTEとはこれ（↓）のことでしょうか。
http://store.apple.com/jp/product/MC377J/A/apple-remote
また、製作したAVRライタと利用環境（OS）を教えてください。 |
|
| トップに戻る |
|
|
リセット
登録日: 2013.06.17
記事: 24
|
| 日時: 2013-06-19(Wed) 18:31 記事の件名: 雑記と利用環境について |
|
|
そうなんですよ、ISP用のコネクタを付けていません。
ライタに差し替えてプログラム更新を行っています。
頒布を考えているのですが、内容としては基板と AVR のセットを考えています。
頒布先でライタを用意される可能性は低いだろうという発想です。またメンテナ
ンスが必要になった場合は、AVR を送ってもらい個別対応する予定です。
ですので、添付した写真のようにゼロプレッシャー付き ROM ライタを作成し、ROM
をひたすら焼いていく という事を行っています。また、この手法を実現するた
めには千秋さんのツールが無いと無理でした。（なにより、パフォーマンスが凄
い）改めて感謝です。
AppleREMOTEはそのリンクの通りです。
手に持った感触とクリック感、必要最小限の機能で、大変重宝しています。
フォーマットはNEC方式で、受け側の難易度も低いです。
参考にしたURLはこちらです。
http://hifiduino.wordpress.com/apple-aluminum-remote/
作成したライタはこちらを参考にしました。
http://www.geocities.co.jp/arduino_diecimila/avr-writer/index.html#top
Programmerには、【AE-UM232R:FT232R BitBang】を使用しています。
ボーレートは300Kを指定していますが、実に快適ですね。
OS は、Windows7 Ultimate 64bit を使用しています。現在の所、問題は発生して
いません。
|
|
| トップに戻る |
|
|
senshu
Site Admin
登録日: 2009.06.01
記事: 2988
|
| 日時: 2013-06-19(Wed) 18:54 記事の件名: |
|
|
リセットさん、今晩は。
FT232RLを使って書き込まれているのですね。これは、単なるBitBangライタではない
ので、かなりの書き込み速度が得られます。Arduino IDEとは速度や自由度に大きな
違いがあります。
実際に使ってみれば、性能の違いはすぐに実感できます。また適切な設定を行えば、
AVRISP-mkII と同等の書き込み速度が達成できます。
＞Programmerには、【AE-UM232R:FT232R BitBang】を使用しています。
＞ボーレートは300Kを指定していますが、実に快適ですね。
300kbps という指定は無効なので、内部的には 230400 bps が割り当てられます。
あるいは、最速の 3000kbps を選択しているのでしょうか。
＞OS は、Windows7 Ultimate 64bit を使用しています。現在の所、問題は発生して
＞いません。
了解です。どの Windows でも、x64 環境で快適に動作するライタは限られます。
幸い、このサイトで紹介しているものは全て x64 環境で動作することを確認しま
した。
| Quote: | 頒布を考えているのですが、内容としては基板と AVR のセットを考えています。
頒布先でライタを用意される可能性は低いだろうという発想です。またメンテナ
ンスが必要になった場合は、AVR を送ってもらい個別対応する予定です。 |
頒布先が使うかどうかは無関係です。私はマイコン開発の効率から、ゼロプレッシャ方式
の採用はお勧めしません。抜き差しの間にMCUのピンを折るなどのトラブルも生じるのです。
（QFPのMCUでは抜き差し自体が不可能であり、抜き差し方式はDIP限定の開発方式です）
ISP 方式に変更するのは難しくありません。せめて開発用のボードだけでも ISP コネ
クタを取り付ければ、MCU を抜き差しするという作業は不要ですから、効率は格段に
向上すると思います。
ISP 用のピンが他の目的に使われているなら、スイッチなどで電気的に開放でき
る工夫をすればよいと思います。
| Quote: | ですので、添付した写真のようにゼロプレッシャー付き ROM ライタを作成し、ROM
をひたすら焼いていく という事を行っています。また、この手法を実現するた
めには千秋さんのツールが無いと無理でした。（なにより、パフォーマンスが凄
い）改めて感謝です。 |
ROM ですか、AVR マイコンは ROM ではないと思うのですが、、、。ISP 用のコネ
クタは安価ですが、コストが優先されるなら実装をオプショナルすればよいのです。
でも必要に応じて取り付けが可能になるように、ISPコネクタ用のホールは用意し
て欲しいと思っています。
ISP 方式ならMCUの抜き差しは不要で、デバッグへの移行も瞬時です。
開発者の勝手と思うかもしれませんが、ぜひご検討ください。
最終編集者 senshu [ 2013-06-20(Thu) 19:09 ], 編集回数 3 回 |
|
| トップに戻る |
|
|
リセット
登録日: 2013.06.17
記事: 24
|
| 日時: 2013-06-19(Wed) 19:35 記事の件名: おお、ありがとうございます！ |
|
|
色々とご助言ありがとうございます。
300Kではなく確かに3000Kですね、ゼロの数え間違いです。
ROMでもありませんしね 
マイコンを始めて半年くらいで、ISP 端子についてはつい最近まで単語自体意識したこと
もありませんでした。（ライタを作る前は、Arduino を使ってブートローダー書き込み、
Arduino に差し直してプログラムのビルドを行おうと考えていました）
動画にもありますように、直前まで Arduino ボード上で開発を行っていましたので、抜く
ことも無く、不便さも感じていなかったのです。
しかし、助言頂いたように抜き差しにはいろんなリスクがあります。次回の開発時には、
対策しておきたい問題です。スイッチで切替えればいいじゃん！のアイデア頂きます。
しかし、Arduino は面白いです。マイコンでもオブジェクト指向的な開発ができるのは、
大変刺激的でした。 |
|
| トップに戻る |
|
|
senshu
Site Admin
登録日: 2009.06.01
記事: 2988
|
| 日時: 2013-06-20(Thu) 08:24 記事の件名: |
|
|
リセットさん、お早うございます。
>300Kではなく確かに3000Kですね、ゼロの数え間違いです。
>ROMでもありませんしね Wink
了解です。数値が大きく'0'が連続するため、誤読の可能性があるようです。
avrdude-GUI では、選択した値をそのまま avrdude に渡すため、表示を 3000000から
3000k に変更するだけでは機能しません。今朝は頭の回転が鈍く、早期の修正は諦める
つもりでした。
しかし昼ごろに修正方法を思いつき、修正作業を行いました。追加は10行程度です。
修正版の実装は、「kを含む値を登録して表示させ、選択して得られた表示データを実
際の値に変換」します。これ以外は今まで通りです。
別の方法もありそうですが、このメニューはライタによって三種類の異なる値が登録
されるので、決め打ちで変換することはできません。
なお FT232RL では、大きな値を指定しても性能が頭打ちになるため、1000000 以
上の指定はあまり意味がありません。1000k を超える指定は、高性能な FT232 後
継チップ用と考えてください。
1000kを指定して16kBのFlashを読み出し、FT232RLとFT2232dの速度差を比較しました。
| Code: | FT2232dでmega168をDump # HEX dump of flash (OK), 00:00:01.25
FT232RLでmega168をDump # HEX dump of flash (OK), 00:00:02.39 |
FT2232dは約2倍の速度ですが、1秒の違いですから高性能といっても誤差の範囲です。
AVRライタとしても利用するなら、I/O電圧の柔軟性を備えたFT232RLが最適です。
※ このテストで、FT2232d指定時に、BaudRate指定に切り替わらない不具合を発見し
たので、avrdude.confファイルも併せて修正しました。
値を変えて Dump などを行ってみれば、実行時間を表示するので簡単に性能評価
ができます。
なお、avrdude-GUI-130620.zip に含まれる avrdude-GUI.exe は BaudRate 表示
を修正しただけです。その他の機能変更はありませんが、BaudRate 値を読み間違
うことは無くなったと思います。
利用してトラブルが無ければ、次回の更新時はこの仕様とします。
最終編集者 senshu [ 2013-06-21(Fri) 18:19 ], 編集回数 19 回 |
|
| トップに戻る |
|
|
senshu
Site Admin
登録日: 2009.06.01
記事: 2988
|
| 日時: 2013-06-20(Thu) 14:54 記事の件名: |
|
|
>マイコンを始めて半年くらいで、ISP 端子についてはつい最近まで単語自体意識したこと
>もありませんでした。（ライタを作る前は、Arduino を使ってブートローダー書き込み、
>Arduino に差し直してプログラムのビルドを行おうと考えていました）
意外ですが、専用基板まで起こされているのですから電子回路には精通されてい
るのではと思います。AVR マイコンの多くは、インサーキットでの Flash 書き換
えが基本です。DIP で入手できる AVR マイコンも限られる時代となり、ISP 方式
しか使えないことも増加しています。
>動画にもありますように、直前まで Arduino ボード上で開発を行っていましたので、抜く
>ことも無く、不便さも感じていなかったのです。
そうですか。私は Arduino IDE の書き換えの緩慢さが耐えられず、avrdude-GUI
を Arduino IDE にも対応できるように拡張しました。
>しかし、助言頂いたように抜き差しにはいろんなリスクがあります。次回の開発時には、
>対策しておきたい問題です。スイッチで切替えればいいじゃん！のアイデア頂きます。
了解です。現状でも、ISP コネクタを追加した補助ボードを作成すれば、開発作
業を格段に効率化できます。開発用のボードだけ、ISPコネクタがあれば十分です。
量産？時は、今までのゼロプレッシャソケット方式が使えます。
>しかし、Arduino は面白いです。マイコンでもオブジェクト指向的な開発ができるのは、
>大変刺激的でした。
AVR マイコン程度のメモリでは、オブジェクト指向を導入しても制約が大きいと
感じていました。メモリ制限の厳しい場合も効果がある、ということでしょうか。
ぜひ、その利点と考える使い方を紹介してください。 |
|
| トップに戻る |
|
|
senshu
Site Admin
登録日: 2009.06.01
記事: 2988
|
| 日時: 2013-06-21(Fri) 18:19 記事の件名: |
|
|
Download用の板に、avrdude-2013-RC15b.zip を置きましたので
そちらを使ってください。 |
|
| トップに戻る |
|
|
リセット
登録日: 2013.06.17
記事: 24
|
| 日時: 2013-06-24(Mon) 23:37 記事の件名: |
|
|
早速のbitrateのドロップダウンメニューの修正対応ありがとうございます。
読み違えることはこれで無くなります。
また、動作確認も行いました。特に問題なく今まで同様使えています。
1回の書き込み＋ベリファイで、おおよそ11秒ほどですね。
以下、抜粋
| Code: | Writing | ################################################## | 100% 6.36s
Reading | ################################################## | 100% 4.43s
# Wrote to flash ... Verify=ON (OK), 00:00:11.12 |
あと、基板を担当しているのは他のメンバーですので、電子工作自体はマイコンに輪をか
けてド素人です。期待に応えられず、申し訳ないです。
色々 ISP に関して頂いた助言は、千秋さんのこれまでの経験則からくるアラートであろう
と考え、対応を考えています。今の基板に設置するのは僕のスキルでは困難なので、DIP
ソケットとスイッチ付きの基板のようなものを作ろうと考えています。 |
|
| トップに戻る |
|
|
senshu
Site Admin
登録日: 2009.06.01
記事: 2988
|
| 日時: 2013-06-25(Tue) 08:39 記事の件名: |
|
|
リセットさん、お早うございます。
ハードウェア設計に関しては詳しくない件は了解しました。
それならなおのこと、ISPコネクタを設けることをお勧めします。
ソフトウェア開発時のハードウェア操作が不要になります。
また、オブジェクト指向の利点をお聞かせください。 |
|
| トップに戻る |
|
|
リセット
登録日: 2013.06.17
記事: 24
|
| 日時: 2013-08-20(Tue) 12:55 記事の件名: ご無沙汰しています |
|
|
| senshu wrote: | リセットさん、お早うございます。
ハードウェア設計に関しては詳しくない件は了解しました。
それならなおのこと、ISPコネクタを設けることをお勧めします。
ソフトウェア開発時のハードウェア操作が不要になります。
また、オブジェクト指向の利点をお聞かせください。 |
ご無沙汰しています、リセットです。
先日無事に頒布を開始しました。色々なご指導ありがとうございます。
ISP は確かに楽になりました。
さて、具体的に書くのは難しいので、抽象的に質問へ返答しますね。
今回のプロジェクトでは状態遷移が色々あり、振る舞いを手続き型で書くと複雑
度が上がりまくることから State パターンを採用しました。
リソースに制約が多く全てをオブジェクト指向で記述はできないため、適宜採用
しています。
これにより、一部のソース複雑度の低下と品質向上、開発効率 UP が得られ、マ
イコンでも利点を感じました。 |
|
| トップに戻る |
|
|
senshu
Site Admin
登録日: 2009.06.01
記事: 2988
|
| 日時: 2013-08-20(Tue) 15:11 記事の件名: |
|
|
リセットさん、こんにちは。
>先日無事に頒布を開始しました。色々なご指導ありがとうございます。
>ISP は確かに楽になりました。
AVRマイコンは、ISPでの書き込みを前提に設計されています。ソケットから
取り外しながら書き込むのは、例外的な使い方だと思います。
>今回のプロジェクトでは状態遷移が色々あり、振る舞いを手続き型で書くと複雑
>度が上がりまくることから State パターンを採用しました。
>
>リソースに制約が多く全てをオブジェクト指向で記述はできないため、適宜採用
>しています。
>
>これにより、一部のソース複雑度の低下と品質向上、開発効率 UP が得られ、マ
>イコンでも利点を感じました。
状態遷移の実現は、C言語の場合は関数へのポインタのテーブルを用意すれば、
シンプルに実現できます。ただし、あまり読み易くないのが欠点です。
どの言語を使っても、（腕次第で）読み易くも、読み難くも書くことができます。
優れたプログラマは、アセンブリ言語でも読み易くて高機能なコードを書けるよう
です。私には無理ですが、、、。 |
|
| トップに戻る |
|
|
リセット
登録日: 2013.06.17
記事: 24
|
| 日時: 2013-08-23(Fri) 08:29 記事の件名: |
|
|
| senshu wrote: | リセットさん、こんにちは。
状態遷移の実現は、C言語の場合は関数へのポインタのテーブルを用意すれば、
シンプルに実現できます。ただし、あまり読み易くないのが欠点です。
どの言語を使っても、（腕次第で）読み易くも、読み難くも書くことができます。
優れたプログラマは、アセンブリ言語でも読み易くて高機能なコードを書けるよう
です。私には無理ですが、、、。 |
発言の意図がわかりません。 |
|
| トップに戻る |
|
|
リセット
登録日: 2013.06.17
記事: 24
|
| 日時: 2013-08-23(Fri) 12:54 記事の件名: |
|
|
| リセット wrote: |
発言の意図がわかりません。 |
これだけでは、私の発言自体も意図が分からないですね。
不躾な発言お許しください。
まず関数ポインタを使うという箇所について。
千秋さんがどのような使い方を想定しているのかが、分からないのです。
例えば、Stateパターンを置き換える方法についてだとわかったと思います。メリットに
ついては、そこを抑えないと論議できないと思います。
またソースの可読性については、メンテナンスのコストを含め、当たり前の非機能要件です。
僕はそこにオブジェクト指向としてのメリットを見出していません。
なにを使っても汚いソースは作れるのです。たとえデザインパターンを適用してもです。
可読性の高いソースは、当たり前の話なんです。メリットとは関係ありません。
複雑度と可読性を混同されていますか？
そしてアセンブラの話は、メリットの話から逸脱していてわかりませんでした。
前回オブジェクト指向についてメリットを記述しましたが、ご返答頂いた内容はこちらが
想定していたStateパターンの置き換えになっていなかったため、意図がわからない、と
いう返答に至りました。 |
|
| トップに戻る |
|
|
リセット
登録日: 2013.06.17
記事: 24
|
| 日時: 2013-08-23(Fri) 21:43 記事の件名: |
|
|
| senshu wrote: | リセットさん、こんにちは。
>先日無事に頒布を開始しました。色々なご指導ありがとうございます。
>ISP は確かに楽になりました。
AVRマイコンは、ISPでの書き込みを前提に設計されています。ソケットから
取り外しながら書き込むのは、例外的な使い方だと思います。
>今回のプロジェクトでは状態遷移が色々あり、振る舞いを手続き型で書くと複雑
>度が上がりまくることから State パターンを採用しました。
>
>リソースに制約が多く全てをオブジェクト指向で記述はできないため、適宜採用
>しています。
>
>これにより、一部のソース複雑度の低下と品質向上、開発効率 UP が得られ、マ
>イコンでも利点を感じました。
状態遷移の実現は、C言語の場合は関数へのポインタのテーブルを用意すれば、
シンプルに実現できます。ただし、あまり読み易くないのが欠点です。
どの言語を使っても、（腕次第で）読み易くも、読み難くも書くことができます。
優れたプログラマは、アセンブリ言語でも読み易くて高機能なコードを書けるよう
です。私には無理ですが、、、。 |
もしかしてと思い、千秋さんの作られたWindowsソフトのソースを拝見しました。
C#をお使いな事と、ソースの可読性にこだわられていらっしゃるので期待していました。
しかし実態は、千秋さんの言葉を引用させて頂くと、例外的な記述です。
具体的に、例外的な記述だと考えるに至った経緯について記述します。
•関数の責務が不明瞭である事、それによる複雑度の上昇。ざっくりいうと、色々やり
過ぎててわけがわからない。修正するとバグが発生するレベルで触るな危険。
•無駄なコメントと必要な場所にないコメント。最初の長いリマークの後工程は何？
ソース管理で適切にリビジョン管理をすればよくないか？
関数に責務を記述したコメントが無いのは何故？
•長すぎる関数。再利用が不可能で、何をしたいのか不明瞭。リファクタリングが必要。
•記述の無い関数が残存。意図があるならば何らかのコメントが必要。この関数は、何も
しない事が責務というものもありうる。
•1本のソースが長すぎる。コメント、空行込みで7Kあるソースがあり、全体を俯瞰で
見渡す事は不可能。
•テキストボックスの内容を構築するメソッドが無く、設定されているものを置換して
構築している。これにより責務が分散され、あちこちでReplaceを行っている。
•Checkとプレフィックスに付いている関数は、リターン値がFalse,Trueどちらが期待値
なのか不明確。isやhas,didなどわかりやすくした方が良い。
などなど、色々とツッコミどころがあります。
また、上記に挙げた実装は、全て顕在化している問題で、リスクではありません。
千秋さんがISPについて、しつこくそんな利用は想定外だ！と仰られている事は、他者に
真似をさせないためにしつこくしつこく言わざるを得なかったと解釈しております。
それと同じ視点で、ソースの見直しもご一考下さいませ。 |
|
| トップに戻る |
|
|
リセット
登録日: 2013.06.17
記事: 24
|
| 日時: 2013-08-24(Sat) 02:57 記事の件名: 補足資料について |
|
|
客観的な資料も添付しておきます。
MainForm.csについて、ソースの評価を機械的に行った結果です。
いわゆる閻魔帳的な存在の図ですね。
では、図をご覧ください。
円の上部から左回りに順次確認しましょう。
-------------------------------------------------------------
・コメント割合 ：平均
・平均複雑度 ：描画エリア外
・平均階層数 ：グリーン外
・最高階層数 ：描画エリア外
・最大複雑度 ：描画エリア外
・クラス内の平均メソッド数：描画エリア外
・ソース内ドキュメント割合：グリーン内
-------------------------------------------------------------
全ての評価項目がグリーン枠内に入るのが、好ましい という具合に見てください。
また、詳しいことはGoogleで検索してみてください。
この資料と現物確認でソースコードレビューを行った結果、残念な結論に至りました。
千秋さんは、問題に気がついたらすぐに対処される方と認識しています。
それは、ISPに関して私にアラート頂いたコメントを見て確信しております。
ソースコードの見直しを行ってください。
開発者の勝手と思うかもしれませんが、ぜひご検討ください。
また、関数ポインタを使用するメリットが私には良く分かりません。
千秋さんが挙げられた根拠となる「Stateパターン」と、それを置き換えるに値する
「関数ポインタを採用したロジック」の評価判定基準とその評価結果をお教えください。
また、想定された「関数ポインタを採用したロジック」の具体例についてもお教えください。
オブジェクト指向をマイコンで採用しないという評価も気になっています。その評価根拠も
教えてもらえませんか？
可読性の高いソース例についても、興味があります。紹介してください。 |
|
| トップに戻る |
|
|
senshu
Site Admin
登録日: 2009.06.01
記事: 2988
|
| 日時: 2013-08-24(Sat) 20:39 記事の件名: |
|
|
リセットさん、興味深い解析結果をありがとうございます。
Docsが少なすぎるのは一人で書いているのと、プロジェクトフォルダ内には置いて
いなるためだと思います。そして、ソースコードではなくこの掲示板にも開発経過
を書いています。
Commentsは多くは無いのですが、名前を工夫し、（自分では）コメントを見なくと
もわかるようにしています。
コードの仕様変更によってコメントが実際の機能とは異なる場合があり、コメント
の修正が漏れて誤解を招くことがあります（既にそうした箇所があると思います）。
しかし、複数のメンバーで開発する場合には許されませんが、現在仕事が混んでいて、
avrdude-GUIの改良に多くの時間を割くことはできません。
時間を見て、全体の見直しをしたいと思います。
ただし、C#でのソフトウェア開発は経験が無く、学習しながら書いている身です。
そのため、改良よりもバグを混入しそうで、気が進みません。
具体的に改良例を提示いただければ幸いです。 |
|
| トップに戻る |
|
|
iruka
登録日: 2009.08.12
記事: 62
|
| 日時: 2013-08-24(Sat) 21:13 記事の件名: Re: 補足資料について |
|
|
リセットさん、こんばんは。
上記の解析ツールに興味を持った者ですが・・・
これは以下のソースモニターなのでしょうか？
http://www.slideshare.net/MoriharuOhzu/ss-9224836
以前から人の書いたクソース（失礼：）をどうやって
退治するかを命題にしておりまして、Ｃ＋＋用の静的
解析ソフトを探していたのですが、無料のものはほぼ
壊滅状態でした。
ＱＡＣ＋＋とか商用のものは目の玉が飛び出るほどボッタクリ
で、導入は無理（笑）でした。
Ｃ＋＋でないなら、（ＣとかＯｂｊＣなら）ＬＬＶＭの
ものが使えるのですが・・・と、困っていたところでした。
ソースモニターの使い心地はいかがなものでしょうか。
ちなみに私はＣ＃は全く分かりませんし、使う予定も無くて
ＣかＣ＋＋のみ使用です。
割り込みしてすみませんが、よろしくおねがいします。 |
|
| トップに戻る |
|
|
リセット
登録日: 2013.06.17
記事: 24
|
| 日時: 2013-08-24(Sat) 22:49 記事の件名: |
|
|
| senshu wrote: | リセットさん、興味深い解析結果をありがとうございます。
Docsが少なすぎるのは一人で書いているのと、プロジェクトフォルダ内には置いて
いなるためだと思います。そして、ソースコードではなくこの掲示板にも開発経過
を書いています。
Commentsは多くは無いのですが、名前を工夫し、（自分では）コメントを見なくと
もわかるようにしています。
コードの仕様変更によってコメントが実際の機能とは異なる場合があり、コメント
の修正が漏れて誤解を招くことがあります（既にそうした箇所があると思います）。
しかし、複数のメンバーで開発する場合には許されませんが、現在仕事が混んでいて、
avrdude-GUIの改良に多くの時間を割くことはできません。
時間を見て、全体の見直しをしたいと思います。
ただし、C#でのソフトウェア開発は経験が無く、学習しながら書いている身です。
そのため、改良よりもバグを混入しそうで、気が進みません。
具体的に改良例を提示いただければ幸いです。 |
千秋さん
コメントを書く意味はいろいろあると思いますが、どのような目的でかかれてい
ますか？
なぜ実装とコメントで差異がでるのですか？
重要なことですが、それは今後開発する物でも同じになりますか？
ならないための暫定対策と是正対策はどのような事をお考えですか？
複雑度と階層についての振り返りはどうだったでしょうか？
ここにはコメントがありません。
ちなみに、現在の状態では、改修を行っただけでもバグが混入する状態です。具
体的な改良については、指摘ですでにキーワードを挙げています。それは、千秋
さんの頭の中にだけ有り、具体的な改良例は残念ながらお見せできません。
それは設計書だからです。
しかし、本音は改良ではなく、再構築が良いと思います。
また、「そのため、改良よりもバグを混入しそうで、気が進みません。」
これは重要な不安感です。
この不安感を払拭するために、マーティン・ファウラーの本をおすすめします。そして、ソースを
変質させることなく綺麗にしていく手法について見聞を広めてみてください。
オブジェクト指向の知識も必要ですが、手続き型でも応用は利くでしょう。
私が真っ先に取りかかるとしたら、責務の明確化でしょう。
VB,C# などのツールで画面を構築し、そのままイベントに処理を記述することで
発生しやすいのですが、「ボタン押下イベントを処理する」と、「ある事を処理
する」がごちゃまぜになっています。まずはここに着手されたらいいんじゃない
ですか？
ソース・クラス・関数の責務を明確にして、可能な限りシンプルな作りにする。
これを行う事で、改修が行いやすい体質へと変化させ、再利用可能とする。
この概念は、C,Objective C,C++,ASM,C#,VB,VBA,VB.Net,なんだろうと共通ではな
いでしょうか。
また、名前は重要です。関数名・メソッド名同様、変数名も適宜見直しが必要だ
と思います。
最終編集者 リセット [ 2013-08-25(Sun) 03:48 ], 編集回数 1 回 |
|
| トップに戻る |
|
|
senshu
Site Admin
登録日: 2009.06.01
記事: 2988
|
| 日時: 2013-08-24(Sat) 23:06 記事の件名: |
|
|
了解しました。
しかし、前述の通り、現状では時間が確保できません。
マーティン・ファウラーの本を入手し、読んでみます。作業は、その内容を理解した
後になります。そのため、改善はしばらく先とになります。
senshu Wrote
＞ただし、C#でのソフトウェア開発は経験が無く、学習しながら書いている身です。
＞そのため、改良よりもバグを混入しそうで、気が進みません。
なお、↑は「短期間に全面的に書き替えて、今のレベルを維持できる自信がない」
という意味です。 |
|
| トップに戻る |
|
|
リセット
登録日: 2013.06.17
記事: 24
|
| 日時: 2013-08-24(Sat) 23:18 記事の件名: Re: 補足資料について |
|
|
| iruka wrote: | リセットさん、こんばんは。
上記の解析ツールに興味を持った者ですが・・・
これは以下のソースモニターなのでしょうか？
http://www.slideshare.net/MoriharuOhzu/ss-9224836
以前から人の書いたクソース（失礼：）をどうやって
退治するかを命題にしておりまして、Ｃ＋＋用の静的
解析ソフトを探していたのですが、無料のものはほぼ
壊滅状態でした。
ＱＡＣ＋＋とか商用のものは目の玉が飛び出るほどボッタクリ
で、導入は無理（笑）でした。
Ｃ＋＋でないなら、（ＣとかＯｂｊＣなら）ＬＬＶＭの
ものが使えるのですが・・・と、困っていたところでした。
ソースモニターの使い心地はいかがなものでしょうか。
ちなみに私はＣ＃は全く分かりませんし、使う予定も無くて
ＣかＣ＋＋のみ使用です。
割り込みしてすみませんが、よろしくおねがいします。 |
はい、ソースモニターです。
算出しようとしている指標値が私のニーズにはあっていましたので、これを皆に
使わせています。運用や適用時期についてはノウハウの部分になってくるので濁
します。
しかし、逆にクソースを産む原因にもなりえます。
使い心地は最上級ですが、性悪説に基づき、スコアがいいものは逆に疑ってかか
る姿勢が必要だと思います。 |
|
| トップに戻る |
|
|
リセット
登録日: 2013.06.17
記事: 24
|
| 日時: 2013-08-25(Sun) 01:12 記事の件名: |
|
|
| senshu wrote: | 了解しました。
しかし、前述の通り、現状では時間が確保できません。
マーティン・ファウラーの本を入手し、読んでみます。作業は、その内容を理解した
後になります。そのため、改善はしばらく先とになります。
|
コメントを書く意味はいろいろあると思いますが、どのような目的でかかれていますか？
後工程では、どのように活用されるのですか？
なぜ実装とコメントで差異がでるのですか？
それは、コメントが間違っているのですか？実装が間違っているのですか？
それは今後開発する物でも同じになりますか？
ならないための暫定対策と是正対策はどのような事をお考えですか？
とても重要な事です。
複雑度と階層についての振り返りはどうだったでしょうか？
ここにはコメントがありません。
ちなみに、現在の状態では、改修を行っただけでもバグが混入する状態です。
具体的な改良については、指摘ですでにキーワードを挙げています。
それは、千秋さんの頭の中にだけ有り、具体的な改良例は残念ながらお見せできません。
指摘で挙げたキーワードで、検索はされましたか？
特に重要なキーワードは、「オブジェクト指向」「デザインパターン」「リファクタリング」です。
オブジェクト指向を理解し、設計を進めていくとある一定のレベルで似た問題に取
り組んだことがある、と過去のリソースを再利用し始めます。この再利用するパター
ンがあることに気がつきます。
これらのパターンを２３種類に分類し、「名前」を付けた。これがデザインパターンです。
GoF（Gang of Four）が建築デザインにおけるパターンを見て考案・提唱しました。
ここで重要な点は、パターンに名前を付けた事です。これにより、有識者間で「State」を使う
と言った瞬間に、
「あぁ、継承を利用して、状態遷移の振る舞いを最適化して拡張性を持たせるんだね。
複雑度は低下して品質とメンテナンス性が向上するね。 ところで、状態遷移のパターン
は何パターンあるの？今後の増加予想は？」
と、実装イメージ、メリット、トレードオフ、アラート点について理解できるように
しています。また、初心者・上級者とのスキル差異を埋める事もできます。
「関数ポインタ」という、変数の型の次元ではありません。
Stateパターンを適用するというのは、設計、思想の話なんです。
しかし、関数ポインタの評価判定基準、評価結果はどのようなものだったのでしょ
うか？興味があります。エレガントであれば是非採用したいです。お教えください。
その後、実装を進めていくうえで、「なんかヤベェ」と、製造を続けていいのか悩
む事があります。きな臭いというか、謎の不安感、圧迫感であるとか。そういうと
き、実装の手を止めてソースコードの問題点と解決を行っていく手法が「リファク
タリング」です。マーティン・ファウラーは、問題点と解決方法をカタログ化し、
書籍化しました。
ここで重要なのは、現在の品質を保ったままソースコードの体質を改善しなければ
いけない という事です。当たり前ですね。そして、リファクタリング中はリファ
クタリングだけを行う という事です。
失礼ですが、C# の統合環境には「リファクタ」がありますよね？使用されたことは
ありませんか？ドライバ関数を作り、関数内部のチェックをされたことはありませ
んか？
マーティン・ファウラーの書籍を参照すれば、どのように品質を保ったまま、ソー
スコードを編集していけば良いかが把握できます。そして、現在のプロジェクトに
不足している、単体テストユニットが必要であることも理解できると思います。
C#のリファクタリング機能が、何をやっているかも把握できます。
そして、この理論が把握できれば、テキストエディタでもリファクタリングが可能
です。
結果として、エレガントに仕上がったソースは可読性も向上しますよ。これは千秋
さんが口をすっぱくして言われていることではないでしょうか？
可読性を向上させるためにソースに手を入れるのはナンセンスなのです。
責務が明確になっており、名称がわかりやすいから、読みやすくなるのです。
可読性は、あくまでも副産物だと私は考えています。
しかし、これらの作業を行っても Try-Catch-Final の適用範囲がおおざっぱ過ぎる
（VB でいうところの、On Error Resume Next）といった問題はフォローできません。
そういった利用方法が誤っていることを理解するのは、また別の次元の話です。
| senshu wrote: |
senshu Wrote
＞ただし、C#でのソフトウェア開発は経験が無く、学習しながら書いている身です。
＞そのため、改良よりもバグを混入しそうで、気が進みません。
なお、↑は「短期間に全面的に書き替えて、今のレベルを維持できる自信がない」
という意味です。 |
今まで私は言語に特化した話は記載していません。どのような言語でも、例えばマ
イコンに関するプログラムでも同様ですよ。
そして重要なことは、正論で攻めてくる相手に対して例えば
「いや、パフォーマンスとリソースを考慮した結果ループを利用していない」
「関数化して細分化することによって、スタックメモリが圧迫されるために
あえて冗長化することを選んだ」
と、理由がいえることだと思います。
私はこう書きました。
-------------------------------------------------------------------------
今回のプロジェクトでは状態遷移が色々あり、振る舞いを手続き型で書くと複雑
度が上がりまくることから State パターンを採用しました。
リソースに制約が多く全てをオブジェクト指向で記述はできないため、適宜採用
しています。
これにより、一部のソース複雑度の低下と品質向上、開発効率 UP が得られ、マ
イコンでも利点を感じました。
-------------------------------------------------------------------------
偉そうなことを言っていますが、私はマイコンでの実装２作目のド素人です。
でも機能においては同業の追従を許さないものとなったのではないでしょうか。
問題の本質が分かっていれば、初めての言語であっても環境であっても余裕で対応が可能なのです。
(設計ですよ と暗に言っているつもりです)
以下、伺いたい点を再掲しておきます。
関数ポインタを使用するメリットが私には良く分かりません。
千秋さんが挙げられた根拠となる「Stateパターン」と、それを置き換えるに値する
「関数ポインタを採用したロジック」の評価判定基準とその評価結果をお教えください。
また、想定された「関数ポインタを採用したロジック」の具体例についてもお教えください。
オブジェクト指向をマイコンで採用しないという評価も気になっています。その評価根拠も
教えてもらえませんか？
可読性の高いソース例についても、興味があります。紹介してください。 |
|
| トップに戻る |
|
|
ばんと
登録日: 2009.09.20
記事: 63
|
| 日時: 2013-08-25(Sun) 18:03 記事の件名: |
|
|
リセットさんはじめまして、はんとと申します。よろしくです。
senshuさんとの会話にでしゃばって申し訳ないですが、少しおつきあいください。
読み間違えなら申し訳ないですが、プログラミングの正解があるような論調ですが、
これまで文芸的プログラミングだとか構造的プログラミングだとかオブジェクト指
向プログラミングだとか色々とプログラミングにはアイデアと思想が導入されてき
ましたが、どれも正解でありどれも正解てはありませんでした。これまでの経験からすると、リセット
さんのやり方が絶対的な正解だとは思えません。
可読性が高いというのは"C 言語ならカーニハン & リッチ・スタイルにするとか GNU
スタイルにするとか Linux スタイルにするとか"、如何に一般的な書き方をするか
ということだと思ってます。オブジェクトだから云々は関係ないと思います。
当方 C# でのプログラミングには慣れてないので可読性が高い (つまり一般的な書
き方) ソースの書き方を知りません。リセットさんは詳しい様子なので、可読性の
高い (つまり一般的な書き方) ソースを読ませていただけると幸いです。
ところで、Arduino は別物ですが、なぜ AVR のようなマイコンではオブジェクト言
語を使う人がすくないかというと、8 ビットの AVR のようなマイコンはシンプルか
つ資源が少ないので、自ずとアセンブラや C 言語を選択するプログラマが多いので
す。ソフトの世界ではいちから作るということは少ないですよね。他人様のソース
を参考に作られていくものですから、C 言語で書かれてる参考ソースが多いと自ず
と C 言語で書くことになります。リセットさんも幾つか作って見ると理解できると
思います。
ところでマイコンでは非オブジェクトつまりアセンブラや C 言語がメインの文化
です。そこでオブジェクト言語について語られても皆さんチンプンカンプンかもし
れません。
当方は java とか C++ とか Perl ・ Ruby とか、ヘッポコなりとも理解できるので
すが、最近のオブジェクト指向言語のトレンドは不勉強なため、リセットさんが書
かれるテクニカルタームで分からなく概念や思想が理解できません。ひとつ教えて
いただきたいのですが、「State パターン」とはステート (状態) を管理するオブ
ジェクトを使ったプログラミング手法のことなのでしょうか ?
State パターンからの連想ですが、ステートマシンという結構古い手法があります。
AVR のようなマイコンでも少し凝ったものになるとステートマシンを想定して設計
されプログラミングされてることが多いです。ステートマシンは switch ・ case
文で実装されることが多いのですが見慣れた手法で可読性が落ちるということはな
いですょ。
オブジェクト指向の言語もオモシロイですが、マイコンのプログラミングは未知な
デバイス (周辺機器) を資料漁りとオシロなど道具を利用して意地で工夫で駆動す
るという醍醐味があります。オモシロイですょ。 |
|
| トップに戻る |
|
|
リセット
登録日: 2013.06.17
記事: 24
|
| 日時: 2013-08-25(Sun) 20:22 記事の件名: |
|
|
はい、はんとさんは読み違えています。
定義も不明確です。
千秋さんとの議論へのノイズとなるので、別の場所で議論をする分には問題ありません。
ちなみに、はんとさんが考える可読性の高さは何ですか？K&Rスタイルであれば可読性が高いと判断されるのですか？
私には無い概念ですので、別の場所で詳しくお聞きしたいです。 |
|
| トップに戻る |
|
|
ばんと
登録日: 2009.09.20
記事: 63
|
| 日時: 2013-08-25(Sun) 21:19 記事の件名: |
|
|
毎度です。ばんとです。
質問してるのに質問で返されましたね。
定義ってなんでしょうか? よく分からないのですが、真面目に書いたつもりなんですが
ノイズですか･･･残念な書き込みですね。
可読性に関しては、前の当方の書き込みを読めば分かると思うのですが、要するに一年後
の自分が読んでも分かるということなんです。
仕事ならコーディングスタイルは企業毎グループ毎に違うのが当たり前で、担当を外れた
時にでも、後任が苦労しないように、企業やチームのコーディングルールに則って丁寧に
書くということです。
チーム参加者が誰でも理解できるよう、予想つかないようなトリッキーな仕掛けはなるべく
使わないように書くことが、ソースに可読性があるというのだと思ってましたが、何か特別
ものがあるのしょうか?
リセットさんの書き込みからすると、どうもあるようなのですが、当方はリセットさんほど
興味はないので、答えは不要です。
リセットさん、頑張ってください。
では･･･ |
|
| トップに戻る |
|
|
リセット
登録日: 2013.06.17
記事: 24
|
| 日時: 2013-08-26(Mon) 00:38 記事の件名: |
|
|
| ばんと wrote: | 毎度です。ばんとです。
質問してるのに質問で返されましたね。
定義ってなんでしょうか? よく分からないのですが、真面目に書いたつもりなんですがノイズですか･･･残念な書き込みですね。
可読性に関しては、前の当方の書き込みを読めば分かると思うのですが、要するに一年後の自分が読んでも分かるということなんです。
仕事ならコーディングスタイルは企業毎グループ毎に違うのが当たり前で、担当を外れた時にでも、後任が苦労しないように、企業やチームのコーディングルールに則って丁寧に書くということです。チーム参加者が誰でも理解できるよう、予想つかないようなトリッキーな仕掛けはなるべく使わないように書くことが、ソースに可読性があるというのだと思ってましたが、何か特別ものがあるのしょうか?
リセットさんの書き込みからすると、どうもあるようなのですが、当方はリセットさんほど興味はないので、答えは不要です。
リセットさん、頑張ってください。
では･･･ |
ばんとさんなのですね。さっきは本文中の挨拶から「はんと」さんと記述してしまいました。
これについては失礼いたしました。
まず語尾に「ょ」とかつけられて、発言内容も的外れな上に別の場所での論議ってのは全くおつむに届いていないしなんなんすかね
私がまじめにあなた様の内容に返答すると、確実に余談の話になって論議の邪魔になるっつってんだよ。
こんなのノイズ以外のなんなんですかね？俺様をもっと尊重しろ的なあれですか？ぶっちゃけまじめに考えた上でレスしてますが、何を脊髄反射で逆ギレされてやがるのか、私にはさっぱり理解できません。
そもそも最初に、
senshuさんとの会話にでしゃばって申し訳ないですが、少しおつきあいください。
と、自分のでしゃばりっぷりを自覚しているくせに「おう、邪魔だ。他でやろうぜ」と返したら「残念な書き込みですね」とか何を抜かしてやがるんでしょうか。
「他でやろうぜ」はおつむに入っていないのでしょうか。
でもまぁ、応援は受け取っておきましょう！ありがとう！ありがとう！嬉しいです。
ばんとさんの話には内容的に面白い所があったので、新規登録者からのメッセージとは別の所でお話しましょうと申し出た次第ですが残念です。 |
|
| トップに戻る |
|
|
リセット
登録日: 2013.06.17
記事: 24
|
| 日時: 2013-08-26(Mon) 00:55 記事の件名: |
|
|
私がアレな人みたいなので議論を戻しましょう。
まず可読性について
| senshu wrote: |
状態遷移の実現は、C言語の場合は関数へのポインタのテーブルを用意すれば、
シンプルに実現できます。ただし、あまり読み易くないのが欠点です。
どの言語を使っても、（腕次第で）読み易くも、読み難くも書くことができます。
優れたプログラマは、アセンブリ言語でも読み易くて高機能なコードを書けるよう
です。私には無理ですが、、、。
|
この千秋さんのレスに対して、
| リセット wrote: |
例えば、Stateパターンを置き換える方法についてだとわかったと思います。メリットに
ついては、そこを抑えないと論議できないと思います。
またソースの可読性については、メンテナンスのコストを含め、当たり前の非機能要件です。
僕はそこにオブジェクト指向としてのメリットを見出していません。
なにを使っても汚いソースは作れるのです。たとえデザインパターンを適用してもです。
可読性の高いソースは、当たり前の話なんです。メリットとは関係ありません。
複雑度と可読性を混同されていますか？
そしてアセンブラの話は、メリットの話から逸脱していてわかりませんでした。
前回オブジェクト指向についてメリットを記述しましたが、ご返答頂いた内容はこちらが
想定していたStateパターンの置き換えになっていなかったため、意図がわからない、と
いう返答に至りました。
|
と書いたことが発端です。
そして、オブジェクト指向については、
| senshu wrote: |
AVR マイコン程度のメモリでは、オブジェクト指向を導入しても制約が大きいと
感じていました。メモリ制限の厳しい場合も効果がある、ということでしょうか。
ぜひ、その利点と考える使い方を紹介してください。
|
| senshu wrote: |
また、オブジェクト指向の利点をお聞かせください。
|
と、何度も催促を受けたので「マイコンに関する掲示板でオブジェクト指向もなぁ」と思いつつ話をするに至っています。
また、千秋さんは
| senshu wrote: |
オブジェクト指向を導入しても制約が大きいと感じていました。メモリ制限の厳しい場合も効果がある、ということでしょうか。
|
のように、導入判定、効果測定を行われています。
ここからオブジェクト指向への見識が広い方であると判断しています。
| リセット wrote: |
さて、具体的に書くのは難しいので、抽象的に質問へ返答しますね。
今回のプロジェクトでは状態遷移が色々あり、振る舞いを手続き型で書くと複雑
度が上がりまくることから State パターンを採用しました。
リソースに制約が多く全てをオブジェクト指向で記述はできないため、適宜採用
しています。
これにより、一部のソース複雑度の低下と品質向上、開発効率 UP が得られ、マ
イコンでも利点を感じました。
|
と、返答したわけです。私から言い出したことでも何でもなく、千秋さんからのヒアリング内容に返答し、また返答を待っている状態なのです。
私は自分自身の知識にも疑問を抱いています。
ばんとさんの例示にもありましたが、マイコンでのオーソドックスなスタイルというのも分かっていません。
そこで、私がオブジェクト指向を適用したことが本当に妥当だったのかを判定したいのです。
そのために、私がどれくらいのレベルにあるのかはある程度推測頂くために、自分が適用したStateパターンについて解説を入れたという経緯です。
以下、伺いたい点を再掲しておきます。
関数ポインタを使用するメリットが私には良く分かりません。
千秋さんが挙げられた根拠となる「Stateパターン」と、それを置き換えるに値する
「関数ポインタを採用したロジック」の評価判定基準とその評価結果をお教えください。
また、想定された「関数ポインタを採用したロジック」の具体例についてもお教えください。
オブジェクト指向をマイコンで採用しないという評価も気になっています。その評価根拠も
教えてもらえませんか？
可読性の高いソース例についても、興味があります。紹介してください。 |
|
| トップに戻る |
|
|
senshu
Site Admin
登録日: 2009.06.01
記事: 2988
|
| 日時: 2013-08-26(Mon) 17:51 記事の件名: |
|
|
リセットさん、こんにちは。
1日ほど、ネットを利用できない環境にいましたが、ここは複数の方が利用する
掲示板ですので、冷静な書き込みをお願いいたします。
ここに参加している方々にも無理なく理解できる書き込みを希望します。
さて、問い合わせの件について回答いたします。
> 以下、伺いたい点を再掲しておきます。
>
> 関数ポインタを使用するメリットが私には良く分かりません。
>
> 千秋さんが挙げられた根拠となる「Stateパターン」と、それを置き換えるに値する
> 「関数ポインタを採用したロジック」の評価判定基準とその評価結果をお教えください。
> また、想定された「関数ポインタを採用したロジック」の具体例についてもお教えください。
組み込み分野に状態遷移表を用いるのは一般的な利用法です。もちろん、記述言語はC言語とは
限らないと思います。
「状態遷移表 C言語 実装例」などで検索すれば、多数の実例を見ることができます。
たとえば、UMLの状態遷移図をC言語のStateパターンで実装&単体テストしてみるには、
関数へのポインタを用いた実装例があります。
> オブジェクト指向をマイコンで採用しないという評価も気になっています。その評価根拠も
> 教えてもらえませんか?
ATtiny2313などの資源に乏しいMCU用にプログラム開発を行うと、↑は理解できます。
FlashやRAMが少ない場合には、C++などのオブジェクト指向言語の機能を利用すると意味のある
コードを生成できません。オブジェクト指向言語は、ある程度リッチな環境用に利用できる
ものと考えています。最低でも、Arduinoなどに採用されているレベルのMCUが必要と考えます。
> 可読性の高いソース例についても、興味があります。紹介してください。
状態遷移表を利用すれば if elseやswitch case文を多用することなくコードを記述でき
ますが、デバッガなどでトレースすると動作がわかりにくいのです。記述性の良さと理解し易さ
は、必ずしも一致しない、という意味で書きました。
同様に、flexやbisonでparserを書くのは容易ですが、生成されたコードはテーブルを多用して
おり、同様の難解さがあります。
マイコン関連の開発が難しいのは、ハード、ソフト、OS用のドライバなどが揃っていない段階で
設計する必要がある点です。
ハードが未完成な段階でソフトを作成する場合も多く、やむなく予定とは異なるハード仕様になる
こともあります。自分で設計製作しているので柔軟に対応しますが、コメントの相違はこうして
生まれてきます。
現在、Windows8で動作するUSB-シリアルポート用のドライバで苦労しています。x64環境では署名あ
りドライバが必須となっていて、独自に作成したドライバをインストールできません。アマチュア
には敷居が高い大きな問題です。
対処方法がわかっていても実現に必要なコスト（個人では負担が困難なほど高額）が発生する場合
には諦めるしかありません。
プログラムの開発手法以前の問題ですが、Windows8やx64環境の普及により悩ましい問題が多数発生
しているのが現状なのです。
リセットさんは、どういう方法で解決可能と考えますか？
ところで、私は動作するコード（かなり低評価ですが）を公開しています。リセットさんが書かれ
たコードも拝見したいのですが、アップロードしていただけないでしょうか。
ぜひ、リセットさんの自信作を拝見したいと思います。 |
|
| トップに戻る |
|
|
リセット
登録日: 2013.06.17
記事: 24
|
| 日時: 2013-08-26(Mon) 20:32 記事の件名: |
|
|
なるほど、面白い話もたくさんありますね。
順次回答できる範囲で回答しましょう。これは携帯からの投稿なので、引用も不十分となります。
ちなみに、この回答するという作業が私は大好きです。
脳みそのシワに知識を定着させる作業でもありますからね:)
さて、不用意発言はお許しください。発言意図を組み入れてもらえるとなお助かります。
千秋さんが関数ポインタ、と言われていたのは、ステートマシンである、という認識であっていますか？
ステートマシンは普通に汎用性が高く、状態を示すにはいいモデルです。
そしてこの例示はある程度私の要件を満たしています。
しかし、適用はしないでしょう。
理由は、状態によって複数の振る舞いを記述するには、関数ポインタを使ったStateマシンの移植では
あちこちに責務が散らばるからです。
ステートマシンで関数ポインタを使うと聞いて真っ先に思うのが、処理毎に配列を用意する実装です。
(認識誤りがあったら突っ込んでくださいね)
関数ポインタの特性上、関数がどんどん増えていくとも言い換えれます。
Stateパターンを使うと、基底クラスに仮想メソッド、もしくは標準動作をするメソッドを追加すれば
良いのです。Stateパターンの根底は継承ですから。
具体的な例示、感謝します。
また、オブジェクト指向の適用判定、ありがとうございます。私のプロジェクトとは全く違う環境を
想定されていたのですね。
私はArduinoを使用しているので、少なくとも要件は満たしているという評価ですね？
flex,bisonは利用したことがありません。ですのでプリコンパイル結果についてはコメント不可能です。
しかし、可読性についてはその通りです。記述しやすいことと読みやすさは比例しません。
また、プロジェクト特性や企業体によって変化するコーディングルールに沿うというのも、BSDスタイル
の記述というのも、可読性とは関連がありません。
千秋さんのソースで一番いいのは、メソッドの命名です。
粒度は粗いですが、何をする 何に というルールが見て取れます
職業柄、是正箇所を指摘することが多く、駄目出しばかりで申し訳ないです。
可読性は、映画のあらすじのように頭に入ってくる事と私は思っています。
実現するためには、
わかりやすい名前であること、つまり責務をあらわす名前であること
程よい粒度であること、細かすぎず、粗すぎない。
欲しい場所にナイスコメントがあること
ネストが浅いこと
複雑で無いこと
これらの複合物だと思っています。
これを丁寧にルールに落とし込むのが面白い。
つまり、リファクタリングの結果です。
リファクタリングを行う動機はきな臭さ、読みにくさ。処理追加がしにくい、メソッド名と処理が
乖離してきた、コードインスペクションでリセットにボコボコにされたなどなど。
丁寧に練られたソースは、メンテナンスも機能追加も楽チンですね。
この後のマイコン開発における課題は興味深いです。
コメントのくだりはよくわかりません。コードの展開の早さにコメントが追いつかないという事でしょうか？
(後で直す！と思っていても、完成してしまうと直せないのがコメントですよね。開発フェーズが変わると
不可能になっちゃいます:( できる限り、乖離しないよう留意頂きたいと思いますよ)
Windows8の状況はわかりません。MSDNも蹴っちゃいました。故に対処法はサッパリわかりません。
ただ、動作不安定を招く可能性がある階層で動作するドライバは、気軽にインストールしたく無いという
ポリシーは理解できます。
そうは言っても過去の資産が使えなくなる憤りもわかる分、千秋さんが辛い思いをされているのはわかりました。
コードの公開は、あり得ません。
私のソースはすべてクライアントが存在します
コードインスペクションであればお手伝いしますよ:)
最初は再構築もと書いていましたが、仕事が忙しいのを忘れていました。
でも、乗りかかった船です。お手伝いはできる限りしましょう。
ルールを作る仕事に戻りましょう… |
|
| トップに戻る |
|
|
senshu
Site Admin
登録日: 2009.06.01
記事: 2988
|
| 日時: 2013-08-27(Tue) 01:36 記事の件名: |
|
|
概ね伝わったようですが、私は C言語での実現を書きました。
＞Stateパターンを使うと、基底クラスに仮想メソッド、もしくは標準動作をするメソッドを
＞追加すれば 良いのです。Stateパターンの根底は継承ですから。
C言語では、↑の実装は出来ないのです。
なお、ソースコードの開示はできない件は了解しましたが、どう書けば望ましいソースになる
のかは良くわかっていません。
今の状況では、「良いソースではこうなる」というものがわからないのです。
C#の例でよいので、リセットさんのレビューを通過したソースの「評価グラフ」だけでも見せ
ていただければ幸いです。
よろしくお願いいたします。 |
|
| トップに戻る |
|
|
coredeino
登録日: 2012.02.15
記事: 180
|
| 日時: 2013-08-31(Sat) 21:20 記事の件名: |
|
|
千秋さん
新規参加者に対しては、もう少し広い心と優しい言葉で対応するほうが、結果的にここの活性化に繋がると愚考しますが。 |
|
| トップに戻る |
|
|
senshu
Site Admin
登録日: 2009.06.01
記事: 2988
|
| 日時: 2013-09-01(Sun) 20:17 記事の件名: |
|
|
coredeinoさん、アドバイスをありがとうございます。
なお、「新規登録者からのメッセージ」のスレッドとしては
重過ぎる内容になりましたので、これで終了といたします。
別の適切なスレッドで意見交換をお願いいたします。 |
|
| トップに戻る |
|
|
|