◎正当な理由による書き込みの削除について:      生島英之とみられる方へ:

TWO == イラッつとするコーディングスタイル->画像>1枚


動画、画像抽出 || この掲示板へ 類似スレ 掲示板一覧 人気スレ 動画人気順

このスレへの固定リンク: http://5chb.net/r/prog/1338703896/
ヒント:5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。

1 :仕様書無しさん:2012/06/03(日) 15:11:36.61
文法的には何ひとつ間違ってはいないし、本人なりに見やすくしようとする意図は汲み取れるのだが、
どうにも気持ち悪くて、「修正してやる!」と叫びながらキーボードを激しく連打したくなる

そういう薄気味悪いコーディングスタイルを発見したら書き込むスレッド




992 名前:仕様書無しさん[sage] 投稿日:2012/06/03(日) 15:08:56.92
このスレ吐き気する

2 :仕様書無しさん:2012/06/03(日) 15:18:31.82
右に定数書けや糞が

3 :仕様書無しさん:2012/06/03(日) 15:19:18.17
TWO( イラッとするコーディングスタイル )で良かったんじゃないか

4 :仕様書無しさん:2012/06/03(日) 15:44:53.56
タイトルに複数行使えたらよかったのに

5 :仕様書無しさん:2012/06/03(日) 15:45:37.75
for

6 :仕様書無しさん:2012/06/03(日) 15:52:01.79
「STLは遅くてサイズも肥大化するからデータ構造は自作しろ」

7 :仕様書無しさん:2012/06/03(日) 16:17:42.39
乙wスレタイうぜぇwww


8 :仕様書無しさん:2012/06/03(日) 18:30:46.31
◆zensure
イラッつとするコーディングスタイル
http://kohada.2ch.net/test/read.cgi/prog/1331385629/

9 :仕様書無しさん:2012/06/03(日) 19:25:02.59
このスレタイは好きだ。でも定数は右で

10 :仕様書無しさん:2012/06/03(日) 19:54:11.63
なにげにガンダムZネタ

11 :仕様書無しさん:2012/06/03(日) 20:33:40.76
>>9
じゃマクロ化してやるよw
if( SUCCEEDED( Function() ) )

12 :仕様書無しさん:2012/06/03(日) 20:40:50.13
ヘッダファイルが・・・・
メンテはさほど手間じゃないだろうが、チーム全員で一念発起してかからないと
そのマクロを排除する作業は永遠に不可能

13 :仕様書無しさん:2012/06/03(日) 20:59:44.54
それ以前にMSが使ってるからな
今更変えられん

14 :仕様書無しさん:2012/06/03(日) 22:06:54.65

なんでみんなCなん?

15 :仕様書無しさん:2012/06/03(日) 22:17:34.21
うちは組込みだからCばっかだねぇ
Linuxカーネルにハンガリアンでコードを
ごりごり追加するのが居て気失いそうになります


16 :仕様書無しさん:2012/06/03(日) 22:18:00.48
そりゃ…高級言語の初期ちゅーのはCやろ

17 :仕様書無しさん:2012/06/03(日) 22:20:53.99
大昔から延々と保守されてるVB6のコード相手にしてると
コーディングスタイル?何それおいしいの?というぐらいはちゃめちゃで
こんな高尚なスレにかける話題が提供できないorz

18 :仕様書無しさん:2012/06/03(日) 23:49:35.85
案件として多いであろうC#、Java、PHPがCに似てるからだろう

19 :仕様書無しさん:2012/06/04(月) 05:12:46.59
とりあえず伝えたけりゃCで書いたほうがいちいち説明しなくてすむな

20 :仕様書無しさん:2012/06/06(水) 22:57:23.20
オッサン同士ならな。
今どきの学生プログラマにとってはCなんぞFORTRANやCOBOLと同レベルだろ。

21 :仕様書無しさん:2012/06/06(水) 23:05:44.58
マジだから笑えない。

22 :仕様書無しさん:2012/06/06(水) 23:33:07.18
ドカタ乙

23 :仕様書無しさん:2012/06/06(水) 23:45:26.78
俺今21歳の学生プログラマだがC/C++で書かれるのが一番分かりやすいんだが・・・

24 :仕様書無しさん:2012/06/06(水) 23:51:51.27
>>23
そうか。
俺はわかりにくいんだごめんな。

25 :仕様書無しさん:2012/06/07(木) 01:10:55.75
>>17
長年かけて熟成した秘伝のソースですね。
沢山の材料が変化して複雑に絡み合って、なんとも言えない味になるよね。
特にVBは…

26 :仕様書無しさん:2012/06/07(木) 01:12:18.70
LLはやっぱグルー的な役割が強くて、素材としてはCとかも使えた方が何かといいと思うよ。

27 :仕様書無しさん:2012/06/07(木) 11:18:41.83
>>24
どんだけ素人なんだよw

28 :仕様書無しさん:2012/06/07(木) 21:26:36.57
別にCなんて過去の遺物素人でも全然問題ないです

29 :仕様書無しさん:2012/06/07(木) 21:40:42.53
アセンブリ言語もC/C++も使えずしてどうやってデバグやってんだお前ら

30 :仕様書無しさん:2012/06/07(木) 21:55:06.57
は?デバグなんてするわけないじゃんw

31 :仕様書無しさん:2012/06/07(木) 23:50:14.34
プロのプログラマーじゃないなら特に必要ないと思うよ。
学生とかに向かって「Cが出来ないと話にならない!」みたいなこといってる奴はもう完全に頭おかしいおっさん。

低レベルなところいじれた方ができること増えるし、プロなら必要だとおもうけどね。

32 :仕様書無しさん:2012/06/08(金) 00:55:36.32
『低レベル』っていう和訳はなんとかならなかったもんかね。

33 :仕様書無しさん:2012/06/08(金) 01:24:38.14
機械からの主観なのがややこしい。

34 :仕様書無しさん:2012/06/08(金) 07:29:29.89
「プロ」ねぇ…

35 :仕様書無しさん:2012/06/08(金) 12:35:35.51
プロの「IT技術者」には必要
プロの「IT事務屋」には不要

36 :仕様書無しさん:2012/06/08(金) 13:28:51.15
歴代担当者がそれぞれ自分の得意な言語でツール実装してたりとか、
言語増えすぎでたまにイラッつとする事もある。

37 :仕様書無しさん:2012/06/08(金) 18:15:12.15
なんか、Cで挫折した奴が「Cなんて今さら不要」って叫んでるみたいだが
Cってそんなに難しいのか?
ポインタがわからなかったか?

図星さしちゃったかなwwww

38 :仕様書無しさん:2012/06/08(金) 18:21:45.25
メモリポインタって何?

39 :仕様書無しさん:2012/06/08(金) 18:34:10.27
ダブルポインタのこと。

40 :仕様書無しさん:2012/06/08(金) 18:36:11.77
メモリメモリ番地

41 :仕様書無しさん:2012/06/08(金) 18:50:03.78
図星のアドレスをポイントしてるのか

42 :仕様書無しさん:2012/06/08(金) 19:49:00.76
>>37
Cはめちゃくちゃ難しい。ハンドルとかポインタとか意味がわからない。ソースは俺。

43 :仕様書無しさん:2012/06/08(金) 20:16:25.96
Cで書いた方がいい時以外でもCを勧めてないか?
むしろ、LL言語に適応できていないんじゃないか?

44 :仕様書無しさん:2012/06/08(金) 20:23:45.91
Cできない奴が必死すぎるんですけどw

