コーディング、テスト、デバッグ、エディタ技術総合 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
・特定の言語や設計、アルゴリズムではなく、
・あくまでも「実装の方法論」について議論するスレです。
・補完、スニペットなどの「コードを構築する」効率的な手法や
テスト、デバッグ自の「操作」の省力方法や、画面構成、必要な構文を
調べる方法、コードベースの中を「移動」する方法、コマンドライン、
ファイル、ディレクトリ関連、必要なドキュメント、参考にするソースコードにた
どり着くためにコンピュータやインターネットを「探索」する技術などについて議論しましょう。
・なるべく、特定のエディタやフレームワーク、ツールなどの専用のワードを多用
せずに、他の人はそのツールを知らない前提で一般用語で議論しましょう。 ツール覚えるのに必死で創造性を発揮するどころではないな。
覚えたころには次がでてくる。W
C#を使うと便利すぎて不満など全くない。使い込んで行けば不満もでるのだろうが
不満をさがしたら自分の未熟以外のものはでてこない。このオブジェクトの海の
なかのどこかに問題をスマートに解決する方法があって、それを自分が知らない
だけという感覚に陥る。こんな意識状態ではきっと創造性などは生まれない。 Personのタイプミスだよ。
いやさ、オブジェクト指向やってると疲れんのよ、主 publicとか private
とか protected とか static とかプロパティの辺がさ、
「クラスの作り方、派生、変更の仕方」なんてもんあまり勉強した内容じゃなくて、
俺が習得したいのは「言語組み込みクラスのメソッドの使い方」なんだよ。
そこらの他人が書いたコードやすでにあるコードなんてどうでもいいの。 >>18
まずはそのクラスがあるヘッダーを#includeする。
次に、変数宣言を使ってそのクラスのインスタンスを作成するコードを書く。
必要ならば、そのインスタンスを使って、メソッドを呼ぶ。 確かにガチガチにオブジェクト指向で塗り固めたコードは見苦しいよ。
訪れるかどうかすらもわからない、「後々のために」を理由に
いろんな修飾子付けてゴテゴテにデブったコード書いて、
「オブジェクト指向ししてる俺は意識高い」みたいなのってなんだかな~
と思う。策士策に溺れるというか、本末転倒なんだよ。 ツールを使いたくない（使えない）ならオブジェクト指向やめるか、一時記憶を強化するしかない 継承したときに使いたいものだけ見えるようにする方法ってあるの？
２つしかいらんのに邪魔なのが１００個も見えるという状況は気分が悪いよね >>23
その２つだけを使いたいことをIDEが知る方法はあるの？ このスレのタイトルに適した本ってなんだろ、コードコンプリートとか、
オライリの実践でバッグ技法とかかな。
おまいらコード書く順番ってどうしてる、
関数の具体的な中身を決めないまま mainから書き始めるか、
関数の部品の中身をつくってから関数同士の組み合わせ方をあとで考えるか、
クラスありきで作り始めるか、クラスの必要性に駆られてからそれまでのコード
をクラスに書き直すか。 プログラムが何をもって「完成」になるかわからないときってない？
なにが成功でなにが不十分なのか明確な基準持っていないっていうか
そもそもあまり関心がないみたいな、テストケース書こうとしたとき
急にどうでもよくなる感じ。
問題がおきたらなおせばいいや、って。 初歩的なことかと思いますが
テスト要領書って、本来コーディング前に作っておくものでしょうか？
うちの会社じゃ
いつもコーディングの後半に作ってるんですが
一般的にはどうなんだろうと思いまして デバッグテクニックって大事なのにぜんぜん共有されないよね
あってもブレークポイントとか変数ウォッチの使い方マニュアルみたいな役に立たない情報しかない >>34
基本的に関数の行数は数行（10行未満）長くても十数行で
それらはテストしやすいように、呼び出しやすい関数になっている。
なのでブレークポイントや変数ウォッチなんか使う意味がない。 >>35
それはまあ確かに理想的だけどレガシーコードや若手の書くコードは実際そうなってないわけじゃん
そういうダメなコードをデバッグする効率のいい方法というか原則とか考え方みたいなものを共有できたらいいと思うんだよね ダメなコードをデバックする効率的な方法？
ダメなコードを簡単に直すのが一番効率的な方法だよ。
その方法のことをリファクタリングという。 × ダメなコードを簡単に直すのが一番効率的な方法だよ。
○ ダメなコード（複雑なコード）を簡単なコードに直すのが一番効率的な方法だよ。 バッチ処理がダメだった時の修正案を実行前実行中に
考えて作っておく。
バッチ処理が失敗した時は速やかに代案を実行する。
バッチ処理が失敗した時の焦りや怒り、うろたえは馬鹿にならないから
そんな状態で代案は生まれにくいし、コーディングミス
をしてハマる可能性がある。
だから健全な精神状態で代案をいくつか用意しておく。 Lnuxでインテリセンスのついた開発環境をおしえてくだされ。まさか
そんなものはない？ >>42
LinuxアプリはWindowsで開発するんだよ。 Eclipse, NetBeans, Emacs, Visual Studio Code, Atom
何でも、ソースコードを所定の場所に置けば、インテリセンスが働くだろ？ オライリの実践デバッグ技法は良書
ただ、GDB DDD Eclipse の使い方を同時並行で解説しているから
少し混乱しやすい。 ツールの使い方じゃなくてもう少し上のレイヤのデバッグテクをテーマにした良書はないのか
ブレークポイントの説明とか何度も読まされて辟易するよ >>47
オライリーのデバッグの本（なんか蝶の書いてあるやつ）は科学的な手法とかアルゴリズムとかが中心だよ DAOのテストってどうしてる？
テスト自体はデータをクリアしてインサートしてDAOのメソッド呼んで戻り値を調べてAssertって感じで普通に書けるんだけど
テストがDBに依存しちゃってるからサーバーが落ちてる時とかメンテナンス中に
にテストが通らなくなって困る
JUnitだけど一時的に機能無効化するオプションとかあるのかな >>51
> テストがDBに依存しちゃってるからサーバーが落ちてる時とかメンテナンス中に
> にテストが通らなくなって困る
ローカルにDB作れば？
> JUnitだけど一時的に機能無効化するオプションとかあるのかな
DAOのテストで、何を無効にするの？ >>16
GUI周りは大いに不満です
C#のCollectionの快適さは異常 >>53
> Collectionの快適さ
具体的にはどこらへん？ 一番がAny()
isEmpty()じゃないことに感動した
大概の拡張メソッドがラムダ突っ込めるし 冗長にも思える拡張メソッドの一群おかげでやりたいことが直感的にできる
Javaもラムダ扱えるってなって喜んだのもつかの間
C#に比べてあまりに貧弱で悲しくなった 明らかにパクリと言われないようにちょっとズラしてパクらないといけない
でもズラしてパクると使い勝手悪くなる
JavaがC#に追いつく日はもう来ないだろうね >>58
そんな事気にしてる言語なんてない…いや、Javaを持ってるOracleは気にするかもな。とりあえずJavaで訴訟するために オライリー
Effective Debugging ―ソフトウェアとシステムをデバッグする66項目
Diomidis Spinellis
読んだ方、どうでしたか？ 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
6LKCX ノートで入力作業するとき、現在行がウィンドウの上のほうに固定されるか、
または上に向かって改行するエディタがあると見やすい。近視なんで。 キー入力を拾わなければならないから
KeyDown
KeyPress
KeyUp
これらのイベントがあるようなので
一文字ずつ表示させればエディタになるんだろうか KeyPressでそのまま表示させることはできた。（上から下）
・下から上へ折り返し表示
・日本語入力
・編集機能
を実装すれば完成 1行プログラミング
Label1.Text = Label1.Text & e.KeyChar ■ このスレッドは過去ログ倉庫に格納されています
