ステップ数が足りなくて叱責された

1 ：仕様書無しさん：2007/03/08(木) 15:38:00

あと３００ステップ足りない。
コメント意外に何を書けばよいか。
C++

35 ：仕様書無しさん：2007/03/10(土) 15:20:58

それは駄目だ

36 ：仕様書無しさん：2007/03/10(土) 15:55:56

自作のスクリプトでソース整形するなんて、絶対やめろ。
スクリプトにバグがあったら、死亡だ。

完成してテスト終わって動いてたのに、
「動かなくなりました」
だと！

謝るのは、俺なんだぞ。

土日出て、目で見ながら手で直せ

37 ：仕様書無しさん：2007/03/10(土) 17:03:35

いやいや整形ツール使うだろ。ふつー。

38 ：仕様書無しさん：2007/03/10(土) 19:28:31

昔実際にあべしが残していったソースで有ったんだが
begin
select
a,
b
into
lv_a,
lv_b
from
c
where
id=1
end;

当時2年目の漏れですら殺意が覚えた炎上prj・・・
先輩から聞いたんだが奴らの契約がstep数だったらしい。
可読性？奴らにそんな考えはないな

39 ：仕様書無しさん：2007/03/10(土) 19:35:22

>>38
それインデントはついてるんだろ？
要素ごとに改行なんてうちじゃ社内規約なんだけどおかしかったのか！？
SQLの文化だと思ってた

40 ：仕様書無しさん：2007/03/10(土) 22:36:49

ステップ数を計ること自体は別に構わん。
そうじゃなく実績を予想に無理矢理合わせようとすることが問題なんだ。

41 ：38：2007/03/11(日) 00:49:46

>>39
まんまこんな感じでしたが？ｗ
インデント？何それな感じで読みづらかた

42 ：葉猫 ◆Jz.SaKuRaM ：2007/03/11(日) 01:28:57

自分で作った1000行くらいのストアドでも怒りが涌いてくるのに、他人が作ったソースで
インデントついてなかったら暴れまつよ。。。。。。。。

43 ：仕様書無しさん：2007/03/11(日) 05:56:01

俺の場合、他人のコードを整形する時は
ほぼ他人の初見のコードを読む時だから
コードの内容を把握する意味でも手作業で整形するなぁ

44 ：仕様書無しさん：2007/03/11(日) 12:32:07

>>42
お前は呼んでない。

45 ：仕様書無しさん：2007/03/13(火) 02:28:02

>42
お前そろそろ死んどけ

46 ：仕様書無しさん：2007/03/14(水) 00:02:28

>>38

すごいね〜。
残業手当稼ぎ放題(ﾟдﾟ)ｳﾏｰ

47 ：仕様書無しさん：2007/03/17(土) 01:55:49

>>37
C とか Java とか C# とか Python ならともかく、
C++ でなんかいいのある? GNU indent は使い物に
成らんし。

48 ：仕様書無しさん：2007/03/20(火) 23:23:15

ステップ数に対してバグが足りなくて叱責されて、
バグを捏造したとこならある。

49 ：仕様書無しさん：2007/03/21(水) 04:15:26

>>47
Artistic Styleじゃだめなの？

50 ：仕様書無しさん：2007/03/22(木) 10:01:41

>>48
ステップ数削った方が教育的じゃね？

51 ：仕様書無しさん：2007/04/08(日) 01:04:36

>>48
漏れは逆に３倍ぐらいのバグを上げて問題視された事があるが無視した。

全部直したから無問題。

それよりもエリート集団wの隠蔽体質を何とかしろと。

52 ：仕様書無しさん：2007/06/17(日) 16:13:21

>>1

1:　goto 2:
2:　goto 3:
3:　goto 4:
延々続き、最後に、goto 1:
で絶対に実行されない行で300行埋めれば良いだけでは？

53 ：仕様書無しさん：2007/06/17(日) 17:42:46

if {
...
}

を

if
{
...
}

に直すのはどう？

54 ：仕様書無しさん：2007/06/17(日) 23:46:24

STLのファイルをincludeせずに直接展開したら、
10万行ほどコードが増えちゃった。てへっ！

55 ：仕様書無しさん：2007/06/17(日) 23:50:52

emacsで全行tabを押せ。整形してくれる。

56 ：仕様書無しさん：2007/06/17(日) 23:51:29

提出用の水増しソースを別に用意しておけばいい。

57 ：仕様書無しさん：2007/06/18(月) 01:12:42

_NOP();
_NOP();
_NOP();

を３００回書け。

58 ：仕様書無しさん：2007/06/18(月) 01:30:15

