5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

良いコードを書くためのノウハウを蓄積するスレ

1 :デフォルトの名無しさん:04/12/05 14:50:20
良いコードを書きたいです。でも、書けないです。
良いコードを読めばよいと聞きますが、どれがよいコードなのか分かりません。
長くないけど、良いコードと悪いコードを比較して、わかり易く教えてください。
デザインパターン適用するといいと聞きますが、どれだけいいのか分かりません。
異常処理書くと汚くなってしまいます。
例外処理はtry{}catch(Exception e){}としてしまいます。
言語や環境、職場によって良いとされる書き方は変わります。
例えば、携帯Javaは容量を少なくするコードが良くなります。
スピードを徹底的に重視すれば、オブジェクト指向は邪魔なだけです。
関数型言語では、再帰呼び出しを使うのが上等です。
コードリーディングとか、達人プログラマーとか、
本買って読むといいらしいけど、お金ないし、
買いに行くのめんどくさいし、ウェブで見たいです。
そういうサイトつくりたいけど、頭悪くて作れません。
てことで、まとめWiki作って、勝手に書き込んで欲しいです。
トヨタ式的なものがソフトウェア産業でできてないと言うし悔しいです。
てことで、良いプログラムを書くためのやり方、良いソースの書き方を議論して、
最強のソフトウェア開発方法をまとめてください。


283 :デフォルトの名無しさん:04/12/29 02:19:27
>>280
「処理の分離/細分化」ではない。「機能の分割」だ。#細かなところは突っ込まないで
機能の分割が出来ていれば命名に悩む事なぞないと思うが

284 :デフォルトの名無しさん:04/12/29 02:23:09
>>280
名前の付け方で困るほど細分化したら却ってメンテ性下がるだろ。
何のための関数なのかが自明なレベルで止めとけって。
(自分には判ってるから大丈夫とかアマチュアな事言うなよ。)

285 :デフォルトの名無しさん:04/12/29 07:25:32
>>280
> ある処理を細分化して
> その処理中の1度しか呼ばれないような関数の場合の
> 命名手法はどんな感じ?
他の関数と同じ方法でつければいいじゃん。

286 :デフォルトの名無しさん:04/12/29 08:48:29
ラムダよりもforeachが欲しい

287 :デフォルトの名無しさん:04/12/29 09:05:00
>>286
アルゴリズムのstd::for_eachで十分……、なわけないよな。

288 :デフォルトの名無しさん:04/12/29 11:12:49
ラムだっちゃ☆

289 :デフォルトの名無しさん:04/12/29 14:07:51
>>286
C#使ってみなよ、あんまり便利でもないよ、for文+イテレータのほうがシンプルでいいね。

290 :デフォルトの名無しさん:04/12/29 14:38:03
>ある処理を細分化して
>その処理中の1度しか呼ばれないような関数の場合の
>命名

そんな困るような分割するのが頭悪い

291 :デフォルトの名無しさん:04/12/29 15:02:50
>>290
たとえば、Cにおけるコマンドライン引数処理なんて
mainの中から一度呼ぶだけだったりしますが。

292 :デフォルトの名無しさん:04/12/29 16:02:51
>>291
呼ばれる頻度で名前の付け方変えるってどこの世界の命名規則でつか?

293 :デフォルトの名無しさん:04/12/29 16:09:08
>>292
さぁ。そんな命名規則見たこと無いけど。

294 :デフォルトの名無しさん:04/12/29 16:10:02
頻度っていうかprivate, staticなものはいい加減に付けがち

295 :デフォルトの名無しさん:04/12/29 17:12:29
関数にしたんなら
関数にされた一連の処理群に何らかの意味的なマトマリを見い出してるはずだから
その意味を英訳して関数名にするがよい

296 :デフォルトの名無しさん:04/12/29 17:14:26
勿論「returnで流れ制御」したいがために関数を作っちゃう馬鹿はどっかいけ

297 :デフォルトの名無しさん:04/12/29 17:21:54
296
便利さと性能、どちら優先かによる

298 :デフォルトの名無しさん:04/12/29 17:31:16
Cライクな言語はもううんざり。

299 :デフォルトの名無しさん:04/12/29 17:34:41
これからはschemeか。

300 :デフォルトの名無しさん:04/12/29 17:39:50
Schemeもいいけれど、ML系のOCaml辺りの方が実用的でよさそう。

301 :デフォルトの名無しさん:04/12/29 17:40:43
>returnで流れ制御
って何?

