コーディング、テスト、デバッグ、エディタ技術総合 [無断転載禁止]©2ch.net ->画像>1枚

・特定の言語や設計、アルゴリズムではなく、
・あくまでも「実装の方法論」について議論するスレです。
・補完、スニペットなどの「コードを構築する」効率的な手法や
　テスト、デバッグ自の「操作」の省力方法や、画面構成、必要な構文を
　調べる方法、コードベースの中を「移動」する方法、コマンドライン、
　ファイル、ディレクトリ関連、必要なドキュメント、参考にするソースコードにた
　どり着くためにコンピュータやインターネットを「探索」する技術などについて議論しましょう。
・なるべく、特定のエディタやフレームワーク、ツールなどの専用のワードを多用
　せずに、他の人はそのツールを知らない前提で一般用語で議論しましょう。

何のスレだか分かりにくいな
開発環境の使い方がメインか

>>2
いや、開発環境ありきじゃなくて、どんな工夫をすればコーディングが
しやすいかを考えていきたい。
同じ開発環境やフレームワークを使っていると、ふと「俺は何かを創ってい
のか、それとも創らされているのかわからなくなってくるときがある。
だから、例えば、「○○製の××のノコギリは便利」じゃなくて、
「どういう状況で、どういう性質の工具を選ぶべきか」
「自分だけのオリジナル工具、オリジナルの使い方があってこういう意図で
　使っている」とかを議論していきたい。

>>1
心意気や良し

こういう焦点がはっきりしないスレは意外と伸びるもんだよな。雑談で。

道具の問題じゃない。

使ってる人間の問題。

意外とIME辞書って使いようによっては強力なツールだと思ってる。
日本人ってアメリカにはない「文字変換」という優れた習慣を持っている
と思うんだが。

パブリックな名前空間でのネーミングに時間を費やすやつは有能。
そういう輩をdisるやつは無能。

辞書を作っておくのが効率的

早い段階で命名が整理されてると混乱しないな

xxx、xxx2、xxx2bみたいに
行き当たりばったりにつけていくのは無能

オブジェクト指向は「再利用の記述」の省力化を目指しているが、
記述を省力化しすぎて「既存コードを読むストレス」を無視している
と思う。「読みながら部分的に手を加えるストレス」というべきか、
もうすでに出来上がったものをどう利用したらいいのか、
手を加えたことで、どう変わったのか恐る恐るやるよりも、
いっそ一から書いた方がずっと楽な場合もある。そっちのほうが安心できる。

NuGet、Excel、VS。
Excelは表からコードを作るのに使える。
RFCとかUnicodeとか表が提供されるもの結構多い。

>>11
オブジェクト指向はけっして「再利用の記述」（の省力化）を目指しているわけではないように思う…というのはさておき、

「既存コードを読むストレス」を無視しているように見えるのは、きっと不完全な開発ツールを使っているからだろう
まず既存コードがどのようなネットワークを形成しているか、具体的にはコードを抽象化してメタ情報（使われている
メソッドがどこに定義されているか、読んでいるメソッドがどのメソッドからコールされているか、インスタンス変数は
どのクラスで定義されどのメソッドがそれを参照・変更しているか等々）として得ることができればかなりストレスを軽減できる
で、実際そういうツールは少なくとも80年代から普通に提供されている（例：Smalltalk環境）し、00年代にはほぼ整っている
「手を加えることでどう変わったのか」を把握する方法はすこし時代が下るけど、ｘＵｎｉｔやバージョン管理で把握・制御可能だ

>>13
ってことはオブジェクト指向はそもそも「サポートしてくれるツールがある事」
が大前提であり、理論より、ツールの使い方ありき、ツール覚える方が先。
ということになるな、そうするとよくありがちなParsonやCarなどをとりあえず
作って抽象的な説明から入るオブジェクト指向の講義はナンセンスということ
にならないか？
「まずこのツールをDLして、操作方法を覚えろ」の方がいいのでは？

