東方算程譚

Oriental Code Talk ── επιστημηが与太をこく、弾幕とは無縁のシロモノ。

目次

Blog 利用状況

ニュース

著作とお薦めの品々は

著作とお薦めの品々は
東方熱帯林へ。

あわせて読みたい

わんくま

  1. 東京勉強会#2
    C++/CLI カクテル・レシピ
  2. 東京勉強会#3
    template vs. generics
  3. 大阪勉強会#6
    C++むかしばなし
  4. 東京勉強会#7
    C++むかしばなし
  5. 東京勉強会#8
    STL/CLRによるGeneric Programming
  6. TechEd 2007 @YOKOHAMA
    C++・C++/CLI・C# 適材適所
  7. 東京勉強会#14
    Making of BOF
  8. 東京勉強会#15
    状態遷移
  9. 名古屋勉強会#2
    WinUnit - お気楽お手軽UnitTest

CodeZine

  1. Cで実現する「ぷちオブジェクト指向」
  2. CUnitによるテスト駆動開発
  3. SQLiteで組み込みDB体験(2007年版)
  4. C++/CLIによるCライブラリの.NET化
  5. C# 1.1からC# 3.0まで~言語仕様の進化
  6. BoostでC++0xのライブラリ「TR1」を先取りしよう (1)
  7. BoostでC++0xのライブラリ「TR1」を先取りしよう (2)
  8. BoostでC++0xのライブラリ「TR1」を先取りしよう (3)
  9. BoostでC++0xのライブラリ「TR1」を先取りしよう (4)
  10. BoostでC++0xのライブラリ「TR1」を先取りしよう (5)
  11. C/C++に対応した、もうひとつのUnitTestFramework ─ WinUnit
  12. SQLiteで"おこづかいちょう"
  13. STL/CLRツアーガイド
  14. マージ・ソート : 巨大データのソート法
  15. ヒープソートのアルゴリズム
  16. C++0xの新機能「ラムダ式」を次期Visual Studioでいち早く試す
  17. .NETでマンデルブロ集合を描く
  18. .NETでマンデルブロ集合を描く(後日談)
  19. C++/CLI : とある文字列の相互変換(コンバージョン)
  20. インテルTBBによる選択ソートの高速化
  21. インテルTBB3.0 によるパイプライン処理
  22. Visual C++ 2010に追加されたSTLアルゴリズム
  23. Visual C++ 2010に追加されたSTLコンテナ「forward_list」
  24. shared_ptrによるObserverパターンの実装
  25. .NETでマンデルブロ集合を描く(番外編) ── OpenCLで超並列コンピューティング
  26. StateパターンでCSVを読む
  27. 状態遷移表からStateパターンを自動生成する
  28. 「ソートも、サーチも、あるんだよ」~標準C++ライブラリにみるアルゴリズムの面白さ
  29. インテルTBBの同期メカニズム
  30. なぜsetを使っちゃいけないの?
  31. WPFアプリケーションで腕試し ~C++でもWPFアプリを
  32. C++11 : スレッド・ライブラリひとめぐり
  33. Google製のC++ Unit Test Framework「Google Test」を使ってみる
  34. メールでデータベースを更新するココロミ
  35. Visitorパターンで遊んでみたよ
  36. Collection 2題:「WPFにバインドできる辞書」と「重複を許す検索set」
  37. Visual C++ 2012:stateless-lambdaとSQLiteのぷち拡張
  38. 「Visual C++ Compiler November 2012 CTP」で追加された6つの新機能

@IT

  1. Vista時代のVisual C++の流儀(前編)Vista到来。既存C/C++資産の.NET化を始めよう!
  2. Vista時代のVisual C++の流儀(中編)MFCから.NETへの実践的移行計画
  3. Vista時代のVisual C++の流儀(後編) STL/CLRによるDocument/Viewアーキテクチャ
  4. C++開発者のための単体テスト入門 第1回 C++開発者の皆さん。テスト、ちゃんとしていますか?
  5. C++開発者のための単体テスト入門 第2回 C++アプリケーションの効率的なテスト手法(CppUnit編)
  6. C++開発者のための単体テスト入門 第3回 C++アプリケーションの効率的なテスト手法(NUnit編)