302 :デフォルトの名無しさん:04/12/29 18:00:46
例えばreturnで多段breakをしたいが為だけに関数を分割するって話だろ

303 :デフォルトの名無しさん:04/12/29 18:16:13
>291
>コマンドライン引数処理

そう名づけりゃいいじゃんかよ

304 :デフォルトの名無しさん:04/12/29 18:20:35
>>303
一度しか呼ばれないような関数を作る奴は頭悪いんだろ。

305 :デフォルトの名無しさん:04/12/29 18:25:54
>304
>一度しか呼ばれないような関数を作る奴は頭悪い

ってのは違うぞw
名前付けに困ってるんだろ?



306 :デフォルトの名無しさん:04/12/29 18:31:12
名前付けに困るような分割=1度しか呼ばれないような関数への分割でしょ。

307 :デフォルトの名無しさん:04/12/29 18:36:58
>>303
main も駄目でつか?


308 :デフォルトの名無しさん:04/12/29 18:38:18
func(){
 func_init();
 func_run();
 func_done();
}
とかだらだらと_でつないでいけば少なくとも迷うことはない。

309 :デフォルトの名無しさん:04/12/29 18:39:03
通行人A、通行人B ・・・ でどうだろうか?

310 :デフォルトの名無しさん:04/12/29 18:39:13
ん?

>1度しか呼ばれないような関数への分割
するときに名前付けに困る時があるって話だろ?

名前付けに困らないから、先のケエスは無問題だ



311 :デフォルトの名無しさん:04/12/29 19:19:30
1 度しか呼ばれない関数を作るのが抽象化の目的であれば良いコードです

312 :デフォルトの名無しさん:04/12/29 20:00:19
どうでもいいけど1度って書くと角度みたいだね

313 :デフォルトの名無しさん:04/12/29 20:08:07
んん?
角度ってラジアンだろ?

314 :デフォルトの名無しさん:04/12/29 20:12:46
>>313
いいえ。

315 :デフォルトの名無しさん:04/12/30 12:48:08
100前後読んでたら、仕様書からいきなりコーディングしてる奴がいた。


316 :デフォルトの名無しさん:04/12/30 20:21:10
蓄積しま
ttp://www.okisoft.co.jp/esc/go/style0.html

317 :デフォルトの名無しさん:04/12/31 11:54:40
>>272
スコープが
上3つはpublic
下2つはpackage

318 :デフォルトの名無しさん:04/12/31 12:59:23
>>317
>>272書いた人?
静的クラス図書いてUPしてほしいな。


319 :デフォルトの名無しさん:05/01/03 12:47:09
スレッドも1/3経過したことだし、これまでに蓄積されたノウハウをまとめない?

320 :デフォルトの名無しさん:05/01/04 10:11:50
電車男みたいに本にして儲けたいらしいが、
ttp://f55.aaa.livedoor.jp/~goodcode/
にまとめるとか。

321 :デフォルトの名無しさん:05/01/04 19:12:06
これまでの成果
---
・公開されているよいソースコードを読むとよい
・assert文を使うとよい
・よい本を読むとよい
・コード量が少なくなるようにする
・メソッドの数をできるだけ少なくする
・クラスはできるだけ作らないようにする?
・リファクタリングする
・素早く頭働かす?
・メンタルの健康を保つ?
・ネストはできるだけ下げないようにする?
・変更履歴にはwhat i didではなく why i did itを書け?
---

この先続けてもたいした成果は得られないような…

322 :デフォルトの名無しさん:05/01/04 21:35:28
結論
自分で書かない
人のやつをパクる

323 :デフォルトの名無しさん:05/01/04 21:44:19
シンプルが一番
可読性も保守性も効率だって

万一、実行速度が問題になったとしてもそれに集中しやすいし

324 :デフォルトの名無しさん:05/01/05 13:50:40
>>322
人のやつもパクらない。
作る側から使う側へクラスチェンジする。


325 :デフォルトの名無しさん:05/01/07 01:58:38
297 :仕様書無しさん :05/01/06 00:55:02
テストファーストとはテスト項目に重点をおいてコーディングを行う開発手法のこと。
テストを通ることを最優先して実装を行う。
モジュールの品質はテストによって保障されるが、 最初からテストを通ることを主目的にしているため、品質の確保がしやすい。
利点として
・テストケースにない機能は実装しないので
「将来発生するかもしれない」とか「仕様書にない機能」のような余分なことをしないので、
余計なバグの混入を防ぐ
・あらかじめテスト項目を作成するため、PGの頭の中でロジックが整理しやすい
などがある。