>>14
どうしてそういう結論になるかわからん
ネットワークのたとえを引き続き用いると
まず最初に小さく単純でいいからネットワークを作ることを学ぶにあたって
どういう風にネットワークを形成していくか、それはどうあるべきかという抽象的な説明は必要ないとでも？

ツール覚えるのに必死で創造性を発揮するどころではないな。
覚えたころには次がでてくる。W

C#を使うと便利すぎて不満など全くない。使い込んで行けば不満もでるのだろうが
不満をさがしたら自分の未熟以外のものはでてこない。このオブジェクトの海の
なかのどこかに問題をスマートに解決する方法があって、それを自分が知らない
だけという感覚に陥る。こんな意識状態ではきっと創造性などは生まれない。

>>14
Parsonてなんぞｗｗｗ

Personのタイプミスだよ。
いやさ、オブジェクト指向やってると疲れんのよ、主 publicとか private
とか protected とか static とかプロパティの辺がさ、
「クラスの作り方、派生、変更の仕方」なんてもんあまり勉強した内容じゃなくて、
俺が習得したいのは「言語組み込みクラスのメソッドの使い方」なんだよ。
そこらの他人が書いたコードやすでにあるコードなんてどうでもいいの。

>>18
ぱーか

>>18
まずはそのクラスがあるヘッダーを#includeする。
次に、変数宣言を使ってそのクラスのインスタンスを作成するコードを書く。
必要ならば、そのインスタンスを使って、メソッドを呼ぶ。

確かにガチガチにオブジェクト指向で塗り固めたコードは見苦しいよ。
訪れるかどうかすらもわからない、「後々のために」を理由に
いろんな修飾子付けてゴテゴテにデブったコード書いて、
「オブジェクト指向ししてる俺は意識高い」みたいなのってなんだかな~
と思う。策士策に溺れるというか、本末転倒なんだよ。

ツールを使いたくない（使えない）ならオブジェクト指向やめるか、一時記憶を強化するしかない

継承したときに使いたいものだけ見えるようにする方法ってあるの？
２つしかいらんのに邪魔なのが１００個も見えるという状況は気分が悪いよね

>>23
その２つだけを使いたいことをIDEが知る方法はあるの？

>> 23
interface

このスレのタイトルに適した本ってなんだろ、コードコンプリートとか、
オライリの実践でバッグ技法とかかな。
おまいらコード書く順番ってどうしてる、
関数の具体的な中身を決めないまま mainから書き始めるか、
関数の部品の中身をつくってから関数同士の組み合わせ方をあとで考えるか、
クラスありきで作り始めるか、クラスの必要性に駆られてからそれまでのコード
をクラスに書き直すか。

まずはピンコンフィグかな

リーダブルコードは有名なのか

で、Rubyのデバッガでいいのある？

プログラムが何をもって「完成」になるかわからないときってない？
なにが成功でなにが不十分なのか明確な基準持っていないっていうか
そもそもあまり関心がないみたいな、テストケース書こうとしたとき
急にどうでもよくなる感じ。
問題がおきたらなおせばいいや、って。

あ

初歩的なことかと思いますが
テスト要領書って、本来コーディング前に作っておくものでしょうか？

うちの会社じゃ
いつもコーディングの後半に作ってるんですが
一般的にはどうなんだろうと思いまして

要領書は設計書書き始めたら並行して書く

デバッグテクニックって大事なのにぜんぜん共有されないよね
あってもブレークポイントとか変数ウォッチの使い方マニュアルみたいな役に立たない情報しかない

>>34
基本的に関数の行数は数行（10行未満）長くても十数行で
それらはテストしやすいように、呼び出しやすい関数になっている。
なのでブレークポイントや変数ウォッチなんか使う意味がない。

>>35
それはまあ確かに理想的だけどレガシーコードや若手の書くコードは実際そうなってないわけじゃん
そういうダメなコードをデバッグする効率のいい方法というか原則とか考え方みたいなものを共有できたらいいと思うんだよね

ダメなコードをデバックする効率的な方法？

ダメなコードを簡単に直すのが一番効率的な方法だよ。
その方法のことをリファクタリングという。