単なる水増しではなくて
「処理を遠回しにする」とか「意味があるような無いような微妙なのを入れる」とかがよくね

59 ：仕様書無しさん：2007/06/18(月) 01:37:49

最適化で消滅するようなのがいい。

60 ：仕様書無しさん：2007/06/18(月) 03:08:59

どこからも呼ばれることの無いダミー関数を
紛れ込ませるとか。

61 ：仕様書無しさん：2007/06/18(月) 04:33:39

お前ら、対策がすでにレベル低いっつーの。

リファクタリング機能で関数全部インライン展開しろ。

62 ：仕様書無しさん：2007/06/18(月) 14:14:57

水増しの方法にレベルの高低があるのかｗ

63 ：仕様書無しさん：2007/06/18(月) 14:42:51

自動単体テスト用のコードを追加したら？
後々役に立つ可能性あるし、コードレビュー時にも言い訳ができる。

64 ：仕様書無しさん：2007/06/19(火) 08:36:31

#define とtypedefによる定義を300行加え、
それらは決して使われることがないというコードならいけると思う。

65 ：仕様書無しさん：2007/06/21(木) 13:13:15

int [] a = new a [300]();
a[0] = 0;
a[1] = 1;
a[2] = 2;
a[3] = 3;
…
a[299] = 299;
でおｋ

66 ：仕様書無しさん：2007/06/26(火) 18:49:25

>>65
こぴぺで楽に。

void step(){
int a=0;
a++;
a++;
a++;
・・・
}

67 ：仕様書無しさん：2007/06/26(火) 20:41:39

考えてみたら、おバカな要求だな。

68 ：仕様書無しさん：2007/06/26(火) 20:43:24

馬鹿なもの作ってんだもの
意味のないもの作ってんだよ

69 ：仕様書無しさん：2007/06/26(火) 23:53:32

俺のところは関数の数で見積もるから
人を減らされないように
共通化できる関数も無理やり分けさせられた

人減らされても共通化したほうがマシな結果になった

70 ：仕様書無しさん：2007/06/27(水) 09:08:34

>>69
別個の関数から共通関数を参照するだけ
とするとか
関数の粒度を下げるとか
いろんなやり方はあると思いますけど。
本末転倒かと。

71 ：仕様書無しさん：2007/06/27(水) 12:30:11

とりあえずその場でステップを踏んでみろ！！

72 ：仕様書無しさん：2007/06/27(水) 13:01:00

貧乏揺すりならいつもやってますぜ

73 ：仕様書無しさん：2007/06/28(木) 01:44:56

なんかシベリアで無駄に穴掘って埋めるだけの作業をやってるような気分になるな・・・

74 ：仕様書無しさん：2007/06/28(木) 16:11:21

貧乳揺すりしても揺れません。

75 ：仕様書無しさん：2007/07/02(月) 01:14:16

>>69
分岐しない物を関数に分ければいいのに。

1ステップを1関数にするとか。

それじゃ悪いのか？

76 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 14:42:51

Rubyのワンライナーとかって、ステップ数どうなるんですかね？

77 ：仕様書無しさん：2007/11/18(日) 15:04:34

ステップ数気にするような人はRuby使わせないんじゃね?

78 ：仕様書無しさん：2008/04/18(金) 22:41:24

あ

79 ：仕様書無しさん：2008/04/18(金) 23:31:14

71はオッサンだな

80 ：仕様書無しさん：2008/04/19(土) 12:27:14

リファクタリング：関数のインライン化
不吉な匂い：コードのステップ数が足りない

81 ：仕様書無しさん：2008/05/31(土) 02:15:30

工数見積もりに「追加ステップ数」「修正ステップ数」「削除ステップ数」「負荷係数」って言葉混ぜる。
その見積もりがうまく通れば、相手の顔を立ててステップ数の話しながら煙に巻くことができる。

82 ：仕様書無しさん：2008/12/27(土) 10:21:33

俺の推奨するやり方ですが・・・

・開発の途中で検討した（古い）関数を、
BAK_関数名_20081227という感じに、当面残しておく。
たとえば、Ａ案、Ｂ案、Ｃ案と検討してＣ案を採用しても
Ａ案とＢ案を消さないということ。

コメントにＡ案Ｂ案Ｃ案の検討結果を記載するから
決してコールされないけど価値のある情報。

83 ：仕様書無しさん：2008/12/31(水) 09:06:47

やっぱりアセンブリ出力して、それを提出したら？
大本のコードいじるよりよっぽど利口じゃん。

84 ：仕様書無しさん：2009/03/24(火) 07:06:36

また目立スレがたったと聞いて駆けつけました