「テスト」とひとくくりにすると混同しやすいが、 「テスト工程をクリアしたら品質が保障される」ということを逆手にとって
「では最初からテスト工程を通ることを重視する」だけであり、 テスト工程でのテスト作業そのものを指すわけではない。

298 :仕様書無しさん :05/01/06 01:03:16
もちろんテスト作業の質を上げる工夫もされているが、 テスト作業(テストケースの作成、結果確認など)がタコなら品質は保証できない。 (これはアフターテストでも同じだが)
アジャイル開発などでは、コードの修正を行ったら回帰テストを全項目行うことを推奨していたはず。
全項目を確認しなおすことで、ソースに対する信頼性を保障することが出来る。
ただし、これを人手やるのは大変なので回帰テストの自動化が求められている。

301 :仕様書無しさん :05/01/06 03:51:53
俺が思うに「最初にテストケースを考える」ことこそテストファーストの真髄だと思うんだ。
(テストファーストを唱えてる人がどう思ってるか知らんけど)
そこで生まれたテストケースが貧弱かどうかは実はどうでもよくて発想の転換で
テストケースを濃くする事とコード書く時に外部条件を意識して書くようにする事
要するに熟達したプログラマが普通にやってるこの2点をシステマチックにやる事で品質向上を狙うモノではないかと。

326 :デフォルトの名無しさん:05/02/05 03:05:22
if(flag){
  func();
}
というインデントが多いみたいだけど
if(flag)
{
  func();
}
これだとダメなの?
こちらのほうが対応するカッコの数とか分かりやすいんだけど。

327 :デフォルトの名無しさん:05/02/05 03:06:08
>>326
人それぞれ。
私は前者。

328 :デフォルトの名無しさん:05/02/05 03:07:27
>>326
なるべく行数を減らした方がコード全体を把握しやすくなるというメリットがある。

329 :デフォルトの名無しさん:05/02/05 03:19:39
でも行数が減って積め積めになるとかえって読みづらいと思う。
コード数を減らす事が良いコーディングと聞いて行数を減らそうと
勘違いする人がいるけど、そういう人に限って凄く密集したような
コーディングするんだよなぁ。
しかも変数名もとにかく短くて意味の通らないものにしたりするし。

330 :デフォルトの名無しさん:05/02/05 03:28:24
>>329
いや、たしかにそうなんだけど、私が言っているのはもっと物理的な面の話。

331 :デフォルトの名無しさん:05/02/05 03:38:03
しかし、こういうのは人に強制できるものじゃないから
人それぞれのコーデイングスタイルがプロジェクト内で混ざり
まくるんだよなぁ。
深いインデントの中に違うスタイルのインデントが入ってきたりとか。

332 :デフォルトの名無しさん:05/02/05 07:32:07
>>329
ifとfuncの間が一行空いている積極的な理由が思いつかない。

333 :デフォルトの名無しさん:05/02/05 07:50:19
if(flag) func();

334 :デフォルトの名無しさん:05/02/05 07:57:42
>>326
つか、カッコの数を数えないといけないようなコードを書くな。

335 :デフォルトの名無しさん:05/02/05 08:02:40
>>326
K&Rに倣っている人も多いんじゃないかな。

336 :LISP大好き:05/02/05 08:04:29
>>334
呼んだ?

337 :EmacsLisp使い:05/02/05 09:05:43
>>336
インデントはエディタに任せるから数えたことないなぁ

338 :デフォルトの名無しさん:05/02/05 10:01:09
括弧の前に改行一個入れるか入れないかで
議論になるお前らのミジンコサイズの根性がかわいいぜ

339 :デフォルトの名無しさん:05/02/05 12:06:51
シッコの穴の小さいやつらだ

340 :デフォルトの名無しさん:05/02/05 14:46:08
>ifとfuncの間が一行空いている積極的な理由が思いつかない。

見やすいじゃないか。ifの横にカッコがある事に気づかない事も
たまにあるしブロック化されているのが明確になっていて良い。

341 :デフォルトの名無しさん:05/02/05 15:07:26
見やすいか? それと同じように>>326の下の方が見にくいという主張も成り立つが。
むしろ条件と関係なくローカルスコープを作るためのブロックと混同しそうでいやだ。


342 :デフォルトの名無しさん:05/02/05 15:27:22
do
{
if (...)
{
...;
}
else
{
...;
}
}
while (...);
と書くのだろうか…
私なら
do {
if (...) {
...;
} else {
...;
}
} while (...);
と書くのだが。

