![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
概要 †
下位ページ †
目次 †C/C++の発達段階 †
Tips †
イディオム †
STL †vector †strstream †
map, reduce, filter †
量化関数 †文法 †pure virtual †
ゲッタ・セッタの生成プログラム †
newと実体の動作の違い †
親のコンストラクタを呼ぶ †decisionCross::decisionCross(StockDayStream* stock, int s, int m, int a)
: decision(stock), _s(s), _m(m), _a(a)
{
}
sstreamとstrstream †
coutに表示させる †#include <iostream>
class HoldingStock {
public:
int m_code;
std::ostream& operator()(std::ostream& ros) {
ros << m_code << " " << m_code << " " << m_sl << " " << m_tp;
return ros;
}
};
isnanがあいまい †
absは危険 †
fstreamのパターン † std::ifstream fin(args_csv);
std::string line;
while (std::getline(fin, line)) {
std::string token;
std::istringstream stream(line);
while (std::getline(stream, token, ',')) {
std::cout << '[' << token << ']' << std::endl;
}
}
知識 †
疑問と後でまとめる †
例外(try, catch, throw)を学びたい †http://wisdom.sakura.ne.jp/programming/cpp/cpp35.html http://ufcpp.net/study/csharp/misc_exception.html 「メソッドの定める結果を達成できないなら例外を投げる」という方針でOK 利用法上の例外： 利用者側が正しい使い方をしていれば回避できる例外→例外はキャッチしない．例外の発生しうるメソッド本体（Doer: do するもの）に対して、 事前チェック用のテストメソッド（Tester）を用意する方法のことを Tester-Doer パターンやTryParse?パターンを使うと呼びます。これを使う 発生は避けれないが、復帰可能な例外→対処可能なら catch して対処してしまう。対処できない（あるいは、対処をもっと上の階層にゆだねた方がいい）場合catch しない。あるいは、一度 catch して、いくつか必要な操作（中途半端な状態を残さないためにロールバックを行ったり、ログを記録したり）を行ってから例外を再度投げる。標準の例外とは違う処理が必要な場合にのみ、自前で例外クラスを作成する（？？）．例えば、FileNotFoundException? を catch せずにそのまま上位に流してもいい場面では、自作の例外でラップしたりはしない。 以下の例面白い．ExistsからReadでファイルが消えている可能性を例外で潰す try { if (!File.Exists(filename))
{
text = "デフォルトのテキスト";
}
else
{
text = File.ReadAllText(filename);
}
} catch(FileNotFoundException?) { text = "ファイルがなくてもデフォルトのテキストがあれば OK"; } 対処のしようがない致命的な例外は，何もしない． ラムダ †
#include <bits/stdc++.h> using function_t = std::function<int(int)>; その他 †
ラムダ †
整理されていないもの †/home/hamko/git/sample/c++/member_function_pointerにメンバ関数のポインタについていい感じにまとめた 一つのcppファイルが，複数の実行ファイルのコンパイルに使われる場合，not usedが現れてしまうがどうすればいい？‘NODATASTRING’ defined but not used [-Wunused-variable] テストを書くメリットまとめ http://www.slideshare.net/hakoika-itwg/4-14292568 僕のテストの問題点として，実際のMakefileとテスト用のMakefileが同じでなければならないのに，Makefileを分けてしまっているせいで何なのかわからなくなっている ただデータ形式を変換するだけのクラス（実体がある必要が感じられないという意味）の実装方法ってどうすればいいんだろう？ 間違い探しのページを作りたい 横で比較できる奴 makeのいい感じの依存の作り方 コーディングルールのかなり量があるもの http://d.hatena.ne.jp/prettysoft/20101019/1294164743 名前空間stdってなんであんなにでかいんだ? http://www.sciencemag.org/content/350/6266/1332.full.pdf ar s または ranlib shared_ptrはバイナリ境界を安全に超えられる，とは 尚、配列を使う場合はboost::shared_arrayをどうぞ。 あのリンク構造をスマートポインタに直したら成長できそう valgrind cleanを担保するスケルトンプロジェクト、依存ライブラリの依存関係をmakeするスケルトンプロジェクト テスト駆動のメリットして，間違えて行消しちゃった系も検出できること doxigenが良いのかわからないけど，eigenのドキュメンテーションを参考にドキュメンテーションの方法論を学ぶ gdbももっと勉強しないとやばい ptrdiff_t テストの実行ファイルの分け方は？実務ではどうなっているのだろうか． git commitのコメントメッセージも，コンパイルが通るのかテストが通るのか何なのかは最低限書かないといけない． 並列化のデザインパターンを知りたい namespaceはいいけど，ファイル名が被ったらどうするの？ L1-L3の危険を実装したテストがほしい． 最適化済みのコードをデバッグすることは何の役にも立たない（このページはものすごくまともな人が書いていてよい） http://blog-ja.intransient.info/2011/05/c-23.html timer.cppというファイルで，time_valというクラスが実装されているのはどうなんでしょう そのcppにはiostreamはincludeしていないけど，他のhppがincludeしてるから動くみたいなのはありか？ バッファオーバーラン https://www.ipa.go.jp/security/awareness/vendor/programmingv1/b06_01.html ソフトのデプロイ時，利用したライブラリのマイナーバージョンまで言うべきでは effective C++ C++クラス，pubとpriどっちを先に書くべきか .aと.soの違いは？ 標準エラーのless eigenは早い http://eigen.tuxfamily.org/index.php?title=Benchmark constexprしりたい ClosedDynamics?を元としたスケルトンプロジェクトを作りたい．静的ライブラリのスケルトンプロジェクトとして優秀なので isnan, constexpr (static constはだめで，static constexprとする必要) http://ja.stackoverflow.com/questions/1920/const%E3%81%A8constexpr%E3%81%AE%E9%81%95%E3%81%84 http://www.slideshare.net/GenyaMurakami/constexpr-10458089 完全hppライブラリはどうやって作るのか？ hppとcppを分ける意味って何？ inlineの意味 TBB http://www.amazon.co.jp/exec/obidos/ASIN/4873113555/38211352-22/ C++でわかっていないといけないこと http://qiita.com/shirakawa4756/items/7430f447883a74831bf9 委譲のメリットですが、やっぱり動的(実行時)に親クラス(委譲先)を変更できるところでしょう。単に委譲先を固定してしまっている場合はあまり価値は感じられないと思います(海外のコードでは委譲と言えば動的で、静的に固定した委譲というのはあまり見ません)。 OpenGL ライトが有効だと色が変わらない http://dixq.net/forum/viewtopic.php?f=3&t=13583 gdbできないので，終了コード1でエラー吐いて死ぬのためてもらえませんかね boostとコピコンの勉強もだな… vectorにインスタンスを突っ込むときの注意 http://www.himajin2001.com/fswiki/wiki.cgi?page=%B5%BB%BD%D1%C5%AA%BB%A8%C3%CC-%A5%DD%A5%A4%A5%F3%A5%BF%C7%DB%CE%F3%A1%A2vector%A4%CE%CD%EE%A4%C8%A4%B7%B7%EA 文章を書くときは初出の単語は必ず定義をしなければならない．プログラミングのコメントとはそういうものだと思うのだが まずそれが何なのかを言う．初期触覚ポリゴン->PolygonTactileInitial?など 関数の最後以外でreturnやthrowするというのは，関数の後のほうのdeleteを忘れているリスクがある 仕事がある程度の段階まで進むと、 あちこちに歪みやアラが目立ってきて、 全部「 はじめからやり直したい 」という気持ちが強くなってきます。 これを私は「はじめからやり直したい症候群」と呼んでいます。 この症候群の特徴は、以下のような言葉で表現できます。 あっちとこっちが 統一されていない のが気になる いまはＡとＢとＣと別れているけれど実は 汎用的な Ｇで対応できるはずだ ＸとＹがごちゃごちゃしていてわかりにくいので 全体的に整理 したい 要するに、全部捨ててゼロから作った方が 絶対 よいものになるのだ でも、安易にはじめからやり直すと、 たいていは失敗します。はじめからやり直す場合は，詳細な計画のもとにやりましょう ack https://www.digitalocean.com/community/tutorials/how-to-install-and-use-ack-a-grep-replacement-for-developers-on-ubuntu-14-04 http://lealog.hateblo.jp/entry/2012/10/02/234021 http://yut.hatenablog.com/entry/20110523/1306111855 ack --cpp hoge, ack -l hogeでファイルのみ出力, ack -i hogeで大文字小文字を無視 intとstringの変換http://stackoverflow.com/questions/5590381/easiest-way-to-convert-int-to-string-in-c 複数のgitレポジトリにまたがって開発している場合，TMGLがこれでClosedがこれでTactileGlove?がこれ，とやらないといけない．つらいけどどうすればいいの？ CNN http://vision.stanford.edu/teaching/cs231n/syllabus.html 10年保守する可能性のあるライブラリってどうすればいいの？行列演算ライブラリが競合しまくるんだけど Makefile http://pokotsun.mydns.jp/?p=1503 GPGPU http://codezine.jp/article/detail/8429 OpenGLって並列になってるの？だとしたら並列の処理をきちんやらないといけないけど，本当になっているのか，どういう計算順序になっているのか，idleとは一体何なのか，などがわからない std::function http://torini.hateblo.jp/entry/2015/03/22/%E9%96%A2%E6%95%B0%E3%83%9D%E3%82%A4%E3%83%B3%E3%82%BF%E3%82%88%E3%82%8A%E3%82%82std%3A%3Afunction%E3%82%92%E4%BD%BF%E3%81%8A%E3%81%86 using estimateTorquesFunc? = Eigen::VectorXd? (Closed::Dynamics& d); extern estimateTorquesFunc?* g_estimateTorques; KISSの原則(迷ったらシンプルに) https://ja.wikipedia.org/wiki/KISS%E3%81%AE%E5%8E%9F%E5%89%87 OpenGL http://cpplover.blogspot.jp/2014/05/opengl.html http://richg42.blogspot.jp/2014/05/things-that-drive-me-nuts-about-opengl.html MVCの必要性とpushMVCとpullMVCの違い http://qiita.com/tshinsay/items/5b1724baf32b8b5113c2 MVCの勘違いわかりやすい，これはVがMを参照しているのでpulllMVC． http://at-grandpa.hatenablog.jp/entry/2013/11/01/072636 MVCのかなり情報量のあるページhttp://kray.jp/blog/think_about_mvc/ ソフトウェアを設計するという感覚がないなあ ビューワのデバッグとかテストってどうするの？UIもそうなんだけど inline http://yukishimakana.blog.fc2.com/blog-entry-10.html コンパイルが通らないということは，バグを未然に防ぐ機能がしっかりと働いているということ，という価値観になるような開発スタイルが大事 ar rcs libclass.a class1.o class2.o class3.o cc main.c libclass.a Linux→winで改行コードが消える問題。nkfの-Lu, -Lwで解決できる。 http://takuya-1st.hatenablog.jp/entry/20100511/1273585953 vimの移動コマンドについてhttp://haya14busa.com/mastering-vim-easymotion/ デバッグとは「ありえたはずの未来」を枝刈りしていくこと．ありえたはずの未来はバグの原因が一個だと前提できれば木構造になる．2個以上だとテーブル構造になりやばい．そのなるべく上流を切る テストをうまくかけるようになると，デバッグの時間をテストの時間に移すことが出来る．テストを書くほうが単純作業ではあるが，かかる時間の分散が低い上，流れ作業というか単純作業なので，全体の頭を使わない感は増す if (testeiofjosidfj) cout << “#” << endl; は，coutだけコメントアウトしてしまうリスクがある．カッコでくくること． http://srz-zumix.blogspot.jp/2015/11/cpplint.html google style guides 任意の多面体形状http://www.wakayama-u.ac.jp/~tokoi/vrml/vrml.pdf オープンソースの定義 http://www.atmarkit.co.jp/flinux/special/opensource/opensource01.html オープンソースの素晴らしさは、世界中の誰もがあなたのソースコードをより良くできることにある ライセンスわかりやすい http://smkn.xsrv.jp/blog/2009/03/summary_for_gpl_mit_cc_etc/ http://d.hatena.ne.jp/cou929_la/20080508/1210252204 日本語に翻訳されたものを置いても、ライセンスとしては効果を発揮しません。 BSDとApache以外は商用だと危険．MITはOKじゃない？ ライセンスを適応しないと… http://www.catch.jp/oss-license/2013/09/10/github/ ライセンス，アウトなことを網羅的にまとめたい．GPLで何したらだめとか で，結局使うときと配布するとき，それぞれで何すればいいの？ Apacheを使う場合．http://vividcode.hatenablog.com/entry/license/android-app-with-apache-license-2.0 MITを配布する場合，トップフォルダかソースコードにMITだよと書けば良い．http://www.catch.jp/oss-license/2013/09/27/mit_license/ 表にまとまっているhttp://qiita.com/tukiyo3/items/58b8b3f51e9dc8e96886 MPLは，library.cを改変したらlibrary.cをの公開義務有り，http://oshiete.goo.ne.jp/qa/8585493.html ライセンス系は全くきちんとまとまっていないので，表にしてまとめたい GPLにするとこんな面倒なことが http://takeshich.hatenablog.com/entry/2015/01/28/161710 http://takeshich.hatenablog.com/entry/2015/10/04/004036 GPLでは、そのソフトウェアのバイナリ（実行形式ファイル）を入手したユーザが、ソースコードの開示を要求した場合についてのみ、その要求に応えてソースコードを開示する義務があります。 言い換えると、ユーザでない人にまでソースコードを開示する必要はありません。 独占的なユーザがいるばあいは，その人の開示要求だけに答えれば良い．しかし，ソースコードを受け取ったその顧客がアプリケーションやソースコードを有償/ 無償を問わず別の第３者に提供することをを制限することはできません。つまり、誰でもソースコードを手に入れられるという状況を完全に阻止する手段はありません。 MPL: The copyleft applies to any files containing MPLed code. LGPL: The copyleft applies to any library based on LGPLed code. GPL: The copyleft applies to all software based on GPLed code. PL系は，バイナリを使った人がソース欲しいといってきた時には開示しなければならないということ． GPLのライブラリを使っていたが，個人利用だったので公開義務はなかったが，GPLの感染により商用利用を許可しなければならない．しかしある時，共同研究者がバイナリを利用するときに，ソースコードの公開を要求した．共同研究者が卒業して貰ったソースコードを改変して商売をし始めた．これはOK，になってしまう． Githubのプロジェクトの半分はライセンスが無い 著作権法では、ライセンスが無いものを使うと著作権侵害になる Githubはライセンスが無いものはデフォルトでApacheV2かCC-BY扱いにするとか何とかしろ “(C)”、を使うことは法律上なんの意味もありません. Copyrightは国際慣習 線形計画法の計算にはフ リーのラ イブ ラリのGLPK(GNU Linear Programming Kit)4) を用い，二次計画法の計算にはフリーのライブラリ OOQP(Ob ject Oriented software for Quadratic Programming)5) を用いた． EigenはMPL, OpenCVはBSD, OpenGLはSGI (SGI Free License B)?， pukiwikiはGPL, liboctaveはGPL, BoostはBoost Software License, libjpegはBSD-like, liboctaveのライセンスとかってどうやって調べるの？ Boost Software License という、ソースコード配布時にのみライセンス表記等が必要というかなり緩いライセンス http://cpplover.blogspot.jp/2013/03/boostcstdinthppendianhpplimitshpp.html Apache 2.0ライセンスでオープンソース化，らしいが，内部でMPL使っているんだとMPLで配布しないといけないんじゃないの？ OpenMPはAPIの仕様の名前なので、ライセンスはOpenMPを実装するコンパイラ次第だと思います。 http://openmp.org/wp/ zlib/libpngライセンスは要約すると（するまでもないほど短いが）・使うなら勝手に使ってくれ。何も書かなくても構わない。でも書いてくれたら嬉しい。・自分が作ったとかテキトーな事を言ってはいけない。・ソースを流用したときはそのことを明示し、ライセンス条文をつけること。 freeBSDとBSDには関係有り BSDはアカデミックによく使われる 明示レベ得るの分類が面白い http://www.atmarkit.co.jp/ait/articles/0906/26/news129.html 具体的にどう表示すればいいかhttp://www.atmarkit.co.jp/ait/articles/0906/26/news129_2.html 実際にあった例として、To Heart 2 というゲームソフトで、xvidのライブラリが混入していました。これはユーザーによって発見されたのですが、結局このゲーム会社には弁解の余地がなく、GPLに基づきソースコードを公開することを決断しました。これによる損害は、ソフトウェアそのものよりも、むしろソースコードの汚さとライセンス管理能力による会社の信用力低下でした。http://leaf.aquaplus.jp/product/xvid.html プロプライエタリ版を出すことは、本名や住所などの個人情報がネット上でばれるばかりでなく、年末調整や住民税の通知などによってオープンソースをやっていることが会社にばれて解雇されるリスク GPLはバイナリとソースをセットにして渡さなければいけないという意味 クローズドな開発モデルは、もはやオープンソースに人的リソースの点で勝ち目がない．従ってオープンソース大事 GPLの重要なもの，libarc, libxvid, Blender BusyBox?の不正流用によるGPL違反 systemコマンドを介してgzipを使ったら？ GLIBCはLGPL 動的リンク(Windowsでいう.dllなど)として使用した場合は、呼び出し元のプログラムにはLGPLを適応させる必要がありません。 BSDとかapacheとかは，みんなに配布しなくてもライセンスを記載しないといけないの？そうだとgithubとかヤバイよね． OSS順守チェッカを確認 全ソフトウェアの公開とは一体何か．ソニーのICOは，プレーステーションの基本システムも公開も必要なのか．GPLに従ったソフトを勝った人と、ソース開示を禁じる契約を結ぶことはできるか GPL違反を裁判にすることはできるの？ 自分の，みたいなのを変数名に明示したい場合ってどうすればいいの？ 正しいこと，ダメなこと，仮説を元にデバッグするみたいなコメントシートみたいな感じで頭を整理する手法 Jenkinsといった，マルチディストーション間でのテストとかやってみたい． LLVMで画面上の操作を行うためのプログラミング言語を作ってみたい．もうあるのかの確認は必須 必要なときに，無印，&, &&をきちんと使い分ける関数の作り方を教えて下さい． http://srad.jp/~bnez/journal/274056/ 破滅的関数の使い方．この辺理解できるとかっこいいっぽい http://shnya.jp/moin/C%2B%2B%E3%81%AE%E8%90%BD%E3%81%A8%E3%81%97%E7%A9%B4#operator_bool.28.29.2BMG5.2FYA- デザインパターンの理解には，このデザインパターンを少し変えたものは何が問題なのか，みたいなのを考えないといけない gitのコミットメッセージをwikiみたいな感じで使う，というのが正しい気がする デザインパターン何種類か http://qiita.com/disc99/items/840cf9936687f97a482b ビルダー「作成物」と「作成過程」と「作成方法」の分離．ディレクターがビルダーインスタンスを持ち，具体的な変更方法はビルダーに移譲する．ビルダーはconstruct関数を何個かもち，これらがビルダーの関数の組み合わせ方を規定する．ビルダーパターンを使うと，今変更すべきなのは作成過程なのか作成方法なのかを選ぶことが出来るようになる．作成過程と作成方法の切り分けは意味的で，作成方法の変更は難しく，作成過程の変更は簡単になるように分離すれば良い？http://hamasyou.com/blog/2004/06/09/builder/ #elif defined(_MAC) arduino processing serial OpenMPとpthreadは根本的に違う http://d.hatena.ne.jp/mscp/20081006/1261915755 gdb基本 http://bxyxvzz.hatenablog.com/entry/2015/09/07/181137 並列gdb http://bxyxvzz.hatenablog.com/entry/2015/09/08/083237 実践デバッグ技法，欲しいなあ 二次計画問題のポートフォリオ．というかこの資料わかりやすくて良い．http://www.me.titech.ac.jp/~mizu_lab/text/pdf-file/LP9-QP-problem.pdf 二次計画法とガウスカーネルとSVM．非常にまとまってて面白い．http://censored.hateblo.jp/entry/2015/06/09/160623 二次計画法，OpenCVだけど http://suzuichibolgpg.blog.fc2.com/blog-entry-202.html 二次計画法quadprog++(++出ないのもあるので注意)，この解説ページの数式は間違っているので注意．等式系は，同じ方向に固まっているので，マイナスがつかなければならない．g++ main.cc /usr/local/lib/libQuadProgpp?.a http://suzuichibolgpg.blog.fc2.com/blog-entry-218.html quadprog++で例外を返す問題があるらしいが.同じデータ点が複数含まれる場合，QuadProg??++は例外を返すことが知られている．abortが頻繁に発生する場合は，同一のデータ点で2回目以降に現われるものは削除する等の前処理を組み入れると良い．また，オプション課題となっているスケーリングを行うと，aboutが減少するとも報告されている． 2次計画問題の解が制約条件を満たさない場合は,solve_quadProg()に与える引数のひとつであるGの対角成分に微小値を加えよ.これは目的関数に同じ式があるとおきる．最小ノルム解を求めるためには，Gに微小な単位行列を足せば良い．##Failure Location unknown## : Error - Error in cholesky decomposition, sum: 0とでる． G=A^t A, g=-b^t Aとしてx^t G x+g^t xを目的関数とすれば良い 引き継ぎは毎年きちんと保守するという意味でも大事 コア数cat /proc/cpuinfo | grep processor ccacheスゴイhttp://oxynotes.com/?p=6846 気兼ねせずmake cleanできるという感じ でもccache clang++が相性悪い感じがした．後で確認． ccacheを使うと，適切にhppをincludeすることによってコンパイルを高速化するというメリットが生まれる 高速化プログラミング http://fast-programming.aglk.net/matrix-calculation/sample1-C.php OpenMPの罠 http://www.isus.jp/article/openmp-special/32-openmp-traps/ vectorの二次元初期化https://topcoder.g.hatena.ne.jp/n4_t/20090520/1242753566 例：time コマンドで計測した 8 並列の実行時間 real 9.34 ← プログラム実行にかかった時間 user 69.38 ← CPUがユーザプログラムを処理した時間 sys 0.15 ← プログラム実行でシステムが使ったCPU時間 user 69.38 / real 9.34 = 7.43 ← 8 並列の効果があった 実装とヘッダを分ける理由https://teratail.com/questions/10742 Cのinlineは必ずstatic inlineを使う（Linuxカーネルでもそうしている），なぜならstaticがないとgnu90で関数定義が残ってしまうから．そしてヘッダのみに書く．http://masahir0y.blogspot.jp/2012/08/blog-post.html C++のinline修飾子はhppの方には書かない オブザーバとMVCモデル．MVCはオブザーバより粒度が大きいアーキテクチャ・パターン． MVCのモデル図http://www.basuke.com/2012/12/31/%E7%8F%BE%E5%A0%B4%E3%81%AE%E3%82%B3%E3%83%BC%E3%83%894/ UIアーキテクチャ・パターンの違いhttp://www.atmarkit.co.jp/fdotnet/chushin/greatblogentry_10/greatblogentry_10_01.html C++でのMVC例 http://www.slideshare.net/TakashiKomada/mvc-26642187 https://www.ogis-ri.co.jp/otc/hiroba/technical/DesignPatternsWithExample/chapter05.html 0xのshared_ptrでオブザーバとブリッジ http://codezine.jp/article/detail/5327 http://myenigma.hatenablog.com/entry/20140821/1408624373 GLUTを使わないOpenGLhttp://www.codesampler.com/oglsrc.htm http://write-remember.com/program/gof_design_patterns/ 参照型は，ポインタ渡しのセマンティクスを保存して，シンタックスを追加したものと解釈可能 実体はデストラクタがブロックの外で必ず呼ばれるという点で安全． クラスの宣言の中で実装しています。こうすれば、メンバ関数は inline と書かなくてもインライン関数になってくれます。 int*& aPtr;とするとポインタの参照渡しが可能 http://marupeke296.com/DP_Singleton.html コピー禁止．http://marupeke296.com/DXCLS_Noncopyable.html git ci -a -m “”で，added a.cppみたいなのって意味ない気がする．コミットメッセージに残すべき情報とは一体何か？ git ci -F- << EOFで，C-dで終わらせると3行かける git commit -m "wa-i1" -m "wa-i2" -m "wa-i3"でもoK コミットメッセージの英語のまとめは重要な気がする vimのqをうまく使う．レコーディングはqajjjjjq @aで，5行下に行くhttp://blog.livedoor.jp/nakamura_tech/archives/51337233.html vim中級者． http://qiita.com/jnchito/items/57ffda5712636a9a1e62 14Gが:14<enter>と同等．短いので便利 コードはコミットメッセージによって必ずドキュメント化されている．それを抽出するための方法など． http://postd.cc/every-line-of-code-is-always-documented/ http://qiita.com/itosho/items/9565c6ad2ffc24c09364 特に「Fixed a bug where (バグを修正した)」「Changed (変更した)」の部分にはほとんど情報がありません。バグ修正や変更を目的としないコミットが一体どれほどありますか?メッセージは プログラムを主語とする動詞句 で書くべきです。(そして主語はいつもプログラムなので省略します)http://qiita.com/magicant/items/882b5142c4d5064933bc Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要 開発フロー研修 http://qiita.com/awakia/items/c571e93e96a1ec28044f#_reference-8e828835a5c8cede9bd2 指摘に関しては、下手に疑問形にすると嫌味っぽくなるし、素直にこうしたほうが良いと言ったほうがわかりやすくて良い gitのコミットメッセージの形式．1行しかコミットメッセージを書かないのは不届きである． https://blog.unasuke.com/2015/what-happens-if-you-write-something-on-the-second-line-of-the-git-commit-message/ コーディング哲学 https://ja.wikipedia.org/wiki/Don%27t_repeat_yourself アンチパターン https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%B3%E3%83%81%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3 学校の勉強でやったこととやっていないことを明確化したい．開発フローを知らなすぎでしょ 「簡潔な設計で十分なところに、過剰に複雑なデザインパターンの使用を強制する。」のはだめ http://mojix.org/2013/02/10/design-pattern-refactoring switchをポリモーフィズムにするなど，面白そうな話がある.「クラスの抽出」「継承を委譲に置き換える」「引数オブジェクトの導入」あたりだ。これらのリファクタリングを私がよく使うということは、それが私のコードの弱みを突いている、ということを意味している。つまり、私のコードはクラスが肥大化しすぎであり、継承を使いすぎであり、引数をバラバラのまま渡しすぎなのだ。 http://typea.info/tips/wiki.cgi?action=PDF&page=%A5%EA%A5%D5%A5%A1%A5%AF%A5%BF%A5%EA%A5%F3%A5%B0 具体例pdf https://ja.wikipedia.org/wiki/%E9%8A%80%E3%81%AE%E5%BC%BE%E3%81%AA%E3%81%A9%E3%81%AA%E3%81%84 https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B9%E3%83%9E%E3%83%BC%E3%83%81 アンチパターン https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%B3%E3%83%81%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3 リファクタリングカタログhttp://refactoring.com/catalog/ http://mojix.org/2012/11/21/beck-impl-pattern カルト的コーディングhttps://ja.wikipedia.org/wiki/%E3%82%AB%E3%83%BC%E3%82%B4%E3%83%BB%E3%82%AB%E3%83%AB%E3%83%88%E3%83%BB%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0 コード自身を説明するような無駄なコメントを加える、ガベージコレクションが問題なく自動的に処理してくれるようなオブジェクトの解放コードを記述する、単純なオブジェクトの生成にもファクトリーオブジェクトを用いる、等。これらはしばしば、プログラマがプログラミング言語に不慣れな場合に、または単に熱心過ぎる場合に引き起こされる。 再利用可能なプログラムコードの開発には、1回限りのプログラムコードの開発と比べて、2倍、3倍の労力がかかる。 普通のコンストラクタ，普通のコンストラクタとして機能するコピコン（CIntArray? array2(array1);），引数渡しで呼ばれるコ
|