45 :仕様書無しさん:2012/06/08(金) 20:25:14.39
                     /j
                   /__/ ‘,
                  //  ヽ  ', 、
                    //    ‘  ! ヽ             …わかった この話はやめよう
                /イ       ', l  ’
               iヘヘ,       l |  ’
               | nヘヘ _      | |   l            ハイ!! やめやめ
               | l_| | | ゝ ̄`ヽ | |〈 ̄ノ
               ゝソノノ   `ー‐' l ! ¨/
            n/7./7 ∧        j/ /     iヽiヽn
              |! |///7/:::ゝ   r===オ        | ! | |/~7
             i~| | | ,' '/:::::::::::ゝ、 l_こ./ヾ..     nl l .||/
             | | | | l {':j`i::::::::::::::::`ーr '         ||ー---{
              | '" ̄ ̄iノ .l::::::::::::::::::::::∧       | ゝ    ',
      , 一 r‐‐l   γ /、::::::::::::::::::::::::〉ー= ___  ヘ  ヽ   }
    / o  |!:::::}     / o` ー 、::::::::::::i o ,':::::::{`ヽ ヘ     ノ
   / o    ノ:::::∧   /ヽ  o  ヽ::::::::| o i::::::::ヽ、 /   /
   /    ノ::::::/    /::::::::ヽ  o  ヽ:::| o {::::::::::::::Υ   /


46 :仕様書無しさん:2012/06/08(金) 20:34:43.02
>>44
先輩、C言語でどんなすごいプログラム作ってるんですか?

47 :仕様書無しさん:2012/06/08(金) 20:47:42.87
Cができるのが自慢なのかw
まさか21世紀になってそんな奴見るとは思わなかった。

48 :仕様書無しさん:2012/06/08(金) 22:07:35.95
20年以上前にできた言語をいまさら使おうという神経が分からない

49 :仕様書無しさん:2012/06/08(金) 22:17:53.55
オートマ限定男が必死になるのと似てるなw

50 :仕様書無しさん:2012/06/08(金) 22:19:15.90
お前ら調子乗りすぎるなよ。
C出来なくても問題ない分野も多いけど、開き直って偉そうにしたら、C言語最強のおっさんと同じレベルになるぞ。

51 :仕様書無しさん:2012/06/08(金) 22:23:06.96
AT限定免許ができたからかえってMT運転できるのを自慢したくなる、みたいな?

52 :仕様書無しさん:2012/06/08(金) 23:08:48.59
そういやこの前、中型とかいうのが出来たせいで
それ以前にとった普通で少し大きなのを運転できるんだよね

似たようなシチュで、俺の婆ちゃんは大型バイクに乗れるらしい

53 :仕様書無しさん:2012/06/08(金) 23:21:03.42
>>52
別に中型ができたせいで以前の普通で乗れる範囲が広がったわけじゃないけどな。
ただ単に、新しい普通の範囲が狭まったから、以前の普通を「中型の8t限定」に改称しただけだろ。

54 :仕様書無しさん:2012/06/09(土) 03:51:16.71
C読めない奴にイラッつとする
Cばかりな20世紀おっさんを見てるとイラッつとする

55 :仕様書無しさん:2012/06/09(土) 17:18:21.66
>>48
50年前に出来た数式を使おうと思わない

56 :仕様書無しさん:2012/06/09(土) 17:58:36.17

     ::|     从
     ::|     从从 
     ::|    从从从
     ::|.  /   |.| ヽ.
     ::|. /     |.|  ヽ
     ::|-〈  __   ||  `l_
     ::||ヾ||〈  ̄`i ||r‐'''''i| |   
     ::|.|:::|| `--イ |ゝ-イ:|/
     ::|.ヾ/.::.    |  ./     
     ::|  ';:::::┌===┐./     
     ::| _〉ヾ ヾ二ソ./
     ::| 。 ゝ::::::::`---´:ト。
     ::|:ヽ 。ヽ:::::::::::::::::ノ 。 `|:⌒`。
     ::|:::ヽ 。ヾ::::::/  。  ノ:::i   `。
     ::|:::::::| 。 |:::|  。 /:::::::|ヾ:::::::::)
     ::|::::::::| . 。 (●) 。 |:::::::::::|、  ::::〈

57 :仕様書無しさん:2012/06/09(土) 18:03:47.80
>>48
80年前にできたアルゴリズムを使おうとは思わない

58 :仕様書無しさん:2012/06/09(土) 20:43:02.30
>>56
流れ止めろよ

59 :仕様書無しさん:2012/06/09(土) 21:51:48.38
switch ((a == 1) == false)
{
case true:
break;

case false:
break;
}

これ書いた奴は天才だと思った(小並)

60 :仕様書無しさん:2012/06/09(土) 23:32:04.26
>>48
100年前から使われてる傘をいまさらつかおうという神経がわからない

61 :仕様書無しさん:2012/06/09(土) 23:51:52.01
>>59
難っw



62 :仕様書無しさん:2012/06/10(日) 00:42:27.70
>>48
紀元前にできたコンクリートをいまさらつかおうという神経がわからない

63 :仕様書無しさん:2012/06/10(日) 00:55:05.54
どうせ言葉とか文字とか火とか肉体とか細胞とか言い出すんだろ
つまんねー流れだな

64 :仕様書無しさん:2012/06/10(日) 01:00:38.33
>>48
32年間女から守り続けてきたお前の股間をいまさらつかおうという神経がわからない

65 :仕様書無しさん:2012/06/10(日) 04:03:47.96
>59
いったい何を行う処理なんだ……

66 :仕様書無しさん:2012/06/10(日) 04:11:09.76
大学で出てくるif使っちゃ駄目っていう宿題とかそんな感じだよな

67 :仕様書無しさん:2012/06/10(日) 04:37:59.75
>>59
これってかなり簡略化した形なんじゃない?

if(a>10) {
else if(b<10) {
else if(c==5) {
}
みたいなものを書く時に

switch(true)
{
 case a>10: ・・・ break;
 case b<10: ・・・ break;
 case c==10: ・・・ break;
}

みたいなことができる。

((a == 1) == false) これはtrue/falseが言語で規定されてないのでは?
つまりtrueは1でfalseは1以外みたいな値にしていると高架化ざるを得ない場合がある。

68 :仕様書無しさん:2012/06/10(日) 07:40:03.54
え、何言語?

69 :仕様書無しさん:2012/06/10(日) 13:24:27.36
>>67
falseが0でtrueはそれ以外ってんじゃない環境がいまどきあるのかー
てか、上記環境でtrueと比較するカスがいなくならないのはなんでなんだぜ

70 :仕様書無しさん:2012/06/10(日) 13:35:53.13
>68
VisualBasicはswitchじゃなくてselectだけど、各caseにif文と同じレベルの条件文書けるね。

71 :仕様書無しさん:2012/06/10(日) 14:54:23.92
>>69
お前は文系だろ。若しくは理系でも数学止まりだろ。

72 :仕様書無しさん:2012/06/10(日) 15:38:38.79
COBOLのEVALUATE文はそんなんだけどなぁ。

73 :仕様書無しさん:2012/06/10(日) 15:48:48.15
Perlも>>67みたいなことできるよね。

74 :仕様書無しさん:2012/06/10(日) 22:01:27.60
数学は科学の女王

75 :仕様書無しさん:2012/06/10(日) 23:35:43.73
スリーサイズは?

76 :仕様書無しさん:2012/06/11(月) 01:08:49.91
B: π
W: e
H: i

77 :仕様書無しさん:2012/06/14(木) 00:00:39.90
イラッつ

78 :仕様書無しさん:2012/06/14(木) 00:37:26.40
実際、ゴミみたいなコード書いてイラっつとさせる奴って数学的センスがないよな

79 :仕様書無しさん:2012/06/14(木) 00:39:35.27
でも動くし

80 :仕様書無しさん:2012/06/14(木) 01:27:01.99
そこ言葉にこそイラッつとするわ
まあ俺の周りにそれを言い訳にするやつが多いからかもしれんが・・・

メモリリークしてんのに「でも動くし」で片付けたのはさすがに呆れた

81 :仕様書無しさん:2012/06/14(木) 02:09:06.00
「そこ言葉」にこそイラッつとするわ

82 :仕様書無しさん:2012/06/14(木) 06:58:03.94
あとでまとめて直すから!

83 :仕様書無しさん:2012/06/16(土) 00:02:58.08
なぜか、どんどん空行を詰めていく奴がいるのだが
理由は不明

84 :仕様書無しさん:2012/06/16(土) 03:12:57.42
比較で=をひとつ書き忘れて代入にしてしまう奴ってVB厨だろw

85 :仕様書無しさん:2012/06/16(土) 03:15:29.89
>83
逆に無駄に空行入れまくるヤツも居るんだよなあ

86 :仕様書無しさん:2012/06/16(土) 07:22:22.00
>>85
具体例で議論しようか?

87 :仕様書無しさん:2012/06/16(土) 08:16:19.51
>>85
俺の経験上、空行を無駄とか言ってる奴のソースは大抵クソ。

88 :仕様書無しさん:2012/06/16(土) 09:57:52.36
関数分ける程じゃない処理ブロックごとに空行入れるとかはやるな。
最近は中カッコで関数内を区切ったりもする。

89 :仕様書無しさん:2012/06/16(土) 11:09:46.45
>>85
お前には無駄に見えるだけ
てか、空行全くなしで書く奴とかまれにいるんだけど、むかつくわ

90 :仕様書無しさん:2012/06/16(土) 11:22:08.24
実際にコード見てみないと「無駄な空行」がどれくらいなのかわからんね

91 :仕様書無しさん:2012/06/16(土) 11:23:15.18
>>88
意図の判るスコープだったらいいが、意味不明なスコープだったらイラッつとくる。


92 :仕様書無しさん:2012/06/16(土) 11:27:13.36
とりあえず、2行以上の空行はいらんな。

93 :仕様書無しさん:2012/06/16(土) 12:14:08.75
チーム内でインデントにタブ文字使う派とスペース使う派が混在してるとけっこうウザい

94 :仕様書無しさん:2012/06/16(土) 14:15:44.35
>>89
空行なしで書けない奴は下手

95 :仕様書無しさん:2012/06/16(土) 15:00:02.13
>>94
曲芸やってるんじゃないんだから、他人が読みやすいように考えろ
大体お前、毎日ケアレスミスのバグ発見されてるだろ
へらへらしながら「スイマセンスイマセン」連呼してるの傍で見てると
顔面パンチくれたくなるんだよブス

96 :仕様書無しさん:2012/06/16(土) 15:05:07.52
>>95
おまえのレベルが低いのはわかった。
次の方どうぞ

97 :仕様書無しさん:2012/06/16(土) 15:06:56.60
>87,89
1行や2行まあ3行なら全然OK
むしろ適度に入れてくれたほうがいい


特に意味もなく10行規模で大量に入れて読みにくくするのを無駄と言って何がおかしい?

98 :仕様書無しさん:2012/06/16(土) 15:07:30.70
他人の読みやすさのための手段が
空白行という発想の時点でしれてるな
要は下手くそ

99 :仕様書無しさん:2012/06/16(土) 15:10:23.34
>>97
理由を考えてみよう

・いやがらせ
・使っている開発ツールのエディタが勝手に入れた
・ファイル分割せよという無言の意思表示
・馬鹿には見えないコード
・君が好きだ

100 :仕様書無しさん:2012/06/16(土) 15:13:03.65
>>99
あれ、あぶりだしだよ
知らない奴結構いるんだな

101 :仕様書無しさん:2012/06/16(土) 19:52:06.40
>99
本人に聞くと「ざっとスクロールしたときに修正した箇所をすぐ見つけられるようにしている(キリッ)」だそうで
馬鹿だということは理解した
一応上司なんで流石にウゼエとまでは言えなかったがコミット前に消すようお願いした

102 :仕様書無しさん:2012/06/16(土) 20:06:26.77
そもそもスクロールが不要なように書け・・・・と言いたいが、
たとえばクラスソースはメンバ関数のソースがだらだら並ぶ

どうすれば

103 :仕様書無しさん:2012/06/16(土) 20:12:35.23
まともなエディタ使え。

104 :仕様書無しさん:2012/06/16(土) 20:19:53.95
スクロール不要なソースなんてほとんどねーわ。

105 :仕様書無しさん:2012/06/16(土) 20:23:05.03
今時たいていのエディタもIDEも折り畳みできるだろ

106 :仕様書無しさん:2012/06/16(土) 20:36:48.29
結局折りたたみか・・・・
もっと未来的なすごい何かはないのか

107 :仕様書無しさん:2012/06/16(土) 20:47:36.64
eclipseだとアウトラインプロセッサ的なツリー表示あるじゃん
あれでいいんじゃないの
統合環境じゃなくテキストエディタでできるソフトは知らないけど

108 :仕様書無しさん:2012/06/16(土) 20:54:10.87
昔80x24文字のスクリーンエディタでコード書いてたときは、
関数の頭の行が 1 + 24n 行めにくるように関数の末尾に空白を入れて調整する奴はいた

109 :仕様書無しさん:2012/06/16(土) 21:00:11.29
private string foo(){
string str = hogehoge();
#region スクロールしたときに修正した箇所をすぐみつけられるようにした、俺様用しおり


















#endregion
return str;
}

110 :仕様書無しさん:2012/06/16(土) 21:01:36.88
if(ここにものすごく長い条件式){[TAB][TAB][TAB]//コメント

 ・・・・・・・・・・・・・・・・・・・・・・・・

}else if(ここも長い長い長い長い長い長い条件式){//コメント

 ・・・・・・・・・・・・・・・・・・・・・

}else{[TAB][TAB][TAB][TAB][TAB][TAB][TAB]//コメント

 ・・・・・・・・・・・・・・・・・・・・・

}



嫌だ!!!!


111 :仕様書無しさん:2012/06/16(土) 22:59:54.46
>>110
自分なら、こう書く /* TABの個数はコメント開始の桁をそろうように合わせる */

if ([TAB][TAB]//コメント
  ここにものすごく長い条件式
) {

 ・・・・・・・・・・・・・・・・・・・・・・・・
} else if ([TAB]//コメント
  ここも長い長い長い長い長い長い条件式
) {

 ・・・・・・・・・・・・・・・・・・・・・

} else {[TAB]//コメント
 ・・・・・・・・・・・・・・・・・・・・・

}

112 :仕様書無しさん:2012/06/16(土) 23:12:21.05
行頭のインデント以外でTABを使う奴にイラッつとくる

113 :仕様書無しさん:2012/06/16(土) 23:15:41.14
if () {
  // ※
  ・・・・・
} else {
  // ※
  ・・・・・
}

114 :仕様書無しさん:2012/06/16(土) 23:19:27.30
俺はelse ifを含む条件分岐はこう書いている
if (条件1) {
 処理1
} else
if (条件2) {
 処理2
} else
{
 処理3
}

ifの桁を揃えたいのが理由なんだが、見づらいだろうか?

115 :仕様書無しさん:2012/06/16(土) 23:51:33.14
>>114
見難いし
最後elseの{の位置がキモイ


116 :仕様書無しさん:2012/06/17(日) 00:11:36.19
>>113
コメントを行頭で揃えるなら、こんな感じかな

if (
  // コメント
  長い条件式
) {
  // コメント
  ・・・・・
} else {
  // コメント
  ・・・・・
}

>>114
二分岐(普通のif文)と多分岐(else if)との区別しづらいと思う

117 :仕様書無しさん:2012/06/17(日) 00:32:12.92
条件がifと同じ行から始まってないのはイラっとくるな

118 :仕様書無しさん:2012/06/17(日) 08:17:21.14
要はぱっと見てすんなりロジックが”入ってくる”か、違和感があるかの感覚なんだよな



なんだっけ、人種や文化に関わらず全ての人類が共通して持つ感覚
たしか学問的に名前があったと思うけど・・・・
(赤→攻撃的、とか、丸形→親しみやすい、とか)


119 :仕様書無しさん:2012/06/17(日) 09:06:23.73
長い条件式は関数にしろ。リファクタリングの基本だ

120 :仕様書無しさん:2012/06/17(日) 09:13:07.30
変数の名前が長いだけなの・・・

121 :仕様書無しさん:2012/06/18(月) 10:51:43.60
関数の名前も長いんですね

122 :仕様書無しさん:2012/06/18(月) 21:56:44.22
変数名や関数名は長くてもいいじゃん
変に短縮されるほうが困る

123 :仕様書無しさん:2012/06/18(月) 22:34:39.10
センスの問題だよな
イテレーターにiとネーミングしたコード見たらファックしたくなった

124 :仕様書無しさん:2012/06/18(月) 23:26:01.91
イテレータだからiでいいじゃないか。

125 :仕様書無しさん:2012/06/19(火) 03:52:18.66
素晴らしすぎて愛をもってファックしたくなったんだよ

126 :仕様書無しさん:2012/06/19(火) 04:38:30.03
長年やってきたが iter > it > i と変わったな
てか範囲forもっと使えるようにになってくれ



127 :仕様書無しさん:2012/06/19(火) 06:50:07.15
iは整数に使って欲しい
イテレータはitrとかにして

128 :仕様書無しさん:2012/06/19(火) 07:34:32.63
特にメリットを感じない俺様ルールにイラっつとした

129 :仕様書無しさん:2012/06/19(火) 09:37:21.71
それは愛のイテレーション

130 :仕様書無しさん:2012/06/19(火) 23:25:45.31
イテレータはiteだな。お手本がiteだったので

131 :仕様書無しさん:2012/06/19(火) 23:30:49.40
ずっと it にしてるなあ
itr はなんとなくウザったい(t→r のタイプがめんどい)けど i を使うのはなんかちょっと…派

132 :仕様書無しさん:2012/06/19(火) 23:49:26.59
習慣的にiはforループのカウンタにしてるからなんか気持ち悪くてitにするなあ。
なにかを指している→itみたいな意味も込めて

133 :仕様書無しさん:2012/06/20(水) 21:25:08.21
FOR_EARCH( i, destination_container )
{
  FOR_EARCH( j, source_container )
  {
     i.insert( j );
  }
}

134 :仕様書無しさん:2012/06/21(木) 00:14:57.97
Google Code Searchの生き残りで調べてみた
http://code.google.com/searchframe

検索式はこんな感じ(iter)
\Witer\s*=\s*\w+\.begin\(\s*\)

itr 75044
it 52320
i 37154
iter 23608
p 1830
ite 811

過半数には満たないがitrが流行のようだ。


135 :仕様書無しさん:2012/06/21(木) 00:33:49.20
>>134
どれでも意味はわかるから、どれでも構わないな
自分は i だが

136 :仕様書無しさん:2012/06/21(木) 02:03:05.78
こんだけ散けてればTOP4は容認せざるを得ないだろう

137 :仕様書無しさん:2012/06/21(木) 02:23:44.97
iteはマイナーだったんだな。

まあ、イテレーター使ってるやつが相当少ないのもあるが。

お手本になったコード以外で使ってるのほとんどみねぇ。

138 :仕様書無しさん:2012/06/24(日) 23:40:28.31
itor 1800

iter は、どうしてそう略すの?イテルって読むの? ってイラッつ。

139 :仕様書無しさん:2012/06/26(火) 09:10:59.97
ENUMerator→enumなんだから
ITerator→itに決まってる。

140 :仕様書無しさん:2012/06/26(火) 09:16:39.83
>>139
こういうわけわからん俺様ルールつくる奴にイラッつとくる

141 :仕様書無しさん:2012/06/26(火) 12:18:55.52
ちょっと納得しかけた自分にイラッつとした

142 :仕様書無しさん:2012/06/26(火) 15:05:58.26
UNIX系のGUIツールキットであるGTKの場合、
Iterator の 略語(変数名)は iter で統一されているみたいだね

あと it という単語は、一見して代名詞(this や that)とまぎらわしいと思う

143 :仕様書無しさん:2012/06/26(火) 15:28:59.21
省略するしないのラインは微妙だね。
iterator, array, index とか instance とか。

144 :仕様書無しさん:2012/06/26(火) 20:47:08.46
aDataとかiNumとかハンガリアン付けたがるオサーンばかりの職場だが
theって頭に付けてるやつは今日初めて見た
singletonなインスタンスとかにはonlyOneとかつけてたし

これ一体どこの流派だ?

145 :仕様書無しさん:2012/06/26(火) 21:07:12.42
theはマイクロソフトじゃないの?

CWinAppの派生クラスのオブジェクトはウィザードでプロジェクト作った段階の
スケルトンでtheAppってグローバルに宣言されてるよ。

146 :仕様書無しさん:2012/06/26(火) 21:33:31.09
>>144
今は亡きCマガの記事で見かけたことがある・・・
と思ったらWebで見れるのね

プログラミングの禁じ手(C言語版)
http://d.hatena.ne.jp/elwoodblues/20090206/1233878765

> 名前といえば,ハンガリアン記法という,暗号めいた名前を作り,型情報を名前の
> 一部にするという不思議な記法があります。ある大手のソフト会社の社員が提唱
> しているので有名ですが,同時に,同じ会社の社員から強烈に批判されていること
> でも有名な記法です。

中略

> 筆者は型よりも,むしろスコープ(通用範囲)を基準に命名規則を考えています。
> これは筆者がよく使うCode WarriorのPowerPlantというクラスライブラリで
> 採用されている命名規則をほとんどそのまま見習っているだけですが,参考まで
> に示しておくと,
> ・関数名は大文字で始め,変数は小文字で始める
> ・外部変数は「g」で始まる名前にする
> ・構造体(あるいはクラス)のメンバ変数は「m」で始まる名前にする
> ・自動変数は「the」で始まる名前にする
> ・引数は参照のみは「in」,書き換えをするのは「out」,両方あるのは「io」で始まる名前にする

なんか違和感あるのもあるな

147 :仕様書無しさん:2012/06/26(火) 22:38:05.14
static または private な関数は小文字で始めるという規約をテスト中

148 :仕様書無しさん:2012/06/27(水) 00:36:43.64
privateな関数名は小文字で始めるって規約あるある。
変数名と同じ表現になってイラっとした。

149 :仕様書無しさん:2012/06/27(水) 02:47:52.46
メンバ関数なら、スタック変数とは使うときの書き方が変わるから、同じ名付け方でいいと思うけどな

150 :仕様書無しさん:2012/06/27(水) 06:00:09.45
the はコードウォーリアのサンプルコードがそうなってた。
Smalltalk 方面の anApple とかからインスパイアされたんだろうが、単数か複数かならまだ情報も増えようが、the はノイズが増えてるだけに思う。
ただ、これをまねて、大文字の The はアプリケーション唯一のインスタンスに使うようになった。TheDictionary のように。

関数名と変数名の命名の差で言うと、関数は動詞始まりというのが昔あった。
動詞始まりというのは要するに関数名全体を命令形の節にしてしまうということだ。
英語で読み下せるプログラムを目指してた人たちがいたらしく、SQLとかそういうことだと思うが、今の obj.pred() 形式には合わないかもしれないね。
if ( container.Contains( item ) ) ...
みたいなのに名残はある。
これはたまたま珍しくきれいにハマる例だけど、なかなかきれいには命名できないね。


151 :仕様書無しさん:2012/06/27(水) 07:29:51.64
>>118
亀だが
集合的無意識だっけ?

152 :仕様書無しさん:2012/06/28(木) 00:39:08.18
引数はa_ 参照はrf メンバはm_ constはc_とかにしてるな。

右にどんどん長くなる。 フルHDじゃたりねぇ。

153 :仕様書無しさん:2012/06/28(木) 10:49:18.96
bool型変数へ代入するときや、bool型の戻り値を返す際の、
比較演算子・論理演算子使用禁止

そんなに中括弧が好きなのか、コーディングルール作成者は

154 :仕様書無しさん:2012/06/28(木) 12:34:06.86
>>153
つまりこういうのが禁止ってこと?

bool b = (x > y);
return x == HOGE;

155 :仕様書無しさん:2012/06/28(木) 15:09:02.43
ぶるっつ

156 :仕様書無しさん:2012/06/28(木) 15:49:00.51
>>153
デバッガでステップ実行したい、っていう理由で、そういう縛りがある客先があったなぁ。
三項演算子も使うなって言われたわ。

157 :仕様書無しさん:2012/06/28(木) 16:59:33.88
>>154
そうそうそれ

158 :仕様書無しさん:2012/06/28(木) 19:59:01.71
>>154
bool b = std::less<decltype(x)>()(y, x);
return std::equal_to<decltype(x)>()( x, HOGE );
でどうだろう?

159 :仕様書無しさん:2012/06/28(木) 21:10:05.62
すげぇイラッつとするなw

160 :仕様書無しさん:2012/06/28(木) 21:58:40.92
>>150
theとかってのはシステムハンガリアンじゃない本来のハンガリアンじゃないか?
あと、theってのは唯一じゃなくコンテキストに依存してるって意味だと思うぞ。

161 :仕様書無しさん:2012/06/28(木) 22:33:21.15
>>158
うぜぇwwwwwwwwww


162 :仕様書無しさん:2012/06/29(金) 07:41:12.39
>>160
>システムハンガリアンじゃない本来のハンガリアン
アプリケーションハンガリアンな


163 :仕様書無しさん:2012/06/29(金) 11:28:17.04
データ仕様書に「2の補数をとる」とあって、2の補数を計算するコードを真面目に書いた奴にはイラッつときた。

164 :仕様書無しさん:2012/06/29(金) 14:06:22.08
const int getIndex(void) const { return m_index; }
const int* const getArray(void) const { return &m_array[0]; }

キモッ

165 :仕様書無しさん:2012/06/29(金) 18:55:12.39
>>160
俺は定冠詞と解釈したんだが、アプリケーションハンガリアンだと the はどういう意味になるんだよ。
そして読み落としだと思うけど、「唯一」に関しては、「大文字の The」って書いてあることを確認してくれ。

166 :仕様書無しさん:2012/06/29(金) 19:10:02.03
>>163
1の補数マシンを想定してより完璧な移植性を取ったのでは。

167 :仕様書無しさん:2012/06/29(金) 20:52:58.11
>>165
Theだと、この前のアレとか、ニュースになってたアレとか、
文脈上で個が特定できるが、固有名詞が無いんで抽象的に呼んでるものを指すだろ。
ただ、文脈の主体が変わればTheが示してるものは変わるんだから唯一ってのはやっぱり変じゃね。

168 :仕様書無しさん:2012/06/30(土) 02:33:20.28
>>164
publicに変数置いてるやつに比べると、天と地の差がある。

もっともオレがそのコードみたら、アホが、publicに移動しないようにcppに移動させるけどな。

169 :仕様書無しさん:2012/06/30(土) 02:48:07.71
コメントが関西弁

170 :仕様書無しさん:2012/06/30(土) 12:55:06.84
コメントがハングル

171 :仕様書無しさん:2012/06/30(土) 15:48:21.87
>>170
イラッつとするより、反吐が出るな。

172 :仕様書無しさん:2012/06/30(土) 17:38:03.79
>>168
C++ならgetが付いてんのがキモいわ
go langとか新しい言語なら非推奨ですらあるのに

173 :仕様書無しさん:2012/06/30(土) 20:05:04.71
C++()じゃ命名規則ぐらいしか新しくできるとこないもんなwww

174 :仕様書無しさん:2012/07/01(日) 00:37:36.45
162 : 仕様書無しさん [sage] DATE:2012/06/30(土) 12:38:09.93

printf("%d", node->next->next->next->next->next->next->next->data);


163 : 仕様書無しさん [sage] DATE:2012/06/30(土) 12:59:45.09
>>162
そんなコードを書いた奴の後ろに回って、グーで殴りそう。

164 : 仕様書無しさん [sage] DATE:2012/06/30(土) 16:39:05.05
>>162
クソワロタw

175 :仕様書無しさん:2012/07/01(日) 01:29:20.50
>>172
省略引数があるから、GetとSetはつけなきゃマズイだろ。

176 :仕様書無しさん:2012/07/01(日) 01:44:33.71
Javaのbeanによる悪習を他の言語に撒き散らすなよ

177 :仕様書無しさん:2012/07/01(日) 01:46:31.26
Javaがもたらした最大の功績はJavaDocスタイルのコメントの普及

178 :仕様書無しさん:2012/07/01(日) 03:22:15.18
//! //< こういうやつだっけ。 あれなんかのツール使ってると意味があるのかね。

>>172はむしろ省略するならIndexの方だったな

179 :仕様書無しさん:2012/07/01(日) 03:33:41.79
>>164
>const int* const

const int*で十分だな
典型的なconst病

180 :仕様書無しさん:2012/07/01(日) 03:36:00.95
const int*

int *const

これ意味違うんだから意味あるんだぜ。

181 :仕様書無しさん:2012/07/01(日) 03:49:36.62
イラッ

182 :仕様書無しさん:2012/07/01(日) 04:04:38.28
>>179
うちも昔const病にかかってたわw

const char **a;
const char **const b;
const char *const *c;
const char *const *const d;

労力や可読性が犠牲になる割には見返りが少ないんで、
結局 a に落ち着いたw


183 :仕様書無しさん:2012/07/01(日) 04:48:51.80
>>180
後者を関数につける意味あんの?

184 :仕様書無しさん:2012/07/01(日) 08:57:59.90
typedef int *pint;
void foo( pint &&x );に渡せないとか?

185 :仕様書無しさん:2012/07/01(日) 15:25:45.16
>>183
関数もクソも戻り値だろうが。 ポインタとしての変更禁止と、ポインタが示す先の値の変更禁止で両方意味あるだろう。

意味を調べもしないでイラッつっとしてるとかまだまだゆとりだな。

186 :仕様書無しさん:2012/07/01(日) 16:41:34.15
>>185
変数だったら意味があるが、関数の戻り値の場合は
const int * でも const int * const でも差はない。
なぜならポインタ値はコピーされるから。
int x() でも const int x() でも差がないのと同じ。
お前こそちゃんと調べたほうがいいよ。

187 :仕様書無しさん:2012/07/01(日) 21:15:53.66
戻り値の受け型の指定だからコピーとか関係ないだろ・・・

188 :仕様書無しさん:2012/07/01(日) 21:51:48.21
>>187
>>164の「関数の戻り値の型」の話だろ
戻り値を受ける「変数」だったらそりゃ意味あるわい

189 :仕様書無しさん:2012/07/01(日) 22:44:10.62
恥かいたのをごまかしたいのか?

190 :仕様書無しさん:2012/07/02(月) 01:37:50.11
>>185
だから戻り値のアドレスを変更禁止にしてどうすんだ
バカだろお前

191 :仕様書無しさん:2012/07/02(月) 01:46:35.60
getArray() = &hoge[0];
こんなことができるとでも思ってるんだろ。
ポインタ覚えたての学生が鼻息を荒くして噛みついてみたってとこか。

192 :仕様書無しさん:2012/07/02(月) 01:56:13.42
>>183はイラッとしてるのか?
>>185のお子様臭が凄い

193 :仕様書無しさん:2012/07/02(月) 03:35:49.46
馬鹿晒しage

194 :仕様書無しさん:2012/07/02(月) 08:40:00.77
inst = GetInsutansu ();

朝っぱらから頭の痛いものが送られてきた
会社行きたくねぇなぁ・・・

195 :仕様書無しさん:2012/07/02(月) 09:54:29.86
ローマ字かww
ローマ字禁止って縛りは今まで経験したことがないが、やっぱり長ったらしい英単語を
つなぎ合わせた名前より、ローマ字で短くした方が判りやすいって思う人多いのかな。

196 :仕様書無しさん:2012/07/02(月) 16:11:39.72
>>192
バカは勉強すればいいけど、クズが上塗りされてる奴は本当にどうしようもないな

197 :仕様書無しさん:2012/07/02(月) 20:42:03.32
>>196 主張に御同意頂き恐悦至極

198 :仕様書無しさん:2012/07/02(月) 21:25:57.27
>>185
40前後のメガネデブ。
基本情報技術者の試験に3回以上落ちたことがあると見た。

199 :仕様書無しさん:2012/07/02(月) 22:17:14.92
5回ほど落ちましたが何か?

200 :仕様書無しさん:2012/07/02(月) 22:33:12.08
今、仕事でプログラムのメンテやってるんだが、ソースコードの酷い事。
マジックナンバーだらけだわ、同じコードの繰り返しがあるわ、意味不明な名前の変数があるわでもう・・・

コーディングの勉強をある程度やってきた人なら、それくらい駄目なことは分かるはずだが・・・
お陰で機能修正や拡張がすさまじく面倒。
でも、仕事だから嫌とは言ってられない。

ああ、明日も頑張ろう・・・・・

201 :仕様書無しさん:2012/07/02(月) 23:18:29.46
>>200
仕事でプログラミングするのは初めてなのかな?

これから先もずっと、そういうどうしようもないコードと付き合っていくことになるからね。

202 :仕様書無しさん:2012/07/02(月) 23:30:43.25
おれ、commandのこと、ずっとcommandoって書いてた

203 :仕様書無しさん:2012/07/02(月) 23:33:33.21
>>201
そう。
今年新人で入って初めてプログラミングの業務に就いたんだ。

当初は、企業ではもっとソースコードの管理に厳格なイメージを期待してたから、
そこから色々学ばなきゃという印象を持ってた。

学生時代には、エレガントなコードを書くよう、口を酸っぱくして言われてきたので、
なおさら愕然としちゃったね・・・・・
これも一つの勉強だと思って頑張っていこうと思う。

204 :仕様書無しさん:2012/07/02(月) 23:46:59.39
>>200
うちも似たような事やってるわw
どうにもならんのでリファクタしていらんコードとか
使ってないコードとか消して行ったら機能追加する前よりコードが減る減る
最近いかに行数減らすか楽しくなってきたよw

長くやってりゃいい事もあるさがんばれww


205 :仕様書無しさん:2012/07/02(月) 23:57:33.01
>>204
ありがとうございます

206 :仕様書無しさん:2012/07/03(火) 02:14:50.36
>>200
意味不明なコード
規約なし
書き方に一貫性なし
コメントなし
ドキュメントなし
テストなし

こんなのザラだ
気持悪くて鬱になりそうだ

207 :仕様書無しさん:2012/07/03(火) 04:26:20.54
そうやって自分では直したつもりなのに、バグを出して痛い目に遭うのが次の段階

208 :仕様書無しさん:2012/07/03(火) 06:20:57.69
そして自分ではエレガントだと思っていたコードがこのスレで叩かれるのが数年後

209 :仕様書無しさん:2012/07/03(火) 06:56:04.56
良いコード: 縦に短く、横に四角く
悪いコード: 縦に長く、横にとんがる(ifのネストが主な原因)

210 :仕様書無しさん:2012/07/03(火) 07:00:36.74
#define PREFIX "foo"




PREFIX".txt"←というリテラル文字列を使う



IDEが親切にSyntax Errorを警告してくれる
かたじけなくてとてもイラッつとする

211 :仕様書無しさん:2012/07/03(火) 07:33:19.72
気持ちは分かるが広く使われ過ぎているしエラーにもならんだろ。

212 :仕様書無しさん:2012/07/03(火) 11:46:14.08
>>200
悪いのはコーディングした本人でも無いことが多い
あなたにもそういうスタイルのコーディングを強制されることになるでしょう

213 :仕様書無しさん:2012/07/03(火) 11:49:20.87
>>204
リファクタリングが許されるようなところは、そもそもそうはならないレベルの職場と思ってたけどそうでもないんだな

214 :仕様書無しさん:2012/07/03(火) 12:01:25.81
そもそもリファクタリングしてるほど納期に余裕無い

215 :仕様書無しさん:2012/07/03(火) 23:40:24.84
主なリファクタリングの流れ

「あとでリファクタリングするから今は動けばいいや」

数年後

「なんだこのクソコードは」

リファクタリング

216 :仕様書無しさん:2012/07/04(水) 00:45:51.41
>>190
変更不可能の定数に意味はある。

217 :仕様書無しさん:2012/07/04(水) 00:50:34.82
>>216
変数なら意味があるのはみんな知ってるんだよ
関数の戻り値の型の話だっつってんだろ

218 :仕様書無しさん:2012/07/04(水) 05:57:31.24
そこをねじ曲げてゴリ押そうとしてるんだな
ゆとりとか言って煽った手前、引くに引けないんだろうが恥の上塗り
メガネデブ確定

219 :仕様書無しさん:2012/07/05(木) 00:12:02.67
for(int i = length - 1; i >= 0; i--) 流派と
for(int i = length; i > 0; i--) 流派と
for(int i = length; --i >= 0; ) 流派で社内派閥争いしてるんだが


220 :仕様書無しさん:2012/07/05(木) 02:03:31.91
惜しいな、俺は
for(int i = length; i > 0; --i)
派だ

221 :仕様書無しさん:2012/07/05(木) 02:27:53.42
> for(int i = length; i > 0; i--)
> for(int i = length; i > 0; --i)

ターゲットCPUによって使い分けるんじゃなくて、どちらかに統一するの?
何か理由があるのかね

222 :仕様書無しさん:2012/07/05(木) 02:31:29.12
>>219
不等号の向きにイラっとするのは目をつむるとして、
1番目と2番目はループの中でのiの使い方次第じゃね?

3番目は有り得ないだろ


223 :仕様書無しさん:2012/07/05(木) 06:05:00.06
>>221
前置にするのは c++ のクラスの場合に一時オブジェクトのコピーが発生しないようにするため。
int には関係ないが、教条主義的に前置に統一しても問題ない。

>>222
ありえないってことはないと思うが while にしろと思う。


224 :仕様書無しさん:2012/07/05(木) 08:23:49.49
>>223
iをブロックスコープの中に押し込めたいんじゃね?
whileでそれをやると{}がもう一段増えるだろ

225 :仕様書無しさん:2012/07/05(木) 12:19:03.59
>>223
一時オブジェクトのコピーが発生するかしないかはコンパイラやコンパイラの最適化条件によるだろ
アホかよ

226 :仕様書無しさん:2012/07/05(木) 14:12:12.83
>>225
おじいちゃん、もうご飯食べたでしょ

227 :仕様書無しさん:2012/07/05(木) 15:14:41.53
うん、おととい食べたばっかり

228 :仕様書無しさん:2012/07/07(土) 00:49:38.86
>>217
戻り値の型でも意味あんだろうが

229 :仕様書無しさん:2012/07/07(土) 00:54:27.57
ポインタのアドレス変更禁止とポインタの参照先の書込み禁止にマジで意味ないと思ってんの?
readオンリーのポートのアドレス返すのに使うだろ。

中途半端に片方にだけconstつけてもメモリ空間に割付られるだろうに。

230 :仕様書無しさん:2012/07/07(土) 00:56:31.33
>>186

231 :仕様書無しさん:2012/07/07(土) 01:14:00.38
>>229
アドレスとポインタの違い分かってるか?

232 :仕様書無しさん:2012/07/07(土) 03:46:14.34
分かってないから食い下がってるんだろ

233 :仕様書無しさん:2012/07/07(土) 17:22:25.42
>>225
どんだけCompilerが進歩しようと
組み込み型以外のPost Inclimentで一時変数作らんなんて無理だろうが
最速な方法でも一時Pointerに突っ込んどくぐらいしか方法がない

234 :仕様書無しさん:2012/07/07(土) 17:24:34.34
int *point = &abs( 100 );
*point += 10;
こんなんできたっけ?

235 :仕様書無しさん:2012/07/07(土) 17:36:02.99
>>233 register

つーか、組み込み型以外のPost Inclimentって何?
言葉作らないでほしいなぁ、まー、知ったか野郎によくあるパターンなんだけど

ところでInclimentのスペルが違ってるけど、大丈夫か?

236 :仕様書無しさん:2012/07/07(土) 17:47:04.01
Incrementだよな?
2カ所も違っててこれは恥ずかしいw

237 :仕様書無しさん:2012/07/07(土) 18:02:34.14
頭の中にClitorisの綴りが焼きついているのだろう

238 :仕様書無しさん:2012/07/07(土) 18:08:52.00
筆記体で書かないとスペルが怪しくなるおっさんが通りますよ?

昔は、筆記体で書ける→勉強できるカッコイイだったのに、いつのまにか
筆記体で書ける→古い世代

悔しい

239 :仕様書無しさん:2012/07/07(土) 18:13:31.09

         _人人人人人人人人人人人人人人人_
        >   そうなんだ、すごいね!      <
       ´ ̄^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^ ̄
            __、、=--、、         __
           /    ・ ゙!       /・   `ヽ
           | ・   __,ノ       (_    ・ |
           ヽ、 (三,、,         _)    /
            /ー-=-i'’       (____,,,.ノ
            |__,,/          |__ゝ
             〉  )          (  )


240 :仕様書無しさん:2012/07/07(土) 20:47:02.22
>>238
筆記体、スペル覚えやすかったよな
ブロック体で書くと間違うから書けなかった…

241 :仕様書無しさん:2012/07/07(土) 20:49:00.95
筆記体じゃないけどadministratorとかは
キーボードならすらすら打てるのにスペルを
口で伝えようとすると混乱する

242 :仕様書無しさん:2012/07/07(土) 20:52:46.20
>>235
registerがどうしたって?
register使おうが一時変数に突っ込まにゃならんことに変わりないだろ

243 :仕様書無しさん:2012/07/07(土) 20:54:48.66
>>237
Christrisがどうしたって?

244 :仕様書無しさん:2012/07/08(日) 13:02:32.00
>>242
ARMでも勉強しとけオッサンorボーヤ


245 :仕様書無しさん:2012/07/08(日) 20:45:47.93
ARMでC++がどんだけ普及してんだよ

246 :仕様書無しさん:2012/07/09(月) 09:10:03.52
iPhone や VITA では普通に使うし、十分だろう。
つーかもう新品売ってないし、D&Eで。

247 :仕様書無しさん:2012/07/09(月) 21:42:11.54
お前が組んでるのかって話だろ

248 :仕様書無しさん:2012/07/09(月) 21:43:23.92
>>244
詳しいんなら、あの三番地コードでどうやって
一時変数を消せるのか書いてみ

249 :246:2012/07/10(火) 10:09:54.94
>>247
普及がどうこういうのに、「お前が組んでる」がどう関係あるんだ。
ちなみに、俺の話ならどっちも組んでるよ。

そんで、The Annotated C++ Reference Manual
 http://www.amazon.com/dp/0201514591
ってのがあって、これが 244 の ARM ね。
その和訳 注解 C++リファレンスマニュアル
 http://www.amazon.co.jp/dp/4810180271/
は絶版なわけ。
で、今読むならC++の設計と進化
http://www.amazon.co.jp/dp/4797328541/
になるんだけど、これの略称が D&E ね。
って、こっちももう在庫ねぇし。

という共通理解があるからこそ 245 がボケとして成り立つわけだ。

250 :仕様書無しさん:2012/07/10(火) 21:01:55.63
>>249
お前がiteratorでポストインクリメントすることとそれになんの関係があるんだ?

251 :仕様書無しさん:2012/07/10(火) 21:07:03.14
>>249
>ちなみに、俺の話ならどっちも組んでるよ。
で、Post IncrementしたIteratorはどういうニーモニックを吐いてるんだ?
組んでるんだしコードで説明できるだろ早くしろ。
ちなみに、std::vectorじゃ意味ないんでstd::listを使った場合の
ニーモニックで説明してくれ。

252 :仕様書無しさん:2012/07/10(火) 22:11:20.77
>>249
てっきりこれの話かと思った
http://ja.wikipedia.org/wiki/ARM%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3

253 :仕様書無しさん:2012/07/10(火) 23:15:31.88
http://goo.gl/toasP
これか?どこのことを言ってるんだ?

254 :246:2012/07/11(水) 13:42:06.08
>>250-251
俺は 246 なんだけど。
君はどっちの立場で、どっちの言い分が分からないんだ?

ちなみに Xcode についてくる iPhone 向け stl のソースコードでの std::list::iterator の operator ++ のソースは
_Self&operator++() { _M_node = _M_node->_M_next; return *this; }
_Self operator++(int) { _Self __tmp = *this; _M_node = _M_node->_M_next; return __tmp; }
だよ。

255 :仕様書無しさん:2012/07/11(水) 20:19:53.81
>_Self operator++(int) { _Self __tmp = *this; _M_node = _M_node->_M_next; return __tmp; }
一時変数発生してるじゃねぇか

256 :仕様書無しさん:2012/07/11(水) 20:29:43.13
>iPhone や VITA では普通に使うし、(何が?)十分だろう。
>つーかもう(何の)新品売ってないし、D&E(C++の設計と進化)で。

主語がなさすぎるし、最後の一文が他とどうつながってんのかさっぱり判らん
そりゃ周りが混乱するわ

257 :仕様書無しさん:2012/07/12(木) 11:33:17.41
あれ?アセンブリまで下がったレベルの話でないの?
やっぱ、変な言葉作っちゃう知ったかはダメだなぁ

258 :仕様書無しさん:2012/07/12(木) 21:14:45.65
ARMったらNEONだとかThumbたとかそっちの話だと思うような…

259 :246:2012/07/13(金) 01:10:27.85
俺は 244 ではないし、一時変数のコピーを否定してない。
245 のボケを拾ったのと、ARM での C++ の普及について突っ込んだだけ。

260 :仕様書無しさん:2012/07/13(金) 05:29:52.97
>>259
じゃお前の書いたD&Eって何だよ

261 :仕様書無しさん:2012/07/13(金) 05:32:33.81
やっと帰れる

せうえば今日if(var=false)にであったぜ
何してくれてんだおっさん…

262 :仕様書無しさん:2012/07/13(金) 06:45:35.14
>>261
if(false=var) → コンパイルエラー

263 :仕様書無しさん:2012/07/13(金) 11:28:00.20
if(var=false)はwarningは出るんだけど
エラーにはならなかったな、ウチの環境だと。

大量のwarningに埋もれてたんで発見遅れたが。

264 :仕様書無しさん:2012/07/13(金) 13:52:26.71
>>263
if (var=false)はエラーにならないが(ただし動作としては想定外だろう)

if (false=var)はエラーになる。

変数に定数を代入出来ても、定数に変数を代入は出来ないだろう?

265 :仕様書無しさん:2012/07/13(金) 14:03:17.27
またその話題を繰り返すというのかw

266 :仕様書無しさん:2012/07/13(金) 16:35:07.05
それ以前に真偽値をわざわざ比較で聞くなよ、って話じゃないのか?

267 :仕様書無しさん:2012/07/13(金) 17:02:32.33
ぼくは左定数派ちゃん!
もうc++書かなくなったけどなー

268 :仕様書無しさん:2012/07/13(金) 20:39:41.92
左に定数つかうのってjavaで
if( "Hoge".equals( str )) ...
の時だけだろ。

269 :仕様書無しさん:2012/07/13(金) 21:25:13.13
両方とも定数っての見たことある

270 :仕様書無しさん:2012/07/14(土) 08:50:37.22
PHPで本番環境と開発環境で別々の文字列をdefineしてる場合に、定数同士で比較して環境により分岐させることはある。

271 :仕様書無しさん:2012/07/14(土) 17:24:25.08
エラーにならないなら同じ変数を比較することがあるな
NaNを調べるのはそれが一番手っ取り早い

272 :仕様書無しさん:2012/07/14(土) 18:29:35.08
自己流のスタイルにこうでいする奴にろくなのがいない

273 :269:2012/07/14(土) 23:09:25.92
うちのはそんな高尚な理由ではなくて、
最初は
If Hoge(fuga) = 7 Then
だったのが、さまざまな改修を経た結果、よく見るとHoge()関数の戻り値が常に7であることが判明
Hoge関数を全部7に置換した結果
If 7 = 7 Then
両方とも定数のIf文のできあがりw


274 :仕様書無しさん:2012/07/14(土) 23:11:55.88
マジでそんなコード存在してるのか...

275 :仕様書無しさん:2012/07/14(土) 23:14:07.87
常に0とか常にtrueならまだしも、常に7を返す関数とはいったい……。

276 :仕様書無しさん:2012/07/14(土) 23:24:20.57
cやperlみたいな定数を持たない言語では関数で定数を表現することがある。
ていうか昔のperlのマニュアルにはシンボル使うよりも高速って書いてあったくらいだし(うろおぼえ)

277 :仕様書無しさん:2012/07/15(日) 02:19:49.15
>>273
今の実装ではHoge(fuga)はたまたま常に7を返すけど、
本来のHogeは7以外の値を返すこともある関数
だったりしないか?

278 :269:2012/07/15(日) 09:50:41.45
>>274
残念ながら存在するんだ。
このIf文消しちゃうとコードチェックの範囲が広がるってんでそのままにしたらしい。
Else以下も普通に残ってる。
>>275
もとはfugaの値から判断していくつかの値を出していたんだけども
平成15年ぐらいからその判断が意味をなくしていたらしい。
>>277
年度ごとに判断内容を切り替えていたらしい。
でも平成15年以降はどう考えても7しか返せないようになっていて、
システム全体で過去の処理は行えないようになっているので
今となっては何を聞かれても7としか答えないアホの子みたいな関数になってました。


279 :仕様書無しさん:2012/07/15(日) 10:29:06.23
よくわからんのだが、それなのになんでわざわざ関数を定数に置き換えたの?

280 :仕様書無しさん:2012/07/15(日) 10:50:25.41
後々のためにコード内に過去の実装をそのまま残すとか、もうやめてほしい
どうせ数ヶ月もすれば何が書いてあったかなんて作業者本人すら覚えていないんだから
コメントアウトを外すよりも一から作り直したほうが安全で速いだろ

281 :仕様書無しさん:2012/07/15(日) 12:39:56.48
>>279
だよな・・・
わざわざ関数を定数に置き換える理由がわからん

282 :仕様書無しさん:2012/07/15(日) 13:01:00.95
こうしてソースコードにおけるトマソンがまた一つ出来上がるのであった

283 :仕様書無しさん:2012/07/15(日) 13:12:27.53
>>282
『トマソンコード』

( ・∀・)イイ!!

284 :仕様書無しさん:2012/07/15(日) 16:01:32.04
ファッション業界見習って無駄なコード追加しよう

285 :仕様書無しさん:2012/07/16(月) 20:38:51.90
>>275
constの無い言語で定数を定義してる場合7だけ返す関数とかありうるな。

Resize( ShowLimit() /* 7 */ );

286 :仕様書無しさん:2012/07/17(火) 14:42:05.00
このスレのせいで他人のコーディングスタイルにイラッとすることが増えた気がする。
コードの解析が進まなくなっちまったでねぇかw

287 :仕様書無しさん:2012/07/19(木) 19:32:36.10
>>278 歴史や理由があるなら、許されると思う。
結構高級な悩み。

288 :仕様書無しさん:2012/07/30(月) 02:23:54.85
このスレに出てくるイラッっとさせるコードを生み出してる人たちって、
フォーマッターとか使わないで手作業でコードスタイル修正してる人たちばっかりなん?
アホみたいな作業は自動化してしまうような時代に、原始的すぎだって指摘してやろうぜ

289 :仕様書無しさん:2012/07/30(月) 02:30:52.36
あー、変数名とか左辺右辺とか、フォーマッターとかでどうしようもない問題もあるか…
ちゃんと見てなかったわ

イラッっとするのは、名前がつけれる処理をprivateメソッド化してない多機能メソッドだなぁ
20行越えるやつとか、保守時に機能の分析にかける時間がめんどくさくてしゃーない

290 :仕様書無しさん:2012/07/30(月) 17:01:51.55
"つけられる" を "つけれる" って書かれるとすっげーイラッつとするわ
「つけれる《ら抜き表現》」って出なかったか?

291 :仕様書無しさん:2012/07/30(月) 17:13:48.82
>>290
もうすでに人口に膾炙してる言い回しを、いちいち指摘する奴にいらつくわ

292 :仕様書無しさん:2012/07/30(月) 23:19:53.42
ら抜き言葉を使う奴はあんまり見ないな
日雇いのバイトとか清掃婦とかが口にするけど
深く関わろうとも思わん

293 :仕様書無しさん:2012/07/31(火) 10:47:42.75
>290
『つけられる』だと『つけることが可能』と『つけられてしまう』の2種類の解釈が可能で紛らわしいから、
ら抜き言葉で使い分けるのは言葉の進化だとする主張もあるぞ。

294 :仕様書無しさん:2012/07/31(火) 13:01:51.14
言い訳に必死だな

295 :仕様書無しさん:2012/07/31(火) 14:37:13.25
イラッつとする日本語スタイルのスレはここでつか?

296 :仕様書無しさん:2012/07/31(火) 20:02:03.77
コメントの日本語がおかしいとすごく気になるよな
特定のテクニカルタームに複数の訳語とか

297 :仕様書無しさん:2012/08/01(水) 00:15:51.27
SCSI インターフェース
TCP プロトコル
COBOL 言語
DLL ライブラリー

298 :仕様書無しさん:2012/08/01(水) 10:57:47.11
VB6厨はどうにかしたほうがいいのかと思う。
Boolean型変数Hogeで
If Hoge = False Then Hoge = True
こんなIf文があると書いたやつを小一時間問い詰めたくなる。

299 :仕様書無しさん:2012/08/01(水) 22:01:56.30
それjavaにもいますから。

いますから・・・。

頼むからこんな低レベルなことコードレビューで指摘させんな

300 :仕様書無しさん:2012/08/01(水) 22:16:56.98
>>299
javaでBoolean(先頭大文字)ならnullも取り得ることお忘れ無く。

301 :仕様書無しさん:2012/08/02(木) 00:48:08.57
お忘れ無く。 (キリッ
じゃねーよw
それはそれで突っ込みどころ満載だわw

302 :仕様書無しさん:2012/08/02(木) 08:01:22.57
>>297
頭字語の元になった単語と重複するからと
名詞を分解したがる奴を思い出した
NEC社製はNE社製になるんかいといじったら収まったが

303 :仕様書無しさん:2012/08/02(木) 08:08:07.27
>>302
こういうふうに的確な突っ込みをくれるといいのだが
たいていは「なんとなく」「いままでそうだったから」

だから、イラッつとされようがなんだろうが俺は沈黙しない

304 :仕様書無しさん:2012/08/02(木) 08:54:47.79
ターミナル駅

305 :仕様書無しさん:2012/08/02(木) 09:19:20.35
Kinkakuji Temple
Biwako Ohashi Bridge
Inawashiroko Lake

標識にはよくこう書いてあるよね

306 :仕様書無しさん:2012/08/02(木) 10:47:53.69
〜寺、〜橋、〜湖までを含めて固有名詞扱いなのかな

307 :仕様書無しさん:2012/08/02(木) 18:48:49.34
ちょっと亀なうえに流れを読まずに恐縮だが、
ら抜き言葉が発生する理由の学術的説明らしきものが
「日本人の知らない日本語」の2巻で説明されていた

説明のところはやや文字が多いが基本漫画なので
読んでみてもらいたい

308 :仕様書無しさん:2012/08/02(木) 19:57:18.11
ステマとか言うヤツは無視してリンク貼れや
でもアフィリエイトは勘弁な!

309 :仕様書無しさん:2012/08/02(木) 19:59:56.01
>>283



バケツウラン方式
=「あとで問題が発生する可能性も確率論的になくはないかもしれないけれど、とりあえず早いからやっちゃえ」

310 :仕様書無しさん:2012/08/02(木) 20:42:45.46
>>302
NEC製でよくね

311 :仕様書無しさん:2012/08/05(日) 20:11:51.50
TWO==じゃねえけどよぉ
比較する方をIF文で最初にもってくる奴ってまじいらつく
俺はそんなコードを引き継いでも絶対同じにしねーからな
後任者が困る?んなの関係ねー!!

312 :仕様書無しさん:2012/08/05(日) 22:55:38.61
>>67
遅レスだが、true/false は件の環境では実装されているようだぞ?
case: true だの case: false だの書いてるから。

このコードが悪い点は、
a == 1 が成立したか否かを見るのではなく、a == 1 が「成立『しなかったどうか』のブール値を見る」という、
かなり後でメンテする人間にやさしくない書き方をしていること。

このケースだと、case 文中の true と false をひっくり返して switch (a == 1) と書き換えたらすごくわかりやすくなる。
さらに進んで、
case 1:
default:
のように書けば switch (a) と書いたり、if 文に書き換えれば良し。というかそう書くべき。

313 :仕様書無しさん:2012/08/05(日) 23:07:02.97
>>264
その書き方は古い。そんなのはコンパイラに「if 文中に代入があるけどおk?」言わせればいい。
言わないコンパイラを使ってる?捨ててしまえ。

>>268
if (str.equals("Hoge")) {
じゃないの?

>>306
その通り

314 :仕様書無しさん:2012/08/05(日) 23:18:17.48
>>313

str.equals("Hoge") はstrのnullチェックに一手間要るのよ。

315 :仕様書無しさん:2012/08/05(日) 23:26:45.01
>>314
待たれよ。
ということは、その str はどこの馬の骨か分からんメソッドから渡された引数なのか?
ならば呼ばれた時に null チェック。
自分が呼んだメソッドが null を返すかもしれない、というなら即座に null チェック。

信用できないやつから呼ばれた、もしくは信用できないやつを呼んだ、でなければ基本的に null チェックは不要だと思う。
しかもそのチェックをやり過ごすためにコードスタイルがおかしくなっては元も子もない。

316 :仕様書無しさん:2012/08/06(月) 00:01:00.91
引数のnullチェックをするかどうかは、nullを許容する仕様なのかどうかによるだろうが。

317 :仕様書無しさん:2012/08/06(月) 01:33:03.86
javaの悪習の一つだし、文字列リテラルを左においてequalsは使わないな
見た目がイマイチってのもあるけれど、
一番の理由は、それはnullがあるケースを想定してそうしたのか
本来はnullである事はバグなのに、それを無視して動作するように書いてる
(もしくは単に何も考えてないのか)が、コード上からだけでは判断つかないから、基本的にやらない

nullが来ることも想定してるのなら、コード一目見てすぐわかるよう、
nullのチェックはnullのチェックでちゃんと明確にわかるようにコード書くわ

コメントでも事足りるけど、コメントは保守されないことが多いし、
コードで表現できる情報ならそれはコードで表現したほうが確実

318 :仕様書無しさん:2012/08/06(月) 03:05:09.96
>>316
よるが、でも if 文内で逃げるようにはしないのが普通。
引数を受け取った直後にチェックするか、戻り値が帰ってきた直後にチェックする。

>>317
まさしくその通り。
素晴らしいレスだ。

319 :仕様書無しさん:2012/08/06(月) 08:03:08.17
チェックする理由がある箇所でチェックすればいいだろ?
nullを許容するのであれば当然nullチェックは記述しないが、
それで意図がわからないとするならどう書くんだ?

例えばこんな処理で、

foo.f( bar.g() );

bar.g()の返値がnullの可能性があってfoo.f()がnullを許容する場合でも
こんな風に書くのか?

G g = bar.g();
if ( g == null ) {
 foo.f( g );
} else {
 foo.f( g );
}

320 :仕様書無しさん:2012/08/06(月) 08:08:43.25
>>319
話の本筋には関係ないが、こういうのはこう書きたい
if (条件) 処理A;
else 処理B;

ただし
・条件は静的でABともにワンフレーズ
または
・条件で関数を呼ぶが、ABでは代入のみ
な場合だけ(デバッグ作業対策)

321 :仕様書無しさん:2012/08/06(月) 08:53:11.83
if 文でブレス省く記述はイラッとくるスタイルの筆頭だな。

322 :仕様書無しさん:2012/08/06(月) 12:16:15.25
”縦長の”五行を二行で済ませるんだからいいだろ

323 :仕様書無しさん:2012/08/06(月) 12:27:11.26
省くなら全部省いて欲しい。

見たらイラッつとするだろうがw

324 :仕様書無しさん:2012/08/06(月) 22:35:33.97
>>320
いらん括弧は省く派だけど、
インデントするのが標準じゃないかなぁ

if (条件)
  処理A;
else
  処理B;

でもガード節だけはこう書く

if (条件) return;


325 :仕様書無しさん:2012/08/07(火) 00:11:12.15
>>322
>>324
要は自分が最初に書くときの都合しか考えてないってことだろ。
だから、メンテのために後からいじる人がイラッとする。

326 :仕様書無しさん:2012/08/07(火) 00:43:15.96
>>325
そのためにコーディング規約を作るんだろ。
括弧の有無くらいIDEのオートフォーマットがあれば困ることもないけどなー


327 :仕様書無しさん:2012/08/07(火) 01:19:48.26
>>326
>コーディング規約

この人は何を言い出すのん。
スレタイを見てないのか見ても意味が理解できないのか、
あるいは、額面通りの言葉から演繹して考える思考力が無いのか。

328 :仕様書無しさん:2012/08/07(火) 12:50:15.35
>>324
自分も同じだ

>>320
デバッグ用途ならコードレビューでも無視するよ
ただし、それがコード上で明確に表現されている場合に限るけど
たとえばC言語なら、#ifdef DEBUG .... #endif で囲むべき

329 :仕様書無しさん:2012/08/07(火) 20:06:16.42
String data = null;
data = xxx.getXXX();

その宣言時のnullはなんなのかと
初期化がないならまだ許せるが...

330 :仕様書無しさん:2012/08/07(火) 20:39:18.38
>>329
null どころか "" やら new String() で初期化してるやつもいたぞ
そいつはクラス型は全部
AAA aaa = new AAA();
aaa = bbb.getAAA();
みたいにしてやがった

331 :仕様書無しさん:2012/08/07(火) 23:19:21.87
C#だと初期化しないとビルド時にVSに怒られるんでやってます・・・

332 :仕様書無しさん:2012/08/08(水) 05:25:59.08
>>331
宣言時に値が決められるのなら宣言と同時に入れておけ



333 :仕様書無しさん:2012/08/08(水) 06:33:25.05
宣言時に明らかにダミーと分かる奴で初期化されてるのはちょっとイラッつとした。

$userId = "user_id";

みたいな

334 :仕様書無しさん:2012/08/08(水) 06:47:09.36
このスレで分った事
慣れとか見た目でコーディングスタイルを決めちゃう人は言い分けが上手い

335 :329:2012/08/08(水) 07:18:38.79
>>330
あるある過ぎて泣けるわ

336 :仕様書無しさん:2012/08/08(水) 12:23:38.02
>>329
String data = null;

data = xxx.getXXX();
の間にコードが入れられた時のための予防策

337 :仕様書無しさん:2012/08/08(水) 14:11:19.64
try catch のせいで宣言と同時に初期化できないこともある。
Java7のtry-with-resourcesでマシになったんだけど、Java7を使わせてもらえねー。

338 :sage:2012/08/09(木) 22:41:31.77
If Hoge = 1 Then
・・・
ElseIf Hoge = 2 Then
・・・

orz

339 :仕様書無しさん:2012/08/09(木) 23:16:21.34
>>336
String data = xxx.getXXX();

入れられようが無いよね

340 :仕様書無しさん:2012/08/10(金) 00:36:55.85
javaではやらない(どうせフォーマッターが保管してくれる)けど、
別の言語で{}の省略は割と多様しちゃってる
使うのは、基本的に処理が増えるようなところじゃないから、問題になることはないんだけど
やっぱ直さないとだよなー…

変数名の長さがアレで、フォーマット後の折り返し位置に納得がいかない場合とかに
宣言と代入を分けることあるな。でもその場合は無駄な初期化はしない。
まぁ、基本的には宣言と代入は同時にやるけどな

>>337
それなー
java7どころかいまだにjava5のプロジェクトとかあってハゲそう
interfaceの実装に@Overrideつけるとコンパイルできないとかないわ…

341 :仕様書無しさん:2012/08/10(金) 00:45:57.33
最近職場で見るイラっとするコーディングスタイル

if( test==test ){
  hoge();
}
else{
  hage();
}

式の前後に入ってるホワイトスペースとか、
ifのあと中括弧の前のホワイトスペースがないあたりが落ち着かないけど
そんなことより else 前後、ほかはまだ我慢できるが、テメーはだめだ!

342 :仕様書無しさん:2012/08/10(金) 01:08:53.64
ただの好みの問題だな。

if elseif else 辺りのそれぞれの条件にコメント入れようとすると
地味にどう書くか悩むw

343 :仕様書無しさん:2012/08/10(金) 02:41:13.69
>>341
わかるwww

if (expr) {
  ;
} else {
  ;
}

こっちが好きだけど
else if だとこうしちゃうな・・・変かな?

if (expr) {
  ;
}
else if (expr) {
  ;
}


344 :仕様書無しさん:2012/08/10(金) 07:20:53.84
elseで改行しないメリットがわからんのだが
コメントも入れづらいし、処理の括りが分かり辛いだろ

345 :仕様書無しさん:2012/08/10(金) 07:29:18.52
おれは、こういうのでイラッつ

if[TAB](条件){[TAB][TAB][TAB]//コメント
処理
}



>>341
何べん見ても笑えるw

346 :仕様書無しさん:2012/08/10(金) 08:18:52.65
>>341
else以下が不要になったときコメント化しやすいとか
IDEの機能使ってコメント化している人ってそういう書き方する
のを見かける。

347 :仕様書無しさん:2012/08/10(金) 08:44:14.47
>>346
こう消せばいいだろ

if( test==test ){
  hoge();
//} else{
//  hage();
}


348 :仕様書無しさん:2012/08/10(金) 09:19:50.39
>>344
うーん・・・たぶんメリットはないな・・・w
K&R or BSDのスタイルに見慣れてるからってのが大きいかな。


349 :仕様書無しさん:2012/08/10(金) 10:01:19.50
>>346
そういう、コメント化されたコードが残ってるのを見るとイラットする。

350 :仕様書無しさん:2012/08/10(金) 10:43:11.13
>>347
場合によったら ifの } 探しで疲れそうだからそれはやめて欲しいw

351 :仕様書無しさん:2012/08/10(金) 19:36:54.90
>>350
エディタやIDE に探させればよい。

うちのエディタはコメント内の { } もカウントしてしまうから
// if (oldCondition) {
if (currentCondition) {
というようなありふれたコメントアウトで対応が取れなくなってイラっつ。

352 :仕様書無しさん:2012/08/10(金) 21:38:53.89
>>341
そのイラっとするスタイルは昔(1980年代)から目にしていたよ
おそらくは当時のC入門書であった「はじめてのC」の影響が大きかった
当時はUNIXワークステーション全盛時代でアプリ開発に大量の新人が投入された
その部署で使われたテキストが「はじめてのC」だった

自分がいたのは通信ドライバ部門だったので「プログラム言語C(K&R本)」だけどね
新人の立ち上げには苦労するけど、最初からK&R本で学ぶことは正解だと思う
「三つ子の魂 百までも」と言われるように、最初に出会った本の出来不出来によって
コーディングスタイルにおける感性(美的感覚)の基礎レベルが決定される

353 :仕様書無しさん:2012/08/11(土) 12:36:12.04
ブロックのブレースを条件と同じ行に置く奴は
何が嬉しいのかよく判らん。対応が見づらいし
ちょっとしたコメントあうともだるい。
そんに1〜2バイトが惜しいのか。

//if( x )
{
}
//else
{
}


354 :仕様書無しさん:2012/08/11(土) 13:05:53.08
バイト数が惜しいんじゃなくて行数が惜しい。

355 :仕様書無しさん:2012/08/11(土) 13:37:25.90
郷に従ってるよ
郷の方が統一されてないことがほとんどだが、その時は好きに書く

356 :352:2012/08/11(土) 13:48:31.24
>>353
予約語 if の後に空白が無く小カッコの両内側に空白を入れるスタイルにイラっとする
 X: if( x )  O: if (x)
これを含めて、ブロックのブレースを条件と同じ行に置くのは、
書籍「プログラミング言語C」(K&R本)に沿ったスタイルだからというのが理由
このK&R流儀は1980年代から続く古典的なスタイルだ
もちろんスタイルは(明確な理由があれば)時代と伴に変化があるものかもしれない
でも、わざわざその伝統を捨てる理由が(少なくとも自分には)見当たらない

357 :仕様書無しさん:2012/08/11(土) 14:13:13.24
a=10*-*n+(p+v)
が読みづらい

a = 10 * -*n + ( p + v )
なので式に空白を入れるようになる

if( ( p + v ) > 0 )
式に空白を入れるようになると一貫性があるので
丸カッコの中に空白を入れるのが当たり前になる

if ( ( p + v ) > 0 )
既にカッコに空白が入っているので
制御文の直後に空白が入ってんのが気持ち悪くなる
また、単行演算子はくっつけるので
ifを単行演算子と見なせば一貫しているように見え自然になる

358 :仕様書無しさん:2012/08/11(土) 14:26:48.54
>>356
そういうのを見ると、ああ、この人はちゃんと勉強してないんだな。
フリーソフトのソースも見ていないんだなって思うね。
あ、でもGNUスタイル。てめーはだめだw


359 :仕様書無しさん:2012/08/11(土) 16:02:21.38
>>357
単項演算子?

360 :仕様書無しさん:2012/08/11(土) 16:09:47.02
>>357
>a = 10 * -*n + ( p + v )
>なので式に空白を入れるようになる
a = 10 * -*n + (p + v)
で十分なので
>式に空白を入れるようになると一貫性があるので
>丸カッコの中に空白を入れるのが当たり前になる
はおかしい。

361 :仕様書無しさん:2012/08/11(土) 16:13:48.53
>>359
 -( p + v )
 if( p + v )
  !( p == v )
while( p == v )

362 :仕様書無しさん:2012/08/11(土) 16:35:28.68
>>359
if や while といった予約語は「文(statement)」を構成する要素であるにもかかわらず、
それを単項演算子に見えるのが変だということじゃないのかと

以下のような例ならOKだと思うけど

a = c ? x : y;  /* ? と : はC言語の三項演算子 */

a = if c then x else y  # Rubyだと if は式を構成する要素



363 :仕様書無しさん:2012/08/11(土) 17:02:54.40
うろおぼえごみん
bool b = (a > 100) ? false : true;
刺したくなった。


364 :仕様書無しさん:2012/08/11(土) 17:15:18.58
PEP8に「括弧の内側に空白入れる奴はバカ」って書いてあったから入れないことにした

365 :仕様書無しさん:2012/08/11(土) 19:01:15.49
ifの後ろに空白は入れないな。

でも、今の仕事でEclipse使ってて、自動成型で空白入るから
最近はどっちでも違和感無く書けるようになってきた。

if /*(p+v)*/ (p-v) {}

みたいに書く気があるなら空白入れるのもいいのかもw

366 :仕様書無しさん:2012/08/11(土) 19:04:09.55
a = if c then x else y



if c then a = x else a = y

これを見比べればわかるように、

367 :仕様書無しさん:2012/08/11(土) 21:32:20.86
三項演算子に代入は必須でないことに気づいてチョット賢くなった気分
条件付きビット処理とかやりたい放題

368 :仕様書無しさん:2012/08/11(土) 21:43:50.11
やめろw
何のための「三」項なんだよ

369 :362:2012/08/11(土) 21:48:28.13
>>362のRubyコードに間違いがあったので訂正

X: a = if c then x else y
O: a = if c then x else y end

まあ、MLやHaskellみたいな関数型言語であれば後ろのendは書かないんだけどね....

370 :仕様書無しさん:2012/08/11(土) 21:54:03.74
>>368
いいじゃんべつに

condition ? bits &= FLGA : bits &= FLGB;

371 :仕様書無しさん:2012/08/11(土) 22:22:19.70
三項演算子自体をやめてくれ
1行ifでいいだろ

372 :仕様書無しさん:2012/08/11(土) 22:25:05.79
>356
<書籍「プログラミング言語C」(K&R本)に沿ったスタイルだからというのが理由

その本でそのコーディングスタイルを採用した理由は明記されてるの?
明記されていなければ、単にたまたま最初に読んだ本がそうだったから、というだけで最近の本で勉強した人と変わらないと思うけど。

373 :仕様書無しさん:2012/08/11(土) 22:26:29.25
>>370
イラッw
せめてこうしてくれ。

bits &= condition ? FLGA : FLGB;


374 :仕様書無しさん:2012/08/11(土) 22:33:05.84
>>372
書いてたかは覚えていないが、予約後のあとに空白を入れるのは
関数の呼び出し箇所をgrepを探せるようにするためって、
昔おっさんに教えて貰った。まぁそんな俺ももうおっさんだがw

最近はIDEが色々やってくれるから、今じゃ紳士のたしなみって感じかねぇ。



375 :仕様書無しさん:2012/08/11(土) 22:58:09.21
>>373
例だと両方&=だったけれど、片方|=とか<<とかだとどうしても三項演算子を使いたくなる

376 :仕様書無しさん:2012/08/11(土) 23:01:35.02
「今の子供たちは、国語でこういう書き方はまちがいだと教えられるらしい。」

「これが、いまどきの子供が仕込まれる正しい書き方だそうだ」


わかるか?

377 :仕様書無しさん:2012/08/11(土) 23:11:47.37
議論に参加できるほどコーディングスタイルにポリシーがあるわけじゃないが、
「間違い」ってスタイルがあるんなら教えて欲しい。

378 :仕様書無しさん:2012/08/11(土) 23:16:50.99
先生から教わることは絶対だろ
教わっていない漢字を使うのは間違いだし

379 :362:2012/08/11(土) 23:29:13.18
>>372
理由は書かれていなハズだよ
でも他の本との決定的な違いは、「プログラミング言語C」が
C言語の設計者自身の手によって書かれた書籍であるということ
(通称の「K&R本」のKとRは著者(=C言語設計者)のイニシャルに由来する)
C言語を誰よりも知り尽くした人によって書かれた本であり、
それゆえK&R本はC言語の原典(バイブル)であると言われている

また、C言語がANSI規格化されるまでの間、
このK&R本がC言語仕様に関する業界標準であったことも付け加えておく

380 :仕様書無しさん:2012/08/11(土) 23:30:08.43
VisualBasicはIDEの整形機能が強力だからおおむね誰が書いても同じスタイルになる。

381 :仕様書無しさん:2012/08/11(土) 23:36:50.41
>>379
字句解析がしょぼかったからでないかな?

382 :仕様書無しさん:2012/08/11(土) 23:46:34.97
if( 10 > b ){}
F( 5, 10 > b );
*( p + 1 );

やっぱif ()は無いで

383 :仕様書無しさん:2012/08/12(日) 00:25:16.23
Code Searchさんに聞いてみたぞ

if (
http://code.google.com/searchframe#search/&q=if\s%2B\%28&type=cs
6,610,000 件

if(
http://code.google.com/searchframe#search/&q=if\%28&type=cs
1,580,000 件


384 :仕様書無しさん:2012/08/12(日) 01:08:09.58
if (  のほうが多数派であることがわかると同時に、
if(   のほうも相当数存在することもわかるな。

385 :仕様書無しさん:2012/08/12(日) 06:49:47.83
まあ、ifでかっこを省略できるなら、if ( とかかせる意味もあんだろうけど。
言語仕様の穴をコーディングスタイルで隠そうとするのはチョットひどいかなぁ。

386 :仕様書無しさん:2012/08/12(日) 11:06:19.34
>>378
触っちゃいけない人だったんだね。やっぱりROMに戻ります。

387 :仕様書無しさん:2012/08/12(日) 13:50:52.81
>379
同じ理論で、Rubyのコーディングスタイルはまつもとゆきひろ氏の書き方が絶対的に正しいと思う?
俺は思わないな。

学習初期に、先人のスタイルを模倣するのはいいことだと思うよ。
でも、ある程度習得できてからは、自分なりのスタイルを確立することのほうが大事だと思う。

組織に参加してプログラミングするとき、その組織ですでに運用されているコーディングスタイルがあるなら、
一般論よりも、すでに運用されているスタイルに準拠するべきだということは異論ないよね?
だったら、自分一人のプログラミングだったら、自分にとっていちばん見やすいスタイルで書くのが正しいと思うよ。
ただし、ファイルごとに書き方がブレるようでは無意味。『自分なりのスタイル』が統一されていれば、ってことね。

言語開発者はたしかに最初のうちはもっとも言語に精通している人物だろうけど、
プログラム言語は使っているうちに洗練されていくものでしょう?
かつてベストだったものが今でもベストだとは限らないよ。
それに、画面サイズだけでいっても、C言語が開発された当時と現在では、1画面に映せる文字数がまるで違うでしょう。
デバイスの進化を追いかけようとしないのはやはり間違ってると思う。

388 :仕様書無しさん:2012/08/12(日) 14:08:28.15
>>383
google code でコード検索できるんだな。
プロジェクトの検索方法は解るがコードの検索方法がわかんね。

389 :仕様書無しさん:2012/08/12(日) 14:22:03.25
デバイスの進化つーても、画面の広さは限られているでしょ
DPIがいくら高くなったところで、文字の大きさはある程度ないとつらいから、表示できる文字数は限られてくる
diff見ることも考えれば、横に2つ並べても支障がないくらいに押さえて欲しい
いつでもデュアルディスプレイやら27インチやら使えるわけじゃないんだから、横に長いコードは嫌だよ

そして縦にやたら長い関数/メソッドは下手くその書くものってのは今でも変わらんわけで

390 :仕様書無しさん:2012/08/12(日) 14:41:41.12
インターフェースとして機能してるわけでもなく
一度しか呼ばれない関数もいらっとするけどな。
よく有るのがInitialize()とかMakeToolMenuXxxx();
コメントで/*初期化処理*/とか/* ツールメニューXxxx */作成で十分

391 :仕様書無しさん:2012/08/12(日) 15:00:39.48
関数が長くなり過ぎないように処理単位で分けてるだけだろ
任天堂のソースなんてアセンブラですら数行で終わるサブルーチンだらけだ

392 :仕様書無しさん:2012/08/12(日) 15:11:05.51
何の意味があるんだ?

a(){}
b(){}

void f(){ a();b(); }

↑を↓で書いたって変わらんだろ

void f()
{
 /********* a *********/
 {
 }
 /********* b *********/
 {
 }
}


393 :仕様書無しさん:2012/08/12(日) 15:17:08.65
>>388
http://code.google.com/searchframe


394 :仕様書無しさん:2012/08/12(日) 15:36:13.80
>>392
コメントを書かずに言語の文法で意味を
記述するようにするのが最近の流行りだよ。
「Clean Code」とか「リファクタリング」を読むといい。


395 :仕様書無しさん:2012/08/12(日) 15:41:30.07
読むといい、と言ってみんなが読むなら苦労しない。

396 :仕様書無しさん:2012/08/12(日) 15:42:02.75
元々コード要素として現れるべきではないものが
関数として現れてるのがウザいんだけど

397 :仕様書無しさん:2012/08/12(日) 16:37:47.50
>>390
関数として仕様を決めることができる。

398 :仕様書無しさん:2012/08/12(日) 16:42:00.96
>>397
何の意味があるのか?

399 :仕様書無しさん:2012/08/12(日) 16:47:36.31
経験則として1つの関数の1箇所しか呼ばれない関数を作る奴は
OOPLの使い方やモジュール化が下手な事が多い。
まぁ、Cで例外処理用に関数を分離してる奴はそれなりに技量が有ったりするが。
それ以外の奴は論理的じゃなく感覚的にコードを書きやがる。

400 :仕様書無しさん:2012/08/12(日) 16:49:44.47
>>392
一度書いたら二度と修正しないほど完成度が高い設計だったら問題はないんだがな
たいていは後でaとbの間やa、bの中に元のa、bの切り分けになじまないコードを追加したりする

それを禁じるために上の書き方をするんだよ

401 :仕様書無しさん:2012/08/12(日) 16:54:26.20
>>398
「仕様通りに書いてね」
「仕様を満たしてるかテストしてね」
って言えるじゃん。

402 :仕様書無しさん:2012/08/12(日) 17:02:39.77
例えば、プログラム起動時に起動オプションと設定ファイルの内容を調べてメモリ上に展開するような
処理は一回しか行われないからmainにべた書きしてもいいかもしれないが、そういうのは初期化関数
として作るのが好みだなぁ。

403 :仕様書無しさん:2012/08/12(日) 17:41:12.44
>>400
むしろ上の方が柔らかい実装の時に困るでしょ
ちょっとした変更のたびに関数のシンボルが増えたり消えたりする

>>401
本来ひとかたまりのものを分割してんだからテストしづらいじゃん
そもそも再利用可能な単位に関数を分割していけば
一度しか呼ばない関数の大きさは呼び出し元に吸収できるぐらい小さくなって
テストの大半は再利用可能な単位に下ろせる筈でしょ


404 :仕様書無しさん:2012/08/12(日) 18:05:09.60
>>403
柔らかい実装って、単に設計がフニャフニャだだけじゃん。

405 :仕様書無しさん:2012/08/12(日) 18:07:07.65
> そもそも再利用可能な単位に関数を分割していけば
> 一度しか呼ばない関数の大きさは呼び出し元に吸収できるぐらい小さくなって
そんなことないよ。
一カ所からしか呼ばれないけど、中で複雑な処理をする関数なんていくらでもある。

406 :仕様書無しさん:2012/08/12(日) 18:15:38.92
>>404
仕様変更があれば結構有るよ。
ボタンが増えたり減ったりとか。
そういう所は固い設計は難しいから柔らかい関数や柔らかいクラスにカプセル化するね。

>>405
具体的にどんな?

407 :仕様書無しさん:2012/08/12(日) 18:24:31.90
>>392
それは「aを行ってbを行う」と"読む"
確かに前者はコード量は増えたし行数も増えたし最終的なルーチン呼び出し回数も増えた(ベタ書きのほうが僅かに確実に高速)

しかし、名前がつけられている
「変数/定数として切り出して名前をつけるとコードの流れが読みやすい」のルーチン版
クラスやメソッドのある言語だとこの「メソッド細分化と再命名」によるリファクタリングが最近は頻繁に行なわれているが、
そうじゃない言語だと見栄えが絶妙に面倒だな

408 :仕様書無しさん:2012/08/12(日) 18:28:31.75
>>406
物理シミュレータの場合、メモリ領域の確保などのソフト起動に必要な処理をコンストラクタに任せて
物理パラメータの設定や相互連携、間接インスタンス生成をInitialize()関数に任せてしまう、とか

409 :仕様書無しさん:2012/08/12(日) 18:40:31.02
>>407
逆にリファクタリングしづらいでしょ
本当に処理が独立してるなら再利用できる訳だし
リファクタリングすればどんどん再利用可能な処理が抜けていって
一度しか必要ない処理はどんどん小さくなっていくでしょ。

>>408
その処理は本当に1プロジェクトに依存してる処理だけなの?
XMLに吐き出しておけば十分とか、切り抜けば他のプロジェクトで
再利用可能な処理が殆どで本当にプロジェクトに依存してるのは極一部でしょ。

410 :仕様書無しさん:2012/08/12(日) 18:40:35.19
>>407
「書くのが若干めんどい」「見掛けが若干キモい気がする」と「読み下しやすくて間違いにくい」とのトレードオフだからなあ
わかりにくいような処理に対してピンポイントに使わないとお釣り出ないよね

411 :仕様書無しさん:2012/08/12(日) 18:46:28.98
> 本当に処理が独立してるなら再利用できる訳だし
この辺が空論だな。
独立してることと、再利用可能であることは別だし、
再利用できるように独立させても、誰も使わないことはよくある。

412 :仕様書無しさん:2012/08/12(日) 18:49:42.72
>>409
一概には言えんが
コメントを書かないとわからんような処理なら
メソッドの抽出はすべきだろう。

参照が一つしかない関数を作るななんて言ったら
main()は何千行にもなってしまうぞ。


413 :仕様書無しさん:2012/08/12(日) 18:50:04.21
>>411
誰も使わなくても再利用可な状態にしておくほうが
人間の感覚で分割するよりマシだよ。テストも作りやすいし。

414 :仕様書無しさん:2012/08/12(日) 18:56:11.99
>>413
その再利用可能っていう基準もお前の感覚でしかないじゃん。

415 :仕様書無しさん:2012/08/12(日) 18:57:21.82
>>412
Unixのソース見てりゃ数百行程度は別に構わないと思える。
他から操作されてる可能性考える必要なくてメンテしやすいし。

1プロジェクト中で1回って話じゃなく他でも再利用できない部分って話だよ。
例えばこういうのはあり。

//一度しか使わないExample
class Example:public TextFormat
{
// プロジェクト依存処理
};

Example examle( コンテキスト情報 );
Label label( &example );// TextFormatは自分で用意してねなライブラリ


416 :仕様書無しさん:2012/08/12(日) 18:59:39.45
>>414
再利用できる以上感覚じゃないじゃん。
できるできないがはっきりしてるなら感覚じゃないでしょ。
再利用できないコードをある人が書いて、
他の人が使うとある日突然再利用可能になったりする?

417 :仕様書無しさん:2012/08/12(日) 19:06:31.03
>416
そこまで徹底的に『再利用できない』と断言できる処理ってどんなの?

418 :仕様書無しさん:2012/08/12(日) 19:09:52.22
(>417の続き)
ふつうプログラム中で1ヶ所からしか呼ばない関数って『再利用しようとすればできるけど、現状では再利用の必要がない』ってものじゃない?
『絶対に再利用できない』って断言できるんなら、たしかに関数化する意味はないけど、
再利用しようとすればできるなら、『ここからここまでのソースがひとかたまり』という部分は関数化しておくべきだと思うよ。

419 :仕様書無しさん:2012/08/12(日) 19:16:52.01
>>417
処理というか関数。イベントで呼ばれたりするわけでもなく
main関数から呼ばれるだけなのにプロジェクト依存のコード
たっぷりねじ込んでInitializeとか大雑把に切り抜いてる関数。
〜MakeProcessとかとりあえず関数が長くなったので抜き出しました系。
リファクタリングすればたいてい再利用部分と呼び出し元に分解できるヤツ。


420 :仕様書無しさん:2012/08/12(日) 19:21:15.01
メンテ考えるなら、関数にわけるなぁ。一人でメンテするならどうとでもなるけど、
他人にメンテさせる場合関数でわけとかないとaの処理とbの処理が密結合しそうで嫌。
関数にわけたところで絶対に密結合が避けられるわけじゃないけど、
「ここは処理をわけてるんだぞ」ってのを明示する意味で関数にくくりだす。

421 :仕様書無しさん:2012/08/12(日) 19:23:14.30
そもそも密結合なものを見かけだけバラしてるから再利用できないんじゃないの?

422 :420:2012/08/12(日) 19:24:33.17
あと、例えばInitialize関数なら、とりあえずInitializeのことだけ考えればいいので頭が楽というのもある。

423 :仕様書無しさん:2012/08/12(日) 19:25:57.94
再利用不可能な部分、プロジェクト依存な部分は極力小ぢんまりと
一箇所に収まっててくれてた方がいいよ。そこだけ書き換えれば大雑把な変更はそこで収まる。

424 :仕様書無しさん:2012/08/12(日) 19:26:29.35
>>419
そこまで再利用性に拘る必要性を感じないかな。
始めから再利用前提のライブラリを組むなら別だけど、
リファクタリングの結果出てきたようなものはどうせ再利用されないし。

425 :仕様書無しさん:2012/08/12(日) 19:29:54.51
>>422
これならブロックの中だけ考えれば十分でしょ
ただ、このブロックの範囲なんて業務が変わるたびに
ぐちゃぐちゃ変わるわけだけど。

/****** Initialize *****/
{
}
/****** Uninitialize ******/
{
}

426 :仕様書無しさん:2012/08/12(日) 19:30:41.59
> ただ、このブロックの範囲なんて業務が変わるたびに
> ぐちゃぐちゃ変わるわけだけど。
ダメじゃん

427 :仕様書無しさん:2012/08/12(日) 19:31:56.49
>>424
リファクタリングすればする程再利用性の低い部分は局所化するでしょ。
iniline化機能とか大活躍。

428 :仕様書無しさん:2012/08/12(日) 19:33:12.84
>>426
だから関数にするのが間違ってるんじゃん。
頻繁に変わるような部分は局所的なクラスや関数に封じ込めといたほうが楽だよ。

429 :仕様書無しさん:2012/08/12(日) 19:40:10.61
>>415
> Unixのソース見てりゃ数百行程度は別に構わないと思える。
いいわけねーだろ。大丈夫か。
gitのソースだって93%が70行以下、うち75%が30行以下だ。

> class Example:public TextFormat
基準が全然わからんぞ、
そんな一時的な継承の方が余計に判りにくくないか?


430 :仕様書無しさん:2012/08/12(日) 19:52:38.71
>>429
単に70行以下に収まってるだけでしょ。それに7%は70行超えてるんでしょ。
局所化した部分は長くなるっていい例じゃん。

あと、linuxのvnsprintfの例。
http://code.google.com/searchframe#3C3saXwSWsQ/trunk/linux-2.6.24.3/lib/vsprintf.c&q=lang:%5Ec$%20function:snprintf&type=cs&l=376

200行近いけど蜜結合してる部分は1つの関数に納めてる。

431 :仕様書無しさん:2012/08/12(日) 20:05:45.33
>>429
クラス部分に関しては避けようが無いから仕方ないという話。
それから同じプロジェクト内なら完全に再利用不可能なわけじゃないし。

432 :仕様書無しさん:2012/08/12(日) 20:18:31.07
読み直してるとちょくちょく誤解を与えるレスしてたような気がする。

ここでの再利用不可な関数の定義
・一つのプロジェクト内でも共有不可
・プロジェクト間で共有不可

プロジェクト固有の処理を1個の関数内に全て納めろと読み取れる
レスが有ったら混乱してるだけなんで無視してね。

433 :仕様書無しさん:2012/08/12(日) 20:20:52.45
>>430
おいおい、それはパフォーマンスを重視して
保守性や可読性を犠牲にしてるところだぞ。
そんなやり方を全部にやってたら全体の7%じゃ済まなくなるんじゃないか?


434 :仕様書無しさん:2012/08/12(日) 20:22:30.04
switchだらだらはどうかと思うが
可読性さがってるか?

435 :仕様書無しさん:2012/08/12(日) 20:32:48.41
>>433
これ以上保守性挙げられるか?

436 :仕様書無しさん:2012/08/12(日) 20:37:53.15
>>427
埋め込む先の関数がある程度以上大きいとキャッシュ容量を圧迫してかえって遅くならないか?

437 :仕様書無しさん:2012/08/12(日) 20:46:12.73
一箇所からしか呼ばれないんだからキャッシュ化されても意味無いでしょ。
大体、1つの関数をキャッシュメモリに載り切らない量にするとなると
1000行以上の巨大関数になるよね。そんな関数を頻繁に呼ぶこと自体なくね。
仮に数百行の関数が有ったとしても全体の7%以下だし。

438 :仕様書無しさん:2012/08/12(日) 20:52:45.49
>1000行以上の巨大関数になるよね。そんな関数を頻繁に呼ぶこと自体なくね。



ニヤリ

439 :仕様書無しさん:2012/08/12(日) 21:00:46.48
>>436
200行前後とかなら気にする必要なくね?
標準ライブラリーですら200行超える関数使ってんだから

440 :仕様書無しさん:2012/08/12(日) 21:04:14.43
キャッシュには、その関数だけでなくほかのもんも入ってるでしょ
エレベーターにデブ(制限重量以内)が居たら他の客も迷惑でしょって話し

441 :仕様書無しさん:2012/08/12(日) 21:08:29.59
他のを含めて1000行以上って書いたんだけど。
64kbとかが主流の時代なんだから1000行なんて60分の1にもならんでしょ。
それに1度しか呼ばない関数をインライン展開する可能性もあるし、
インライン化しなかったらキャッシュひっくり返す可能性もあってそれはそれで効率が悪いじゃん。

442 :仕様書無しさん:2012/08/12(日) 21:09:29.70
×他のを含めて1000行以上って書いたんだけど。
○他の関数が乗っている事を踏まえて1000行以上って書いたんだけど。

443 :仕様書無しさん:2012/08/12(日) 21:13:57.47
大した問題じゃないけど1次キャッシュの命令用は32KBか

444 :仕様書無しさん:2012/08/12(日) 21:15:06.94
64kBだと原稿用紙80枚か
命令数は原稿用紙3枚で40として3200

合ってる?

445 :仕様書無しさん:2012/08/12(日) 21:18:03.74
命令が1バイト固定じゃないから考え方を変えろとしか・・・

446 :仕様書無しさん:2012/08/12(日) 21:25:24.09
話の流れで見易さとか感覚による部分に
明確な基準を作りたがらない辺りがやっぱり
プログラマーの集まるスレだと思ったw

447 :仕様書無しさん:2012/08/12(日) 21:36:59.15
キャッシュの話出てたけどよく考えたらC++やネイティブ向け言語処理系固有の話で
インタプリター系言語じゃインタプリター次第だから気にしても仕方ない話だよね。
それにC++やCに関しては処理系次第で必要があれば勝手に調整するし。
例えばVCはブロック{}使えば同じ関数内でもスタック調整するしね。

448 :仕様書無しさん:2012/08/13(月) 01:05:46.40
>>435
それこそ一度しか参照しないstatic関数に分割していけば
わかりやすく、かつ保守しやすくならないか?こんなイメージで。

static int init_context(&context, .......
static int reject_out_of_range(&context, ........
static int parse(&context, ........

int vsnprintf(char *buf, ...........
{
  struct vsnp_context context;

  init_context(&context, .......
  reject_out_of_range(&context, ........
  parse(&context, ........

  ......
}

実際やるとポインタのデリファレンスが増えるんで、
インラインで書いてるだけの話じゃないか?


449 :仕様書無しさん:2012/08/13(月) 03:08:16.40
だったらstatic inlineで

450 :仕様書無しさん:2012/08/13(月) 10:33:50.88
サッカーの説明をするのに
「味方側11人・敵側11人で行う、外周70cmで重量450gの球体を、人体の手以外の部分で1m以内の範囲で操作し、
時には味方に蹴り渡したりして、より多く敵側の一定領域へ蹴り込む競技」
と言うよりは
「11人vs11人で、ボールをドリブルしたりパスしたりしてより多くゴールを決めた方が勝つスポーツ」
にして、各単語の意味を別に定義しておいたほうが、自他の意思疎通の際に簡潔で分かりやすいし、「文章の」意味の理解で発生する齟齬も防げるじゃん

って話じゃないの?

451 :仕様書無しさん:2012/08/13(月) 12:12:58.78
>>324 括弧は必ずつけろ。これは命令だ。

452 :仕様書無しさん:2012/08/13(月) 13:12:01.33
命令じゃない構文の場合は不要なの?

453 :仕様書無しさん:2012/08/13(月) 14:55:35.87
return に括弧を付ける奴が実在する。
しかも return( 0 ); のようし、括弧との間に空白を付けずに。
聞いてみると関数のように見えるようにだと。return を呼び出してそこから戻ってきたら困るだろうに。

if と括弧の間の空白はどっちでもいいと思ってたが、これを思い出したので、今日から if の後ろに括弧を付けろこれは命令だ派になろうと思う。

逆に関数のシンボルと括弧の間に空白を置くやつも実在する。
これは常にというわけではなく、引数セットが同一の時に引数の桁を合わせようとしているのだが、括弧の後ろの空白で調整すればいいじゃん。


454 :仕様書無しさん:2012/08/13(月) 14:56:34.32
> if の後ろに括弧を付けろ
って何だ俺は。
括弧の前に空白を付けろだ。

455 :仕様書無しさん:2012/08/13(月) 19:41:56.96
>>448
linuxのコメントで説明してる方がましだナァ。
わざわざ流れを絶って他の関数見に行くのも面倒だし
その関数名でどの値が変更されるのかもわかりづらいし

456 :仕様書無しさん:2012/08/13(月) 20:47:07.47
【命名】 馬から落馬コード


foo = (cond) ? true : false;

457 :362:2012/08/13(月) 21:47:43.72
>>387
>同じ理論で、Rubyのコーディングスタイルはまつもとゆきひろ氏の書き方が絶対的に正しいと思う?

絶対的かどうかは知らないが、現行のRubyのスタイルはまつもと氏の原典「オブジェクト指向
スクリプト言語Ruby」に沿ったものになっているのでは。もちろんRubyは表現力の豊かな言語であり、
原典出版当時からメタプログラミングや関数型言語風プログラミングなどの発展があった。
それでも原典にある改行やスペースの入れ方に従ったスタイルになっていると思う。

>一般論よりも、すでに運用されているスタイルに準拠するべきだということは異論ないよね?

もちろんだ。郷に入れば郷に従う。それがプロ(職業プログラマ)だと思っている。

>だったら、自分一人のプログラミングだったら、自分にとっていちばん見やすいスタイルで書くのが正しいと思うよ。

自分一人のプログラミングならば、自分なりの個性的なスタイルを追求するのは間違っていない。
でも、スレタイにあるイラッとするうんぬんというのは、集団での開発や外部へリリースするコードという、
書く人と読む人が別々の状況ではないのかな?その場合、個性的なスタイルは、他のメンバからすれば
一人よがりだったり自己満足のオナニーに映るよね。

>かつてベストだったものが今でもベストだとは限らないよ。

前にも書いたように(>>356)、わざわざK&R Cのスタイルを捨てる理由が見当たらないんだ。
少なくとも、if/while/for/returnの直後にカッコを置くスタイルは、関数と判別しづらくなる欠点がある。
これは文と式(関数)という言語設計の基本を理解していない、思いつきで生まれたスタイルだと言わざるをえない。
もしも明らかに可読性や保守性に優れたスタイルが提案されたなら、それを受け入れるよ。

458 :仕様書無しさん:2012/08/13(月) 23:20:10.40
>>455
んな事いってたらOOなんか使えないだろ。
メンバ変数がどのメソッドで変更されるのか全部把握するのか?



459 :仕様書無しさん:2012/08/14(火) 01:44:05.34
>>457
予約後が関数名と区別できないならマを辞めたほうがいいんじゃないか?

460 :仕様書無しさん:2012/08/14(火) 01:46:11.00
>>458
前スレでprivateなメンバー関数は極力static関数にしてメンバーを引き渡せってのが有ったね。
あれには同意する。

461 :仕様書無しさん:2012/08/14(火) 01:50:16.37
>>458
OOのと違って目的が決まったメンバーじゃなく
とりあえず分割して追い出すためだけに
寄せ集めた構造体なんで解りづらいっす
出来の悪いオブジェクトみたいな感じ

462 :仕様書無しさん:2012/08/14(火) 01:53:23.52
ちゃんと呼び出し元と独立してて再利用できるような形で整ってると読みやすいんだけどね

463 :仕様書無しさん:2012/08/14(火) 02:03:18.19
>>461=462
>>461の補足したつもりだけど>>461=462が解るようにレス番付けてなかった

464 :仕様書無しさん:2012/08/14(火) 02:20:56.17
>>461
分割前とどう違うんだ?
でかい関数の上の方に寄せ集めた変数の塊も判りにくいんじゃないか?




465 :仕様書無しさん:2012/08/14(火) 02:39:21.95
常にA-B-C-Dの順番で呼び出してくださいという関数があったら
使いづらくて仕方ない。いっそ一つの関数にまとめろよと思う
それと同じだな

466 :仕様書無しさん:2012/08/14(火) 02:49:14.22
>>465
途中にreturnやbreakを入れないで下さいという
長い関数があったら使いにくくないか?
gotoなんかも入ってるぜ?


467 :仕様書無しさん:2012/08/14(火) 02:53:21.24
>途中にreturnやbreakを入れないで下さいという
>長い関数があったら使いにくくないか?
どこから出てきた話だ?

468 :仕様書無しさん:2012/08/14(火) 10:11:32.46
>>465
外から使うための関数じゃないから。

469 :仕様書無しさん:2012/08/14(火) 10:40:15.20
もはやコーディングスタイルの話題から脱線している件について、

470 :仕様書無しさん:2012/08/14(火) 14:17:23.25
>>465
それだったらA,B,C,Dは非公開にして、A->B->C->Dの順に呼び出す公開関数Eを普通は作るだろ

471 :仕様書無しさん:2012/08/14(火) 19:55:59.15
>>465
open->read->closeも順に呼び出さないと使えないんだが…



472 :仕様書無しさん:2012/08/14(火) 20:50:47.60
>>468-470
隠すかどうかはどうでも良くて読みづらい編集しづらい
読むってのはライブラリとして利用させてもらってる立場の話じゃなく
隠したコードを編集する立場だからな
linuxのコードと見比べてみ

>>471
RAIIな形ならいいじゃん
あと、ある一点でしか想定してない関数とは違うでしょ

473 :仕様書無しさん:2012/08/14(火) 21:09:30.64
>>471
readとかwriteとかcloseとかハンドルが無効だったら戻り値とは言え
安全になるようエラー返してくれるよね。件の一度しか呼ばない関数も
安全に使えるようにチェック入れるの?

474 :仕様書無しさん:2012/08/14(火) 21:15:28.15
どう思う?


if ( !(....)) {}


if (!(...)) {}

475 :仕様書無しさん:2012/08/14(火) 21:32:57.01
>>473
そんなの当たり前だろ。意味のある入力と結果を返すように
しなければリファクタリングする意味がない。

あとファイルディスクリプタの番号は再利用されるから
いきなりcloseしてエラーになるとは限らないぞ。


476 :仕様書無しさん:2012/08/14(火) 21:37:49.26
>>475
そうか。やっぱ保守性悪いな。


477 :仕様書無しさん:2012/08/14(火) 22:01:27.48
多少大筋の変わる仕様変更があると、関数消して
新しい関数追加して引数コメント付けて
呼び出し元にもコメント付けて >>475 の様な人の場合なら
エラーチェックも追加して

もう一回別で使ってるんなら我慢も出来るコストじゃ有るんだけどねぇ


478 :仕様書無しさん:2012/08/14(火) 22:02:21.95
エラーチェックじゃなかった入力チェックだった

479 :仕様書無しさん:2012/08/14(火) 22:55:30.34
そんなに関数分割って解りやすい?
再利用のための必要悪でしょ?

480 :仕様書無しさん:2012/08/14(火) 23:18:03.96
わかりやすいこともあるしわかりにくいこともある
悪のこともあるし正義のこともある。

関数分割はただの道具だ。
正しく使えばいい結果をもたらすに決まってる。

481 :仕様書無しさん:2012/08/14(火) 23:52:50.14
>>477
大筋が変わるような時点で負けていることに気付け。

482 :仕様書無しさん:2012/08/15(水) 00:47:10.04
勝ちとか負けとかどうでもいいよ。
すごくどうでもいい話。

どっちみち先に進まないといけないんだからさ。

483 :仕様書無しさん:2012/08/15(水) 01:40:55.50
変更履歴をコメントで入れるヤツにイラッwww

// 管理番号 xxxxxx ほげほげ 2012/08/14 田中 Start
if (hoge) {
  hogehoge();
// 管理番号 xxxxxx ふがふが 2012/08/15 鈴木 Start
  fugafuga();
} else {
// 管理番号 xxxxxx ほげほげ 2012/08/14 田中 End
  piyopiyo();
}
// 管理番号 xxxxxx ふがふが 2012/08/15 鈴木 End

田中と鈴木で範囲被っててカオスwww
svn使ってるんだからやめて・・・w


484 :仕様書無しさん:2012/08/15(水) 02:40:52.71
>>483
結構大手が開発したソースでもそんなんだよね
Hとか

485 :仕様書無しさん:2012/08/15(水) 06:37:09.17
>>481
勝ちたかったの?君の勝ちでいいよ。

それはともかく、機能追加しただけで1つの関数の
内容が大きく変わることは割とよく有るね。
今まで読み込んだバイト数が必要になって関数の
数行ごとにカウントの式を追加したり。

486 :仕様書無しさん:2012/08/15(水) 06:46:37.87
他人に勝った負けたで生産性やら保守性やらが
上がるんならいくらでも勝った宣言するんだがな・・・

487 :仕様書無しさん:2012/08/15(水) 07:41:10.64
>>483
あるあるw
ソースには変更履歴書くくせに、コミットするときにコメントはろくに書かないとか。
何のためのバージョン管理システムなのかと……

488 :仕様書無しさん:2012/08/15(水) 08:07:33.40
>>483
ありすぎて困る
そして誰得になっていって、どこかのタイミングで誰かが消す作業を行う・・

489 :仕様書無しさん:2012/08/15(水) 08:19:45.01
消すと激怒するんだよなw

490 :仕様書無しさん:2012/08/15(水) 08:38:03.62
>>486
そこは「いくらでも負けを認めるんだがな」と言うんだよ
イラッとするぜw

491 :仕様書無しさん:2012/08/15(水) 13:10:43.10
修正履歴はヘッダと修正箇所に日付氏名を入れて記入すること
って普通大手では決まってるのよ

492 :仕様書無しさん:2012/08/15(水) 13:15:14.23
だから大手は軒並みソフトが弱いんだな。

493 :仕様書無しさん:2012/08/15(水) 13:54:38.62
>>479
分割されたものがきれいな範囲でまとまっていればわかりやすい。
そのように分割して外に追い出すことができれば、元の関数は手続き的凝集となり、あれもこれも一つの関数で行っていた状態よりは、いくらかはマシになる。
分割されたそれぞれの関数の凝集度もよくなる。
きれいに分割できた時にはね。

494 :仕様書無しさん:2012/08/15(水) 16:41:06.00
>>491
修正部分の上に別の修正がかぶさって20年ちかく熟成されたカオスなコードを読まされる身にもなれっつーの

495 :仕様書無しさん:2012/08/15(水) 17:16:29.58
>>494
いやバグを作りこんだ下請けと担当者に死の鉄槌を加えるには必須です

496 :仕様書無しさん:2012/08/15(水) 17:21:44.27
鉄槌さえ下せればコード自体はどうなっても構わんとか、まさにクズの思想だな

497 :仕様書無しさん:2012/08/15(水) 17:28:56.61
>>495
バージョン管理システムも導入してないの?

498 :仕様書無しさん:2012/08/15(水) 17:50:22.83
バージョン管理は最初から固定メンバーや若干の入れ替わりなら有効だけど
頻繁に派遣や下請けが入れ替わる環境では返って邪魔なだけ

499 :仕様書無しさん:2012/08/15(水) 17:53:05.62
邪魔になる理由がわからない。。
バージョン管理システムも使えない派遣しか雇えてないところとか?

500 :仕様書無しさん:2012/08/15(水) 17:55:15.42
数人規模の零細に流れ流れてやってきたコードなら文句言うのもわかるが
大手は下請け別部門別担当者別でバグ発生率とかデグレ発生率とか普通に管理してるから
会社によっては壁に貼りだすところもある成績表みたいにな
そういうところではソース上に記入させるのは普通です

501 :仕様書無しさん:2012/08/15(水) 17:57:26.90
>>497
某大手メーカM菱電機では、一切使われていなかったなあ....
自分達の担当部分に関してはOS標準(HP-UX)のRCSでしのいだけど
派遣なのでシステム権限が無く、SVN/Gitは導入できなかったし

502 :仕様書無しさん:2012/08/15(水) 17:57:51.10
バグ管理システムも使ってないとか?

503 :仕様書無しさん:2012/08/15(水) 18:26:50.33
大手ほどExcelで管理とかソースに履歴とか原始的な方法使ってるよな。
ベンチャーなんかの新興企業の方が発想が新しい傾向がある。

504 :仕様書無しさん:2012/08/15(水) 18:29:01.82
そりゃ能なし飼っとく余裕なんてないからね

505 :仕様書無しさん:2012/08/15(水) 18:30:56.49
部分的に切り出して個々は協力会社Aにアウトソースしようとかあるか
10人とかで開発してるわけじゃないので外部のどの会社にもソースリポジトリ触れる状態にはしておけないでしょ

506 :501:2012/08/15(水) 18:44:18.12
>>502
当然,使っていない
HだとB票/P票で採取してPCL消化/バグ発生曲線で管理するけど、類似のQA(品質保証)手法は見たことがなかった
あと、線表(工程管理表/ガントチャート)すら使われていなかった(工程会議は口頭説明のみ)
すべてにおいてプログラマ個人の力量に頼った開発だった
しかたないから、自分達はExcelで線表とバグ発生曲線を書いて自己管理していた
まあ、末端のコーダ扱いで投入されたから、そんなものかと気にしていなかったけど....

507 :仕様書無しさん:2012/08/15(水) 18:46:40.89
だから、
これ実行できないんですけど、どうやってテストするんですか?
っていう状態でソースがやってくるんだな。

ま、結局テストせずに納品するんだけどね。

508 :507:2012/08/15(水) 18:48:28.36
あ、>>507>>505へのレス。

509 :仕様書無しさん:2012/08/15(水) 18:52:27.21
>>505
逆に、外部の会社使ってるのにソース管理システム使わずにどうやって
管理しているのか興味ある。手作業でマージしてるとか?

510 :仕様書無しさん:2012/08/15(水) 18:54:25.40
プログラムって楽しいよな
でも、いま学生の人は間違ってもIT業界には就職するなよ

511 :仕様書無しさん:2012/08/15(水) 18:58:37.30
アウトソースって意味わかってるのか?
手取り足取りバグのとり方から品質管理までやってたら意味ないだろ
ほんと零細かお前らw?

512 :501:2012/08/15(水) 19:30:00.83
>>509
横レスだけど、>>501のケースでは最終顧客との間に専用のネットワークがあって、
M菱側で結合テストを終えたコンポーネントのソース一式をtar.gzで固めてから
FTPで指定ディレクトリへアップロードしていた
そして客先の連動テスト環境化でバグが見つかれば、再度アーカイブをアップロード
おそらく最終顧客の担当者が手作業でマージしていると思われるw

最終的にはWordで書いたドキュメントと一緒にソースをMOで納品となる

513 :仕様書無しさん:2012/08/15(水) 20:59:41.08
>>498
情シス部門が無いなら(無いのも問題だが……)しょうがないかもしれないが、
普通派遣PGの入れ替わり程度なら即座にアカウント発行されているぞ。

それに、そんなに頻繁に得体の知れない奴が入れ替わるんだったら、正常に
動いていた状態に即座に戻せるようにバージョン管理システム必須じゃないの?

514 :仕様書無しさん:2012/08/15(水) 21:02:08.79
気持ち悪い!!!やめてくれ・・・・・・・・・・

foo(aaa + bbb,ccc - ddd,eee + fff);

515 :仕様書無しさん:2012/08/15(水) 22:45:40.58
>>514
foo(aaa() + bbb(),ccc() - ddd(),eee() + fff());
これはどう?

516 :仕様書無しさん:2012/08/15(水) 22:50:26.52
発射する・・・・・発射してまうで・・・・

517 :仕様書無しさん:2012/08/21(火) 16:27:55.98
>>514
そんな書き方されて、バグだされて、デバッグするとき物凄く苦労した覚えがある
あーそんな書き方してた奴、今どこでなにしてんだろ

518 :仕様書無しさん:2012/08/25(土) 05:58:44.42
ソース管理でコミットログとか残してるのに、不要処理をコメントアウトするのがイラッとする

519 :仕様書無しさん:2012/08/25(土) 12:32:40.86
メソッドのへの分割は、処理にコードレベルで名前をつけることでもあるしな
それと再利用とはまた目的が違うとおもうけどなー

コメントで処理を説明すればいいっていうのはわからなくはなし、やるけど、
コメントはフォーマッターとか効かないし、文体や書式の個人差が大きいから機械的に処理できないし
本人以外にうまく伝わらないような説明文かかれてたりすることもある
それに、コメントってコードじゃないから保守されないことが多くて、
嘘説明になってたりするのもよく見るから、長い処理ほど説明コメントは避けたい
コードで表現できることはコードで表現したい

まぁぶっちゃけ、イラッとするような冗長メソッドは基本的にコメントもついてないけどな…

520 :仕様書無しさん:2012/08/25(土) 15:26:32.60
未来の自分に、お前はまたこのコードを書くだろうがこのコードを書く必要はないんだ
って事を伝えるためにコメントアウトして残す事はたまーにある。

521 :仕様書無しさん:2012/08/25(土) 16:22:52.70
>>520
そりゃたんなる横着じゃないかw
ソース管理から過去のソース(どのリビジョンか調べる手間が要るが)ひっぱって
くるだけだろうに。

522 :仕様書無しさん:2012/08/25(土) 17:50:29.58
すべてのソースファイルの一行目に

//TAB4

うざ・・・

523 :仕様書無しさん:2012/08/26(日) 04:07:15.55
>>522
4^10000とかにでも書き換えたれや

誰も困らん
困るやつが悪い

524 :仕様書無しさん:2012/08/26(日) 04:48:27.42
コメントトラップって、詳細設計を後書きしてるようなプロジェクトに多い気がする

525 :仕様書無しさん:2012/08/26(日) 13:37:31.57
変更開始のコメントはあるのに、変更終了のコメントがなかったり
変更開始〜終了がいっぱい合って、それぞれがスパゲッティになってる状況とか
やめて欲しい。

てか紛らわしいのでむしろ要らない

1関数1000行単位で1ファイル1万行単位とかやってるからそうなる。
関数に切り出せる塊で、ブロックで治すんだったら、関数に
切り出せよとかマジで思う。


526 :仕様書無しさん:2012/08/26(日) 15:19:06.25
コーディングルール強制エディタって、ない?

行数が増えすぎた関数とか、スペルが怪しい命名とか、
リアルタイムで監視していて即画面を赤くしてその後作業を拒否るみたいなの

527 :仕様書無しさん:2012/08/26(日) 15:20:35.89
直せなくなるじゃんw

528 :仕様書無しさん:2012/08/26(日) 15:21:43.57
前回のセーブポイントまでもどるわけだな

529 :仕様書無しさん:2012/08/26(日) 15:40:42.24
スペルチェックは欲しい。略語辞典付きで。

それでも辞書に登録されちゃうと、Syainmei_NyuryokuInput()とか馬鹿な関数は撲滅できないんですけどね。
あ、でもSyanimeiとShainmeiの混在は減るのか


530 :仕様書無しさん:2012/08/26(日) 15:53:03.00
Romajiで打ち込むと、英単語の候補を表示してくれるとか、どう?

531 :仕様書無しさん:2012/08/26(日) 22:40:38.42
MS-IMEはカタカナから英語に変換できるよ

532 :仕様書無しさん:2012/08/26(日) 23:05:47.23
それがプログラミング環境で役にどう立つと?

533 :仕様書無しさん:2012/08/27(月) 03:36:30.92
VBで漢字変数でなくかっこいい英語変数を使える

534 :仕様書無しさん:2012/08/30(木) 20:39:18.17
知らない英単語使って、後で何の事か分からなくなる位なら、
最初から日本語で書けって。

535 :仕様書無しさん:2012/08/31(金) 00:16:01.38
それも仕方ないけど、その前にシソーラスを使おう。んで、検索ヒットの多いのを選ぼう。

536 :仕様書無しさん:2012/09/01(土) 16:00:07.32
コメントが関西弁
本人は東北出身

537 :仕様書無しさん:2012/09/01(土) 16:34:00.40
// なんでやねん

538 :仕様書無しさん:2012/09/01(土) 21:12:29.90
bool flg = (condi) ? true : false;//いらんがな

539 :仕様書無しさん:2012/09/02(日) 02:05:36.95
シソーラスもいいね
今まで英辞郎使ってたよ

540 :仕様書無しさん:2012/09/02(日) 02:21:43.65
public int hoge() { return bool値 ? 1 : 0; } // そのままbool値を返せバカ (Java)

541 :仕様書無しさん:2012/09/02(日) 06:56:38.49
//foo.cpp

#define False 0
#define True 1




なんでやねん

しかし、trueやfalseに変更しようとするとなぜかエラーが出るので
面倒くさくなって放置している

542 :仕様書無しさん:2012/09/02(日) 12:30:50.24
大した規模でもないのにいたるところにboolが氾濫して混乱するし、微妙なtypoがムカツク

#define T 1 // hogeh
#define true -1 // fuge.h
#define Ture 1 // fuga.h


543 :仕様書無しさん:2012/09/02(日) 13:05:50.14
ソースのコメントアウトの件は、発注元の役所なりの要求だから残さざるを得ない。
自社で開発して維持してるならともかく、年度契約とかで落札した案件じゃ、渡されるのは生ソースのみ、納入するのも生ソースのみ、一応コメントアウトが役に立つ場合も少しだけはあった。

544 :仕様書無しさん:2012/09/02(日) 14:07:50.70
10年以上次の状態のソースを何人も手を入れたソースをいじることになった…orz

・修正時はコメントにし、新たな記述追加
・なんでもグローバル変数で、あちこちからアクセス
・一番最初のコーディングスタイルがみんな嫌いだったのか、スタイルが統一されていない

みんな、その場さえしのいで逃げちゃったw

545 :仕様書無しさん:2012/09/02(日) 14:17:20.91
ちょっと日本語がおかしいですね

546 :仕様書無しさん:2012/09/02(日) 14:33:07.35
544の書くコメント文にイラっとする人は少なくないはず

547 :仕様書無しさん:2012/09/02(日) 14:58:51.23
>>544
おまいの日本語はアレだが内容については激しく同情する。

似たような状況のVB6ソースをC#に移植するプロジェクトに投入させられたのだが
どうやって逃げようか検討中だ。

548 :仕様書無しさん:2012/09/02(日) 15:26:10.97
別言語への移植だったら、表面上の動作だけ同じで、旧ソースは読みもしないってわけにはいかんかな?

549 :仕様書無しさん:2012/09/02(日) 15:40:52.12
それがいい
リファクタリングの名の下に好き放題やっちまえ

550 :仕様書無しさん:2012/09/02(日) 15:56:46.29
>>548
バグが有った時に元のソースを確認しやすいと言われる。
主に目Grep、日付フォルダバージョン管理システムが主流の
ところでよく言われる。

551 :仕様書無しさん:2012/09/02(日) 16:01:32.23
クソソースはもう読みたくないマジで
そんな俺は職業プロ失格なんだろうなきっと

552 :仕様書無しさん:2012/09/02(日) 16:27:00.94
>>548
細かいとこで相違点でまくりでフルボッコにされるわwww

553 :仕様書無しさん:2012/09/02(日) 16:33:53.58
細かいところまで同じを望むのなら、システム変更する必要ないのに。
VB6のソフトの外面をC#で包むだけで検収通るかもしれないぞ。

554 :仕様書無しさん:2012/09/02(日) 16:41:46.24
相手方にはソースも渡しますorz

555 :仕様書無しさん:2012/09/02(日) 20:01:23.07
>>551

それでずっと通ってきたのなら、いい環境だったのだと思う。

最近そんなのばっかで、これで金をもらってるからしょうがないと思うようにしてるが、
実際他の派遣さんはすごく嫌がって、なるべく関わりあいになりたくないのがありありと分かる。

最近だと、機能修正で判定するロジックをちょっと変えるのに、("<"を"<="に変更するレベル)
関数の追加は機能修正なので禁止とか言われて、いちいちその場で
全部コピペしまくって直してた。

1回目の修正は頑張ったけど、その後、それだと仕様に問題が
あるとわかって更に徹夜で修正させられたときはマジデ泣けた。

556 :仕様書無しさん:2012/09/02(日) 21:04:12.15
>>544
その手は結局自分の担当範囲だけ自分の分かるように作るのが一番だってオチに行き着くんだよね。

557 :仕様書無しさん:2012/09/06(木) 00:58:52.61
似たような処理があったらコピペするという発想が生まれるやつは全員しねばいいとおもう
共通化できるならユーティリティ的な処理として切り出せ、コピペするなよ
修正量が倍倍になっていくっつのアホか!!!!

っていう愚痴(´・ω・`)

558 :仕様書無しさん:2012/09/06(木) 01:32:35.04
1個所のロジック使いまわすと、そこがダメになった時全部だめになるじゃないか!

と逆切れされたんだが、俺の1徹半目の頭では反論が思い浮かばなかった
てか言葉が思い浮かばなかった

559 :仕様書無しさん:2012/09/06(木) 02:05:56.20
皆さんは1行だけのif文ってカッコつけますか?
自分は何行だろうと付ける習慣がついてるんだが

560 :仕様書無しさん:2012/09/06(木) 02:24:09.90
昔読んだ本に1行でも修正で複数行になることがあるので最初から付けておいた方がいいと書いてあった
今は付けなくなったけどw

561 :仕様書無しさん:2012/09/06(木) 06:37:20.09
処理ブロックを見た目で明確にするためにも付ける派

562 :仕様書無しさん:2012/09/06(木) 08:06:43.59
>>558
一箇所だめになっても全体では大丈夫(結果に影響しない)ということは、
その箇所はそもそも不要だったってことにならない?

それから、ここはダメでもほかはOKということは、
そもそもそのダメになった箇所は他とは別の位置づけだったということで
それなら”その箇所に”使い回しをしたこと自体がおかしいでしょ

結論として、基本設計がタコでゲソ

563 :仕様書無しさん:2012/09/06(木) 09:09:09.43
その先輩の真意はわからんが、バグやなんかの修正で、そこに依存する部分が
多すぎると逆に大変、てのはあるな。
それも含めて、共通モジュールはそれを利用する側よりしっかりと設計・実装
する必要があるわけだが、同じような処理だからまとめてしまえ、ってのも
その意味では安易すぎるだろ。

564 :仕様書無しさん:2012/09/06(木) 10:27:02.92
>>563
おいおい、問題のあるコードを
百箇所に以上にコピペしちゃうのと、
一箇所にあるコードを百箇所で呼び出してるのと、
イザ実際に問題発生した場合どっちが収束早いと思う?
もちろんコピペ箇所の発見から始めるんだぜ。

565 :仕様書無しさん:2012/09/06(木) 12:23:47.33
>>564
問題のあるコードを残してる方が悪い。
100箇所コピペする前に修正しろよ。

566 :仕様書無しさん:2012/09/06(木) 12:26:02.21
似たような処理をまとめた共通処理は、
時間が立つと共通処理じゃなくなってくるのが問題。

567 :仕様書無しさん:2012/09/06(木) 12:26:15.04
まあ、たいていの場合
コード書く連中と、
数ヶ月後に不具合が発覚して修正する連中は
別の人なんだけどね

568 :仕様書無しさん:2012/09/06(木) 12:33:44.28
仕様レベルで同一な事を指しているかどうかが肝だな。

569 :仕様書無しさん:2012/09/06(木) 21:12:30.86
共通処理を基底クラスにまとめているようなプロジェクトには近寄りたくないな

570 :仕様書無しさん:2012/09/06(木) 22:40:27.57
え? その為のモリタポイズムだろ?

571 :仕様書無しさん:2012/09/06(木) 23:24:15.81
古いソースコードをコメントアウトに#if 0 〜 #endif 使うのマジでやめて欲しい


572 :仕様書無しさん:2012/09/07(金) 10:41:11.65
>>571
統合環境使えよ

573 :仕様書無しさん:2012/09/07(金) 11:45:59.68
古いコードをコメントアウトって時点でwww
残さずきっちり削除してしまえwwww

574 :仕様書無しさん:2012/09/07(金) 12:46:54.52
>>573
とあるメーカーのコードは、歴代機種の残骸が漏らさず残ってるぞ。
なんでって、それがそのメーカーの社内ルールだから、外部者もそれに従う。
おかげで有効なコードが全体の一割しか無いとか普通。

575 :仕様書無しさん:2012/09/07(金) 13:31:32.46
>>572
統合環境でも対応できないことが多々あるからなぁ。
灰色になってたから、コメントアウトされてるんだと思ってたら
実は生きていたとか。

576 :仕様書無しさん:2012/09/07(金) 13:38:39.08
>>575
そう言うのはステップ実行するしか無いなw

577 :573:2012/09/07(金) 13:53:16.16
>>574
実はうちのも結構コメントが多かったりするw
フリーソフト駆使して数えてみたら有効なコードは六割だった。
バッサリ削除してぇ。

578 :仕様書無しさん:2012/09/07(金) 14:01:55.43
フリーソフトのコードがメーカー謹製のコードに入ってるわけ無いけどな。

579 :仕様書無しさん:2012/09/07(金) 17:41:07.40
突然何を言っているんだ?

580 :仕様書無しさん:2012/09/07(金) 20:11:12.53
:   |: l    |  |:   /  :|│      |   l |   :| |              | \__
:   |: l    |  |   /|   :|│      |   l |   :| |              |  '⌒)
:   |: l: __/|  |:  l│  │     、 _|_,,...斗匕゙∧|    |        |, ゙  ∧
:   |: |   |人`T¬ト|--ヘv|      |   /| __/  |    |         ;   ハ
: : . |::八 :ルィ斧芋ミ∧  │      :ルイ斧芋弌ミ|_/|          ト :|  ! |│
::::::::|::. |〃  ん::(,,ハ`ヾ 八     〃 ん::(,,ハ  }i |  ′      | |  { |│ 「バレなきゃ
::::::.八 _圦   {/{:::::j゜|   :    丶  /:  {/{:::::j゜| ノ゙ リ /  |  {「\|│ l.   lV        犯罪じゃないんですよ」
::::::::.   |    乂_ン _: : \ \∨ : : _ 乂_ン ,  /   '   |   Y| |.   | ∨
::::: |\八   ` ー…_彡    \/\  `ー…_彡 /|/      |   'レ"⌒\|乂\
::::: |  丶\ ::::::::::.               .:::::::::./  //     リ  /  ヘ.  \  ̄
 :::∨    \__           {          ∠二イ゙::/ :|   /    /   \. }
  ::\\    <__                八/  |  ,゙   ノ_,|   ヘ、  〉
\  :::|\\____/                .:':::/    |/{  {_ノ| /     ハ
,'∧:\|   ゝ .        '⌒^`       イ/:::/  ///八   [〈  r'-  }∧
/,'∧     ∨ >            _ <///:::/    ////ハ / ト、 }  /'/∧
//,'∧     ∨///{≧o。  ..__,.. <//////:::/    /,'/////}/  └ ´ /'////〉

581 :仕様書無しさん:2012/09/07(金) 20:22:10.26
なにこの流れw

582 :仕様書無しさん:2012/09/07(金) 21:47:25.50
変数名とか関数名を変えたり関数の順番書き換えたりして使ってるわw

583 :仕様書無しさん:2012/09/07(金) 23:12:05.90
>>576
うちはエラーになるように書き換えて
コンパイルエラーが出るか試してたわw


584 :仕様書無しさん:2012/09/08(土) 03:34:57.89
自分が過去に書いたソースで、実際には再利用されることがありえない
オブジェクト指向の箇所は削除して回りたい

585 :仕様書無しさん:2012/09/08(土) 09:50:17.34
>>584
なんで?

586 :仕様書無しさん:2012/09/08(土) 11:53:56.92
今の現場の場合、予想ステップ数と実ステップ数を比較して、
進捗率を図るwので、古いソースコードをコメントアウトしてる。

行数が減ると生産性がマイナス評価を食らう。
予定行数より足りないとわざわざループ開いて水増ししてる人もいるが、自分はコメントで水増しをしてる。

そんなんだからゴミみたいなコメントとコードが減らない。

そもそも、C言語で1ステップって1行なのかずっと疑問に思ってる。

587 :仕様書無しさん:2012/09/08(土) 12:00:49.63
「予想ステップ数」を出せるのがスゲーわ。

588 :仕様書無しさん:2012/09/08(土) 12:11:28.98
>>587
おれも馬鹿だと思うけど、コーディングとかしたことない人間が弾きだしてる。
毎回全く当たらないが、儀式のように見積もってる。

589 :仕様書無しさん:2012/09/08(土) 13:58:02.05
>>586
まだそんなとこあんのか
納品用ソースコードを生成するコード用意しとくと捗りそうね

590 :仕様書無しさん:2012/09/08(土) 14:20:56.98
>>588
見積もるだけならまだいいが実際とずれたときに原因分析までやるようになったら末期

591 :仕様書無しさん:2012/09/08(土) 15:06:51.18
やってるんならマシだと思うけどね。
プログラミングはできなくても管理のプロフェッショナルなんてのが
そういう役割してたりするし。

592 :仕様書無しさん:2012/09/08(土) 15:33:16.26
往々にして、管理のプロフェッショナルに合わせることが目的になってたりするけどな。

593 :仕様書無しさん:2012/09/08(土) 16:04:20.29
管理のプロフェッショナル様のお使いになられている情報は
現場が手間暇かけて作り上げています。
どうぞ有意義にご活用くださいませ。

594 :仕様書無しさん:2012/09/08(土) 16:07:01.23
まともな予実管理しないで数字合わせを強要するのは
そもそも「管理のプロフェッショナル」とは言えんだろう。

595 :仕様書無しさん:2012/09/08(土) 16:50:34.39
ここって管理スタイルスレだっけ?

596 :仕様書無しさん:2012/09/08(土) 18:58:14.04
そういう管理者がイラッつとするコーディングスタイルを生んでいるって話だろう
>586を見よ

597 :仕様書無しさん:2012/09/08(土) 19:13:15.82
報告する側も適当な辻褄合わせをするからそんな意味のない管理が
いつまでも続いているんだろう。管理者の側からはその管理方法で
プロジェクトがちゃんちゃんと進んでいるようにしか見えないからな。
似たような話がワインバーグの本に書いてあったはず。

598 :586:2012/09/08(土) 22:30:36.13
>>593
まさにそれだwwww
このスレで初めて腹抱えて笑えた。

ちなみに品質向上でナゼナゼ分析もやってるんだけど、
ダレダレ分析になって犯人を挙げることに目的が変わってるから、儀式だよね〜

そして人はノイローゼになって、い亡くなり、根本原因にたどり着かず品質も向上しないし
見ててイラッとするコードになる。

599 :仕様書無しさん:2012/09/08(土) 22:53:47.86
>>598
だって馬鹿な顧客が月例会議で進捗率を要求するんだもの
月次報告書に載せる数字が要るんだもの


600 :仕様書無しさん:2012/09/08(土) 23:41:38.67
胃が痛くなる話ばかりだ
管理の奴らの分析って、諍いの原因創出とマの神経摩耗以外に価値あんのかねw

特にドラッカー敬愛してる奴らの要求の意味不明さが疑問だったので読んでみてるんだけど、
別に理不尽な事が書かれてる訳でも無くて尚更混乱する

601 :仕様書無しさん:2012/09/08(土) 23:48:04.28
>ちなみに品質向上でナゼナゼ分析もやってるんだけど、
>ダレダレ分析になって犯人を挙げることに

元請けのデバッグ屋が馬鹿なせいなのか、陰謀なのかわからないけど
リリース前の不具合が孫受けの俺のせいにされそうです!w

602 :仕様書無しさん:2012/09/10(月) 23:34:17.58
古いコメントも重要な情報なので消さないで残しましょうと言われたorz

// del // とか
/* 以下削除コメント */ とか

禿げそう…

603 :仕様書無しさん:2012/09/10(月) 23:45:53.44
//の形式ならまだ許せるが
/*〜*/の形式でそれをやられると殺意がわく

604 :仕様書無しさん:2012/09/11(火) 00:25:16.33
>>603
まさにソレ
grepしただけだとわからないという…

605 :仕様書無しさん:2012/09/11(火) 23:07:34.68
>>600
管理の奴らの分析って、最初に理屈が通るストーリーを作って、
そのストーリーに当てはまる原因を「考えている」
ストーリー上で説明の付かない原因は「認めない」

606 :仕様書無しさん:2012/09/12(水) 00:12:58.04
コーディング規約に、
コメントは /*...*/ のみ。 // ... 禁止。
ってのがあって萎えた。

607 :仕様書無しさん:2012/09/12(水) 01:02:32.75
C言語ならわりと普通。

608 :仕様書無しさん:2012/09/12(水) 01:19:41.04
>>605
ああ、なんか凄く納得
それを防ぐ効果的な方法論書いてる本でもないかなw
ジュンクあたりでゆっくり立ち読みしてくるわ

609 :仕様書無しさん:2012/09/12(水) 10:46:01.10
>>606
コメントの内容でコンパイラがエラー吐いたりする事あるから・・・

610 :仕様書無しさん:2012/09/12(水) 11:40:39.32
いまだにC99未対応(コメントだけすら)のコンパイラ使ってるところあるんだな
てか、コンパイラが対応してるのにデフォのオプション設定が未対応になってて、それを変更してないからエラーとかってところもあったなw

611 :仕様書無しさん:2012/09/12(水) 12:21:05.15
C99対応のコンパイラでC99としてコンパイルするんならいいんだけどね。
言語としては未対応なのに、コンパイラが対応してるからという理由では
//コメントは使えない。

612 :仕様書無しさん:2012/09/12(水) 13:47:42.30
でも動くし

613 :仕様書無しさん:2012/09/12(水) 16:55:20.97
最近のコンパイラならC++形式のコメントを許可するとかってチェックあるよな

614 :仕様書無しさん:2012/09/12(水) 19:06:45.25
みんな使えるんだけど、移植性のため規約はC89どまりってのはあるな。うちだけど。

615 :仕様書無しさん:2012/09/13(木) 23:41:40.07
実際に//が使えないコンパイラに移植する機会はあるの?

616 :仕様書無しさん:2012/09/14(金) 01:12:57.99
<table>
<% If isAdmin Then %>
 <tr>
  <td>管理者:<%= rs.("USERNAME") %></td>
  <td>ユーザID:<%= rs.("USERID") %></td>
  <td>所属:<%= rs.("DIVISION") %></td>
 </tr>
<% Else %>
 <tr>
  <td>登録者:<%= rs.("USERNAME") %></td>
  <td>ユーザID:<%= rs.("USERID") %></td>
  <td>所属:<%= rs.("DIVISION") %></td>
 </tr>
<% End If %>
</table>

617 :仕様書無しさん:2012/09/14(金) 01:15:38.36
× rs.("USERNAME")
○ rs.Item("USERNAME")

>>616間違えたorz

618 :仕様書無しさん:2012/09/14(金) 19:07:14.56
ははっVBとASP.NETか
rs(foo)とかユーザコントロール作ってバインドしろという話し?

管理者と登録者にラベル使えってことか

619 :仕様書無しさん:2012/09/14(金) 22:47:24.25
どういう経緯でこうなったんw

620 :仕様書無しさん:2012/09/14(金) 22:49:48.12
<table>
 <tr>
  <td><% If isAdmin Then %>管理者:<% Else %>登録者:<%= rs.("USERNAME") %></td>
  <td>ユーザID:<%= rs.("USERID") %></td>
  <td>所属:<%= rs.("DIVISION") %></td>
 </tr>
</table>

せめてこうしてくれ

621 :仕様書無しさん:2012/09/14(金) 22:50:31.30
あ End If 忘れた どうでもいいけど

622 :仕様書無しさん:2012/09/14(金) 23:06:19.19
少しも問題の本質にかすってねえしwwwwwwwwwwww

623 :仕様書無しさん:2012/09/14(金) 23:12:28.72
これ問題の本質なるものが介在してるとですか。すまんわからんw
vbつーか.netよう知らんけど

624 :仕様書無しさん:2012/09/14(金) 23:14:25.25
VBもHTMLに埋め込むことができたのか
PHPではなさそうだし何のタグかと思った

625 :仕様書無しさん:2012/09/15(土) 08:40:28.04
知らない言語だとどうもピンと来ないな。
俺も最初は>>616みたいに書いて、使い慣れた1週間後くらいに書き直す気がするw

626 :仕様書無しさん:2012/09/15(土) 08:51:27.63
>>620みたいに複数の節を一行にまとめられると見にくいから

<table>
 <tr>
  <td>
   <% If isAdmin Then %>
    管理者:
   <% Else %>
    登録者:
   <% End If %>
   <%= rs.("USERNAME") %>
  </td>
  <td>ユーザID:<%= rs.("USERID") %></td>
  <td>所属:<%= rs.("DIVISION") %></td>
 </tr>
</table>
こんなかんじかな

627 :仕様書無しさん:2012/09/15(土) 09:03:55.27
HLTMLの構造を維持しつつ埋め込みという意味で
>>626より>>620の方が俺には解析しやすい。

628 :仕様書無しさん:2012/09/15(土) 13:15:23.56
HTML(+埋め込み言語)の場合、あとで非プログラマのデザイナーがメンテナンスすることを考えて、
行数削減よりもとにかく可読性を高めたほうが正しいと思う。
だから>616もありえなくはない。

629 :仕様書無しさん:2012/09/15(土) 14:01:47.41
つか、ビューに条件判断なんか入れるんじゃねぇよ

630 :仕様書無しさん:2012/09/15(土) 14:16:10.17
それはMVCをちょっとかじっただけの奴によくある間違い。
オブジェクトの設計論なんだから、MVCそれぞれが内部にロジックを
持っていて何もおかしくない。
逆に、Viewでやるべきロジックを全部Controllerに持たせていたりしたら
そっちの方がおかしい。

631 :仕様書無しさん:2012/09/15(土) 15:46:06.91
プログラムのバグはどうとでもなるけど、
Webの見た目がゴネ始めると辛いからな・・・

632 :仕様書無しさん:2012/09/17(月) 21:18:09.29
>>2
何故か俺のコードに対して、解り易いと言われた
もちろん左に定数書いていたw

633 :仕様書無しさん:2012/09/18(火) 11:47:16.72
>>622のいう本質っていったいなんだったんだろう・・・・

634 :仕様書無しさん:2012/09/18(火) 19:17:21.56
ここは本人にタネあかししてもらわんと本当のところはわからんが、
>>629というオチじゃね?

635 :仕様書無しさん:2012/09/19(水) 09:05:23.56
ってことは、
rsの中に「管理者」か「登録者」を示すカラムを入れておく

Userクラス作って「管理者」か「登録者」を返すメソッドを用意する(rsの内容もUserクラスに)


636 :仕様書無しさん:2012/09/19(水) 20:21:36.60
#if HOGE
public class Service : Hoge.hoge.Service {}
#slif FUGA
public class Service : Fuga.fuga.Service {}
#slif HAGE
public class Service : Hage.hage.Service {}
#endif

書いたやつ氏ね。

637 :仕様書無しさん:2012/09/19(水) 20:22:09.73
slifちゃうelifだった。typoしたままコピペってもうた

638 :仕様書無しさん:2012/09/21(金) 14:16:55.17
おまえにイラッつとするわ
てか、おまえみたいなのがイラッつとするコードを量産してるんだろうな

639 :仕様書無しさん:2012/09/22(土) 08:08:40.91
イライラの大半は構文だけあっているものや、コメントに存在する
IDEがそういう風に育ててる気すらしてくる

640 :仕様書無しさん:2012/09/22(土) 11:22:32.62
あと規約

641 :仕様書無しさん:2012/09/22(土) 11:29:34.21
>>632
え?左に定数が常識じゃないの?条件文。
ゆとりはどうか知らんけど〜

642 :仕様書無しさん:2012/09/22(土) 11:52:19.19
>641
いろんなソースを見てきたが、少なくとも『常識』ではなかった。

643 :仕様書無しさん:2012/09/22(土) 13:42:32.16
おれよくこういうコード書くけどダメなんか?

if ( 0< hoge && hoge <= max )


644 :仕様書無しさん:2012/09/22(土) 13:47:20.30
別に普通なコードだと思いますが

645 :仕様書無しさん:2012/09/22(土) 14:14:04.40
結局、左右どっちでも書くから固定するのが常識という訳ではない。という話。

646 :仕様書無しさん:2012/09/22(土) 14:23:18.10
javaでは 定数.equals(変数) にしろとよく言われる

647 :仕様書無しさん:2012/09/22(土) 14:27:04.69
>>643
括弧でくくれよハゲ

if ((0 < hoge) && (hoge <= max))

648 :仕様書無しさん:2012/09/22(土) 14:33:15.08
この程度で括弧つけると逆に読みにくくなる

649 :仕様書無しさん:2012/09/22(土) 15:15:13.50
さすがに>>463にカッコつけるのはどうかとおもうが、ORとANDの優先順位が自明かどうかで悩むときがある
論理「和」と論理「積」なのだから順位は自明でカッコつけるのは汚いだけ、と個人的には思うんだけど

650 :仕様書無しさん:2012/09/22(土) 15:37:01.15
その辺は、同一プロジェクトに馬鹿が混ざってるかどうかで変わるんじゃね
格好つけずに括弧つけとけハゲ

651 :仕様書無しさん:2012/09/22(土) 15:37:43.09
>649
(〜&&〜) || (〜&&〜) のときだよね?
俺が大丈夫でも引き継ぎした新人が間違えるかもしれないからカッコつける。

652 :仕様書無しさん:2012/09/22(土) 15:42:43.60
ふふふ、みなさんはまたしょうもないことでお悩みのようですね…… Lispを使えば優先順位など関係無いのですよ! ふあはは ふはは ふはははは

653 :仕様書無しさん:2012/09/22(土) 15:48:48.22
君はもとから括弧だらけじゃないか

654 :仕様書無しさん:2012/09/23(日) 00:16:53.84
bool b=(((a&0x1)==0x1)?true:false);

655 :仕様書無しさん:2012/09/23(日) 00:20:59.54
>>654
やめろ糞デブ!

656 :仕様書無しさん:2012/09/23(日) 01:27:13.08
>>649
どう書かれているかだけじゃなく、どういう意図かにもよる
文法だけで判断するのはまちがい

657 :仕様書無しさん:2012/09/23(日) 14:13:30.81
>>646
作法だよね。ドットネットじゃあまり普及してないけど
ちゃんと定数は左に書け、
と思う。

658 :仕様書無しさん:2012/09/24(月) 00:19:18.39
>>654
こういうので、1→trueの自動キャストってやっていいもの?

659 :仕様書無しさん:2012/09/24(月) 00:32:54.80
ダメ

660 :仕様書無しさん:2012/09/24(月) 02:21:44.53
好きじゃないけどこんなbool変換もあったね。

bool b = !!a;


661 :仕様書無しさん:2012/09/24(月) 06:43:23.62
「ノンゼロは真にキャスト」って、言語仕様のレベルで規定されていなかった?

662 :仕様書無しさん:2012/09/24(月) 07:56:17.47
Cでは、ノンゼロは真にキャスト、真は1にキャスト、と定義されていたはず

663 :仕様書無しさん:2012/09/24(月) 18:00:15.02
そんなks言語捨てちまえよ

664 :仕様書無しさん:2012/09/24(月) 18:06:55.47
偽は0、真は1つーとPythonもそーだな
別にクソとも思わんが

665 :仕様書無しさん:2012/09/25(火) 17:41:53.91
#defone TRUE (0==0)
#define FALSE (!(TRUE))


666 :仕様書無しさん:2012/09/25(火) 17:56:19.89
誤字でいらっと?

667 :仕様書無しさん:2012/09/25(火) 19:45:56.75
>>641
俺以外はみんな右に定数だったなぁ

668 :仕様書無しさん:2012/09/25(火) 20:33:25.17
別にどっちでもいい
一方に強制しようとする奴が馬鹿なだけ

669 :仕様書無しさん:2012/09/25(火) 21:29:19.74
>>606
MISRAで/*...*/に決まっていますので・・・
ありがとうございました

670 :仕様書無しさん:2012/09/26(水) 10:19:24.98
ありがたくねえけど
「ありがとうございました」としか言いようのない気分になった

671 :仕様書無しさん:2012/09/27(木) 12:24:13.27
https://twitter.com/void_No3/status/250896800112844800

たしかに林晴比古推奨な時点で定数左は終わってるな

672 :仕様書無しさん:2012/09/28(金) 20:35:20.81
voidまだネットで活動してたんだ
すげーな

673 :仕様書無しさん:2012/09/28(金) 22:46:26.00
今だにCだけの知識で頑張ってるよ。


674 :仕様書無しさん:2012/09/29(土) 22:14:25.74
条件文が長くなって複数行になるとき、短い方を先に書くのが解りやすいから、
定数を左にしているよ

675 :仕様書無しさん:2012/09/29(土) 22:25:47.65
俺は、定数名は長く、変数名は短くするけどなぁ。ふつうそうじゃないか?

676 :仕様書無しさん:2012/09/29(土) 22:29:45.97
たとえば変数statusに入れる定数はSTATUS_RUNNINGとSTATUS_WAITINGみたいに、
定数はプリフィクスが長くなるから自然と長い名前になる。

677 :仕様書無しさん:2012/09/29(土) 23:00:55.12
条件文が長くなるのって、コーディングスタイルに問題があることを暗示しているんじゃないかと思う

条件文に限らず、1行で書くべきコードがつづら折りになっているのもそうかもしれない

678 :仕様書無しさん:2012/09/29(土) 23:14:29.67
同一仕様のコードで比較した場合はそうも言えるかもしれないけどね。
仕様を考慮せず絶対的な長さの比較だけなら、コーディングの問題の
有無とはほとんど無関係だろ。

679 :仕様書無しさん:2012/09/29(土) 23:32:26.40
話題ずれてね?まあスレ的には今更か
どんな複雑怪奇な仕様だったらその手の汚いコードを許容できるんだろ。時間ないときの仕様変更かな
はじめから複雑な仕様なら設計でクリアに扱えるよう努力するし、余裕あるときの仕様変更なら腕の見せ所だとばかりになんか燃えるw

個人的には、イライラするコードに陥りがちな要因は、仕様よりは謎スタイルを強制される時に多発する印象

680 :仕様書無しさん:2012/09/29(土) 23:39:43.04
値の上限と下限をチェックするだけでも単純に長くなるだろ?
なんか努力すればそれを短くできるのか?

681 :仕様書無しさん:2012/09/30(日) 00:36:55.19
何言いたいのか明確にしてけろ
前提語らなきゃ「関数化なりマクロ適用するなりクラス設計で吸収するなり好きにしろボケ」みたいな事しか書けないが、そういう回答は望んでないんだろ
定数が長いんだろ。で、一体どういう状況で何にお困りなんだ?
言語の想定は任す

682 :仕様書無しさん:2012/09/30(日) 00:45:00.96
困 ←凝視していると松井に見えてくる

683 :仕様書無しさん:2012/09/30(日) 00:47:11.55
>>681
誰に言ってんのかわからんからアンカーつけろ

684 :仕様書無しさん:2012/09/30(日) 01:19:10.75
>680
言語側に努力してほしいね
if (20 <= age && age <= 60) ってのを
if (20 <= age <= 60) って書ければいいんだ

685 :仕様書無しさん:2012/09/30(日) 01:25:15.89
>>684
(・∀・)イイヨイイヨー

686 :仕様書無しさん:2012/09/30(日) 01:44:21.30
>>684
理想っぽいけど優先順位以外の演算子のルール増えてますよねそれ
実装してる言語ってあります?



687 :仕様書無しさん:2012/09/30(日) 02:09:40.16
>>686
結合性の規定があるから一意に決まるだろ?

688 :仕様書無しさん:2012/09/30(日) 02:23:48.32
>>687
型が混ざるとそう簡単には決められないかと
全体をboolとして評価するルールが必要になり、その場合の結合法則がまた必要になってとBNF相当混乱するんじゃないか

689 :仕様書無しさん:2012/09/30(日) 03:11:09.34
関数作るのがそんなに面倒くさいか

690 :仕様書無しさん:2012/09/30(日) 04:06:56.85
if(age.ge(20).and.ge(60))
これで読みやすい。

691 :仕様書無しさん:2012/09/30(日) 07:15:29.46
(if (< x y z) hoge fuga)
やはりLispは最強か

692 :仕様書無しさん:2012/09/30(日) 07:25:26.40
sorted :: (a->a->Bool) -> [a] -> Bool
sorted _ [] = True
sorted _ [_] = True
sorted comp (x1:x2:xs) = comp x1 x2 && sorted comp (x2:xs)
if ( (<) `on` age) [person1, person2, person3]

693 :仕様書無しさん:2012/09/30(日) 11:05:45.15
実際に左に定数を強要された人はいるの?

694 :仕様書無しさん:2012/09/30(日) 12:17:24.77
>>693
ほとんどの会社のコーディング規約が、条件式中の定数は左に書くようにと定めてるよ。

695 :仕様書無しさん:2012/09/30(日) 14:19:20.21
つまりコーディング規約を作ろうなんて思う奴は馬鹿なのさ

696 :仕様書無しさん:2012/09/30(日) 15:50:09.56
>>694
マジデ?
その割には見かけないけど

697 :仕様書無しさん:2012/09/30(日) 15:53:55.70
某ゲーム機のサンプルが左側定数だったような気がした。

698 :仕様書無しさん:2012/09/30(日) 18:41:19.42
>>694
俺はそんなコーディング規約は見たことがない。
多いかもしれないがほとんどってのは眉唾もんだな。

699 :仕様書無しさん:2012/09/30(日) 20:38:58.60
決めたころに==演算子の左辺は定数にしようというバカげたな主張がまかり通っていただけでしょ。

700 :仕様書無しさん:2012/09/30(日) 20:54:14.18
逆に、なんで定数が右じゃないとイヤなのか理解できない

701 :仕様書無しさん:2012/09/30(日) 20:54:54.90
ルールは偉い人が決めるからね
どうでもいい項目に角を立てて反対する理由もない

702 :仕様書無しさん:2012/09/30(日) 20:59:05.01
>>700
日本人だから。

703 :仕様書無しさん:2012/09/30(日) 21:20:26.50
他人のコードを読む場合は、左定数だろうが右定数だろうがどうだっていい
自分が書くコードは、自分の流儀に反するスタイルを強制されるとイラっつとする

結論:各自好きなように書け

704 :仕様書無しさん:2012/10/01(月) 00:00:50.03
本来 == と書かなきゃならない所を

if (FIXEDPARAM = testdata ) { func(); }
って間違えて書いてコンパイルエラーで救うためさ

これが右定数だったら、
if (testdata = FIXEDPARAM ) { func(); }
必ず通るか、必ず通らないってなるからな。

まあ、こういう間違いはワーニングレベル高くしとけばレポート出るけど
ワーニングは無視する奴らだと、BUGが潜在化するからな。

705 :仕様書無しさん:2012/10/01(月) 00:09:57.13
>>704
そんなことするくらいだったら
#define EQUALS ==
ってやっときゃもっと確実じゃね。

706 :仕様書無しさん:2012/10/01(月) 00:15:36.39
>>705
if ( FIXEDPARAM EQUALS testdata ) { foo(); }
誰がメンテすんだよこんなもんw

707 :仕様書無しさん:2012/10/01(月) 00:20:01.94
別に関数ぽく書いてもいいぜ。
#define EQUALS(a,b) a == b

= と ==を間違えるっていうんならこれくらい徹底すべき。

708 :仕様書無しさん:2012/10/01(月) 02:52:07.82
経験20年以上のプログラマですが、
=と==を書き間違えたことなど一度もないです。
ほんとにそんなミスあるの?


709 :仕様書無しさん:2012/10/01(月) 03:03:00.29
>>708
俺もたまに思う
あってもテストでさくっと潰せる程度の問題しか経験ないす
過去にそれに起因するよほどのバグでもあったのかね

710 :仕様書無しさん:2012/10/01(月) 05:22:37.18
>>708
他人のコードメンテする機会があると、笑っちゃうようなミスが沢山あるぞw
もちろん == と = の書き間違いなんてザラ

711 :仕様書無しさん:2012/10/01(月) 08:57:55.11
代入文がIf文の条件式として使えることに問題があるんでないの?

712 :仕様書無しさん:2012/10/01(月) 09:23:04.22
>>710
他人はともかく、あんたはどうなんだ?

713 :仕様書無しさん:2012/10/01(月) 11:13:37.76
= と == 書き間違えたらデバッグ時に分かるはずなんだけどねぇ

714 :仕様書無しさん:2012/10/01(月) 11:24:21.79
= と == の書き間違えなんて、都市伝説だろ?
そんなものが他人の目に触れたり、コードメンテ(笑)にまわる?
>>710 は、意図的に代入してるのを、盲目的に == に変えたんちゃうか?(笑)

715 :仕様書無しさん:2012/10/01(月) 11:34:50.07
意図してやってるのはまさにイライラするコードだな
稼働中のソースで条件式内代入あったら見なかった事にしたくなるw

716 :仕様書無しさん:2012/10/01(月) 12:39:09.81
>>714
C FAQに載る程度にはよくあるミス
http://c-faq.com/style/revtest.html

そこには、最も経験を積んだプログラマですら犯す可能性のあるミスと書かれている
実際、俺は何度か見たし自分でも何度かやらかしたことがある
俺は右定数派だが、Cとは異なる代入比較演算子を採用している言語で開発した後とかに、まれにやっちまったことがある
コンパイラの警告で潰せるミスだけどな
見たことないって言ってる奴は日曜プログラマかJava厨だろう

717 :仕様書無しさん:2012/10/01(月) 13:25:41.54
>>716
> そこには、最も経験を積んだプログラマですら犯す可能性のあるミスと書かれている

どこにもそんなこと書かれてませんが?

718 :仕様書無しさん:2012/10/01(月) 13:38:44.30
信号は赤、より、赤は信号、って言われた方がしっくりくるチョンコPGだろ

719 :仕様書無しさん:2012/10/01(月) 13:55:38.10
>>717
To be sure, accidentally using = instead of == is a typo which even the most experienced C programmer can make.

720 :仕様書無しさん:2012/10/01(月) 14:33:23.07
>>716
おまえみたいなオナニープログラマの話はどうでもいいんだよ

721 :仕様書無しさん:2012/10/01(月) 14:44:25.98
だから、 ただの typo だろ?
= と == をことさら取り上げる必要あるのか?
辞めたら?プログラマ

722 :仕様書無しさん:2012/10/01(月) 14:50:40.11
>>716
は、その前に英語の勉強をした方がいいな。
老婆心ながら

723 :仕様書無しさん:2012/10/01(月) 14:51:38.29
>>716
ミスが良くあるんじゃなくて、0 = xと書く奴がC FAQに載る程度には有名って事だろ。

> まれにやっちまったことがある
Cは多分50万行くらい書いたと思うけど、こんなミスねーよww

724 :仕様書無しさん:2012/10/01(月) 14:52:21.67
コメント英語縛りは幸いにして未経験
でも、やれって言われたらコメント書く量減る気がする。

725 :仕様書無しさん:2012/10/01(月) 14:59:55.94
>>716
見たことある:
 自分がやっちゃった→お前が未熟なだけ
 他人がやったのを見た→お前の周りは低レベルだらけ

726 :仕様書無しさん:2012/10/01(月) 15:20:16.71
そちゃ、typo はあるだろ、人間だから。
だけど、そんなのに気づかずに人に渡すような奴のプログラム、一から信用できんな。

727 :仕様書無しさん:2012/10/01(月) 15:36:11.83
>>726
だから、定数を左辺に置くスタイルにするんですか?

728 :仕様書無しさん:2012/10/01(月) 15:53:51.85
そちゃとか書くおまえはtypo多いんだろうなあ
つーかtypoが多い奴がtypoを防ぐための工夫を否定してるのか
終ってんな

729 :仕様書無しさん:2012/10/01(月) 16:00:00.70
俺ならtypoを防ぐことよりも可読性を高めることの方を優先するわ。

730 :仕様書無しさん:2012/10/01(月) 16:09:06.92
同値分割くらいやるだろ
そんなテストやりもしないから、左を定数に書けってか

731 :仕様書無しさん:2012/10/01(月) 16:17:00.17
逆に左に定数を書くことでテスト項目減らせるならそれもありかもなw

732 :仕様書無しさん:2012/10/01(月) 16:26:34.35
左定数派は値テストを削ってバグの温床を生むことが証明されたな

733 :仕様書無しさん:2012/10/01(月) 16:36:01.86
a == 0と書こうが0 == aと書こうが、
・aが0の時のテスト
・aが0以外の時のテスト
のどちらもする必要があるだろ。

>>731
一体どのテスト項目を省略するつもりなんだ?

734 :仕様書無しさん:2012/10/01(月) 16:36:43.24
そういうテストで出ない危険性があるから、定数は左なんだよ
何入れてもtrueの場合はどうするんだよ

735 :仕様書無しさん:2012/10/01(月) 16:37:44.05
条件分岐する意味がないですね
左定数派は想像以上のスキルをお持ちのようだ

736 :仕様書無しさん:2012/10/01(月) 16:39:18.59
ワロタ

737 :仕様書無しさん:2012/10/01(月) 16:50:54.05
typoはテストで全部見つけられるものじゃないだろ
typoが多い奴がtypoを防ぐ工夫を否定してるのがひどいわ



738 :仕様書無しさん:2012/10/01(月) 16:53:39.68
>>734
if (a = 0)
と書いてしまったとき、

> ・aが0以外の時のテスト
がパスしないだろ。

739 :仕様書無しさん:2012/10/01(月) 16:57:16.18
左定数派ってテストしないのか

740 :仕様書無しさん:2012/10/01(月) 16:59:01.71
するだろ

741 :仕様書無しさん:2012/10/01(月) 17:01:02.65
Cならlintかsplintくらい使えよっちゅーことですな

742 :仕様書無しさん:2012/10/01(月) 23:03:50.45

tmpHeikin = (tmpKei=GetKei())/GetKazu();

スキルを見習えと言われた人のコードが関数名とか変数名もほぼそのまま、これだった…


743 :仕様書無しさん:2012/10/01(月) 23:39:16.61
VBじゃないのにVB臭がすごい

744 :仕様書無しさん:2012/10/01(月) 23:54:35.37
なんか>>714が必死すぎて笑える
仕事回してもらえなくてよっぽど暇なんだな

745 :仕様書無しさん:2012/10/02(火) 00:07:23.28
>>723
> Cは多分50万行くらい書いたと思うけど、こんなミスねーよww
50万行程度じゃ、2〜3年程度の経験だろ
まだまだだな

746 :仕様書無しさん:2012/10/02(火) 00:29:49.12
最近の本「リーダブルコード」の7.1「条件式の引数の並び順」では
調査対象となるものを先に書くのが自然になる。と書かれているね。
ついでに定数を左に書くヨーダ記法は過去のものである。とも。


747 :仕様書無しさん:2012/10/02(火) 00:37:31.44
>>746
へー。海外にもあるんだ。
日本ローカルのルールだと思ってた。
仕事でアメ人やインド人のコード読んでるけど定数左に書いてるのは見たことないな。
やってるのは日本人のしかもスキルが微妙なやつだけだったりw

748 :仕様書無しさん:2012/10/02(火) 00:38:22.39
それを否定してる奴はいないんじゃね?

= と == を間違えるなんて見たことないしありえない

C FAQには、ありうるtypoだと載ってるが

どこにも書かれてませんが?

> To be sure, accidentally using = instead of == is a typo which even the most experienced C programmer can make.

発狂

というつまんねー流れ


749 :仕様書無しさん:2012/10/02(火) 00:46:31.98
typo で間違えることはあるけど両方変数だったらどうしようもないしな。
つまらん小細工よりリーダビリティのほうが重要だよ。


750 :仕様書無しさん:2012/10/02(火) 02:18:39.91
>>747
> へー。海外にもあるんだ。
> 日本ローカルのルールだと思ってた。

これはもうゆとり乙としか言いようがないw

751 :仕様書無しさん:2012/10/02(火) 02:46:10.32
>>747
ちょっと話はずれるが、最近のインドは日本に特化しすぎて
何も言ってないのにエクセルの方眼紙仕様書とか作ってきてうざいよw
大手企業がインド使いまくるのはのはいいけど、俺ルールゴリ押しして
日本の悪習を世界にバラまかないでくれと言いたい。


752 :仕様書無しさん:2012/10/02(火) 02:51:55.37
定数左に関しては、20年前には既にlint使えよって言われてる話なんだけどな。

753 :仕様書無しさん:2012/10/02(火) 08:33:17.71
>>750
すまんがおっさんだよ。
調べてみたら C FAQ に書いてあるのな。
ここ10年くらい見てないから忘れてた。

754 :仕様書無しさん:2012/10/02(火) 22:51:29.46
C言語のポインタ配列とか配列の参照渡しとかで頭ぐちゃぐちゃですorz

755 :仕様書無しさん:2012/10/02(火) 22:57:29.66
鼻から脳みそ垂れてきてるぞ

756 :仕様書無しさん:2012/10/02(火) 23:34:35.43
鼻から悪魔がじゃじゃじゃじゃーん

757 :仕様書無しさん:2012/10/03(水) 03:53:18.85
20年前にlintねえ

758 :仕様書無しさん:2012/10/03(水) 04:57:47.06
なかったとでも?w

759 :仕様書無しさん:2012/10/03(水) 10:44:28.66
>>757
Wikipediaより
> Lint first appeared (outside of Bell Labs) in the seventh version (V7) of the Unix operating system in 1979.
> It was derived from PCC, the Portable C Compiler, which was included with that system. Lint and PCC
> were developed by Stephen C. Johnson, who also authored the parser generator yacc.

少なくとも、1991年には日本のWSには入ってた。
多分1980年代に普及したんじゃなかろうか。

760 :仕様書無しさん:2012/10/04(木) 02:11:44.08
色々と記憶が薄れているが、1990年代中頃には
PC用の製品(Gimpel SoftwareのPC-lintとか)が
サザンパシフィックなどにより輸入販売されてて
C Journal あたりに広告載せてた。


761 :仕様書無しさん:2012/10/04(木) 07:26:28.52
おまえらは20年前にlintを使ってたの?


762 :仕様書無しさん:2012/10/04(木) 10:41:23.87
20年前はbasicとマシン語で遊んでた

763 :仕様書無しさん:2012/10/04(木) 10:49:54.41
20年間はプログラムなんて他人に組ませればいいと思ってた。
どっかで道を間違えた。

764 :仕様書無しさん:2012/10/04(木) 13:00:53.28
20年前なんて、アセンブラでゲーム作ってよ。
UNIXを使う環境だったけど、そもそもlintなんて使う理由も無かった。


765 :仕様書無しさん:2012/10/04(木) 13:56:07.53
>>764
そりゃ仕事でUNIX Cやってないなら使う理由内でしょ

766 :仕様書無しさん:2012/10/05(金) 00:34:51.04
今日見たイラっとするコード
http://kohada.2ch.net/test/read.cgi/prog/1306646249/746n

767 :仕様書無しさん:2012/10/05(金) 00:44:18.64
定数位置より実害は出ないけど、括弧のスタイルは簡単に人をイライラさせることが出来るよな

768 :仕様書無しさん:2012/10/05(金) 00:55:14.15
TWO == イラッつとするコーディングスタイル->画像>1枚
TWO == イラッつとするコーディングスタイル->画像>1枚
TWO == イラッつとするコーディングスタイル->画像>1枚
TWO == イラッつとするコーディングスタイル->画像>1枚
TWO == イラッつとするコーディングスタイル->画像>1枚
TWO == イラッつとするコーディングスタイル->画像>1枚

769 :仕様書無しさん:2012/10/05(金) 07:21:42.71
何これ、続きがすげえ気になるんだけどw
タイトル教えてくれ

770 :仕様書無しさん:2012/10/05(金) 18:13:39.24
>>766

756 :仕様書無しさん [sage] :2012/10/05(金) 12:10:34.02
>>746とかイラッつとするわw
http://kohada.2ch.net/test/read.cgi/prog/1338703896/l50

757 :仕様書無しさん [sage] :2012/10/05(金) 18:05:32.18
この程度で読みにくいとかイライラするようなプログラマはいらねーな。
レベル低い

771 :仕様書無しさん:2012/10/05(金) 19:55:48.10
不統一な中括弧もうんこだけど if( hoge ){ みたいなカッコの開始終了に無駄ホワイトスペース入れる奴はやめてほしいな。
むしろ外側にスペース入れたいくらい。

772 :仕様書無しさん:2012/10/05(金) 20:04:33.55
if ( hoge ) {
    /* do something */
} else {
    /* do something else */
}
僕なら、こう書くかな

773 :仕様書無しさん:2012/10/05(金) 20:32:31.64
↓俺のバイヴルなんだけど、お前らにもこっそり教えちゃおう☆
http://www.kernel.org/doc/Documentation/CodingStyle

774 :仕様書無しさん:2012/10/05(金) 22:07:09.53
>>773
Linux style か。
Cだけだと 8 タブでいいけど C++ と混ぜると無駄に横長になって見づらいんだよな。
別々のスタイルにする手もあるけどついてこれない人間も出てくるし。

775 :仕様書無しさん:2012/10/06(土) 07:25:45.94
Bivle

776 :仕様書無しさん:2012/10/06(土) 10:47:37.90

1ファイル1万行超えが普通にあるプロジェクトで、万元戸とか言って
バカにしてたら、当の本人に

「知ってるかい?古いVisualStudioは1ファイル65536行超えると
クラッシュしやすくなるから、ちゃんと分割しないといけないんだよ」
とか言われたorz

もう、この人と仕事したくない…


777 :仕様書無しさん:2012/10/06(土) 10:56:24.94
Cがステータスな人とも仕事したくない

778 :仕様書無しさん:2012/10/06(土) 23:21:13.17
Cしかできません(キリッ
っておっさんに会ったことあるけどどうしてるかな。
ご飯食べられてるのだろうか。

779 :仕様書無しさん:2012/10/07(日) 02:21:53.62
組み込み分野で食ってるんじゃないの

780 :仕様書無しさん:2012/10/07(日) 02:23:19.67
文法だけしか知らないのでは?
組み込みは無理

781 :仕様書無しさん:2012/10/08(月) 14:42:13.37
派遣で申し訳ないんだが、今の現場、Cの仕事が一人分以上は楽にあるんだが、
なぜかC言語だけしかできないと落とされるっぽい

オーダー出している人と現場が乖離してるのか、1言語だけだとNGなのか
わからないけど謎

782 :仕様書無しさん:2012/10/08(月) 15:03:29.49
>>781
C言語だけしかできないってのが良くわからん。
普通に考えて、Cがそこそこできれば、C++だってC#だって書けるだろ?


783 :仕様書無しさん:2012/10/08(月) 15:11:41.79
いまどきCしかできないってのは経験不足と見られるんじゃね?
プログラミングはCだけだったとしても、長くやってりゃスクリプト
言語のひとつくらいツールとして使いこなしているのが普通だろうし。
あと、オブジェクト指向言語を経験してないと見られるのも弱いだろうね。
実際の仕事がCだけだったとしても。

784 :仕様書無しさん:2012/10/08(月) 16:10:18.55
表向きの募集と実際の仕事が違うんじゃね?

785 :仕様書無しさん:2012/10/08(月) 17:17:18.81
C以外を使ったシステムも連動してるかもよ
まぁ再利用し辛い人材は使いづらいから要らないんだろ、当然な感じはする。

786 :仕様書無しさん:2012/10/08(月) 19:42:08.99
AもBもなしで、いきなりCからでした。
ただ苦しいだけでした。
今はずっとPTSDのリハビリ中です。

787 :仕様書無しさん:2012/10/09(火) 11:21:24.26
つまらないおっさんのジョークを聞くとイラッつとする

788 :仕様書無しさん:2012/10/09(火) 12:48:12.31
分かる自分もおっさんと言う事に気付いて欲しい

789 :仕様書無しさん:2012/10/09(火) 13:16:57.26
>>787の意図するもの

Ossan res786;
Ossan me;
if (res786.joke() == DULL) {
 me.irritated();
}

>>788

Ossan res786(DULL);
Ossan me(NOTDULL);
me.irritated(res786.joke());

790 :仕様書無しさん:2012/10/09(火) 13:23:25.85
こうだろ

>>787

Ossan res786;
Ossan me;
if (res786.joke() == DULL) {
 me.irritated();
}

>>788

Ossan res786(DULL);
Ossan me(NOTDULL);
if (res786.joke()) {
 me.irritated();
}


791 :仕様書無しさん:2012/10/09(火) 13:56:31.38
>>788
俺わからないんだけど、AとかBとかCについて教えてもらえないかな

792 :仕様書無しさん:2012/10/09(火) 14:02:26.38
意味わかんねーとイラッつとするなw

793 :仕様書無しさん:2012/10/09(火) 15:24:28.07
キスをAとかいうアレか。

794 :仕様書無しさん:2012/10/09(火) 20:07:15.85
>>761
家内制手工業してた

795 :仕様書無しさん:2012/10/09(火) 23:24:07.83
【1】
sqlSelect = "SELECT "
sqlSelect &= "COL1, "
sqlSelect &= "COL2, "
sqlSelect &= "COL3"

【2】
sqlSelect = "SELECT"
sqlSelect &= " COL1"
sqlSelect &= ", COL2"
sqlSelect &= ", COL3"

さてどっちがイラッつとするでしょう

796 :仕様書無しさん:2012/10/09(火) 23:30:52.92
こんなテーブル定義にイライラする

797 :仕様書無しさん:2012/10/10(水) 00:05:13.19
どちらもわざわざ分けて書く必要ないじゃん

798 :仕様書無しさん:2012/10/10(水) 02:28:26.55
COL2とCOL3の間にCOL4が入る仕様変更が来るのが
お決まりの会社なのかもだぜ

799 :仕様書無しさん:2012/10/10(水) 03:28:18.35
&=にイラッとする。

800 :仕様書無しさん:2012/10/10(水) 08:55:03.62
SELECT * のほうがイラッつとする

801 :仕様書無しさん:2012/10/10(水) 09:54:48.82
インデントされてないのにイラっつとする

802 :仕様書無しさん:2012/10/10(水) 18:59:49.43
qstr = _
q.Select_("foo", "bar", "sum(baz) as sum_baz") _
.From_.Lp_.Select_("top 100 hoge", "huga", "*").From_("HOGE").Rp_.As_("T1") _
.Where_(e.Eq_("foo", piyo).And_.Lt_("bar", poyo)) _
.GroupBy_("foo", "bar") _
.Query
どうせ書き捨てのソースだから良いよね、と思って
上みたいな感じでクエリが作れるようにMeを返すクラスを作って魔改造している
これ見せたら先輩になんて言われるんだろ

803 :仕様書無しさん:2012/10/10(水) 22:39:50.93
< どうせ書き捨てのソースだから良いよね、と思って

そういうソースにかぎって長生きするんだよ

804 :仕様書無しさん:2012/10/10(水) 23:46:54.20
>>802
仲間がいたとは驚きを禁じ得ない
俺はSQLビルダー用途でのメソッドチェインは一度の満足で終わってしまったけど、一式やってる様子見るに使い物になってる風だなー楽しそう
超イラっとするのも素敵w

OpenGL扱うイライラメソッドチェインやったらおもろなくて意気消沈
ステートマシンでやっても繋げにくいだけで萌えなかった。いややる前に分かれよボケって話だが
くけけ

805 :仕様書無しさん:2012/10/12(金) 20:09:58.49
頑としてコーディングスタイルの標準化を受け入れないリーダー


どのコードをチェックアウトしてきても常に常識的なスタイルであれば
今の残業時間を大幅に削減できると俺は思うのだが、どうだろう?

(見やすければ、そのぶんすみやかに思考を整理できる)

806 :仕様書無しさん:2012/10/12(金) 20:16:07.27
常識的なスタイルで書く分、思考能力が削られることになるけどな。

807 :仕様書無しさん:2012/10/12(金) 20:23:31.01
>>805
全員にとっての標準が作れないと悟ってるんだろ、そのリーダーさんも
強制力のないおおまかなガイドライン作る提案程度から始めるのが吉

君が他スタッフ全員から全幅の信頼を受けてない限りは、君の望む事態にはならんと思うよ

808 :仕様書無しさん:2012/10/12(金) 20:27:09.93
フォーマッターにかければものの数秒で終わる話なのに・・・・・・・・・・

809 :仕様書無しさん:2012/10/12(金) 21:11:27.98
>>806
そんなわけないだろ

810 :仕様書無しさん:2012/10/12(金) 21:50:22.00
>>807
おれのことを信頼しろと言っているのではなく、
カーニハン、リッチー、クヌースの経験に基づいたスタイルをリスペクトといっているのだ

811 :仕様書無しさん:2012/10/12(金) 23:33:41.21
>>810
今更それかーって言う奴らがいるから悩んでるんでそ?
そんだけの根拠じゃ権威主義と笑われて終る上に、古いって馬鹿にするだけの奴も居る訳だ。無駄に間延びするわとか最近の本でそんなん見たことねーよとかさw
聞いた事のない出版社のJAVA教本盾にして迫ってくるアホとかぎょうさんおるのよ
論拠整えなきゃそんな馬鹿どもと同列扱いよ

だから強制力のないおおまかなガイドラインの提案から始めろって。膝付き合わせてりゃ、十人十色のいろんな論拠聞けるぜ

君の望む事態にはならんと思うが

812 :仕様書無しさん:2012/10/12(金) 23:57:10.43
ゲリラ戦
くっさいコードファイルを見たら即indent

813 :仕様書無しさん:2012/10/13(土) 10:21:58.59
インデントしただけでもその箇所をテストしないといけなくなるじゃん

814 :仕様書無しさん:2012/10/13(土) 11:01:07.84
インデントだけでもスペース派とタブ派とか空行もインデントするか空白なしで即改行かとか派閥がある

815 :仕様書無しさん:2012/10/13(土) 11:04:23.16
ふいたw

816 :仕様書無しさん:2012/10/13(土) 11:56:40.85
>>814
空行のインデント?流石にそこまで気にする奴はバカ認定していいと思うwww

817 :仕様書無しさん:2012/10/13(土) 12:14:11.15
Man Page of indent

http://linuxjm.sourceforge.jp/html/GNU_indent/man1/indent.1.html

818 :仕様書無しさん:2012/10/13(土) 12:15:45.85
コーディングスタイルの差異でいちいち思考が妨げられるなんて甘えだろw
困るのはメンテナンス作業での追加削除のスタイルが統一出来ない程度だ。

819 :仕様書無しさん:2012/10/13(土) 19:29:37.12
まともな同僚が多い職場なんですね
うらやましいです

820 :仕様書無しさん:2012/10/13(土) 19:54:26.13
>816
改行コード表示するエディタで表示がデコボコになってると気になる
バージョン管理システムで変更箇所とみなされちゃうから直すわけにもいかないでうっとおしい

821 :仕様書無しさん:2012/10/13(土) 20:31:59.20
ウンコスタイルに育てられた新人がウンコスタイルになった


他人に迷惑がかかるバグを絶対に出さないならいいが、そうでないんだから、
あとからコードを読む人間のことを考えて書いてほしい
(お前、毎日毎日バグ修正情報のメールだしてるじゃん)

書いて欲しいというか、コミットする前に自動整形ツールを通して欲しい
(処理ブロックを作業終了時に空行なくミッチリつめるのは、やむをえないから許す)

822 :仕様書無しさん:2012/10/14(日) 10:06:54.08
コミット時に処理動かすくらい簡単にできるだろ。

823 :仕様書無しさん:2012/10/14(日) 10:19:18.07
できるなどうかじゃないし

メンバー全員に上が指示すればいいのに
あれこれ理由をつけて、やらない

824 :仕様書無しさん:2012/10/14(日) 10:22:23.01
無駄なことはしないのは正しい。

825 :仕様書無しさん:2012/10/14(日) 12:53:59.17
バグが多すぎるとさらに上から何度も言われているくせに
派遣と外部委託を切らされた途端にそのザマなくせに

826 :仕様書無しさん:2012/10/21(日) 15:57:48.44
TWO==varみたいな変な書き方を「うまいやり方」だと思うようなセンスの人って、
同時に「三項演算子は解りにくいから禁止」なんていう変なセンスも併せ持っていたりするのかな。


827 :仕様書無しさん:2012/10/21(日) 19:57:37.38
どんだけ左定数に恨みがあるんだよ
先輩に苛められたのか?
左定数は昔のCのバッドノウハウだから、左定数が好きな人は昔からCでコード書いている人
そういう人はむしろ三項演算子大好きが多い

828 :仕様書無しさん:2012/10/21(日) 20:15:52.94
三項演算子を代入しないで使ったらキモがられたでござる

829 :仕様書無しさん:2012/10/21(日) 20:19:25.74
最後にC言語で書いたのは何時の話だったか・・・

830 :仕様書無しさん:2012/10/21(日) 20:28:43.26
三項演算子で副作用だけ使うのは俺もキモいと思うわ。

831 :仕様書無しさん:2012/10/22(月) 06:58:59.12
>>827
え?なんでバッドノウハウなんだ・・・?
だめなん?

832 :仕様書無しさん:2012/10/22(月) 08:20:01.97
またシーかぁ

833 :仕様書無しさん:2012/10/22(月) 20:57:33.67
>>831
別に俺はどっちでもいいが、このスレには左定数を狂ったように叩く奴がいるからな
過去にトラウマでもあるんだろう

834 :仕様書無しさん:2012/10/22(月) 22:08:21.62
>>833
そうなのか、解説サンクス
おっちゃんよくやるから焦ったわ

835 :仕様書無しさん:2012/10/22(月) 22:39:22.27
>>829
大学の単位で。
今25だけどCやる機会あるかなぁ

836 :仕様書無しさん:2012/10/22(月) 22:55:51.12
>>831
コンパイラの警告すら読めないか、解析ツールも使えない人向けのノウハウだから。

837 :仕様書無しさん:2012/10/23(火) 07:14:51.89
>>834
叩かない側の意見だけ参考にして納得してるのはどうなんだ
まぁお前の問題だから別にどうでもいいけどさ

838 :仕様書無しさん:2012/10/23(火) 13:06:26.92
>>837
叩く意見出してからもの言え

839 :仕様書無しさん:2012/10/23(火) 20:32:43.32
まぁ実際には「左定数は有効だ」という意見が否定されているだけで、
べつに左定数で書いて悪いわけじゃないしな。
それを、叩かれたと感じた人はいたのかもしれんけど。

840 :仕様書無しさん:2012/10/23(火) 21:20:43.17
まったくだな
左定数でコードを書くことを強制されるのは勘弁だけど
他人が書いたものを読んだり、そのスタイルに合わせて部分的に修正するくらいならどうってことないしな
ただ>>836は間違いだろ
用心を重ねることが悪いことであるはずがない

841 :仕様書無しさん:2012/10/23(火) 22:00:11.19
用心してコンパイルオプションを指定しておけばエラーにできるので不要かと。


842 :仕様書無しさん:2012/10/23(火) 22:28:18.58
うん、不要だね
やってもいいけどね

843 :仕様書無しさん:2012/10/23(火) 22:46:48.44
そいう意味では、システムハンガリアンみたいなものだね。

844 :仕様書無しさん:2012/10/23(火) 23:05:21.91
システムハンガリアンは抽象度を下げるだけで害しかないだろ


845 :仕様書無しさん:2012/10/24(水) 00:49:27.52
わかりやすいと思ってる人にはわかりやすいんじゃないの?

846 :仕様書無しさん:2012/10/24(水) 05:17:08.66
抽象度が高ければいいわけでもないよ。
rubyとかやってると、ぶっ壊したくなる。

847 :仕様書無しさん:2012/10/24(水) 10:27:39.69
アセンブラ上がりの俺にとっては有難いルールだったんだが、
高級言語だとその辺はあると逆に邪魔ってのもわからなくも無い。

仕事する上では自分のポリシーは特に持ち込まず現場のルールに
従っている。

848 :仕様書無しさん:2012/10/25(木) 02:31:37.74
if (ZERO >= cond) {

849 :仕様書無しさん:2012/10/25(木) 23:57:47.92
//デバッグ用、リリース時にはDEBUG ENDまでコメントアウトしてください。

850 :仕様書無しさん:2012/10/26(金) 07:31:24.43
>>849
#ifdef〜#endifで囲んどけよwww

851 :仕様書無しさん:2012/10/26(金) 22:31:24.42
Cから来た人間の適応力の無さは異常

852 :仕様書無しさん:2012/10/26(金) 22:33:45.53
テンプレートは躊躇するよなあ
適切に使えるのかとか、バイナリに無駄が発生しないのかとか
気になって

853 :仕様書無しさん:2012/10/26(金) 22:37:46.67
著名なプログラマは大体Cあがりじゃないの?

854 :仕様書無しさん:2012/10/27(土) 00:46:57.10
>>851
Cで落ちこぼれて他の言語に鞍替えしただけじゃないかと思う。

855 :仕様書無しさん:2012/10/27(土) 10:34:56.59
C上がりの老害プログラマーがアレルギー反応するもの
・class意外のC++キーワード、特にtemplateとoperator
・関数の途中にある変数定義、特にfor文の中
・例外処理、特に失敗したnewがNULLを返さないこと

856 :仕様書無しさん:2012/10/27(土) 21:58:55.42
>>855
Javaあがりのゆとりの間違いだろw

857 :仕様書無しさん:2012/10/27(土) 22:00:53.73
はぁ?

858 :仕様書無しさん:2012/10/28(日) 00:38:25.51
まぁ確かに、長いことCとJavaやってきて最近C++使うことになった俺からすると、
templateをgenericsのようなものかと思ったら「はぁ?」な状態だったし、C系統の
言語でoperatorは逆にやりすぎだと思った。
ただ2番目は、C99じゃあ認められているしそれ以前からも使える処理系はあったから
べつに違和感はない。

859 :仕様書無しさん:2012/10/28(日) 01:14:34.60
三番目知らない人多いかも
おれも、入門書に書いてあったの忘れて、あとで読み返して愕然とした

860 :仕様書無しさん:2012/10/28(日) 01:51:18.67
operatorなんて多言語への移植性がなくなるものを使うなよ

861 :仕様書無しさん:2012/10/28(日) 12:48:23.04
>>860
Delphi厨乙

862 :仕様書無しさん:2012/10/28(日) 19:16:29.87
>>855
一般的な内容のように書くから誤解を招くんじゃないの?
「Cをちゃんとマスターできなかった老害プログラマ」のことだったら
納得いくけどな。そういう人はもともとやっていた言語すら怪しい。

863 :仕様書無しさん:2012/10/28(日) 21:40:05.70
「Cをちゃんとマスターできなかったプログラマ」はC++についていけなくて
Javaが出たときに大喜びだったからな

864 :仕様書無しさん:2012/10/28(日) 22:30:39.22
Cもできなかった奴がJavaやってどうするよ。

865 :仕様書無しさん:2012/10/28(日) 22:49:51.04
Cって言うよりポインターな。

866 :仕様書無しさん:2012/10/28(日) 23:18:52.88
まぁたしかに初心者がつまづくところだが、いくらやっても理解できなかったとしたら
そもそもプログラマとして才能ないだろ。
Javaなんかさらに理解できないんじゃねーのか。

867 :仕様書無しさん:2012/10/28(日) 23:55:43.43
>>861
Delphiでもできるぞ

868 :仕様書無しさん:2012/10/29(月) 00:40:05.00
ポインタを関数の引数と配列へのアクセス手段にしか使えない奴は糞。
C/C++プログラマーを20年やってる奴でもそんなのばかり。

869 :仕様書無しさん:2012/10/29(月) 00:42:01.44
最近多いんだよねー
Javaとかちょっとかじった程度で
「俺プログラマーやってます」って顔する子

あるある
最初の入り口がオブジェクト指向なんだよね
最近の子って

そうそう
そんなんじゃ使い物にならねぇっての

870 :仕様書無しさん:2012/10/29(月) 00:45:26.65
>>869
まぁまぁそういうなや
若いってことはまだ成長するんだろうし

871 :仕様書無しさん:2012/10/29(月) 00:49:46.78
>>868
いや、それ以外に使うと一気に危険度が上がるから使わないに超した事無いんだけどな。

872 :仕様書無しさん:2012/10/29(月) 02:05:09.40
うはっ、新人に説教されちゃったよ俺

873 :仕様書無しさん:2012/10/29(月) 02:48:11.81
「使わないに越したことはない」に反論できないなら老害乙としか言えない


874 :仕様書無しさん:2012/10/29(月) 07:21:25.15
> 関数の引数と配列へのアクセス手段にしか
あと思いつくのは構造体のメンバにポインタ使うくらいなんだけど
具体的にどういう用途に使えたら>>868に認めてもらえるの?

875 :仕様書無しさん:2012/10/29(月) 08:33:37.81
定期的に見かける、「ポインタをマスターできた奴」が、どこにいるかわからん
「マスターできなかった奴」を馬鹿にするという低レベルの争い。
「マスター」するのによっぽど苦労したんだろうなw

876 :仕様書無しさん:2012/10/29(月) 09:18:07.02
CUDAならシェアードメモリにデータを写してポインタで扱ったりするから、引数や配列じゃない扱いをしてると言えるっちゃ言える
そういった、ハードと密接な関係を持った技術が足りないって事なのかな…オブジェクト志向だとそんな部分は隠蔽する方向に設計するだろうし

877 :仕様書無しさん:2012/10/29(月) 13:57:05.88
>>875
確かにちゃんとポインタ使ってプログラム書ける奴が「俺、ポインタをマスターしたから」
みたいに言ってるのは見たことが無いw

別にトリッキーなポインタの使い方が出来るから偉い、というわけでもないと思う。

でもポインタが絡んでくると「俺には分からん」とデバッグを投げる奴がいて迷惑かけられた
上に、ポインタは可読性を損なうから使うな、バグの温床だ、と言われた(要は俺の先輩)。

ついでに誰も突っ込まないから
>>869,872
例の漫画のセリフだねw最近あのURLのコピペを見かけないが。

878 :仕様書無しさん:2012/10/30(火) 00:00:25.06
>>875
糞スレ立てたのお前だろ

879 :仕様書無しさん:2012/10/30(火) 00:14:09.61
>>878
糞スレ上げたのお前だろ

880 :仕様書無しさん:2012/10/30(火) 00:36:02.30
ポインタマニアなのかキャストマニアなのか、
こういうのをやっててイラッとした事ならある。

extern char *dynamic;

if (dynamic != NULL)
  ((int (*)(char *, int, int, int))dynamic)("hoge", 1, 2, 3);



881 :仕様書無しさん:2012/10/30(火) 01:22:08.59
>>880
マニアでも何でもない。
ただの老害。

882 :仕様書無しさん:2012/10/30(火) 02:57:07.06
「コマンドラインインタプリタみたいなもの」を
安直に作りたい時には、そんなキャストもしたくなるかもな。


883 :仕様書無しさん:2012/10/30(火) 06:48:51.48
最近はもうコーディングの制限を規約じゃなくて
言語の選択で回避する時代になってきてる感じ。

884 :仕様書無しさん:2012/10/30(火) 07:19:46.84
>>874
関数ポインタくらいは使えてほしいところじゃね?

>>876
隠蔽する技術があるのと、隠蔽された環境をつかう技術があるのは違うからね。

885 :仕様書無しさん:2012/10/30(火) 16:56:13.71
>880
普通のポインタと関数ポインタとの間には、互換性がないから、危険

886 :仕様書無しさん:2012/10/30(火) 23:09:02.89
全角英数が入り混じったファイルをプログラマーに見せると最悪しぬ

887 :仕様書無しさん:2012/10/30(火) 23:31:17.19
>>880

つうか、なんで最初にchar*で宣言しているのかが意味不明。
組み込み?

888 :仕様書無しさん:2012/10/31(水) 09:53:19.89
>>887
void *がなかったK&R時代には、その代わりにchar *を使っていたから

889 :仕様書無しさん:2012/10/31(水) 19:55:22.11
>>888
そうじゃなくて、後でキャストするくらいなら最初からそのポインタ型で宣言しとけって話だろ。

890 :仕様書無しさん:2012/11/01(木) 00:36:23.71
あんな函数やこんな函数を呼ぶための
函数へのポインタの配列を使いたい時もあるかもしれないぜ。

まあ一枚皮かぶせたほうがすっきりしたんで必要なくなったが。


891 :仕様書無しさん:2012/11/01(木) 07:33:32.78
そこまでやるなら「ポインタマニア」と呼んでやってもいいかもしれない。
が、俺ならそこは構造体にするな。なんで配列なんだろ。

892 :仕様書無しさん:2012/11/01(木) 18:48:01.41
関数ポインタの配列なんてc++のメンバ関数ポインタに比べたらどうでもいいレベル

893 :仕様書無しさん:2012/11/01(木) 21:32:48.90
テンプレートじゃダメなんですか?

894 :仕様書無しさん:2012/11/01(木) 21:39:04.84
a == 0 を a = 0と書いてしまうより、
a = 0 を a == 0
と書いてしまうことが多い。

895 :仕様書無しさん:2012/11/02(金) 03:13:27.03
無駄にタブが多いコード。
コードの無能さとタブの多さは比例する。

896 :仕様書無しさん:2012/11/02(金) 10:49:20.13
4tabで書いたのを8tabで見ていたり?

897 :仕様書無しさん:2012/11/02(金) 10:53:01.40
逆に言えばタブを全く使っていないのが有能なコードということになるが

898 :仕様書無しさん:2012/11/02(金) 11:02:03.82
1行プログラミングの再来か!?

899 :仕様書無しさん:2012/11/02(金) 11:17:02.09
expandtab余裕

900 :仕様書無しさん:2012/11/03(土) 09:49:16.10
tab使わないとカーソル移動がめんどいな

901 :仕様書無しさん:2012/11/03(土) 09:57:24.47
この前他人のPHPの仕事の引継ぎで、
規約にタブじゃなくてスペースってあったからそうしたけど、
思った程困らなかった。

Eclipseで自動変換ではあったけども。

902 :仕様書無しさん:2012/11/03(土) 11:25:00.72
厳密にインデントしていったら画面が真っ白になって
右スクロールしてようやくコードが見えたなんてことも

903 :仕様書無しさん:2012/11/03(土) 11:56:54.66
>>902
それは適度に構成考えて分割しないからだろw

904 :仕様書無しさん:2012/11/03(土) 13:48:30.63
更新履歴で埋め尽くされたコードを見ると、
「コミットメッセージに書けよ」と思ってしまう。

905 :仕様書無しさん:2012/11/03(土) 13:57:37.82
マージして更新履歴でコンフリクトでると萎える。


906 :仕様書無しさん:2012/11/04(日) 02:20:03.32
カーソル連打してインデントされてる場所を移動するケースとかそもそもないけどな
だいたい、最終的にフォーマッターかけりゃいいだけだから、行頭のインデントずれてるとか関係ないし
そのあたりはカーソル位置とか気にせず適当に書いて大丈夫だもんな

907 :仕様書無しさん:2012/11/04(日) 02:22:07.38
だれがいつ更新したかなんてゴミデータをコードに残す慣習はいい加減やめるべきだよな
ゴミデータと一緒に時代についていけないゴミもごっそり削除してしまいたい

908 :仕様書無しさん:2012/11/04(日) 03:19:29.34
更新履歴、それは責任のなすりつけあいを回避して、よりクリティカルな責任を現場に課すための絶好の治具
更新履歴を甘く考えてはいけない
あれはIT土方どもを畏怖させる鉄球付きの足枷だ
服従せよ、バグに鉄槌を、バグを生んだ物には制裁を

って事になってる現場も少ないみたいね
今の現場も形骸化しとるわ。誰のバグか追跡はできるけど、それする暇でバグ治す感じで毎回うやむやに

909 :仕様書無しさん:2012/11/04(日) 11:52:44.98
>>908
バグ仕込んだ当人がとっくの昔に辞めてるなんて珍しくも何ともないからな。

910 :仕様書無しさん:2012/11/04(日) 13:23:24.41
>>908
マジで担当してねープログラムに俺のソースからヘッダコメントを名前そのままに
転載すんのやめろあのクソ野郎
てめえの責任を俺になすりつけんなよ

911 :仕様書無しさん:2012/11/04(日) 14:55:13.82
それはひどいwwww

912 :仕様書無しさん:2012/11/04(日) 19:00:19.23
整列された数万件のデータをご丁寧に全舐めして検索するコードを書く奴は恥ずかしい。

913 :仕様書無しさん:2012/11/04(日) 19:14:38.70
それはコーディングスタイルの問題とは違うような・・・・。

914 :仕様書無しさん:2012/11/04(日) 19:15:30.55
あー、告白すると関数分割をつい忙しさにかまけて怠ってしまうことはある
巨大で同じような処理が何個も放置して済まないとは思う
メンテできない長さじゃないが、あれは恥ずかしいな、我ながら

915 :仕様書無しさん:2012/11/04(日) 20:25:40.44
WindowsAPIがサッパリ理解できない
何と何を組み合わせて機能が実現するとかサッパリわからない。

916 :仕様書無しさん:2012/11/04(日) 21:04:08.38
>>915
初めはみんなそうよ、そこでいい書に出会えるかどうかってけっこうキーポイント
だとおもう。
俺のオススメは「解説」ではなくて「書物」のような印象を受ける本をまず選び
それから本格的な解説なりを読んだほうがいいと思う。

語る感じのするものね。回りくどいけど、そのほうがいい。入りやすさが違う。
感のいい人なら解説でもいいけどね。

917 :仕様書無しさん:2012/11/04(日) 21:16:17.09
今はブログに書いてくれてる人が多いおかげで本とか読んだこと無いな。
特殊なハード向けだとそもそも本が無いとか、
本が出たけどそれよりいい本書ける程度の知識があったりとか。

918 :仕様書無しさん:2012/11/04(日) 21:19:28.83
語る感じのする書物といえばオライリー

919 :仕様書無しさん:2012/11/04(日) 21:34:09.29
冒頭のアメリカのオタクのジョークが寒いからあんまり読みたくない

920 :仕様書無しさん:2012/11/04(日) 23:12:20.19
>>915
複雑だけど決まりきった使い方しかしない
あるAPIは別のAPIの入力のためにだけ存在する

だったらまとめてひとつのAPIにしろよと小一時間愚痴りつつ
今日も決まりきったコピペをしている

921 :仕様書無しさん:2012/11/05(月) 20:57:31.11
pinvoke.netからのコピペを生業としています

922 :仕様書無しさん:2012/11/05(月) 22:26:42.19
コーディングスタイルというか、メイク時に発生するワーニングをずっと放ったらかしに
されると、気になる

いやそりゃあ実行ファイルはできるぜ?
でもさ、ワーニングって完全ではないから出るものが多く、放ったらかしていいものだとは
思えないんだよね

923 :仕様書無しさん:2012/11/05(月) 23:34:23.06
1. この〜は使われていませんというワーニングが出る。
2. 〜を削除する。
3. リリース用にマージしてコンパイルしたら、「〜がありません」というコンパイルエラーが出る。
4. 開発環境では〜は削除されているが、削除した部分の変更は、顧客の都合で、
 適用が差し止められていた。


924 :仕様書無しさん:2012/11/05(月) 23:49:33.74
警告放置のヤツに限って
「クオリティを上げようキリッ」とか説教を始めるから困る

925 :仕様書無しさん:2012/11/08(木) 00:57:20.47
コンパイルが通らないソースをチェックインして帰る奴はもっと困る。

926 :仕様書無しさん:2012/11/08(木) 18:44:02.64
Javaだと警告は全部削除するけど、昔C勉強してた時は
「警告は問題ないものが含まれており、完全に出ないようにするよりも、読みやすくする方が大事です」
みたいな事が本に書かれてたなあ
そういう警告の例も出てたけど、今振り返ってみるとそのコンパイラが腐ってんだろ?と思う

927 :仕様書無しさん:2012/11/10(土) 00:28:56.81
Microsoft謹製のVisualC++でDirectXプログラムを普通に書いただけでも警告出る

928 :仕様書無しさん:2012/11/15(木) 23:36:33.61
重要な警告が埋もれて見落とす

929 :仕様書無しさん:2012/11/20(火) 02:20:56.62
消せる警告は消していくべきだけど無視する糞が多いこと
あとは俺々フォーマットでコード書く奴

930 :仕様書無しさん:2012/11/20(火) 02:52:08.66
っていうか、コンパイルオプシションで出る
ワーニングが制御できることを知らん人がいるのか。

931 :仕様書無しさん:2012/11/20(火) 06:55:46.59
>>930
問題にしてるのは姿勢であって、そういう臭いものに蓋をして知らんぷりする
態度はどーもな
無論、わざわざ警告が出ることを承知で書いててなら全然ありだけど

932 :仕様書無しさん:2012/11/20(火) 07:45:30.49
臭いものに蓋っつか、必要じゃない警告は止めてかまわんだろう。
態度のことを言うなら逆に、どういう内容の警告なのか考えず
一律に「出るからダメ」的な態度をとるほうが問題のような気が。

933 :仕様書無しさん:2012/11/20(火) 08:12:38.03
コンパイラオプションで止めてしまったら、
必要な箇所も必要でない箇所も一緒くたになってしまうだろ。

934 :仕様書無しさん:2012/11/20(火) 09:37:14.70
>>932
だから姿勢だっつーのに頭悪いな

935 :仕様書無しさん:2012/11/21(水) 02:40:26.69
アプリケーションの要件や適用分野を考慮して、
コーディング規約を作って、コーディング規約に従って
ワーニングオプションを設定するというのは、
そんなに間違った態度とは思えないんだが。
無関係のワーニングの中に、重要なワーニングを埋没させてまで、
すべてのワーニングを表示させることがそんなに立派な態度なのかね?

936 :仕様書無しさん:2012/11/21(水) 03:07:53.33
まてまて。警告を表示させる事それ自体が目的の奴はいなかろうw

うちはJava一本だからか、警告は全て潰せで済んでるんだけども。
スレ読む限りどうしても消せない警告があるとか、警告通りに対処するとむしろ害がある場合があるって事のようだし
なんかしら事情があるなら、ワーニングオプションと規約による対処はもちろん妥当だと思うよ

937 :仕様書無しさん:2012/11/26(月) 22:42:47.94
register教信者にイラッ☆

register int hoge;
register int fuga;
// ...10個くらいregisterが続く
register int piyo;
register int piyopiyo;

get(&hoge); // アドレスを取る・・だと!?

938 :仕様書無しさん:2012/11/26(月) 22:56:13.63
まだregisterってあったのか

939 :仕様書無しさん:2012/11/26(月) 23:58:23.47
>>937
っていうか、コピペで意味知らずに使ってるんじゃね?

940 :仕様書無しさん:2012/11/27(火) 06:33:09.96
似たようなのにinline教がある
そして邪教__attribute__

941 :仕様書無しさん:2012/11/27(火) 13:30:48.19
#pragma 最強

942 :仕様書無しさん:2012/11/27(火) 21:56:06.18
#ifndefだらけのソースを今だに書く老害がいる

943 :仕様書無しさん:2012/12/03(月) 00:46:26.25
普通にインデントしたら100行位になるコードを一行にずらああああっと書くクソゴミ

944 :仕様書無しさん:2012/12/03(月) 00:59:07.08
生クエリを1行で書きやがったか?w

945 :仕様書無しさん:2012/12/03(月) 12:51:27.71
多重ネストさせた三項演算子とか

946 :仕様書無しさん:2012/12/03(月) 23:17:43.37
50行ほどの同じようなコードを数ブロックコピペしてある
よく見ると変数が一つだけ違ってる

947 :仕様書無しさん:2012/12/04(火) 01:54:33.47
そういうのに限ってpublic staticとか

948 :仕様書無しさん:2012/12/04(火) 03:33:55.31
プロパティなら許すん

949 :仕様書無しさん:2012/12/06(木) 16:47:36.88
クラスメンバー変数に「m_」を付けるスタイル、
最初は気持ち悪くて仕方なかったが、
今ではすっかりこれ無しじゃダメな体になちゃった・・・
人が作ったクラスにも全部付けちゃう。

950 :仕様書無しさん:2012/12/06(木) 17:20:00.01
きもいな
なんか利点あんの?

951 :仕様書無しさん:2012/12/06(木) 18:16:31.13
俺はアンダーバーは付けないタイプだなー

利点としては、ローカル変数との見分けがつくくらい?
ほかにはハンガリーなんて使わんが、メンバ変数だけには付けるな

952 :仕様書無しさん:2012/12/06(木) 19:07:44.23
>>950
ローカル変数や引数と名前が重ならない。
逆にローカル変数にはthe, 引数にはin/outをつけて区別するというような
風習もあるけど、それやるくらいならメンバ変数に接頭語つけた方がいいと思う。

953 :仕様書無しさん:2012/12/06(木) 21:51:31.78
一行120文字くらいのクソ長いコメント書くのやめて欲しい。
視線移動を考慮してないので読みにくい。

954 :仕様書無しさん:2012/12/06(木) 22:11:29.99
メンバ変数にtheなら昔見たことあるけど、ローカル変数に
接頭辞付けるルールってほとんど聞いたことないな。

955 :仕様書無しさん:2012/12/06(木) 23:52:44.08
ハンガリアンコーディングは本家MSもやめたんじゃなかったっけ?
Java ならメンバ変数は、this つければ見分けがつくから、
メンバ名自体を変える必要を感じないな。

956 :仕様書無しさん:2012/12/07(金) 00:02:45.85
thisつけなくても使えてしまうから区別したいわけでしょ。
まぁ、JavaならEclipseなんかで見分けてくれるけど。

957 :仕様書無しさん:2012/12/07(金) 00:37:24.60
スレの趣旨的には、プリフィックス云々より、
this つけないコーディングの方がイラッとくるな。

958 :仕様書無しさん:2012/12/07(金) 01:28:26.15
>>955
今はハンガリアン記法使うなって以外にも命名するときには略すなって言ってるな
徹底できてるのかどうかは不明だが、英語できない奴はイラッとしてそうだし、英語できないプログラマにイラッとしてる奴も居そうだw

959 :仕様書無しさん:2012/12/07(金) 05:24:23.47
booleanだけは「b」付けたいなぁ。
bSuccessみたく。

あと参照渡しで結果を期待する引数には
「ret」付けたい。retErrorとか。

960 :仕様書無しさん:2012/12/07(金) 06:07:18.85
>>959
いまどきのbooleanはisHoge/hasHogeだろ

961 :仕様書無しさん:2012/12/07(金) 10:00:28.19
わかりゃいいんじゃね?

962 :仕様書無しさん:2012/12/07(金) 10:51:44.48
変数名が英単語として意味をなさないものになるのがなんか抵抗がある。
論理値は「〜ble」とかでいいんじゃね?

963 :仕様書無しさん:2012/12/07(金) 12:19:42.39
flgHoge は何故かよく見る

964 :仕様書無しさん:2012/12/07(金) 12:31:29.16
furaguHogeだろ

965 :仕様書無しさん:2012/12/07(金) 19:09:14.87
flgOreta
flgTatta

966 :仕様書無しさん:2012/12/07(金) 21:39:58.74
flgEnableFlag

967 :仕様書無しさん:2012/12/08(土) 18:04:10.95
flgとflagが混在してるとイラっとする

968 :仕様書無しさん:2012/12/08(土) 18:48:52.65
「flgとflagとfuraguは用途が異なるので違う名前にしています」

969 :仕様書無しさん:2012/12/08(土) 19:16:59.94
boolean YuukouFlag;
boolean YuukouFlagInvalidFlag;
long YuukouFlagInvalidFlagNoYuukouKigen;
boolean YuukouFlagInvalidFlagNoYuukouKigenNoUseFlag;

970 :仕様書無しさん:2012/12/08(土) 20:38:46.39
変数名/関数名ネタはどうしてもuwariteと比較してしまう

971 :仕様書無しさん:2012/12/08(土) 22:37:08.45
>>966
これはあるあるだな

972 :仕様書無しさん:2012/12/09(日) 00:39:17.04
関数の中で被らないように長い名前にしてるのは分かるんだけど、ちょっとイラっつとする事はあるな。
実際 data とか名前付けて被ってておかしな動作した事はあるんだけどもw

973 :仕様書無しさん:2012/12/09(日) 02:39:10.51
それも居るな
tempとか安直な変数宣言して複数のロジックで使い回して
微妙にスコープがかぶってるところで
特定のケースでのみ値上書きするようにしちゃって
みょーな挙動させてイラッつとさせるコード書くヤツ

974 :仕様書無しさん:2012/12/09(日) 02:39:41.49
英単語2〜3つ続ければ大体かぶらない

975 :仕様書無しさん:2012/12/09(日) 03:20:35.30
FirstTemporaryData
SecondTemporaryData
ThirdTemporaryData

976 :仕様書無しさん:2012/12/09(日) 03:52:29.16
dataだのtmpだの安直な奴はメソッドの中で定義していても多様されるとイラッつとするレベル
逆に広域定数かつ使用頻度の高い変数名がやたら長いのもイラッつとする
例えば整数を直接書くなというコーディング規約が生み出すConst hogehoge_zero = 0;やらConst hogehoge_one = 1;の事
最近は見てないけど、整数を直接書くなっていうのはマジ簡便だわ、どうせそこら中にif(foo != PublicData.hogehoge_zero) { return bar; }だの何だのがはびこって結局保守性変わらない
整数とか使用頻度高すぎだから、結局一箇所一箇所hogehoge_oneとかで書き直さなきゃいけないの目に見えてるから

977 :仕様書無しさん:2012/12/09(日) 04:29:11.28
oneとかzeroとかいう名前にする意味が分からない
どうして列挙型を使わないのか

978 :仕様書無しさん:2012/12/09(日) 05:05:27.66
×
Const hogehoge_zero = 0;
Const hogehoge_one = 1;

Const SUCCESS = 0;
Const ERROR_HOGEHOGE = 1;

zeroだのoneだのの意味が無い名前はダメ

979 :仕様書無しさん:2012/12/09(日) 08:24:51.75
>>97
const int kErrWrite = -2;
const int kErrOpen = -1;
const int kOk = 1;

980 :仕様書無しさん:2012/12/09(日) 08:52:26.93
数値の0を表すconst変数をzeroにしたことはあるな。

981 :仕様書無しさん:2012/12/09(日) 15:38:53.07
>>977
「定数は必ず別に定義する事」
みたいなルールがあるとたまに見かけるなw

#define KANRI78493_00
#define KANRI78493_6464
#define KANRI78493_256256

char temp[KANRI78493_256];

助けて・・!

--realurl
lud20220212082013
このスレへの固定リンク: http://5chb.net/r/prog/1338703896/
ヒント:5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。

TOPへ TOPへ  

このエントリをはてなブックマークに追加現在登録者数177 ブックマークへ


全掲示板一覧 この掲示板へ 人気スレ | >50 >100 >200 >300 >500 >1000枚 新着画像

 ↓「TWO == イラッつとするコーディングスタイル->画像>1枚 」を見た人も見ています:
コーディングスタイルを統一する意味ってあるの?
コーディングスタイルにこだわるスレ
【AutoML Zero】Google、人間より早くコーディングを繰り返す自己進化するAIプログラムを開発【遺伝的アルゴリズム】
レコーディングスタジオあれこれ
ストロングスタイルの定義は?
【音楽業界】レコーディングスタジオの現状
なぜレコーディングスタジオにSONY製機材が多いの?
レコーディングスタジオとかの映像見るといつも思うんだけど
ストロングスタイルヒストリー
あれ?このレコーディングスタジオって赤羽橋じゃなかったの?
G1はストロングスタイルのど真ん中!
小川問題から垣間見える淫獣・夏焼雅のストロングスタイル
【悲報】KANさんが自分のラジオでアップフロントのレコーディングスタジオが無くなったことを暴露wwwwwww
今の新日本は完全にストロングスタイルを捨てたPart2
マードックのケツ出しはストロングスタイルの根源
【ストロングスタイル】新日サーカススレッド1956【廃止】
ウォシュレットを使わず必ず紙で拭き取るストロングスタイルの乃木坂ちゃんは?
Zoomのミーティングでホストする時は必ずレコーディングする
【カズ長男】三浦りょう太「頑張っていることが大事」父親譲り“キングスタイル”で俳優業突き進む…インタビュー [爆笑ゴリラ★]
結局ストロングスタイルとかUWFってスープレックスとかトペとか危険な技やらないでガチもやらないっていう最高のぬるま湯だったよな?
所ジョージ曰く曲をレコーディングするのに1曲100万円くらいかかるそうだ
声優や歌手のレコーディングってちょっとミスったら最初から全部録り直しするの?
【悲報】譜久村「歌割はレコーディングする前からつんくさんの意図である程度決まってる」「でもこれが実力主義だもん」
【IT】画像からHTMLやCSSを自動コーディングする人工知能が遂に誕生してしまう これHTMLコーダー死んだだろ……
【音楽】SpotifyのCEOが「アーティストは3?4年に一度レコーディングするだけでは生活していけない」と持論を述べ批判を浴びる #はと [少考さん★]
【モーニング娘。10期】サトウマサキこと佐藤優樹ちゃんを応援するでしょ~596ポクポク【レコーディングがしたい今日この頃!!!】
シュプリームでお洒落に武装し、アルマンドを抜いて、ブラックカードで支払いをするのが、イマドキのおじさんの最強スタイル
【グラビア】WEEKDAYはグラドル日記 グラドル界一のスタイルを目指し日々ポージングを研究する『咲村良子』[05/06] ©bbspink.com
【グラビア】365日グラドル日記 見とれてしまうスタイル抜群のパーフェクトボディーで魅了する『Kagami』[03/13] ©bbspink.com
【エスワン ナンバーワンスタイル】NTR同窓会 愛する妻と最悪な元彼の気が狂いそうな胸糞浮気映像。 三上悠亜【巨乳/ハイビジョン】 ©bbspink.com
配列、線形代数、写像、ベクトル、幾何学コーディング
【アプカミ】つばきファクトリー「可能性のコンチェルト」楽器レコーディング
【本田望結】全身ブラックの夏コーデ披露「スタイル良い」「オーラ凄い」の声続々 [首都圏の虎★]
【音楽】松本伊代がデビュー40周年アルバム発売、筒美京平の未発表曲をレコーディング [湛然★]
【音楽】DA PUMPが12年9カ月ぶりのベストアルバム発表、全収録曲のボーカルを再レコーディング
【技術】スプレーでウイルスを90日間寄せ付けない新コーディング技術「MAP-1」が開発される [暇人倶楽部★]
【音楽】なかにし礼氏 人気企画アルバム「なかにし礼と13人の女優たち」第2弾 浅野ゆう子が19年ぶりレコーディング
BMWコーディング その1
GAFAのコーディング面接に合格したい!
【CodeIQ】コーディング転職 4社目【paiza】
【CodeIQ】コーディング転職 2社目【paiza】
【CodeIQ】コーディング転職 3社目【paiza】
【レコーディング】スタジオモニター【編集】
中田ヤスタカ、ハロプロのレコーディング方法を全否定
【paiza】コーディング転職 9社目【AtCoderJobs】
【paiza】コーディング転職 7社目【AtCoderJobs】
【paiza】コーディング転職 11社目【AtCoderJobs】
【paiza】コーディング転職 8社目【AtCoderJobs】
【paiza】コーディング転職 10社目【AtCoderJobs】
【paiza】コーディング転職 12社目【AtCoderJobs】
【paiza】コーディング転職 6社目【AtCoderJobs】
【paiza】コーディング転職 5社目【AtCoderJobs】
コールドリーディングをマスターする無職
【AKB48G】顔もスタイルもいいメンバー
【千葉】ラブスタイルドラッグ【LSD】
顔とスタイルと性格だけ良さそうなメンバー
エミネムさんのフリースタイルラップwwwwwww
■ ハロプロ研修生 ■ 『ハロドリ。』【第115回】 発表会舞台裏!後藤に涙のサプライズ ■ ドラマ撮影裏側&新曲レコーディング ■
フリースタイルダンジョン出てほしいメンバー
Perfume、天才音楽P・中田ヤスタカとの出会いが転機 レコーディング指示に「悔しくて泣いた」「ゲームみたいな楽曲で戸惑いました」 [muffin★]
【悲報】フリースタイルラップバトルブーム、終了
ハロメンが選ぶ顔・スタイルがいいメンバーランキング
【櫻坂1st】カップリングは6曲で3列目だけ入れ替わる新スタイル!
【グラビア】「制コレ」杉本愛莉鈴、ナンバー1抜群スタイルを水着で披露
【ヒップホップ好き】プロレスリングシバター【横浜スタイル】#40
02:59:47 up 21 days, 13:23, 0 users, load average: 10.15, 10.80, 10.25

in 0.02816104888916 sec @0.02816104888916@0b7 on 010216