343 :デフォルトの名無しさん:05/02/05 15:47:33
条件式が複数行になる場合
if(...
 ...
 ...) { // ここと
 ...; // ここがくっついて見えるのが嫌


344 :デフォルトの名無しさん:05/02/05 16:15:32
>>342
インデントされてないが上の書き方のほうが見やすい。
まぁdoは自分は使わないけど。

345 :デフォルトの名無しさん:05/02/05 16:24:11
>>344
do
{
while (...) ...;
}
while (...);
while (...) ...;

do {
while (...) ...;
} while (...);
while (...) ....;
では?

346 :デフォルトの名無しさん:05/02/05 16:29:16
うえは
}
while (...);
が紛らわしくてやだ

347 :デフォルトの名無しさん:05/02/05 16:34:23
>>340
> ブロック化されているのが明確になっていて良い。
ifとそれに続く処理が別のブロックのように見えちゃうのはいかんだろ。

348 :デフォルトの名無しさん:05/02/05 16:46:37
良いコードを書くためには
Eclipseを用意し、設定でコードの警告メッセージを出す設定で、無視となっているものをすべて警告に変更する。
コードフォーマッタを使う。
Subclipseプラグインをインストールし、Subversionでバージョン管理する。
メトリクスプラグイン、プロファイラプラグイン、CheckStyeプラグイン、Jalopyプラグイン、Findbugsプラグイン、
Code Analysisプラグイン、SolarEclipseプラグイン、SimScanプラグイン、プロパティエディタプラグイン、
Lombozプラグイン、Sysdeo Tomcatプラグイン、Hibernateプラグイン、Sobalipseプラグイン、
JBoss-IDEプラグイン、DbEditプラグイン、EclipseUML Omondoプラグイン、Easy Strutsプラグイン、
Bytecode Ontlineプラグイン、XMLプラグインをインストールする。

Apache Antでbuild.xmlを書く。
MevenideをEclipseにインストールし、
Apache Mavenでproject.xmlを書く。
Mavenを利用してJakarta CommonsのAPIを積極的に使う。

テストファーストを実践し、JUnitを毎日欠かさず実行する。

これでよしっ!

349 :デフォルトの名無しさん:05/02/05 16:56:00
>>341
>ローカルスコープを作るためのブロックと混同しそうでいやだ

ローカルスコープを作るためのブロックなんて使わない。
これで万事解決。


350 :デフォルトの名無しさん:05/02/05 17:31:10
>>349
アフォハケーン

351 :デフォルトの名無しさん:05/02/05 18:27:23
>>345
do
{
  while (...)
  {
     ...;
  }
}
while (...);

while (...)
{
  ...;
}

インデント、ブロック化、改行を活用する。

352 :デフォルトの名無しさん:05/02/05 20:22:55
結論はやはり人それぞれ。

353 :デフォルトの名無しさん:05/02/05 22:51:35
30年かわらぬ嗜好品だな

354 :デフォルトの名無しさん:05/02/05 23:15:02
人間の目は横に並んでいるので縦方向に長いものは把握しにくい


355 :デフォルトの名無しさん:05/02/05 23:19:41
do{
  while (...){
     ...;
  }
}while (...);

while (...){
  ...;
}


どう考えてもこっちの方が把握しやすい

356 :デフォルトの名無しさん:05/02/05 23:30:37
本で読んだ受け売りだけど。
#ifdef FOO
if (hoge)
#else
if (piyo)
#endif
{
  statements;
}
こういう場合に、エディタの括弧対応調査機能が働きやすいというのがある。

357 :デフォルトの名無しさん:05/02/05 23:32:34
バッドノウハウだな。

358 :デフォルトの名無しさん:05/02/05 23:41:13
if(hoge){
foo;
}

の人は何で

if(hoge{
foo;}
にしないの?

359 :デフォルトの名無しさん:05/02/05 23:42:07
}else{

360 :デフォルトの名無しさん:05/02/05 23:44:24
>>358
}が最後尾になって追跡しにくいから。
関数型だったら手続きがないから最後尾の}はOKだけど。

361 :デフォルトの名無しさん:05/02/05 23:47:12
>>356
それに近い事よくやるよ。
ifの行だけ#ifdefとかで無効になっても残ったブロック部分も
問題なくコンパイル出来るしね。

362 :デフォルトの名無しさん:05/02/06 00:11:17
>>356
普通は
#ifdef FOO
#define COND hoge
#else
#define COND piyo
#endif
if (COND) {
 stmts;
}
みたいに書かないか?

