GUIアプリケーションの単体テストをどのように行うか？ - rabbit2goのブログ
GUIが絡むアプリケーションを作っていて困るのは、テストを意識せずにマニュアル通りの手順で作ってしまうと単体テストが容易に実行出来ない点だ。入力がGUI依存ではテストコードから上手く呼び出せないし、また処理結果をGUIに表示するような構成では人間が目視しない限り結果の成否を判断出来ない。 だから、このようなアプリケーションの開発では、単体テストでの検証を考慮して下記のような設計にしておく必要が有る。 GUIレイヤーと、実際の処理を行うレイヤーを分離しておく。実動作時はGUIから、単体テスト実行時はテストコードから、実処理を行うレイヤーの機能を呼び出す。もちろん実処理を行うレイヤーはGUIレイヤーに依存しないようにしておく。 実処理レイヤーの結果は、デザインパターンのオブザーバーパターンにてGUIレイヤーに通知し、GUIを更新させる。これなら単体テスト実行時にはGUIに関係なく（呼び出すこと
名前の付け方 - CATchy programming
スコープを示す文字を付けることは、私も有効な方法だと考えていますので、採用しています。m_ 以外でも右の表のような種類を使用しています。 しかし、変数の型を示す文字を付けることは、あまり意味がなく(全然ないとは思いませんが)悪性の副作用があるので、私はこれを嫌っています。 悪性の副作用の１つ目は、以下のような良くない名前を付けてしまうことが可能になってしまうことです。整数の作業用変数と文字列の作業用変数では、もちろん異なる内容が格納されるはずです。しかし、以下の例では異なる内容を格納するのにもかかわらず、おなじ名前を付けてしまっています。これは混乱の元であり、複数のプログラマがメンテナンスを行う場合などに、誤ってバグを入れてしまう可能性が高くなります。バグを入れないまでも、プログラムの修正により多くの時間がかかってしまう要因になります。(プログラムの修正にかかる時間の半分は、そのプログラム
第15話 コーディング規約は必要か？：ソフトウェア開発に幸せな未来はあるのか：エンジニアライフ
少しご無沙汰しています。 今回からまた新しいシリーズです。ソフトウェアに関係する事柄のあれこれについて書いてみたいと思います。3回程度の予定です。 今回はコーディング規約についてです。コーディング規約がどんなものかはプログラマやSEなどを経験していれば知らない人はまずいないと思います。会社としてきちんとドキュメントになっているところもあれば、部や課、プロジェクト単位で適用している所もあるようです。 ただ、わたしの経験では、なぜか、なかったところの方が多かった気がします（気がするというのは実際はあったが見たことがなかっただけかもしれないので。もっともそれじゃないのと同じですが）。 現在のわたしの状況に関しては、「なかった」ので、わたしが作ってメンバーに周知しています。わたしが作るコーディング規約に関しては基本的にA4用紙に1枚程度の量で、そんなにきつく縛っていません（たぶん）昔ほどコーディン
三項演算子を使うべき理由
三項演算子を使うべきでないとする規約や現場って、結構多い。 それに対する「使う」派の主張もたまに見かけるが、「控えめに使うなら許されるべき」なんて消極派だったり、「三項演算子すら理解できない奴はクズ」なんて議論拒絶派だったり、或いは「三項演算子の方が格好良くて好き」的な頭脳労働苦手派であったりする。 自分は使用肯定派だけど、なるべく合理的に三項演算子について考えてみたい。日曜なのに暇だしな。 最初にまず、「if 文ではなく三項演算子を使うべき」状況を考えて、その後で、良くある三項演算子否定論への異議を述べてみる。（言語は C# とか Javaを想定） ■■ if 文を避けて三項演算子を使うべき理由 ★ 変数の宣言と定義を同時にできる 一時変数への値の設定について、宣言と同時なのと宣言から離れているのとで、どちらが良いコードかという問題だが、後者の「離れて」が正解なんて言う人は聞いたことが無
闇プログラマーに喧嘩を売ってしまった昼下がり～条件分岐篇～
※このまとめに含まれるプログラムは一種のパズル的な遊びです。 くれぐれも用法用量を守った上で正しくご利用ください＞＜ 実用するならば、“言うまでもなく” if か ?: を利用すべきです。 やばい連中に喧嘩を売ってしまった……。 続きを読む
関数の途中でreturnはしてはいけない？ - 関数から値をreturnで戻すとき、#include<iostream>... - Yahoo!知恵袋
関数の途中でreturnはしてはいけない？ 関数から値をreturnで戻すとき、 #include <iostream> #include <iomanip> int isSosuu( int n ){ if( n <= 1 ) return 0; for( int i = 2; i < n; ++i ){ if( ! ( n % i ) ) return 0; } return 1; } int main(){ for( int n = 1; n < 20; ++n ){ std::cout << std::setw(2) << n << "は素数" << ( isSosuu( n ) ? "である" : "ではない" ) << std::endl; } return 0; } というように、関数の途中でreturnで値を返すことがあるのですが、 先日先輩から「途中でreturnをつける
達人プログラマーに学ぶ コメントは必要？不要？ | Act as Professional
HIROCASTERの経験から SIer時代にコメントの重要性と言うより納品物としての必然性を教え込まれた記憶がある。例えば、こんなコメントは不必要である。 class foobar { /** * foobar class のコンストラクタ */ public function __construct() { foo = array(); bar = array(); } } 「public function __construct()」と書かれているのにわざわざ上でコメントを書く必要性はない。同じ意味を違う言語(表現)で書いているだけだ。重複であるといってもよい。DRYの考えに反する。 でもこれ、ドキュメントを自動生成して納品物とする場合、クラスずつにページがあって、コンストラクタの場所にいろいろと書かれている場合と何も書かれてない場合とかってのは、納品物として白紙はまずいわけで、こう
C++コーディング雑記
[ C++で開発 ] C++コーディング雑記 C++のコーディング標準、スタイル、習慣について、思うところを主観にもとづいて勝手にぶちまけるページ。 悪しき風習 妙ちくりんな省略形 特に石器時代のUNIXのC言語の風習だが、やたらめったら省略形を命名している。tmp, chk, prc, ctrl, con, 名前の長さに制限のあるコンパイラやリンカだった時代の名残りだけど、可読性を破壊しているだけ。省略形はやめよう。省略形の方が可読性が高いと思う人は要注意。 プリプロセッサ礼賛 マクロのオンパレード。ちょっと面倒な（と本人が思う）コードをマクロに置き換えて悦に入る。一人方言みたいなものなので、可読性を破壊しているだけ。 やたらに条件コンパイルが多いのも困りもの。モードのお化けのようなコンパイル条件は可読性を破壊しているだけ。プログラムA用、プログラムB用と入り込むならクラスを分けようよ。
コードから情報を追い出せ！プロパティファイルの常識
プロパティ操作の基本、java.util.Propertiesクラス Java言語からプロパティファイルを扱う1つ目のAPIは、java.util.Propertiesクラスです。クラス名がそのままプロパティファイルを扱うことを示していますね。 import java.io.BufferedInputStream; import java.io.FileInputStream; import java.io.IOException; import java.io.InputStream; import java.util.Properties; public class PropertiesSample { public static void main(final String[] args) { final Properties prop = new Properties(); Inp
技術レポート「効果的なソースコードのコメントについて」｜ソフテックだより｜株式会社ソフテック
コメントとは、プログラム言語で書かれたソースコードのうち、覚え書きとして記述される注釈のことです。 コメントは多ければ良いというものではなく、意味のないコメントはコーディング時間の無駄になるばかりか、ソースコードを読む人を混乱させることにもなります。 そこで本号では、効果的なソースコードのコメントの書き方や注意点について紹介したいと思います。プログラム言語はC言語で説明します。
Factory Method パターンの利点
#3です。 自信なし。 --- (たぶん)最重要な側面(のうちの1つ)を書き忘れてました。 前述の「CollectionとIterator」の例で言うと、 sunのJDKについてくる「標準クラスライブラリとしてのCollection」は、 Vectorだったり、LinkedListだったり、 その他いろいろ、 いくつか「すでに存在」していると思うのですが、 ここで、「sunの標準ライブラリに存在しない、 自分オリジナルのCollection、MySupecialListというのを作りたい！」 と思ったとします。さらに 「このMySupecialListに合うIteratorは、 既存のsun標準ライブラリのIteratorの中には見当たらず、 これも自作するほかないんだよな～」 というケース。 いわば、 『"プラグインな"Collectionを使う時』 です。 このケースでは、 自作者は単
プログラム間にボタンを掛ける「DI/AOP」（前編）
「DI（Dependency Injection）」および「AOP（Aspect Oriented Programming）」と呼ばれる技術が注目を集めている。これらはオブジェクト指向プログラミングにおけるプログラムの単位であるクラスを，互いに結び付ける新たな技術である。システムへの機能変更ニーズが高くなり，さらに開発期間が短くなっている開発の現場において，開発の効率化や品質向上を実現する新たな手段として期待されている。まずはオブジェクト指向プログラミングにおける課題を明らかにし，DIやAOPがそれらをどう解決できるのかを見よう。 DIでクラスを容易に付け外す オブジェクト指向プログラミングの一つ目の課題として，「変更時にクラスの修正が必要になる」ことがある。そもそも，オブジェクト指向で開発したプログラムは，オブジェクト指向ではないプログラムと比べ，機能の削除や変更が容易であることが特徴だ
僕が考えるAOPの適用ポリシー
「 Javaナイトセミナー(Vol.3)」で宿題(?)だった「AOPの適用」について，僕なりの意見を以下に述べようと思う。 AOPはトランザクションやロギング，ベースとなる機構で必要な前処理などを適用することが代表例なのは揺るぎのない事実だろう。そして，AOPのこれらの処理に対する適用は，プログラマからテクニカルで毎度毎度のお決まりコーディングを削減することができ，さらに継承やTemplateパターンなどを駆使することなく前処理を実行できるため，対象のクラスを汚す必要がない（何らかのクラスを継承しなくて済むなど）という利点をもたらしてくれる。 しかし，業務的に必要な前処理や共通的な処理の実行にAOPを使用すると，本来業務処理をコーディングするプログラマはAOPに関する知識を必要としなくて済むはずなのに，業務処理の記述に比較的難解な技術となるAOPを覚えてもらうことになる。敷居が高くなるだけ
プロとしての行為 Act as Proffesional
1．一般的なコーディング規約に目を通し、エレガントなコードを知る エレガントなコードを書くためには、エレガントなコードを知らなければならい。その土台を築いているコーディング規約について、オープンソースではどのようなものが使われているのか理解しておこう。入社する予定の会社が採用している言語については必ず目を通しておこう。 PHP PEAR 標準コーディング規約 symfony CodingStandards Perl perlstyle Ruby クックパッド株式会社のRubyコーディング規準 Matzスタイル NaClで採用している規約 Python PEP 8 そして、あなたの身近にあるオープンソースのコードを実際に読んでみよう。この時点でコードの仕組みや設計が理解できなくても良い。コードがエレガントかどうか？を感じ取って欲しい。こう書いた方が、良いのではないか？など、考えてみよう。
ウェブリブログ：サービスは終了しました。
「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 ※10秒後にBIGLOBEのおすすめページに遷移します
リストの最速ループの書き方 - R42日記
処理順序が重要でない場合に、ArrayListや配列を走査する場合には、フツーなら for (int i = 0; i < list.size(); i++) { Object o = list.get(i); ...(略) } とかやる*1わけだが、 昔は色々と病気に罹患していた*2ため、こんな書き方をしてしまっていた。 for (int i = list.size(); i > 0; ) { Object o = list.get(--i); ...(略) } この書き方だと、 list.size()は一回しか実行しない 0との比較はバイトコード上は特別扱い(インストラクションが減る)なので、ちょっと早くなる なので、たぶん最速だと思う。(もし他にあったら教えてください) ちなみに、 for (int i = list.size(); i-- > 0; ) としないのは、iが0のときの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Welcome to nginx!
はてなブログ | 無料ブログを作成しよう
http://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf
Lisp:コメント