AWARDS


Microsoft MVP
for Visual Developer - Visual C++


Wankuma MVP
for いぢわる C++


Nyantora MVP
for こくまろ中国茶

Xbox

Links

記事カテゴリ

書庫

日記カテゴリ

読みやすくねぇよ!

ネタ元 → コーディングスタイル

      読みやすいコード
        とは、多くのプログラマの最大公約数のようなものだろうか?


最大公約数てーことはいちばんわからんちんに合わせるってことですか。
何が哀しうてわからんちんに足引っ張られにゃあかんのですか。

コック集団のなかに見習いが一人いたら出来合いの
レトルトハンバーグあっためて客に出しますか。

void string_copy(char dst[], const char src[]) {
  int i;
  for ( i = 0; src[i] != '\0'; ++i ) {
    dst[i] = src[i];
  }
  dst[i] = '\0';
}

...コレ、読みやすいですか?
なんかね、ひらがなだけで論文書いたような居心地の悪さを感じます。
ひらがなだけでかいたぶんしょうがよみやすいはずがないじゃないですか

void string_copy(char* dst, const char* src) {
  while ( *dst++ = *src++ ) {}
}

僕にはむしろコッチの方が読みやすいだけでなくわかりやすいんですケド

投稿日時 : 2008年6月26日 9:42

コメントを追加

# re: 読みやすくねぇよ! 2008/06/26 9:54 シャノン

俺には strcpy( dst, src ); のほうが読みやすいです!

> *dst++ = *src++

これは一行にあまりに多くの動作を詰め込んでいるので好きじゃなかとです。

# re: 読みやすくねぇよ! 2008/06/26 10:05 biac

こーゆー定石って言うか、 イディオム(?)みたいなもの。 新しい言語やライブラリだと、 どうなんだろう。
他にも
if(NULL == (fp = fopen(ほげ...))) return えらーじゃ;
みたいな書き方とかね。 C/C++ だと、 こーやって書くんじゃ、 ってのが沢山あるんだけど。

Java だと、 10年以上使われてきたから、 いろいろ固まって来てるのかな?
C# は… まだカオスかなぁ f(^^;

# re: 読みやすくねぇよ! 2008/06/26 10:11 επιστημη

うん、イディオムになっちまえばカタマリとして理解できる
からヘンにいぢくられるよりわかりやすいんですよ。
妙な縛りをかぶせてほしくねぇです。

# re: 読みやすくねぇよ! 2008/06/26 10:36 774RR

MISRA-C なんてのはまさにこの
馬鹿が書いてもバグらない→
いちばんわからんちんに合わせるってことです也
ウチの部署でも導入するか?って検討を行っていたので断固拒絶ちう

# re: 読みやすくねぇよ! 2008/06/26 11:16 επιστημη

んー、問題は"わからんちんがコードを書いてる"って実態なのかな。

調理師免許持ってない見習いが見よう見真似で
ハンバーグ焼いてるよなもんよね。

# re: 読みやすくねぇよ! 2008/06/26 11:42 ネタ好き未記入

三項演算子が駄目なら、
case 0; foo(); break;
とか書いたら駄目なのでしょうか?
妙に行数が増えないからいいと思うんだけど・・・

# re: 読みやすくねぇよ! 2008/06/26 11:47 凪瀬

ないすメタファ!

# re: 読みやすくねぇよ! 2008/06/26 14:03 とっちゃん

おいらは
 while ( *dst++ = *src++ ) {}

 while( *dst++ = *src++ );
で書いてる人w

これで熟語化されてますわw
dst[i] = src[i];
な書き方は、ポインタをずらせない要因がある場合くらいかなぁ。

# re: 読みやすくねぇよ! 2008/06/26 14:51 めたぼ なら

わたしは
while( *dst++ = *src++ );
が好きな人ですが。
C#を教えるようになってから、考え方が180度変わりましたねぇ。
# 好きかどうかは同じだけど、べき論が変わりました。

> んー、問題は"わからんちんがコードを書いてる"って実態なのかな。