363 :デフォルトの名無しさん:05/02/06 00:15:47
単独で記述することができないキーワードが先頭に来るのはきもい。
x
if (hoge)
{
}
else
{
}

o
if (hoge) {
} else {
}


364 :デフォルトの名無しさん:05/02/06 01:30:05
きもいじゃ理由にならん。
見た目で語るなら個人差がある。

365 :デフォルトの名無しさん:05/02/06 02:17:00
>>362
それだとifでbreak張ってもCONDがどちらか分からないんじゃない?

366 :デフォルトの名無しさん:05/02/06 04:40:28
m
a
i
n

これにはびっくりしたよw

367 :デフォルトの名無しさん:05/02/06 08:36:21
>>356 >>362
普通は
int hoge()
{
...
}
int piyo()
{
...
}
int (*stmts[])() = {hoge, piyo};
int fuga = stmts[FOO]();
みたいに書かないか?


368 :デフォルトの名無しさん:05/02/06 09:50:48
>>367
#define FOO
だったらどうする

369 :デフォルトの名無しさん:05/02/06 10:28:22
>>368
あふぉか?

370 :デフォルトの名無しさん:05/02/06 15:36:03
>>21
> 9 a(1, 1);
これだな。

こういったスペースの調整はとりあえずフォーマッタツールでどうにかなる
Eclipseならコードフォーマッタの設定でできる。

しかし、フォーマッタツールによっては厄介なこともまだまだある。
たとえばEclipseのコードフォーマッタは
//によるコメントを乱してしまう。

たとえば
////////////////////////////////////////////////////
//       コメント                        //
//       コメント                        //
//       コメント                        //
////////////////////////////////////////////////////
のようなボックスで囲まれたコメントをつける癖のあるコメントがある
コードにたいしてコードフォーマッタを実行すると
見事にこのコメントが乱れてしまう。
VC++プログラマがEclipseを使おうとしたときによく陥る問題である。

こういう場合
/**
* コメント
* @author $Author$
* @version $Id$
*/
で統一する必要がある。
VC++プログラマが書いたコードを調整したいときもこの問題に直面する。
//を好んで使う癖がある人のコードに対して/** */ を求めると
抵抗する人もいる。実際そういう人と仕事をしている。

371 :デフォルトの名無しさん:05/02/06 15:38:33
>>362
それだと

#ifdef CHECK
if (COND)
#endif
{
    sttmts;
}

と書けないから。


372 :デフォルトの名無しさん:05/02/06 15:52:02
>//を好んで使う癖がある人のコードに対して/** */ を求めると

Eclipse側の問題を//スタイルのプログラマにしわ寄せさせるのは良くない。

373 :デフォルトの名無しさん:05/02/06 16:00:56
(;゚∀゚)=3ウハウハを蓄積

374 :デフォルトの名無しさん:05/02/06 16:03:21
>>372
>Eclipse側の問題を//スタイルのプログラマにしわ寄せさせるのは良くない。

C89 との互換性を考慮するプログラマにしわ寄せさせるのも
いかがなものかと。


375 :デフォルトの名無しさん:05/02/06 17:04:29
互換性考慮がチームで決定された方針なら全員あわせるべき。
それが個人による趣味の範囲なら人それぞれ。
C++で//を使うなという話自体はナンセンス。

376 :デフォルトの名無しさん:05/02/06 17:09:35
複数行に渡るコメントは、#if 0 を使ったり include にしたり

377 :デフォルトの名無しさん:05/02/06 17:56:34
>>376
>include にしたり
?

378 :376:05/02/06 18:15:11
>>377
コメント行のみで構成されるテキストファイルを作ってincludeするのだよ

379 :デフォルトの名無しさん:05/02/06 18:23:33
>>376
それはそれでひとつのテクニックだとは思うけど、
コメントの為にあるものではないし、
エディタ上ではコメント扱い(の表示)になってくれない。

380 :デフォルトの名無しさん:05/02/06 18:25:33
>>378
ごめん、それ、何の意味があるのか判らない。
例えばfoo.cppに
// See foo.txt for detail.
って書けば済む気がしてならないんだけど。

381 :デフォルトの名無しさん:05/02/06 18:27:08
>>378
基本的に、コメントはコンパイラじゃなくて人が読む物なのに、
わざわざ別ファイルにして、そっちを開かなきゃいけなくなるのが馬鹿馬鹿しい。と思えるのは自分だけですか?

382 :69式フリーPG ◆hND3Lufios :05/02/06 18:28:14
無意味

383 :デフォルトの名無しさん:05/02/06 18:49:54
まともに動けばそれで良い

130 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)