× ダメなコードを簡単に直すのが一番効率的な方法だよ。
○ ダメなコード（複雑なコード）を簡単なコードに直すのが一番効率的な方法だよ。

バッチ処理がダメだった時の修正案を実行前実行中に
考えて作っておく。
バッチ処理が失敗した時は速やかに代案を実行する。
バッチ処理が失敗した時の焦りや怒り、うろたえは馬鹿にならないから
そんな状態で代案は生まれにくいし、コーディングミス
をしてハマる可能性がある。
だから健全な精神状態で代案をいくつか用意しておく。

最近deltadebugに興味がある

なんだいそれ？

Lnuxでインテリセンスのついた開発環境をおしえてくだされ。まさか
そんなものはない？

>>42
LinuxアプリはWindowsで開発するんだよ。

例えばC#アプリの例でお願いします。

Eclipse, NetBeans, Emacs, Visual Studio Code, Atom

何でも、ソースコードを所定の場所に置けば、インテリセンスが働くだろ？

オライリの実践デバッグ技法は良書
ただ、GDB DDD Eclipse の使い方を同時並行で解説しているから
少し混乱しやすい。

ツールの使い方じゃなくてもう少し上のレイヤのデバッグテクをテーマにした良書はないのか
ブレークポイントの説明とか何度も読まされて辟易するよ

>>47
お望みの書籍はこれかな？
https://www.amazon.co.jp/%E9%81%93%E5%85%B7%E3%81%A8%E4%BA%BA%E9%A1%9E%E5%8F%B2-%E6%88%B8%E6%B2%A2-%E5%85%85%E5%89%87/dp/4787712101/

>>47
オライリーのデバッグの本（なんか蝶の書いてあるやつ）は科学的な手法とかアルゴリズムとかが中心だよ

>>47
テスト駆動開発とかは？

DAOのテストってどうしてる？
テスト自体はデータをクリアしてインサートしてDAOのメソッド呼んで戻り値を調べてAssertって感じで普通に書けるんだけど
テストがDBに依存しちゃってるからサーバーが落ちてる時とかメンテナンス中に
にテストが通らなくなって困る
JUnitだけど一時的に機能無効化するオプションとかあるのかな

>>51
> テストがDBに依存しちゃってるからサーバーが落ちてる時とかメンテナンス中に
> にテストが通らなくなって困る
ローカルにDB作れば？

> JUnitだけど一時的に機能無効化するオプションとかあるのかな
DAOのテストで、何を無効にするの？

>>16
GUI周りは大いに不満です

C#のCollectionの快適さは異常

>>53
> Collectionの快適さ

具体的にはどこらへん？

一番がAny()
isEmpty()じゃないことに感動した

大概の拡張メソッドがラムダ突っ込めるし

冗長にも思える拡張メソッドの一群おかげでやりたいことが直感的にできる
Javaもラムダ扱えるってなって喜んだのもつかの間
C#に比べてあまりに貧弱で悲しくなった

なるほどなるほどAny()ですか

明らかにパクリと言われないようにちょっとズラしてパクらないといけない
でもズラしてパクると使い勝手悪くなる
JavaがC#に追いつく日はもう来ないだろうね

>>58
そんな事気にしてる言語なんてない…いや、Javaを持ってるOracleは気にするかもな。とりあえずJavaで訴訟するために

オライリー
Effective Debugging ―ソフトウェアとシステムをデバッグする66項目
Diomidis Spinellis

読んだ方、どうでしたか？

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

6LKCX

S9R

ノートで入力作業するとき、現在行がウィンドウの上のほうに固定されるか、
または上に向かって改行するエディタがあると見やすい。近視なんで。

キー入力を拾わなければならないから
KeyDown
KeyPress
KeyUp
これらのイベントがあるようなので
一文字ずつ表示させればエディタになるんだろうか

KeyPressでそのまま表示させることはできた。（上から下）
・下から上へ折り返し表示
・日本語入力
・編集機能
を実装すれば完成

1行プログラミング
Label1.Text = Label1.Text & e.KeyChar