どこの現場も人が足りんとですよ。
わからんちんでもなんでも、借り出さざるを得ないわけです。
(T_T)

# re: 読みやすくねぇよ! 2008/06/26 15:10 επιστημη

> 借り出さざるを得ない

そこんとこは百も承知なんだけど、だからってその対策が
"わからんちんに合わせましょう"はあまりに下策ぢゃねぇの? と。
全体のスキル・レベルを持ち上げる努力を諦めちゃなんねぇだよ。

# re: 読みやすくねぇよ! 2008/06/26 15:42 ネタ好き未記入

私は下手な人にあわすのではなく、プロの人のコーディングルールにあわす事により社員教育になると思うのですが、実際問題「下手な人に合わす」現場しか遭遇したことがありません。もちろんデスマーチが発生しましたがw
酷いときには、「オブジェクト指向知らない人が居るから、オブジェクト指向関連の機能禁止」(VB.NETのプロジェクトw)とか平気でありました。
もうこの業界どげんかせんといかん!。
ここはやはり匠であるεπιστημηさん達が立ち上がるべきだと思います。

# re: 読みやすくねぇよ! 2008/06/26 15:51 めたぼ なら

> 全体のスキル・レベルを持ち上げる努力を諦めちゃなんねぇだよ。

これはもちろんもちろんごもっともです。
言葉足らずでした。

わたしが言いたかったのは初心者にとってバグの原因になりかねないような省略記法はやめた方が良いかも...と考え方が変わってきたのです。

たとえば、

・3項演算子はわたしはありだと思います。

・ifにブロックを作らず単文しか書かないのは危険だと思います。

・whileも同様。短文どころか;だけでしかも行末に書くのは超危険。
# 私は好きですけどね。

・インクリメント/デクリメント演算子を計算式内に使うのは危険。前置か後置かで処理結果が変わるのも危険。

ぱっと思いつくのはここらへんでしょうか。ここら辺程度は初心者さん向けに合わせてあげる方が良いと思っています。

# re: 読みやすくねぇよ! 2008/06/26 16:55 出水

一流のコックだけ集めているならいいんですけど、
実際は未経験者が3年の経験と偽ってくる世界ですから
生焼けハンバーグを出すぐらいならレトルトも仕方ないというのが私の考えです

あと、ブレイクポイントやprintfを仕掛けにくいので
処理はできるだけ個別に、行を稼ぐって癖がついてます
たまにステップ数(笑)のためだったりしますが

# re: 読みやすくねぇよ! 2008/06/26 19:06 ネタ好き未記入

何はともあれεπιστημηさんのコーディングスタイルの定義がみたいです。

# re: 読みやすくねぇよ! 2008/06/26 19:08 ネタ好き未記入

>あと、ブレイクポイントやprintfを仕掛けにくいので処理はできるだけ個別に、行を稼ぐって癖がついてます

これは邪道ではないと思います。
現にコンパイラもデバッグバージョンではしている事です。NOP植え込みまくりですw

# re: 読みやすくねぇよ! 2008/06/27 10:55 アキラ

> ・インクリメント/デクリメント演算子を計算式内に使うのは危険。前置か後置かで処理結果が変わるのも危険。

少なくてもC++では、前置と後置の違いはしっかり抑えたうえで使わないといけません
後置の場合は一時オブジェクトのコストがあるのでボトルネックになってしまうこともあります
なので、初心者のうちに前置と後置をしっかり教えてあげれば
↑にあるようなのは危険だとは思いません

# re: 読みやすくねぇよ! 2008/06/27 11:12 アキラ

あ、私の場合は読みやすいと難しいは全然別問題なので
難しいことは、レビューのときに教えるようにしてます。
(定期的にチーム内にメールでEffectiveな感じの技術情報流したりとかも)
難しいことをやっちゃダメと言い出したら
デザインパターンとかイディオムなんて使えないです

# re: 読みやすくねぇよ! 2008/06/27 11:43 επιστημη

> επιστημηさんのコーディングスタイルの定義

"ごらんのとおり"ですよ♪
とはいえ結構揺れてるんですけどね。

タイトル
名前
URL
コメント