1 :
仕様書無しさん :
2006/09/16(土) 00:48:10 考えようぜ。
2 :
仕様書無しさん :2006/09/16(土) 00:49:51
C++でstatic使ったら死刑。
3 :
仕様書無しさん :2006/09/16(土) 00:51:56
変数名はソースを見やすくするため8文字固定とする。 最初の2文字が型を示し、次の二文字で機能略称を示すこと。
>>2 それじゃC++でまともにWindowsプログラムが組めんがなw
5 :
仕様書無しさん :2006/09/16(土) 00:53:14
全てのコメントがAA
6 :
仕様書無しさん :2006/09/16(土) 00:58:25
コメントで世間話禁止
7 :
仕様書無しさん :2006/09/16(土) 01:00:35
8 :
仕様書無しさん :2006/09/16(土) 01:04:13
多重継承をしたら腕立て300回。 それでも、しなくてはならないなら、すれば良いさ。
9 :
仕様書無しさん :2006/09/16(土) 01:05:57
caseとelsif禁止 全部ifのネスト
10 :
仕様書無しさん :2006/09/16(土) 01:09:07
11 :
仕様書無しさん :2006/09/16(土) 01:16:47
ポインタの限界に挑戦する。 int *******************************i;
12 :
仕様書無しさん :2006/09/16(土) 01:21:10
演算子は全て自作。
英単語のスペルミスったら100回書き取り
14 :
仕様書無しさん :2006/09/16(土) 01:25:41
スタックに積んだら積みっぱなし。
15 :
仕様書無しさん :2006/09/16(土) 01:30:25
newしたら、 あとで誰も見てない所でこっそりdeleteしてあげる(はぁと)
16 :
仕様書無しさん :2006/09/16(土) 01:42:21
ローカル変数使用禁止
17 :
仕様書無しさん :2006/09/16(土) 01:47:52
バグ出したらクビ
変数の頭にbだlだ付ける。 読みにくくって仕方ねぇ。
メモリ開放禁止
スタック使用禁止
1関数のステップ数は400程度とすること
(1)1レベルインデントする場合は、行頭にtabを1つ入れること。 スペース8個にしてはいけない。 (2)n>=2レベル以上インデントする場合は、行頭にtabを1つ入れ、 その後にスペースを(n-1)*4個入れること。 この場合、途中にスペースが8個以上続いても、 これをtabへとunexpandしてはいけない。 なんで行頭だけtabに固執してんだよ???
>>22 4カラムインデント派と8カラムインデント派の政治的妥協の結果だろうな
タブはエディタによって見え方違うから使うなと散々言われているな リリース前に置換するからいいけどかったるいっちゃあかったるい 1行74(だっけ?)文字までってのは本気でやめて欲しい
tabでもスペースでもいいけど、 tabとスペースを混ぜるのだけはやめろ。
26 :
仕様書無しさん :2006/09/17(日) 11:02:49
ログの出力は必ず "よ、元気か!!:" で始める。ちょっと癒される。
27 :
仕様書無しさん :2006/09/17(日) 12:10:43
「~するかも?」とか「~するかな?」とか「~するはず」等と 不安を煽るコメントは書かない。
修正前のコードは削除せず、コメントにする
問題点・疑問点があったら、まずソースコードのその部分にコメントとして書き込んで、後で修正忘れが無いようにする。
処理の流れを追いやすくするためすべての処理はmein関数内に入れる
main を meinと書かない。
>>28 CVSとかSubversionを使いなさい。
33 :
仕様書無しさん :2006/09/17(日) 13:56:50
Bob?
>>32 それでこの問題が解決するって考えは甘くないか?
つーか甘かった
36 :
仕様書無しさん :2006/09/17(日) 16:10:06
>>2 >>4 匿名名前空間使えとかそういうこと?
Windowsでまともにプログラム組めないの?
>>22 これはかなり逝けていますね。
>>24 1行74をJavaのコーディングルールで規定されそうになったことがある
38 :
仕様書無しさん :2006/09/17(日) 16:40:02
1メソッドは30行以内にすべし。 1メソッド800行とかさ、漏れには理解不可能。
>10 caseもelseifも存在しないsmalltalkで開発してるオレへの挑戦か?
40 :
仕様書無しさん :2006/09/17(日) 17:40:00
>>22-23 インデントをどうするかをルールにするより、どのエディタを使うかを
ルールにしたほうが早い気がするのは俺だけ?
エディタも設定でTab幅とか変えられるし・・・
タブだとソースの容量がほんの少し減るよね。
>>40 もう、SQL叩き打つようなコードのだと慣れて無いエディタ使わせると効率落ちるだけじゃね?
俺は普段メモ帳だからオールマイティだけど。
>>43 >SQL叩き打つようなコード
ちょっとココ、突っ込みたいけど我慢しとくわwww
タブ(0x09)をHTMLタグ、タブが表す表示幅をCSSと考えると
46 :
仕様書無しさん :2006/09/18(月) 00:27:03
gotoは片道切符。
コメントは縦書き /* ← */ /* こ */ /* こ */ /* で */ /* ク */ /* リ */ /* ア */
1クラス5関数以内(getter,setterは除く)
goto 禁止
1メソッド10行まで
//のコメント禁止
ネストは最高3つまで。
プロトタイプ宣言は必ず書くこと。
ローマ字禁止。
>>37 Eclipseデフォルト設定で
自動フォーマットすれば、勝手にそうなるからでは?(74文字かどうかは忘れたけど)
FindBugsにもそういう設定があったよね。
>>52 SunのCコンパイラだとエラーになるし。(C99対応する前の話。今はしらね)
SVNなどで管理しているソースは、 以前のソースをコメントで残さない。 …なんの為のツールなんだと思ってるんだか。 2000.3.22 xxxx関数の呼び出し 以下コメントでソースとか平気で残ってて、可読性が悪すぎorz
>>57 いや、これC++でのお話なんですよ。
根拠不明だけど、Cのコーディング規約をそのままコピペしたっぽい。
誰も疑問もたずに従ってたのが不気味でした。
javaにて toStringを作者名でオーバーライド;w;
>>61 俺も見たことあるよ、その規約。
しかも他の項で#endifにはコメント入れろって書いてあって
#endif // _XXXXX_
のような例が出ててわらた。
64 :
仕様書無しさん :2006/09/28(木) 23:49:24
打て、とにかくがむしゃらに打て。 打ちまくれ。キーを。
職場でオナニー禁止
>>49 goto 禁止 & return は1つのルールが最凶。
無駄な flag とループがいっぱい。
書いていて欝になった。@目立
67 :
仕様書無しさん :2006/09/29(金) 19:24:49
>>66 わかる!!
flagとか意味も無く多用するなと言いたい!!
セットしたのに何にもしないで捨てるだけとかやめてくれ。
flagを見ると条件反射で何か重要な判定に使用するんだろうなと
身構えてしまう悲しい俺の性。
68 :
仕様書無しさん :2006/09/29(金) 19:38:35
すまん。微妙に話がずれた。 returnを一つにするためにflagを使うってことだね。 returnが一つじゃなくても理解できるからそんな心配するなよって言いたくなるね。
このスレ地味にウケる。
・変数を各所でつかうな←原文忘れた そのせいでboolを3つ用意とか、、、それぞれ一度しかつかわないのに ・変数を宣言したら必ず初期化、渡された変数(アウトパラ)も初期化 当然でかいstructも毎回初期化 それで処理速度遅い言われても知らんがな(´・ω・`)
デザインパターンを使用したら、その旨をコメントに明記。 そしてさらに、「変更時は要相談」と明記。 なぜなら、デザインパターンを知らんやつがそのコードを見ると なに分けの分からんコード書いてんだと言って勝手に書き換えてしまうから。 せっかくのBridgeやStrategyが見るも無惨な姿になっていく。 「先輩、分かりやすくしときました」 ってお前、何言ってんだ~。やめてくれ~。
72 :
仕様書無しさん :2006/09/29(金) 23:15:32
スタック待避のタイミングは 関数処理呼び出し時は、呼び出す直前で、 割り込み処理は、割り込み処理内の先頭で。 スタック待避は必要なもののみを待避して、処理が助長にならないようにする。
逝けてるコーディングルール:VB いくらやっても判った気がせんC/C++な自分。
74 :
仕様書無しさん :2006/09/30(土) 10:59:59
>>42 そういやCurlはソースファイルのサイズで課金されるらしいから
そういう言語ではメリットあるかもね。
>>70 大して逝けているとは思えない。
むしろバカ避けとしては立派な部類。
>>70 そんな職場で働きたいな
うちは「例外エラーは全てのプロシージャ・関数に書こいて途中で落ちないようにしよう」くらいしかねー
問題があると他のシステムではどうしてる?真似してないのが悪いって事になる
>>70 の内容を見ると、むしろ70の方が逝けてると思うんだが
少なくとも、型が同じだからといって、異なる用途に一つのローカル変数を 使い回すのはDQNだな。ループカウンタとかフラグとかでやってる香具師を よく見るが。
79 :
70 :2006/09/30(土) 15:23:51
別になにも文句言われないならいいんだけど メモリ足りないとか処理能力試験で性能でないから改善しろとか こんな(元は)簡単なプログラムこれ以上どうこうできん(´・ω・`)
80 :
仕様書無しさん :2006/10/01(日) 18:21:07
>>71 >デザインパターンを使用したら、その旨をコメントに明記。
よくいるよな、覚えたから、と言ってスグに使いたがる奴
無理矢理適用して非常に判りづらい代物にしてオナニーしてやがる
デザパタ使用したなら理由も書いておけって
まっとうに理由が書ければオナピーではないというジレンマ。
ハンガリー記法オンリー
>>80 なんか嫌な事でもあったのか?
聞いてやるから言ってみろよ。え?
荒れるからやっぱやめた。すまん。
Cでbreakはswitchの中のみって良くあるルール? 組めなくは無いけど、結構きつい。 おまけに関数の途中でのreturn禁止。 continueも禁止
>>85 最適化すると、アセンブラレベルでのトレースが殆ど不可能になるからな。
goto使ってるのとbreak,continue使うのは、シンタクス的に違っても、やってることはかわらない希ガス。
>>85 まともな所ならないよ、まぬけルールだね
>>86 アセンブラレベルでトレースするなら最適化禁止しるw
>goto使ってるのとbreak,continue使うのは、シンタクス的に違っても、やってることはかわらない希ガス。
構造化プログラミングから勉強しなおして来い
>>85 breakでエラー処理にとばすというのは、よくやる。
>>87 いや、86のいってること、そんな間違っちゃいないんじゃないかな。
フローをすっとばすという意味では「やってること」はgotoと変わらないと思う。
例外のtry~catchもそうか。
ただ、どれも使い所がgotoに比べて限定されるから
乱用が避けられていいんじゃないかなと。
構造化定理ってのは、逐次と条件分岐と繰り返しだけでプログラムが組めるって やつだね。実際には不便過ぎるからcontinueやbreakみたいな制限つきジャンプが 導入されているわけだ。関数の途中でのreturnも同じ。 MISRAなんかはこれらを禁止するルールがあったと思うけど、推奨レベルの 項目だったかもしれん。
91 :
仕様書無しさん :2006/10/02(月) 22:21:23
アセンブラレベルで考えるとたしかx86系の場合(間違ってたらすまん) short jmp near jmp far jmp 等で実行速度や実行時のデータ量が変ってくるはず。 breakとgotoって使い方によってアセンブラの落ち方が変るのかな。 最適化して同じコードに落ちる事もあるだろうけど。 というより、 CPUからみてどれだけ離れたアドレスに飛ぶかでアセンブラのコードは変ると思う。 ただアセンブラを意識し始めたら始めたら if文の条件で<と>のどっちを使うかとか、 ループのforかdo whileのどっちを使うかとか、 考えないとってことになる。 zフラグを見てのブランチだと早いとか、cmpだとどうだとかさ。
92 :
仕様書無しさん :2006/10/02(月) 22:25:20
前にやったプロジェクトでは malloc, calloc禁止のとこがあった。このプロジェクトは失敗した。
free禁止よりマシ
>>92 それは組み込みとかでは問題ないでしょ
MISRAにはそういったルールがあるわけだし。
95 :
仕様書無しさん :2006/10/02(月) 22:37:45
>>94 組み込みはしらんがソラリスの開発だったよ。
96 :
仕様書無しさん :2006/10/02(月) 22:39:19
カーネルオブジェクトを激しく使う合間でmallocなどしてると 処理が追いつかなくてあっという間にリークするというのはあるので malloc,calloc使うのはいいが、メモリPoolingクラスなどにする 必要があるでいいかな。
97 :
仕様書無しさん :2006/10/02(月) 22:40:19
やっぱりイケてるルールは if文の代わりに三項演算子で書くというのがかっこいいな。
>95 斗う漢のbrk(2)だな!
99 :
仕様書無しさん :2006/10/02(月) 23:27:49
昔はカーソルからの入力判定による座標の変更を IF文じゃなくて論理演算でやるってのがあったな。 IF文を使うと処理が遅くなるからってのが理由だった。
/dev/zeroをprivateでmmapすればいいじゃん。
101 :
仕様書無しさん :2006/10/03(火) 23:03:01
y=x/7*14なんて書いたら即刻死刑。
たしかに意味のある定数なら #define で命名しておくべきで、 プログラム中に直接埋め込むのはよくないな。
えーと、こうかな? y EQUALS x DEVIDES CONST_7 MULTIPLIES CONST_14
意味ある定数でも #define はねぇだろ ちゃんと const 使えって
いやもしかしたら
>>101 は
y=x*2
と書けってルールだったりして。
x * 60 * 60 * 24 とかも死刑とか。
y=(x/7)*14 こうかけってんじゃね?
y = x*0.142857142857*14 こうでしょ。
y=x<<2と書けってルールだきっと。
y=(double)x/7*14 だろうきっと
y = x / 7 * 14 こうじゃね?
正解はこれ y=x/7.0*14.0
114 :
仕様書無しさん :2006/10/05(木) 21:24:23
115 :
仕様書無しさん :2006/10/05(木) 21:32:33
>>101 >y=x/7*14なんて書いたら即刻死刑。
シンプルな一行だけど、凄く奥が深い。
俺は
y=x<<2
に一票。マイコン系だと7で割るってかなりやばい。
>y=x<<2 だと4倍されてしまいますが
117 :
仕様書無しさん :2006/10/05(木) 21:55:08
しまた!!かっこ悪すぎ俺、皆笑ってくれ。
あまり笑えんのだが・・・
119 :
仕様書無しさん :2006/10/05(木) 22:05:31
ベーマが懐かしス。
120 :
仕様書無しさん :2006/10/05(木) 22:15:51
y=x/7*17*32/64+7+23-30 とか書いても賢いコンパイラは y=xと解釈してくれた 気がする。
整数演算だと x/7*14 と x*2 の結果が違うことあるから勝手に判断されるのは賢いと言えるかどうか てか、もうこのネタ引っ張るのやめようよw
volatile 使う?
123 :
仕様書無しさん :2006/10/07(土) 01:35:48
fainalを使おうぜ!!
124 :
仕様書無しさん :2006/10/07(土) 02:07:17
analを使おうぜ!!
125 :
仕様書無しさん :2006/10/07(土) 02:15:03
viagraを使おうぜ!!
sex void main(insert) { }
<?php $a = 0; if ( $a == 1 ) { echo "a == 1"; } else { echo "a != 1"; } ?> ↑ifのカッコ内で、カッコと式の間にスペースを入れて読みやすくしているようなコードを見かけるけど、ルールにした方がいいですか? ・入れ子になってるとか、カッコをたくさん使う場合、カッコの数合わせを確認しやすいとか、そういうメリットでやってんのかな? ・詳しく知らんが、LISPみたいにカッコをたくさん使う言語?の独特な記述を取り入れているのかな? どうなんでしょうか?
>>127 どこからツッコムべきか。
・スレ違い
・そもそも板違い
・IDEの整形にまかせとけ
・整形ツール使え
・好みの問題
129 :
仕様書無しさん :2006/10/08(日) 00:47:15
いやいや、ここは親切に答えてあげようじゃないか。 > ・入れ子になってるとか、カッコをたくさん使う場合、カッコの数合わせを確認しやすいとか、 > そういうメリットでやってんのかな? ウ~ンそうでもないんじゃないのかなと思うけど、そうなんじゃないかもしれないかもないね。 > ・詳しく知らんが、LISPみたいにカッコをたくさん使う言語?の独特な記述を取り入れて > いるのかな? そうかもしれないけど、そうじゃないかもしれない、結局の所あらゆる可能性を考えると 正確な判断は難しい。
130 :
仕様書無しさん :2006/10/08(日) 19:17:31
何と、うちの会社にはコーディングルールなど存在しない(いやマジで
>>1 過剰なルールなら避けるに決まっている。
Subversionを使えば必要がないくだらないコメントも省けるんだし。
#ifdefなどのJavaに無いプリプロセッサ禁止。 演算子のオーバーローディング禁止。
レビュー禁止
134 :
仕様書無しさん :2006/10/11(水) 22:25:10
キーは、脇を閉めて内角をえぐるように打つべし。
135 :
仕様書無しさん :2006/10/14(土) 12:46:50
>>122 volatile使っても何故か最適化されてしまうときがある。
なぜだ?
>>135 1.プログラマの勘違い
2.コンパイラのバグ
お好きなのをどうぞ
137 :
仕様書無しさん :2006/10/15(日) 11:20:30
gotoが何故嫌われるのかわからん いちいちbreakとか使うの煩わしい
>>137 あとで他の人が流れを追いにくいから。
他の人が修正するときにミスを誘発しやすい。
逆に言えばそうならない使い方なら問題ないね。
そうならない使い方をみんなが出来るわけじゃないから規制されてるわけで
schemeとか末尾再起はgotoにしてるよね 完全に管理できてるなら、スタックも消費しないし有効なんだけど、 なんせ、人が使うには高度すぎる機能なんだと思うよ。
関数が小さいなら問題ないような。 むしろグローバリー変数の方が問題。
グローバリー変数・・・・ なんでもかんでも配達してくれそうな変数だなw
143 :
仕様書無しさん :2006/10/15(日) 22:13:30
>>138 俺はエラー処理はほとんど goto でやってるよ
変数名にgstXXXってのをみたよ。 ぐろーばるすとらくちゃーの略だってさ。
ヤバイ グローバリーがツボw
先物?
>>142 もしかしてデリバリー変数とごっちゃになってないか?
149 :
仕様書無しさん :2006/10/17(火) 18:54:20
社内恋愛禁止
150 :
仕様書無しさん :2006/10/17(火) 22:18:58
<<2って4倍だよな? <<xって*(2^x)だから 2倍は<<1だろ? 俺間違えてる?
間違っちゃいないが、そんな古いネタにいつまでも固執してんなよ
152 :
仕様書無しさん :2006/10/18(水) 09:14:08
>>145 それわりと普通じゃね?
特にVBなんかの場合。
午前中、「ソース修正は元ソースをコメント化」をやらされた cvs使ってるのにorz
グローバル変数はgとか接頭辞を付けるってのはあるね。 あまり数がないことが前提だが。
>>154 結構ありますね。
でも、そんなことするよりもスコープ指定でやれよ、といつも思うデス。
(Cなら)まずファイル内staticで片付くモノならそうすべきだな。
cvSってのはいざというときに復元したいために使ってるんであって 保守とか開発とか修正とかやる立場なら ソースそのものは「直感的に見てすぐパッと」知りたいもんじゃないの?
昔、こういう間違いを見たことがある。 Private gstrHoge As String 名前で区別しても、それが間違ってちゃ意味ねーよな、と。
>>158 そういうのはソースレビューでチェックしろ
そういうソース書くやつは、他にもたくさん同じようなことしてるよな・・・。
Public から Private に格下げしたんじゃね
Private pgrHoge Ass String
ソースレビューって何ですかorz そんなことするルールが無いことがorz
164 :
仕様書無しさん :2006/10/21(土) 11:37:14
↑逝けてる現場だな。
165 :
仕様書無しさん :2006/10/21(土) 11:53:08
コードレビューて言わない? ソースレビューじゃ広島焼きみたいだ
コードレビュー無し、仕様書も無し、の現場なら知ってる。
ソースレビュー(広島) オタフクソース:90点 カープソース:75点
ソースレビューでもコードレビューでもなんでもいいけど そんなだからトラブル時に中身の分かる者が休んでいると対応が翌日とかになっちまうんだよな 転勤とかなったらどうすんだよ
それより、辞めたらとか、入院したらとか、死んだらとか。
170 :
仕様書無しさん :2006/10/21(土) 16:56:25
今日は広島焼き食いたくなった。これから食いに行く。
171 :
仕様書無しさん :2006/10/21(土) 21:27:09
広島焼き、ネギトッピングオプションで食った。 うまかった。ソースはオタフク。
移行案件で、仕様は現物とソース おもいっきりトラぶって、ばっくれたが、後でコードレビューがあって叩かれまくられたらしい 規約もフレームワークも仕様も無視だったらしい というかそれら全部提示なかったし
逝けてるコーディングルールじゃなくて 逝けてるコーダかよ!
ソースコードレビューやるのは良いが、少人数だとちゃんと教えられるレベルの人が居ないなんてことも。 「変数宣言は必ず関数・メソッドの先頭」、「gotoは絶対禁止」なんて人がいっぱい居る会社だからな。 俺も最近までそんな奴らの一人だったわけだが
176 :
仕様書無しさん :2006/10/23(月) 00:04:22
ルールの真意を知っている人は ルールを崩しても良い場合を判別できるけど、 そうでない人がマネして、崩してしまうと困る。 赤信号を渡っていいかどうかと似てる気がする。 ちゃんと車が来てない事を確認できれば渡っていいが それが出来ないなら、まずは赤では渡るなと。
守破離だよな
179 :
仕様書無しさん :2006/10/23(月) 15:40:46
ハンガリアンって、いまどき、どうなの? 僕は大嫌い。型は宣言をみればわかる。
ハンガリアンにしないと型がわからんくらい でかいソースが問題だわなあ。
181 :
仕様書無しさん :2006/10/23(月) 17:07:27
でかい=長い関数? むかし、同期のデバッグ手伝ったんだが、 コピペの塊みたいなCの関数があって、2000行くらいあって コンパイラが警告吐いていた、長すぎだよって(W +++ 関数の長さは50行まで、と言いたい。
>>181 うん。ローカル変数だったら長すぎる関数。
メンバやグローバリーだったら長すぎるクラス・ソース。
ハンガリアン、途中で型変えたりしにくいしイヤン。
事前にちゃんと設計しろといわれりゃそうだけど。
183 :
仕様書無しさん :2006/10/23(月) 18:38:08
>ハンガリアン、途中で型変えたりしにくいしイヤン。 正解だと思うよ、手を入れることは前提にしないとね。 プロジェクト内とかでも、可読性とか一貫性とか最小限にすべきだよね、 この手のルールは。そもそも王道なんてないわけだし。
>>181 俺が見た最長関数は9千行超えてたよ
もうね、分割しようっていう気力もわかずにコード書き足したよ
はは、ははははははは・・・
それはもはや関数じゃないだろw
俺は8000行までしか見た事がない。
たった2000行ぐらいでした。mainが。
ちゃんと関数に分けて作ったらソースレビューで分けすぎとか言われた。 「はぁ?」とか思いながら既存のソース見たら1関数がウン百行、 ついでにグローバル変数の宣言もウン百行。 お前ら分室にこもってばかりいないでもうちょっと外の空気を吸えよと。
しかもテーブルは全く正規化されていない。第1正規形にすらなっていない。 ソースレビューなんかする前にテーブル設計レビューやってもらえよと。 今思えばあの分室はコボラーが支配してたのかも。
ごめんよ。 おれは ・ 汎用機能 他のシステムその他開発に転用できる機能(あるディレクトリのパスリスト取得する、とか) ・ 固有機能 そのシステム内でのみ多々使われる機能(システム内の共通オブジェクトに関する処理とか) ・ サブ/メインフロー 汎用、固有の機能呼び出し部分 って分割の仕方してて、サブ/メインフロー部は2000ステップとかざらにある。 (ただしその1/2は空行だけど、処理ブロック単位に分ける為の) 仕様変更多発の(っていうか仕様確定ぜんぜんできず、検証がてら開発入らないと間に合わない) Prjを5,6年やってるんだけど、これで開発やってたらがんがん仕様変更いれられても、 固有箇所に関する変更、サブ/メインフロー部分に関する変更、って 感じでほとんど仕様変更部分が他関数にまで影響しなくなった (汎用部分には不具合以外では仕様レベルの修正は入らない=変更なし)。 楽だから多分やめられない・・・冗長プログラミング、って名づけてみた。
それって普通なんじゃ・・・
>>188 1行しか処理の無い関数いっぱい作ってる奴も見たことあるけどなw
getter、setterやコールバックとかじゃなく。
>>190 フロー部に汎用性がなく不可分であるなら
それは正しい
>>192 適切な分割単位になってるならそれでいいんじゃないか?
一箇所からしか呼ばれないなら終わってると思うが。
各々方、機能の分割には限界が無いという前提を忘れていないか
>>194 一箇所からしか呼ばれなくても構わん。
関数に分ける意義の一つは、正しい関数名を付けることだからな。
ってか、他システムでも使えそうな関数作っといて、 他システム開発で流用する(ソースをプールはコンプラうんぬん、はおいといて)。 結局コーディングって毎回1から作るか、 自分用のライブラリ作りで積み上げてくか、 で数年経ったら大きな違いが。 毎回同じ処理1から実装して同じ不具合出してた奴がいた。 そのコード解析/対応をするのがおれだったから そいつには氏んでほしかった・・・
はまぐちぇでも学習するのになw
>>194 C,java,C++なんかの場合、構造体のメンバを返す関数とか作らないか?。
return struct.menber;
みたいなの。
if(xxxx==0)
return 0;
else
return struct.member;
とか。
機能分割して細かいソースに分けておくのは業務知識の蓄積にも意味があるな セキュリティの観点からソースの直接の流用は出来なくても、分割するために思考削除した経験は活きて来る
>198 はまぐふぃと
自分が担当する以前に存在していたコードを 必要な範囲まで理解するってのも重要だと思う。
>>202 そんな時間があればな・・・
前にやってた人の分があるのだから早くできるだろうと思われるのが関の山
関数というシステムが何のためにあるのか、忘れ去られているんだな・・ 冗長性を最小限にしようというシステムだぞ。 人間の思考パターンとも一致するし。 冗長に書くと、最適化レベルの変更だけで、コードサイズががくっと変わる・・。 そういう場合は、かなり怖いよ。どういう変更が入ったか解らないし。
205 :
仕様書無しさん :2006/10/28(土) 12:41:12
仕事中に株禁止
>>202 >>203 プログラマが常に抱えるジレンマ。
既存のコードを理解するか。
理解しようとしてもどうしても出てしまう理解漏れを恐れて一から作るか。
一から作り直す事で、新たなバグを生み出してしまわないか。
作業時間が、しばしば以下のようになるのをどう説明したら良いか。
(コード理解時間+コーディング+デバッグ)>(一からコーディング+デバッグ)
207 :
仕様書無しさん :2006/10/28(土) 15:59:45
>>66 俺の関わったPJでは、この規約で
do {
if ( ホニャララ ) { break; }
} while(0);
ってやってた。
悪くないけど、インデント深くなるし、
関数抜ける gotoくらいは許可して欲しいよな。
ちなみに1行は80だったな。
208 :
仕様書無しさん :2006/10/28(土) 16:07:18
>>120 整数演算で
y = x/7*14 とかって使うんだけど、これって良くない?
Cなんだけど。小数点切り捨て。
いちいち
z = x/7
y = z*14
とかやると面倒だから、上みたいに書いてるんだが。
209 :
仕様書無しさん :2006/10/28(土) 17:34:49
>>208 プロジェクトによるんじゃないかな。
マイコン系だったらy=x<<1ってしないとアウトな場合もあるよ。
7で割ると処理時間がいきなり増えるから。
コードにいきなりy = x/7*14 って書いてあっても
意味が分かれば良いとは思うけど
なんで7で割ってるの?14をかけるの?ってことになると
不親切かな。後から見た人が首を傾げるかも。
210 :
仕様書無しさん :2006/10/28(土) 17:46:13
>166 >コードレビュー無し、仕様書も無し、の現場なら知ってる。 そういう会社で働いてた。 テスト(デバッグじゃなくてね)も、納品前(しかも三日前とか)に纏めて一回やるだけ。 人の作ったのを見て作るから、どっかでバグが紛れ込むと、伝染病のごとく広がっていく。 高速化のため、 if ( condition == true ) ではなくif ( condition ) と書く、というルールがあったな。 それを考えると、このスレの話題はものすごくレベルが高いと思いまする。
211 :
◆7mzqs59qfc :2006/10/28(土) 19:17:30
これ↓高速化になるんだ。 病気で頭まわらんからよく検証できんけど。 >if ( condition == true ) ではなくif ( condition )
ま、ふつーなら最適化でつぶされるけど。
214 :
210 :2006/10/28(土) 20:45:48
高速化にならんよ、当然。 加算命令一個減らしてもタカが知れてるし。 それが業務アプリのUIとくれば、馬鹿っぷりをご理解頂けると思う。
VisualBASIC2.0の頃の話じゃね?
boolean型を返す関数の場合だけの話 if ( condition == true ) って気持ち悪い if ( condition ) の方がすきだな
/7*14はネタだよね。 だれかネタといってくれー!!!
そういう現場ではこんなことも起こりそうだな。 typedef int boolean; #define false 0 #define true 1 //... boolean condition = 2; //... if ( condition == true )
219 :
210 :2006/10/28(土) 23:44:10
>>215 いや、.net。
まさに逝けてるコーディングルール。
「こうすると早い」とか言うネタほどうさんくさいものは無いからな。
221 :
仕様書無しさん :2006/10/29(日) 00:32:40
脳内コンパイラー持ってる奴が多い。 TPOをわきまえずに最適化しようとする奴多すぎ。 210じゃないけど、業務アプリのUIを「早く」してどうすんだと。 TPOをわきまえずにコードを最適化しようとする奴は、社会人としてのTPOもわきまえてない、 なんて法則ありそうだなw
222 :
仕様書無しさん :2006/10/29(日) 00:39:36
>>216 それは可読性が悪い。
condition という変数がboolean型であると知っているのは本人だけ。
他の人が見る時は一々定義を参照するはめになる。
bolCondition みたいにする命名規約があればいいけどね。
>>222 普通ちゃんと変数名つけるでしょ。
bolなんてのじゃなくて、もっと自然なの。
isなんちゃら、とか if とつなげて文章みたくよめれば
逆に比較演算子無い方がいい。
それにさ、if(condition)ってなってたら定義をいちいち参照しなくても
boolean扱いして読めばいいんだな、って判るよな、普通。
2chですらTPOを弁えてない奴は、ニートが学生である。
C言語では TRUE との比較は避けるべきコーディングてのが常識だろう
>>226 0:偽
その他:真
だからってこと?
おれ普通に
if(fFlg == true){
if(fFlg == false){
とも使っちゃってるや。フローの流れ的に意味通ればいいかな、と。
論理型定数との比較自体がナンセンス。
>227 かなりダメ
>>226 Cじゃなくて、論理値にtrueとfalseしか使えない言語だったらおkだろ?
232 :
仕様書無しさん :2006/10/29(日) 09:51:12
>>230 でもほとんどのPJで仕事量=ライン数という感じだよな。
ソフ開で開発工数の求め方とか勉強したけど、
現場では全然使わないな。
233 :
仕様書無しさん :2006/10/29(日) 09:52:32
>>217 最適化で *2 ってなっちゃいますかね?
それが怖いなぁと思ってんですが。
いちお、いまの環境では意図どおりに
計算されてたのは確認したんだけど。
C言語で if( foo = func()[6] ) { //色々fooをつかっったやつ } とかってのは駄目?。後輩に何やってるかわからねぇと言われた。 あげくの果てに==の間違いかと思って修正したとかorz。 Cだと0以外って認識なんだけどなぁ。
関数呼び出しを条件部分で使うのは可読性下がるかなぁ、と。 if(nRet = func()){ } はおれ nRet = func(); if(nRet != 0){ } にするけど。
>>234 誤解や難読の元だと分かっただろう。
何を失うわけでもないのだから、代入と判定は分けておけ。
>>207 それって目立?おっき?多分どっちかだったと思うけど。
漏れも最初にそれ見たとき変ってるなぁとおもた。
けど、goto 禁止なら結構妥当ではと思うよ。
>>232 いわゆる「ステップ数(w)」というヤツですな。
最近はFでもあんま聴かないけどw
>>238 内部というかチェック部隊はステップ数しかわからないが、
現場の人たちはみんなそれぞれ工数偽装ツールを持っているので
金額から逆算できるステップ数で報告しとくと何の問題もない
チェック部門が毎年の様に色々な物を変えてくるけど
チェックをしてるメンバーの頭の出来<メンドクサイと思って適当な報告をする為のツール(工数偽装ツール)
なので、いつまでたってもトラブルプロジェクトを事前にぬき出す事が出来ない
240 :
仕様書無しさん :2006/10/29(日) 16:07:04
>>239 俺はコレクションや制御文の数が極端に少ないVBコードのメンテをしたことがあるが、
それはもしかして、ステップ数稼ぎの為の展開パーサか何かをかまされた後なのか…?
かなり昔、民営化した某企業の仕事やったとき コーディング開始早々にプログラムリストを印刷して提出するように言われた で、出来てる分出したら少ないと文句言われて同じものを3部出して提出したw
>>241 同じの3つコピペして2つコメントアウトしときゃコンパイルも通る。
印刷物ならわかるまい。
パンチカード時代から技術を研鑚し合ってきた紙上デバッグ部隊が控えている可能性は
>>222 conditionがbool相当の型以外でも良いのってC/C++くらいじゃないの?.NET対応言語だと。
245 :
74 :2006/10/29(日) 18:01:49
246 :
仕様書無しさん :2006/10/29(日) 18:23:00
>>241 お役所系は結構そういう話があったらしいね。
印刷されたプログラムリストの「厚さと重さがキモ!」のような。
>>245 従量課金性が蔓延したら・・・
ローカルスコープの変数、メソッド名等は全て一文字。
保守性を担保する為に「台帳」の復活。意味のある名前を付けるときには申請/許可が必要。
文字列はアルファベットか半角カナ。
ジェネリック(テンプレート)超推奨。
とかになるんだろうか…w
248 :
仕様書無しさん :2006/10/29(日) 20:14:47
>>235 のようにしろ!というルールあったよ・・・
if ( func() == hoge ){
}
は駄目で
tmp = func();
if ( tmp == hoge ){
}
ってことね。
まあステップ数(=申告規模)増える点はメリットっちゃあメリットだが・・・
どう見ても違うとおも
252 :
仕様書無しさん :2006/10/30(月) 01:30:30
>>234 警告レベルあげると警告がでるコンパイラも多いと思う。
>>233 ならないならない。7で割った値の整数部掛ける14になる。
そうじゃなかったらコンパイラのバグ。
> 7で割った値の整数部掛ける14 うへ、じゃあ 1.1258*14=14.1258 とかそんな計算がまかり通るのか
C の整数の演算で /7 * 14 が 2倍とは異なるなんてのは 基本中の基本なわけで、これを禁止にしてるのって何が理由何だろう・・・ ドキュメントは全部ひらがなで書くとか、そんな会社か? >1.1258*14=14.1258 整数部だけ掛け算したあとで少数部を加えるのか・・・ これどんな独自言語処理系?
キャストは明示しようね^^
>>255 >C の整数の演算で /7 * 14 が 2倍とは異なるなんてのは
>基本中の基本なわけで、これを禁止にしてるのって何が理由何だろう・・・
直感に反するからじゃね?
残業続きなら間違えそうではある。
>>256 char *str;
str = (char *)malloc(256);
とかか? 逝けてるね。
>>258 それ C++ では必要になる。ソース変更していいんなら new char[256] とするところだけど。
>>258 のどこが悪いのかわからない俺は逝けてるに違いない
優先順位で悩むくらいなら括弧つけろよ
未来永劫一言語しか使わないつもりの会社なら言語に依存したコーディングルールにして置くって手も有るな
>>258 昔から
char *pszStr = NULL;
pszStr = malloc(sizeof(char) * 256);
if(pszStr == NULL){
}
ってな書き方してる。昔はcharのサイズが変わるんじゃね?って言われてたんだよね。
たしかにJavaじゃ変わったが。
>>262 ちなみにとりあえず今は言語覚えたくない、分からない、勉強する気ない、
ってCの開発を避けてVBに固執してる若い奴が、
「いい迷惑」「まわりのやる気をうばう」って理由でほされる事になりそう。
1言語のスーパープロフェッショナルってならともかく、
たかだか数年しかキャリアのない奴が、「それ分かりません、やりません」とか
えらそうなこと言うなと。おまえら知らないことだらけだろ、今が覚えるフェーズだろ、と。
265 :
263 :2006/10/31(火) 01:09:35
しまった、キャスト忘れた。 char *pszStr = NULL; pszStr = (char *)malloc(sizeof(char) * 256); if(pszStr == NULL){ } ね。VCとかではエラーになる。
>>265 > VCとかではエラーになる。
なんで?知らずに C++ 使ってるだけじゃねーの?
>>266 もち拡張子は.cppだよ。
だってCString使うもの。重くたっていいじゃない。便利だもの。
完全Cでの開発って10年前の最初の1年くらいだった。
その後はオブ指抜きのC&C++って感じの開発が十年続いたノサ。
>>265 C++ なら new char[256] だろ。
もしかして new のことを「オブ指」って言ってんの?
C++ と VC を混同してるあたりもヤバイな。
269 :
265 :2006/10/31(火) 01:49:51
>>268 C++とVC、混同、ねぇ(ずっとVCだからしてるかも知れないねぇ。)。
オレ的には、例外嫌いなんだ・・・ただ、それだけ。
ret = func();
if(ret == x){
// エラー発生
}
エラーハンドルは処理のすぐ後で、それがおれのポリシー
ってか、PGって揚げ足取りだなぁ。まぁ、おれも似たようなもんだけど。
>>269 例外嫌い? CString はいいのかオッサン?
CStringの例外は見てない、許してくれ。 オッサンは無精なんだよ。 平気でCStringに500MBとか持たせるけどな。
・・・・
>>271 無精なら new して例外無視しとけよ。
ダブルスタンダードしね。
嫌いっていうか新しいパラダイムに適応できてないだけでしょ 言い訳みっともない
一緒に仕事したくない。。
>>265 pszStr の初期化いらねぇんじゃね?
...と重箱の隅をつついてみる。
しかし sizeof( char ) は使った事無いなぁ。
char が1バイトではなくなったら...1バイト単位の処理はどうするんだ?
>>255 そもそも7で割る事が禁止って仕事もある。
それ以前に割り算禁止、掛け算禁止ってこともある。
計算は、足し算と引き算(引き算は補数でやることも)、
あとはビットシフトのみ。
あと計算した結果が常に同じならば、
それはその結果を代入して、よけいな計算をして処理が遅くなるのを防ぐ。
例えば
a=b+(1+2)/3*4なんてのをコードに書くのは御法度。
シビアな組み込み系だと、
秒単位で動作する機器に対して0.0何μ秒単位の誤差オーダーを求められる事もある。
同期を取るために、アセンブラに落として、一命令の処理時間を計算して
合わないときはnopでサイクル数をあわせて同期を取るってこともある。
って、もしかして話しがずれてる?
>>276 俺は結構sizeof(char)って書き方するよ。
そうですか。で?
ずれまくりだし、そこまでシビアならはじめからアセンブラで書くだろw
なんかZ80あたりでRTOSすら使わない組込系のお話? C言語なんか使うなよw
>>276 1バイト単位の処理なら(size_t)1を使えばいい
でも本当にそれは1バイト単位の処理なのか?char1つ分を単位にした処理ではないのか?
一度、組み込みの快感にはまるともう抜けられない。
それを「組み込まれた」という。
誰が上手い事を言えとwww
>>279 C では、char 型はそのビット数によらず常に sizeof(char) == 1 であるってのを
どこかで読んだことがあるような記憶があるんだが。記憶違い?
287 :
286 :2006/10/31(火) 23:21:57
288 :
286 :2006/10/31(火) 23:29:22
一人で騒がしい奴って居るよな
ほんじゃsizeof(wchar_t)は必ず2になるの?
自分で調べろアホ
292 :
仕様書無しさん :2006/10/31(火) 23:37:08
爺氏ね
>>282 必要なのは char 1 つ分の処理ではあるから1Byte単位にこだわる必要はないか。
でも、char が2Byteになる時には殆どの既存コードが動かなくなる様な気がするので
sizeof( char ) はコードの厳格さに関する自己満足レベルの話でしかないのでは?
>>290 wchar_t とか DWORD とかは勝手に typedef してるだけだから「必ず」ではないだろ。
char と同列に語るべきではないと思う。
>>290 sizeof(char) が 1 である理由を確認して考え直せ。
char=6bit ward=24bit な、変態環境も世の中にはある。
sizeof(TCHAR)は必要だよな?な?
297 :
仕様書無しさん :2006/11/01(水) 10:28:10
爺は巣に帰れ
wardなんて型はしらんな それにcharが6bitでもsizeof(char)は1を返すんじゃないの
この糞コテアホなん?
>>298 ×ward
○word
すまんな。
Cがどう実装されてるかは知らんが、アセンブラレベルでwordアクセスしかなく
1word=3charな変態CPUだ。
WORD懐かしいっす。
わーどうしょう
303 :
仕様書無しさん :2006/11/04(土) 00:21:19
電源を入れるときは周辺機器から。
インデントは半角スペース4文字TAB使うな。
CHAT_BIT
>>305 スペースインデントは腹を切って死ぬべきだ。
あとで、置換出来るメリットからTAB派
タブだとソフトごとに表示結果変わるだろ。 タブインデントこそ腹を切って死ぬべきだ。
置換すりゃええだろアホか
311 :
仕様書無しさん :2006/11/04(土) 15:45:46
スペースだとカーソルの移動でキーを押す回数が多くてイライラする。
312 :
69式フリーPG ◆hND3Lufios :2006/11/04(土) 15:52:20
そんなときはctrl+カーソル
コテってアホばっかか
>>313 ん? いや、普通にctl+カーソルで飛んでいくけど・・・
315 :
仕様書無しさん :2006/11/04(土) 16:23:16
オプソのソースはスペースタブが常識。 タブじゃないとダメとか言ってるのは日本固有の業務系ドカタか携帯ドカタ。
____ / \ | ─ ─ | | (●) (●)| |\(__人__)/| 常識的、と君は言うがな? \ |` ⌒´ | / 自分のいう常識が、必ずしも他人の常識と同じであるとはかぎらない。 / 丶' ヽ::::: 常識とは人の数だけ存在するのだよ。 / ヽ / /:::: これはどのような物事にもいえることだ。 / /へ ヘ/ /::::: 例えば善悪。何が善で、なにが悪かなんてしょせんは人が決めたこと。 / \ ヾミ /|::: 必ずしもそれが絶対とは限らない。 (__/| \___ノ/::::::: ニーチェも「一切は許されている」って言ってるしね。 / /:::::::: 社会で言われている善悪はいわば相対的な善悪なんだよ、 / y )::: 常識だってそうさ、社会で言われている常識は相対的な常識でしかない。 / / /:::: ならば絶対的な「それら」はどこにあるのか? / /:::: それは個人の中に存在する、つまり人の数だけ「それら」はあるんだよ。 / /::::: 突然こんなことを言われても理解できないかもしれないが、 ( く:::::::: きっと君にもわかる日がやってくる。 |\ ヽ::::: 「真実は常に君と共に。」 | .|\ \ ::::: 自分を信じて生きるんだ。 \ .| .i::: \ ⌒i:: \ | /:::: ヽ 〈:: \ | i:::::: (__ノ: __ノ )::::: (_,,/
317 :
仕様書無しさん :2006/11/04(土) 16:32:20
とりあえず、GNUのサイトから適当にダウソしてソースをみてみろ。
オプソのソースはスペースタブが主流。 タブじゃないとダメとか言ってるのは日本固有の業務系ドカタか携帯ドカタ。
Delphiだと字下げは2文字が基本なのでスペース
インデントなんぞプロジェクトに合わせりゃ良いだけだって。 俺はわざわざコーディングルールにしなくても良いとは思うけど。
スペースインデント野郎は自分のインデント幅を 他人に押しつけたくてしようがないオナニー野郎なんだわ。 ホント腹を切ってしぬべきなのだわ。
322 :
69式フリーPG ◆hND3Lufios :2006/11/04(土) 16:35:21
いや、MSのサンプルソースも殆んどスペースインデントだと思うな。
323 :
仕様書無しさん :2006/11/04(土) 16:37:31
アホコテ氏ね
どうでもいんでんと
オプソがスペースなのは当たり前だろ・・・ 気をつかってんだよ。
326 :
仕様書無しさん :2006/11/04(土) 16:47:44
はあ?スペースなんて有り得ないな。
327 :
仕様書無しさん :2006/11/04(土) 16:49:32
常識の無いドカタだな。
>>319 とりあえずDelphiってインデントが2文字なの?
というよりも、Delphiって専用のIDEがあるの?
329 :
仕様書無しさん :2006/11/04(土) 16:56:49
過去にあったかもしれませんが、今は終わってます。
>>328 Delphiの前身のTurboPascalがIDEのはしりなんだよ
Delphi 買ったことあったなぁ Versionすら忘れたけど ほとんど使ってないから
ツールで簡単に変換できるものはどうでもいい。
半角スペースでインデントされていると、カーソルの移動が面倒くさい。
無限ループって怖くね?www
インデントと中括弧と命名規則は永遠の宗教論争だな。
はあ?インデントの度に1ないし3回もスペースバーをパンパンパンと叩くのか? やめてくれ馬鹿馬鹿しい。
OSXだとタブが多いな。
>>336 タブの代わりに指定数のスペース入れてくれるエディタは結構多いと思うがな。
まぁタブが入力できなくなるが、そういう需要があるんだろ。
しかし例えばスペース4つの倍数と規定されてたら、
ミスって3つや7つにしちまいそうな気もする。
俺はタブの方が好きだ。
>>336 君のキーボードにはTABキーがついてないのかね
今時、オートインデント機能も無いエディタ使ってるの?
やめてくれ馬鹿馬鹿しい。
オートインデントは正直うざい
ど~でもいいですよ~
逝けてるコーディングガール
季節を先取りした木枯らしが・・・
オプソもコーディングしてるときはタブだろ。 cvsに上げるときにgnu indent掛けてるんだろ。
346 :
仕様書無しさん :2006/11/05(日) 11:55:38
おまいemacs使ったことないだろ。
おまいemacsしか使ったことないだろ。
TABをスペースに自動変換する機能が無い糞エディタって何?
edlin
4タブと8タブがの奴が居るのが一番悩ましい。 置き換えは簡単だが、参照にファイルの変更を伴うのが苦痛だよ。 量子力学じゃあるまいし。
よくわからないけど、インデントが合っていないと困ることってあるの?
>>353 なんで、わかんないのにマ板にいるんだよw
>>352 量子力学との関連はどう理解すればいいの?
インデントを決めとかないとPGがケンカするからですw
観測する事で波動関数が収束することを、むりやりこじつけたかったのだろww バカが。
結局インデントがタブだろうがスペースだろうが4文字だろうが8文字だろうが 現場で統一されてればそれでいいんだよ
PGならゴチャゴチャ言ってねーで変換プログラムくらい作れやー
361 :
352 :2006/11/05(日) 23:10:18
>>358 そのとおり。
観測するという行為自体が観測対象に影響を与えるって言いたかった。
>>356 そういうこった。
>>361 「バカが。」っていわれてるんでちゅよ(´・ω・)
>>361 それって何?
ハイゼンベルクのなんちゃら原理?
コペンハーゲン解釈?
シュレディンガー音頭
箱の中の猫?
踊っているか、踊っていないか、それとも
箱を開けたはずのシュレディンガーが、 箱の中に入っている!!
死んでるとか死んでないとかじゃない、 もっと恐ろしい物の片鱗を味わったぜ
ここでいつものAA登場 ↓
∩___∩ | ノ ヽ / ● ● | | ( _●_) ミ これですか?わかりません>< 彡、 |∪| 、`\ / __ ヽノ /´> ) (___) / (_/ | / | /\ \ | / ) ) ∪ ( \ \_)
ガスを充満させた箱の中に(ry
・ソースコードのインデントを自動整形してくれる。 ・ハードタブ(TAB)をソフトタブ(半角スペース)に変換してくれる。 ・ソフトタブの半角スペース数を設定できる。 ソースコードを書くエディタには、やはりこれは欲しい機能ですね。
上記3点を満たしているエディタやIDE、満たしていないエディタ、IDEを報告してください。
クラスの初期化ロジックを別ファイル(ヘルパクラス)に分けて 記述しなければならないというルールがあって参った。 初期化の中でクラスのメソッドやフィールドを呼ぶので 軒並みpublicにしなければならないという・・・
>>376 この糞ルールのために、MSはPartialクラスを実装したに違いない!!!!
つか、そのルール作ったやつ死ねよ
380 :
仕様書無しさん :2006/11/07(火) 15:56:19
viの整形に逆らうな
美の成形か。
geditの日本語入力まわりの不具合をなんとかしてください。 vi嫌いなのにviで入力なんて・・・ イマックスはよー分からん。
今ックス
384 :
仕様書無しさん :2006/11/08(水) 23:48:58
emacs最高!!
Tabだなぁ。 Tabはインデント、スペースは構文上の区切りという規約にしてる。 インデントの規約は「○○は1インデント、××は2インデント」とかで決めてるから特に困らないな。 インデントの幅は見た目の問題なんだから、見る側が好みに合わせて設定すりゃいい。 #と、HTML4+スタイルシートちっくな考え方をしている
387 :
385 :2006/11/09(木) 23:06:01
>>386 「見た目の問題なんだから、見る側が好みに合わせて設定すりゃいい」
とか書いてしまった俺には何の意味もないな。
Pで改行すんな
ULはインデント用のタグじゃねぇ
PにULやらOLやらTABLEやら突っ込むな
NOBRもTTも使うな
テーブルでレイアウトすんな コンチクショーヽ( `Д´)ノ
以上
>>385 テキストエディタの中だけならそれでいいんだけどね。
CUI のコマンドシェルや GUI のテキストコントロールなど、
標準でタブ幅の設定ができない箇所は多い。
タブを使わなければ、そんな箇所でも問題は起こらない。
標準で豊富なカスタマイズが可能になっている HTML と
同じ考え方は不適切だと思うね。
ノーブラ禁止
390 :
385 :2006/11/10(金) 00:28:06
>>388 >CUI のコマンドシェルやGUI のテキストコントロール
おまいはどこでコーディングしてんだ。
ソースコードの解析ツールとかgrepの結果とかの話か?
>標準で豊富なカスタマイズが可能になっている HTML と
>同じ考え方は不適切だと思うね。
別な意味を持っているものを、同じもので無理やり実現しようとしてることに違和感を感じるんだよな。
意味に合った要素を準備するのはHTMLに限らないと思うんだが。
HTMLだって昔はごっちゃだったのを整理したんだし、その辺を整理するのも悪くないと思う。
まぁ、プロジェクトで使ってるツールで不都合なことが多すぎって状況なら別にスペースでもいいんだけど…
開発中のソースはリポジトリに放り込んでおいたら 翌日にレポートが出来てて今日もいっぱい警告出てるって感じじゃないのか
>>387 > テーブルでレイアウトすんな コンチクショーヽ( `Д´)ノ
よくわかるんだけど、でもそれに代わるいいものがないんだよねぇ。
CSSでやりゃいいじゃん
古いブラウザ対応しなきゃならんとなるとCSS駄目。
395 :
385 :2006/11/10(金) 23:00:03
>392
>
>>387 > よくわかるんだけど、でもそれに代わるいいものがないんだよねぇ。
386のサイトに関しては、「いっそ全部preで囲んでしまえ」とかと思うワケよ。
Pで改行してULでインデントしてTABLEで桁を揃えてんだからな。
>394
>古いブラウザ対応しなきゃならんとなるとCSS駄目。
テーブルレイアウトはケータイやPDAで見ると全部垂れ幕状態になって非常に見難い。
「見えればえ~やん」ってスタンスなら、ちゃんとマークアップして
見た目はブラウザお任せな方がずっと汎用性が高い。
ちゃんとマークアップしてれば、フィルター作って各ブラウザ用に変換かけるのも楽だ。
素人が好きに作ってるページとかなら別にいいんだけど、技術屋がやってるのを見ると
「あぁ、ブラウザの差異を機械処理で吸収するとか頭にないんだなぁ」と思う。
エリクサー高えんだよ。
確かに! 見れればいいじゃんっつーなら テーブルで整形なんてすんなつーはなしだな
>>395 業務でやるなら携帯とPCは完全に別扱いにするだろ。
どうせ別々のコンテンツ用意するんだから。
NN4.7に対応しなきゃならん場合でもフィルタ用意するのか?
そもそも数年前からメンテしてる場合だとCSSはまともに使えん。
かといって今風のやり方にするために顧客に金出させるわけにもいかん。
新規で最新環境のみの対応ならどんなに楽か。
すまん、業務じゃなくて「技術屋が個人で」か。
趣味にどれだけ時間裂けるかだな。
>>386 のページは2000年だからこれでも普通だと思う。
オーサリングソフト使ったようにも見えるし。
NNのことは忘れろ!
今更NN4.7はないだろ・・・ 常識的に考えて・・・
そんな危険なソフト使ってること自体が犯罪に近い
そいつらみんなばかばっか
405 :
仕様書無しさん :2006/11/11(土) 14:42:38
>>385 Tabだと
1文を途中で折り返したいときに困るんだよなぁ
>>405 状況が想像できん。詳しく頼む。
おおかたヘボいエディタを使ってるか、
使い方を間違ってるだけなんだろうけど。
>>405 スペースでも、
同じ
ことが言えるん
じゃ
ない?
つまり
>>405 は、そもそもインデントしないということか。そりゃ逝けてるな。
お前ら馬鹿すぎ。 405が言いたいのは Results results = HogeLogic.getResults(arg1 ,arg2 ,arg3 ,arg4 ,arg5); って書きたいときにarg2以下がtabだと揃わないって事だと思う。 つーか、基本的にはtab使う奴なんて死んだ方がいい。
揃える必要性を感じない どうしてもってならこれでいいじゃん揃うよ Results results = HogeLogic.getResults( arg1 ,arg2 ,arg3 ,arg4 ,arg5);
411 :
385 :2006/11/11(土) 17:09:36
>398 業務の場合も含めてだけど… ケータイで「も」見れることが大事なのだよ。 昔からのシステムを作り直せとは言わないけど。 >NN4.7に対応しなきゃならん場合でもフィルタ用意するのか? テーブルレイアウトしか受け付けないようなブラウザには テーブルレイアウトに変換した結果か素のHTMLを見せてりゃいいだろう。 >399 技術屋の「見た目より書いてあることが大事」的な思考には 正しいHTMLが一番適しているからな。 一番手がかからないぞ。
>>409 エディタんも整形がバカなだけだろ。
Tabとか言うレベルの話じゃない。
>>414 その非統一さがいやなんだろうが。
まぁ、Javaなら結局エクリプスのフォーマッタで一発なんだが。
>>415 失せろ。java糞。
IDEの話なんかしてないんだよ。
エクリプスはもはた業界標準のIDE。 使えない爺はさっさと引退しなよ。w
業界標準なのかよくわからんが、 エクリプスで多言語用のアドイン入れるくらいなら 絶対、秀○使う。 インテリセンスよりも打った方が早い。
>>393 >>395 たぶん意図がうまく伝わってないかな。
テキストの整形程度ならそりゃテーブルは使わないだろうが、
問題なのはサイト全体のデザインとしてのレイアウトを、テーブル
以外でうまくやる方法がないことだと思うよ。
<div>でposition:absoluteを使う方法はあるが、いちいち座標を
指定するのもなんだし、ソースを見てイメージが浮かばないし。
>>418 おれも秀○派。
ところでエクリプスの画面って2分割できないの?(プラグ印でもいいけど)。
標準状態ですごく使いにくいんだが・・・
VSがネ申に見える。
>>420 いや、VSは普通に神だろ。
今更MSに無用な反目を向ける阿呆は放置でよし。
で、2005がもう少し軽くなってくれたら嬉しいなぁ。
VSは基本的に重いことが問題なわけで 解決するどころかどんどん重くなってるようだが
エクリプスよりははるかにマシ。
424 :
69式オサンクローン ◆4E1yVnBRhg :2006/11/11(土) 22:49:23
なんだなんだツール薀蓄ばかりのジャワ糞がここまで進出してきてるのか
425 :
仕様書無しさん :2006/11/11(土) 22:54:46
>>421 あのさ、おまいさんがエディットしてるPrjは
ASP.NET VBかC#だろう。あれは多少重いな。しかしC/C++のPrjはスコスコと軽いぞ
>>425 >しかしC/C++のPrjはスコスコと軽いぞ
ウソツキ...
427 :
仕様書無しさん :2006/11/11(土) 23:04:43
スマンスマン漏れのは2003だったよ
>>427 それもManagedC++を触るとえらく時間かかるようにならん?
デバグとか。
429 :
385 :2006/11/11(土) 23:38:02
>419 大丈夫言いたいことはちゃんと分かってる。 >392 と >395はそれとあんま関係なく >386 のサイトに関してのコメントだ。 2000年だそうだし、しょうがないけど。 >問題なのはサイト全体のデザインとしてのレイアウトを、テーブル >以外でうまくやる方法がないことだと思うよ。 おれもCSSにレイアウトマネージャがあると嬉しいけど、 その理由でHTMLにテーブルを入れるのは安直すぎるぞ。 データと見た目を分けることに意味があるんだよ。 それを混ぜると上手くいかないことが今までの経験で 分かったからHTML+CSSな流れになったんだろうに。 何でわざわざ同じ轍を踏みに行く?
430 :
仕様書無しさん :2006/11/11(土) 23:52:08
>428 漏れはアンマネージ専だからわからん スマソ
431 :
仕様書無しさん :2006/11/11(土) 23:53:05
KDevelop使ってのは俺だけ?
さけてるコーディングルール if文には必ず、{} を付ける
>>419 テーブルタグ使ったら、座標の指定や幅の指定がいらなくなるのか?
>>410 いい例が思いつかないが...
if(
XX == YY ||
....)
{
とか。
意味和漢ね
if (NULL == *pStr) return; じゃなくて if (NULL == *pStr) { return; } って事だろ。俺は後者派。 前者は新しく処理くわえた時、不具合出やすいからな
438 :
仕様書無しさん :2006/11/13(月) 08:06:03
>>437 っていう主張も多いんだけど、ルールにして
他人に押し付けるほどじゃないんじゃね?
と思ってしまう。
特に俺って
if ( a == 0 )
{
return;
}
っていうコーディングスタイルだからなぁ。
つけるならどっちでもいいが、一行だから省くと時折いたいめに会うって事だよ 条件式で定数を前置にしろーと同一だな
きょう日のエディタ、開発環境には ブロック範囲のガイド表示機能くらいついてる
中括弧問題をグダグダいう奴はModula2を使え
if ( a != 0 ) i++; j++ もちろんわかってて書いてますがなにか?;
;
自分がわかってるから良いとかエディタでどうのっていうなら コーディングルールいらねーじゃん なんの為のルールか考えろ
括弧を新しい行に書くのってどういう場合に有利なんだろ。 コーディング規約になってるのも多いけど。
pascalからの移行組の発想ではないか、と 思ったことがある。 if cond then begin end; ちなみに、逆にCからdelphiに来た人で if cond then begin end; なんて書いてた人がいたがこれは結構見づらかった。
>>444 コーディング規約にあれば従う
お前のところではifには必ず括弧付けろとあるんだろうが、
その項目がない規約もあり、だからあれこれスレで雑談してる
俺正義、お前の意見聞きたくも無いってんならシランがな
エディタや開発機能がシンプルだった頃と、
道具で補完できる今となら、規約が変わっても不思議じゃないと思うがね
同意。 逆に、定期的な改訂周期が存在しない規約なぞ糞だと思うのだ。
>>447 最近じゃ体裁に関するルールはxxxxのツールにyyyyなルールファイル使って整形しろだったりするな
450 :
仕様書無しさん :2006/11/13(月) 17:59:29
あのさ プログラムってなんだかンだ 直列回路じゃん 並列回路言語つくらないか?
↑ おまえもしかして1970年代ぐらいで生活してるの? 21世紀に戻ってこいよ。
450はスレッドを知らない
>>445 インデントが分かりにくいというだけかと
>>446 if cond then begin
~
end;
こっちの方が(・∀・)イイ!!
っつうか、
if cond then
begin
~
end;
はステップ数水増しでつw
>>446 if cond then begin
~
end;
こっちの方が(・∀・)イイ!!
っつうか、
if cond then
begin
~
end;
はステップ数水増しでつw
455 :
454 :2006/11/13(月) 21:41:40
スマソ。チャタッタm(__)m
チャタ(・∀・)リング
ふぅ。出るパイ。。。
おれわさ。 { ブロック内の処理 } ついてるほうが好きなんだわ。 ただそれだけ。 埼玉も今週末あたり紅葉してるかな。
>>454 俺もそのコーディングスタイルなんだが、マイナーだな
俺の理由は、
・行数減らしたい
・C言語ではカーネルスタイルでコーディングしてる
・MODULA-2っぽい
461 :
454 :2006/11/14(火) 00:39:15
>>457 出鱈目にステップ数が1行無駄なんでつぉ~。
457タソは、いまだにコーディングシートにφ(.. )カキカキでつかねぇ?
括弧の位置なんてどうでもよかろう。宗教みたいなもんだし 大事なのは全員が最後まで一貫して使うことだ
でも昔いたな、配列の初期化とかで、予備含めて添え字100くらいあるのを ループとか使わずに100行書いてた。 彼曰く「ステップ数稼ぎだよ」「やってることは同じでしょ」「ループなんて使ったらもったいないじゃん」。 合ってるよな。間違いない。金になる考え方だ。 それでも、わかっていてもステップ数を減らしてしまおうとするのは何故なんだろう? 自分で自分の首を絞めているだけなのに。 ステップカウンタツールも自製他製問わず「空行、コメント行を省く」にチェックを付けてしまうのは何故なのか。 空行やコメント行にもソースの可読性向上には重要な意味があり、規約でも必須としているはずなのに。 納品前夜、終電見送って打ち込んだコメント行が、実績にならなくて良いのだろうか? 納品物に記入されるステップ数に、昨晩打ったコメント行はカウントされていない。 それでもやり遂げた充実感に満たされるのは何故なのだろう。
今時、ステップ数で評価されるプロジェクトなんかあるのか まあ、あるんだろうなw ホワイトスペース入れられる所すべてに改行入れとけよw
ステップ数でプログラムを評価しようというのが、そもそもナンセンス。
>>462 宗教みたいじゃないコーディングルールの方が少ないよ。
そこをあえて宗教論争して盛り上げないとここは。
467 :
仕様書無しさん :2006/11/14(火) 02:14:20
>>464-465 俺はステップ数以外でやってるプロジェクトやったことないなぁ。
複雑さで係数かけるやり方とかあるけど、やっぱ客観性に乏しいんだろうね。
係数が恣意的になっちゃうから。
468 :
463 :2006/11/14(火) 02:24:37
よくよく考えたら10年前の話だわorz そいつが会社辞めたのはその数年後だったな。 写真が趣味で、通勤途中で見かけた美人を撮っては見せてくれたのを思い出す。 この趣味も今じゃありえないな…
たまに面接で聞かれる。ステップ数どんだけ書いたかって。 そもそもステップ数ってなんだろ? あと何行書いたかとか聞かれる(今までのトータルで)。 そんなの数えてないし。行数って大事なの? Javaなら短い行でできたファイルを量産するって結構あるから それ全部足して自己管理するのはめんどくさ。
>>463 は文才あるな。
小説家に転職したらいいのに。
>>463 ステップ数は殺し屋に何人殺したことがある?って聞いてるようなものかな
その仕事場ではきっと重要なんだよ
貴様は今まで食べたパンの数を
音をあげさせてやる パウッ
避けてるコーディングルール 再帰はつかうな
つ[無限ループ] ま、おれは使うんだけど。ディレクトリ階層の検索とかでね。
>>475 再帰やマルチスレッドを考慮できないバカは結構いる
>>475 単純に、スタックオーバーフローを避けるためだろ。
再起でスタックがどんどん積みあがって落ちる。
schemeみたいに末尾再起を正しく取り扱う言語を使ってたり
再起が浅いことが保障されてる場合ならいいけど
再起が深そうなときに使うのは少し怖い。
再起→再帰 でした。
昔のCOBOL/FORTRAN/BASICは再帰できない。
481 :
仕様書無しさん :2006/11/17(金) 16:14:41
ここってネタスレじゃなかったの?
483 :
仕様書無しさん :2006/11/17(金) 18:42:53
プロセスのリサイクルって奴じゃなかったっけ?
>>482 つまり、
「Postscriptプリンタはバカ」
って言うことか?
>>482 Postscriptプリンタが馬鹿なんじゃなくてPostscriptプリンタを作ろうと言い出した奴が馬鹿
488 :
仕様書無しさん :2006/11/23(木) 01:27:59
デバッグする時はまずバグの特定をして、そのバグを修正する。 何処がバグか不明なのに、 とりあえず、不具合を起こさないような動きをするように変更しるな。
if(str == null) ってnullの比較するじゃん。でもnull代入のコーディングミスの危険性があるから if(null == str) と書くべきじゃないかと、ソースレビュー時にPLが問題視。nullチェックは後者が常識、前者では品質が保たれていない、だと。 全ソースをチェック、修正することになった。 もちろん、かなりのソースに関連があると思われたため、単体から試験をやり直すことにしよう、という話に。 すでに結合試験が始まっていたため俺は大反対したがPLの意志は固く、かなりのソースに修正が入り、試験もやり直し。 もともと遅れていた工程がもっと遅れた。遅れの理由はもちろん(?)、「PGのコーディングスキル不足」とかなんとか。 ちなみに結構最近の話。言語はJava。
そんなPL見捨ててしまいなさい。
491 :
仕様書無しさん :2006/11/23(木) 09:48:02
492 :
仕様書無しさん :2006/11/23(木) 09:50:52
str = null とする馬鹿が多いのだなw さすがジャワ糞の集合
null == strを代入とすると null = str nullにstrを代入できるのか?できたとしてnullだろう。 で、nullはtrueなのかfalseなのか?
>>489 おまいのようなPGしかいない、PLに同情するよ
>>493 if (str = null) と書いてあると、コンパイル時に「型が違う」と言われる
という解釈で良いのかな?
そんなのcheckstyleあたりで警告出せるだろ コーディング完了基準にcheckstyleでのチェックで警告0ってのを入れれば大した手間にならないよ
if (str = null) ならコンパイルが通る。 if (null = str) ならコンパイルが通らない。→ミスが防げる。ってことよ。
498 :
489 :2006/11/23(木) 14:10:09
なんか理解してくれてないから自分でいうけど、 Javaだと if (str = null) はコンパイル通らんのよ・・。
499 :
仕様書無しさん :2006/11/23(木) 14:19:15
ああ、確かにJavaは通らん。 気を利かせてくれてるんだろ。
そっかJAVAはif文の中身はブール型にならなきゃダメだったね。
C#とかも。
真偽値型を備えていて、なおかつifの条件式に 真偽値型以外が許される言語のほうがめずらしい。
503 :
仕様書無しさん :2006/11/23(木) 16:24:05
つか、Cでも最近のコンパイラは条件式のとこに代入式が入ってたら警告出せるぞ。
>>503 ついでに数値型が入っていたときも警告出してほしい。
それがルールであるならばコード化作業着手以前に 周知すべき事項だろ。 PLの自己満足のために「ジャンケンあと出し」や「証文の出し遅れ」 を通してしまうとは。 「PMは何をしている?」と問いたいね
>>503 if( ret = func() )
の場合も警告出るの?
別に間違いでは無いと思うのだけど...俺は書かんけど。
>>506 だから「警告」なんだろ。エラーじゃなくて。
>>506 警告出ますよ。というか、出るようにできるというか、出ないようにもできるんだけど。
>>507 ワーニングで充分じゃんw
っつうか、ワーニング残しておくの??
まー確かに警告があると気持ち悪いわな
少なくとも全ソースチェックとやらは警告レベルを上げればC言語でも出来る。 もし、目視チェックしてるとしたらリアルバカだなw
>>509 問題なく消せるときは消しておく。
>>506 なら if((ret = func()) != 0) とか。
根拠の無いキャストが要るようなときは放置。
if ('\0' != p) { なんて書き方をCでやる必要などまったく無い。 そんなのはコンパイラの警告機能が劣ってた80年代のまま脳味噌が停止した奴か、 古臭いコンパイラを強いられてるところだけ。 ましてやJavaでだなんてわけわかんね。
>>498 ますますわからん。じゃ、なぜそのPLはあえてそれを使おうとしてるの?
もう
>>498 のように説得してそれの修正をやめるべきだと思うけど。
つか、自分だったらそうする。
ついでにこういう無駄な修正はデグレや修正ミスの原因になるとかなんとかも 付け足す。
>>514 PLは、「ブール型」という概念を知らなくて、なおかつ、
C言語とJavaとで文法が違うってのを知らないんだろう。
517 :
仕様書無しさん :2006/11/23(木) 21:24:25
親は子供の事を意識しない。 マジで親が子供のやる事にちょっかい出すと最悪な事になる。 C++の話だよ。
継承の話?
職場の話だろwwwwwwwww
いや、しがらみでうちに保守が回ってきた よそが作ったC++のクソコードのことだな。きっと。
いやいや、うちの親会社のことだろう。
>>516 仮にそうだとしても、その程度のことを説明して納得させられない時点で
自業自得だと思う。
最も逝けてるコーディングルール。それは……何でもアリ 識別子の命名パターンだけをとっても ・GNUスタイル(get_foo_bar)とcamlCase(getFooBar)の混在 ・ハンガリアンのようなものに則っていたり、いなかったり ・大文字で始まってるけどクラス名じゃない ・小文字で始まってるけどクラス名 ・全部大文字だけど定数じゃない! な調子。 こんなバーリトゥードの下、3~4人で同じソースをつついてるから 10行毎に言語が変わっているように見える。
>>523 逝けてる以前にスタイルをバラバラにすること強要して
やってるんでなければルールとは言えないがな。
>>489 PLはジョエルのエッセイでも読んだんだろ。
ここって、フリーの人間が多いの? 最近の言語の補助に頼ってると環境が変わったとき痛い目みるんじゃね? そういう事もあって、できる回避策はやっておくのに越したことはない。 個人で自宅環境しかないなら知らんが
>最近の言語の補助に頼ってると環境が変わったとき痛い目みるんじゃね? こういうアホが紛れ込むと厄介だよな。マジで。
>>523 バーリトゥードにも禁じ手は有る。(頭突き、目潰し、急所)
『全部大文字だけど定数じゃない!』は目潰しくらいに当たらんか?
>>527 >環境が変わったとき痛い目みるんじゃね?
痛い目見ないように環境の方を変えろ。
機械ができることを人間がやってる方が馬鹿らしい。
環境が無いなら作る。 それが出来るのが真のプログラマー。
まともな環境を使わせてくれないような仕事は 大抵デスるので受けなきゃいいんだよ って部長に言いたい
>>436 if( の行は既にindent入ってて括弧の中で改行すると
if( と 条件 がずれる。
535 :
仕様書無しさん :2006/11/30(木) 21:33:06
staticやめてくれ~~。
うむ。C + winのコールバックとか。
537 :
仕様書無しさん :2006/12/01(金) 13:03:02
C++とかJAVAとかC#は、お節介すぎてなんかムカつく。 ファーム開発でプアな仕様の昔ながらのCクロスコンパイラを触るとホッとする。
リッチなアプリケーション作るのにC使うのも辛いだろう
C++はC互換じゃないのが痛い。
540 :
仕様書無しさん :2006/12/02(土) 12:28:45
CからC++に移植すると結局分けの分からん事になるから 互換とかなくて良い。
541 :
仕様書無しさん :2006/12/02(土) 12:30:06
馬鹿ほどこだわるCPP 馬鹿ほどえばりくさる「おじじぇくとすぃこう」w
とオブジェクト指向が判らない馬鹿が申しております。
まあ実際ほとんど構造化で書けるんだが カプセル化はあったほうがいいな
544 :
仕様書無しさん :2006/12/02(土) 12:52:04
オブジェクト指向がきちんとできる人だけで開発してるプロジェクトは問題ない。 オブジェクト指向が出来なくても構造化で全部やれる人だけで開発している場合も問題ない。 オブジェクト指向が出来る人とオブジェクト指向が出来ない人が混在して開発すると 悲惨な事になる。
staticって何で使ってはいけないの?
それがわからないなら使うな 必要なところでは使え
グローバル変数やスレッド共有変数と極めてよく似た性質を持っているから。
548 :
仕様書無しさん :2006/12/02(土) 20:46:20
kwsk
549 :
仕様書無しさん :2006/12/02(土) 20:50:02
staticやグローバルを否定する馬鹿は 業務アプリまたはディスクトッププログラマ
そりゃ低レベルは可読性よりも効率が要求されるからな
551 :
仕様書無しさん :2006/12/02(土) 20:52:29
>>549 必要なところで使えって書いてあるのにwwwww
レス読まずに反射神経でレス書いたり、仕様書読まずにソースコード書いたり。
これからの季節、さぞ、デスマで大変だろうね。
552 :
仕様書無しさん :2006/12/02(土) 20:55:40
>>551 だからいつも必要になる仕事をお前が知らないだけなんだよw
適材適所はauto変数だろうがstatic変数だろうが当たり前。 ついでにローカル変数かグローバル変数か、ファイル/クラスグローバル変数なのかも。 どこの領域に取られるか、スコープがどうなるか理解できないバカは 一番実害の少ないauto変数しか使わせないのがいいのかもな。 そういう奴は初期化を忘れそうだけど
554 :
仕様書無しさん :2006/12/02(土) 20:59:29
>>552 すまん。
お前が、いつ日本に来たかは知らないが、読解可能な文章を書いてもらえないか?
意味がさっぱりわからん。
555 :
仕様書無しさん :2006/12/02(土) 21:00:24
スコープ厨==オブジェクト宗教厨
ドカタのコードはスコープの防火壁で囲まないと危険でしょー。 最近はさらにJVMのプロセス境界で実行環境自体を囲むんだぜ。 それでも防火壁に激突した跡を残すけどな。 それを「ぬるぽ」という。
557 :
仕様書無しさん :2006/12/02(土) 21:02:48
あらららら、ジャワ糞だったんだあwwww なるほどー
558 :
仕様書無しさん :2006/12/02(土) 21:04:07
>グローバル変数やスレッド共有変数と極めてよく似た性質を持っているから。 同期ぐらい普通に取れよwwww カタワwwwww
559 :
仕様書無しさん :2006/12/02(土) 21:06:18
ジャワ糞はシブイぜ 朝起きてコンビニ寄る。これは絶対外せない日課だ。なぜって? PCに向かった時のおやつを購入するためだ。最近はうずらの燻製たまごがお気に入りだ。 もちろんコーヒも購入する。すたあばっくすブランドだ。ジャワが好きな俺って結構おしゃれなんだ。 すたあばっくすのコーヒの横にあるうずらの燻製たまごパッケージがまた絵になるんだなあ。 ・・・俺ってシブイ(独り言)
キモヲタは訳のわからない語りが多いな
561 :
仕様書無しさん :2006/12/02(土) 21:15:03
>>グローバル変数やスレッド共有変数と極めてよく似た性質を持っているから。 >同期ぐらい普通に取れよwwww >カタワwwwww それなに?っていうのがジャワ糞たんなのです
>同期ぐらい普通に取れよwwww >カタワwwwww 最初は良くても そういうのが重なってくるといずれ把握できなくなるだろ
その程度のドカタをかき集めて開発している現場もあるんですよ。ご理解いただきたいです。
静的というのが理解できないんだから仕方ないじゃない。
性的なら得意なんだけどな
自慢じゃないが性的というのは理解できる。
うへ、かぶった orz..
お前ら・・・ (あぶねえオレも同じレスするところだったぜ)
おれも・・
570 :
仕様書無しさん :2006/12/03(日) 02:05:21
オレの職場では担当者がstaticを使わざるおえないって言って来た時は どうしても使わなくっちゃならない理由をレビューで説明してもらう。 それで、皆で他に回避策はないか、必然性は妥当かを考えて、 それでOKが出て初めてstaticを使えるってことになる。 何かをstaticにしてしまうと、 そのstaticに引きずられて、その後で拡張される時に 他の場所もstaticにせざる終えないって可能性が出てくる。 そうなると、保守性を考慮して作ったクラスの構成に 例外的な処理(static関数など)が入り込んでしまって、保守性が低下してしまう。 それに、インンスタンス化前にstatic関数が呼び出せてしまったりするなど (もともとそれが、目的なら良いが)、危険な状態が発生する。
571 :
仕様書無しさん :2006/12/03(日) 02:07:42
オブジェクト指向をやたらと振りかざすヤツは確かに困る。 しかし、しかしだ、 開発環境で必要とされているにも関わらず 理解する努力もせずにオブジェクト指向なんかいらねえとか言ってるヤツは マジで、一体どう扱えば良いのか分からん。 仕事で要求されているにもかかわらず、 技術を身につけようとしないのは プログラマ以前の問題だと思う。
>>549 確かにWebアプリとか作っててセッションオブジェクトとか使うけど、
あれってグロ変に近いものがあるからね。
ってこと?
staticだめってやつはInteger.perseIntもつかうなよ?
574 :
仕様書無しさん :2006/12/03(日) 06:37:30
へー。Javaってstaticもつかえないんだ。本当に糞言語なんだね。
物事には用途があるからな
Javaは動的に確保するのがスタンダード
577 :
仕様書無しさん :2006/12/03(日) 11:08:37
>Javaは動的に確保するのがスタンダード 動的になにも考えず確保しつづけるジャワ糞(馬鹿) そしてスレッドコンテキスト切り替えの最適化もろくにできない欠陥VMが 悲鳴をあげだし再起動。またメモリがどんづまったりスレッドでジャムると 再起動に時間がかかるんだよなあ。
578 :
仕様書無しさん :2006/12/03(日) 12:35:44
C厨爺は巣に帰れよ。きもいから。
579 :
仕様書無しさん :2006/12/03(日) 12:37:44
はい、感情論出ました。
言語なんて手段にすぎないのになぜ争うかなぁ・・・ ちょっと上の立場の奴から見たらおまえらLv低すぎだぞ、と。 JavaでもCでもPerlでもなんでも、目的(客の要望)を果たせればそれでいいと思うのだが・・・ まぁ、後の品管のためにもコーディングには凝るとしてだ。。
582 :
仕様書無しさん :2006/12/03(日) 13:01:45
ジャワ糞が業界をだめにする
COBOLを馬鹿にするな~! ってかCOBOLは知らないなぁ。とりあえず使う機会に出会わなかった。
584 :
仕様書無しさん :2006/12/03(日) 13:08:22
確かに、言語にやたら拘るのもどうかと思うな。 ただ、ひとつの言語しかできないヤツは、死んでほしいとは思うけど。
585 :
仕様書無しさん :2006/12/03(日) 13:18:44
Javaでstaticをつかいこなせないからって、Cでもstaticを使うなというのは基地外沙汰。
Cは小規模なプログラムを書くのに向いてるからいいんじゃね
587 :
仕様書無しさん :2006/12/03(日) 13:22:14
チマチマと組み込みソフト書いてるんでしょ?
588 :
仕様書無しさん :2006/12/03(日) 13:26:38
staticはレビューしないと使用禁止だなんてどれだけ低レベルな会社なんだぜ。
589 :
仕様書無しさん :2006/12/03(日) 14:06:29
static使うとだめなんだぜ? (笑)
OS/2で開発してたときだが 上位会社からデバッガ使用禁止と言われたことあるなあ 理由はそこの課長がデバッガの使い方知らないから いや、まじでw
>staticはレビューしないと使用禁止だなんてどれだけ低レベルな会社なんだぜ。 そういう考え方をするヤツが、俺は分かってるから平気だと言いながら バグを作り込むんだ。しかも自分が問題を発生させてる自覚もない。
saticの妥当性についてレビューするのは良い事だと思うけどなあ。
staticを使う理由があって、その理由が納得できるものであればgood. でも、 「オブジェクト指向うぜ~、カプセルかめんどくせ、デザインパターン分けわからん 鬱陶しいからstatic使ってでcみたいにやれば楽じゃね。」 ってのはbad.
594 :
仕様書無しさん :2006/12/03(日) 14:53:28
なんじゃそりゃ
オブジェクト指向が分からないヤツは技術的に問題がある。 オブジェクト指向をやたらと振りかざすヤツは性格的に問題がある。
596 :
仕様書無しさん :2006/12/03(日) 14:57:49
staticのことはもう良いよ。許してやろう。staticに罪はないんだ。
597 :
仕様書無しさん :2006/12/03(日) 14:58:11
シングルトンだぜ?
マルチプルインスタンスの対語は シングルトンインスタンスなの?
600 :
仕様書無しさん :2006/12/03(日) 16:37:23
へーstatic使うとカプセル化できないんだー
>>590 管理職がコーディングに手を出すってあたりがそもそも駄目っぽいよな。
技術についていく暇のない奴が技術に口を挟むなというのだ。
「プレイングマネージャ」とやらは本当に優れた万能選手にだけできること。
いや、まて
>>600 はシングルトンの事を言ってるのかもしれんぞ。
とりあえず、危険だから近づくな。
>>600 >へーstatic使うとカプセル化できないんだー
以外と出来ないよ。
606 :
仕様書無しさん :2006/12/03(日) 17:27:17
>>600 君に足りないのはstaticへの愛だ。
607 :
仕様書無しさん :2006/12/03(日) 17:35:53
Javaってstatic使うだけで破綻するんですか。
608 :
仕様書無しさん :2006/12/03(日) 17:40:05
馬鹿か。お前。
道具は使い方次第で人を殺す凶器にもなる
612 :
仕様書無しさん :2006/12/03(日) 18:05:09
とりあえずstaticは使うな。
>>612 元に戻った。www
こうして喜劇は繰り返される。
final static で定数定義すんのは常套手段だべ。
staticでこんなに笑える日が来るなんて。www
616 :
仕様書無しさん :2006/12/03(日) 19:02:45
どうして使っちゃいけないの
使っちゃいけないというか使う場所は限られてる気がするな あとはバグのトレースが面倒とか それはともかく変数名ローマ字は勘弁してくれ
618 :
仕様書無しさん :2006/12/03(日) 19:24:19
はあ?なんでトレースが面倒になるんだよ。
>>618 面倒にならない方法があったら、むしろ教えてくれ。
620 :
仕様書無しさん :2006/12/03(日) 19:29:59
Eclipseを使え。Eclipseがすべて解決してくれる。 バカは余計なことを考えず、与えられたものを使え。
↑なにやら天才様がお怒りになりあそばしてるようでございまする。
/ ̄ ̄ ̄ ̄ ̄ ̄ \
/⌒ヽ / '''''' '''''' ヽ
| / | (●), 、(●) |
| | | ,,ノ(、_, )ヽ、,, |
| | | `-=ニ=- ' | 天才の
>>620 さまがお怒りじゃ!
| | ! `ニニ´ .!
>>620 さま怒りをお鎮めくださいじゃ。
| / \ _______ /
| | ////W\ヽヽヽヽ\
| | ////WWWヽヽヽヽヽヽヽ
| | ////WWWWヽヽヽヽヽヽヽ
E⊂////WWWWWヽヽヽヽヽヽヽ
E//// ヽヽヽヽヽヽヽ
| | //WWWWWWWヽヽヽヽヽヽヽ
623 :
仕様書無しさん :2006/12/03(日) 19:39:44
はあ?なんで変数名ローマ字が駄目なんだよ。
624 :
仕様書無しさん :2006/12/03(日) 19:44:58
privateにしておけばstaticでも大丈夫。
>>623 >はあ?なんで変数名ローマ字が駄目なんだよ。
まじっすかwww
626 :
仕様書無しさん :2006/12/03(日) 20:08:46
>>624 >privateにしておけばstaticでも大丈夫。
地味に面白い。w
627 :
仕様書無しさん :2006/12/03(日) 20:11:26
ジャワ糞様が スレを吉本喜劇に変えてくれました
C厨の成りすましとみた。
明日仕事だろ。歯磨きして寝ろ。
どうやら核心を突いてしまったようだ。
631 :
仕様書無しさん :2006/12/03(日) 20:29:43
過去にもstatic談義が重くねスレで出たが C/C++のstatic仕様と糞ジャワの仕様がまったく違うのを誰も指摘できなかった ジャワ糞たちであった。アーメン
一番うざいのは、Java厨がJavaの知識でもってC/C++のソースを見て、 「何これ?なんでこんなstatic使ってるの?ププ」 ってのだな。
633 :
仕様書無しさん :2006/12/03(日) 20:35:38
だからジャワ糞なのですよ
634 :
仕様書無しさん :2006/12/03(日) 20:37:40
まあジャワ糞がいてくれるからマ板が面白くなる これでいいんだけどね
C厨爺は巣に帰れよ。きもいから。
636 :
仕様書無しさん :2006/12/03(日) 20:52:15
仲良く力を合わせれば良いのに
あわせても生まれるはパスタばかりかな
コーディングルールもクソもない。 Javaはクソ。
大辞泉より ジャバ【Java】 米国サンマイクロシステムズ社が開発したインターネット用のプログラム言語。OS やパソコンの機種に関係なく動作することが可能で、動画や音声データ用のプログラムやインターネット対応のワープロなどのソフトを開発することができる。 くそ【×糞・×屎】 [名] 1 動物が、消化器で消化したあと、肛門から排出する食物のかす。大便。ふん。 : ...ぜんぜん違うじゃねぇかよ。
641 :
69式オサンクローン ◆4E1yVnBRhg :2006/12/03(日) 22:05:05
ジャワはマジ糞だなあ
642 :
仕様書無しさん :2006/12/03(日) 22:13:24
なんか荒れそうになっても笑いがあっていい一日だったな。
643 :
仕様書無しさん :2006/12/03(日) 22:16:11
ここは罵ると気持ちが落ち着く人達のスッドレですね
Javaを知らない俺にCとJavaのstaticの違いを詳しく
まぁ、C++の場合だと同じ意味合いでのstaticもあるんだけど、Cの場合は性的変態って、もとい静的変数っていうJavaにない別の文脈でも使われるってことだべか。
とりあえずおれは ・ 今のおれ(ちゃんと仕様にのっとって、不具合を生み出しにくい、リリース以降の障害もトレースしやすい) ・ 未来のおれ(忘れたころに過去システムの改修とか依頼された時、なんでこうしたんだろうとかどう仕様変更を実現しようかとか) どっちも困らないコード書けばとりあえずいいと思っている。
647 :
仕様書無しさん :2006/12/03(日) 23:53:08
とりあえず、Javaはポインタすら使えないのがウザイ。 何アレ?
Javaはポインタを使う必要性が無いからなぁ。
>>647 みたいに、delete忘れてメモリリーク起こす心配もしなくていいんだぜ。
とりあえず、
>>647 がJavaでポインタ使えなくて困った例をしめしてくれると
ありがたいんだが。
そのくせJAVAはぬるぽを起こす
JAVAのポインタはアドレスを指さないだけだろ
Javaの場合はC++でいうところの参照だな。
>>650 ぬるぽと起こさずにどうしろと? だんまりを決め込めってのか?
ぬるぽってのはなぁ、「私を無視しないでっ」っていう理不尽なプログラマに訴えてるんだよ。切ないじゃねぇか。
>>647 おめぇはゲロみてぇなコア吐いてろwww
654 :
仕様書無しさん :2006/12/04(月) 08:30:05
はあ? Javaはもはや業界標準言語でしょ? 暴れてるのはC厨?VB厨?それともコボラ?
655 :
仕様書無しさん :2006/12/04(月) 08:58:51
>>654 がジャワ糞を代表して
ジャワ教を布教してくれる事と思います。
ぬるぽ無くしたいなら参照なくすしかないよな。 んで全て戻り値で取ってくる。 本当にそんな環境でプログラムしたいか?
経験を背景に発言させてもらえば。 楽しいぞw 戻りたいとは思わないけど。
658 :
仕様書無しさん :2006/12/04(月) 20:01:40
蒸し返すようで悪いのだが、staticを使う時って、 (1)デザインパターン(シングルトン等) (2)共有資源の確保 (3)インスタンス化する前にアクセスする必然性がある時 ぐらいかな。ぱっと思いつくのは。他にあるかな。
すげぇループwww しかも、C丼の臭いがぷんぷんする。 クラスを配列化した場合に、起点となるヤシにすたてぃっくがないと こまるなぁ
660 :
仕様書無しさん :2006/12/04(月) 20:34:13
インスタンス化する必要の無いクラス、もしくはインスタンスが単一のクラスならいいじゃない。
>>658 >staticを使う時って、
>(1)デザインパターン(シングルトン等)
目的と手段が入れ替わってないか?
俺がstaticを使うのは、グローバル変数や関数をファイルローカルに隔離するときくらいかな
663 :
仕様書無しさん :2006/12/07(木) 21:24:03
リアルタイム系の同期取りのためにstaticを使う。
664 :
仕様書無しさん :2006/12/07(木) 21:50:26
303のstatix、元気かな
スタックポインタ経由じゃ遅いときだな。
666 :
仕様書無しさん :2006/12/09(土) 01:16:40
クラスローカルでの整数定数でも使うなーstatic const int hoge = 1;
667 :
仕様書無しさん :2006/12/09(土) 01:45:01 BE:119815283-2BP(294)
>>658 C#とかJavaのライブラリでも、それ以外でstatic使ってるだろ
668 :
仕様書無しさん :2006/12/09(土) 01:49:58
>>549 ディスクトッププログラマというのがどんなものか想像つかないが、それはともかく、
それら以外にどんな種類のプログラマがいるの?
【ディスクトップ】(外誤科) Google検索結果 2003/12/16 ディスクトップ:41,700件 コンピュータ業界における誤字の代表格と言えば、「ディスクトップ」です。 専門家、一般人を問わず、様々な場面で目にすることができます。 文字としてもよくみかけますが、実際にこう発音している人も少なくありません。 無論、普通に発音すれば「デスクトップ」となるはずです。 確かに、「disk/disc(円盤)」はコンピュータと大きなかかわりがあります。 しかし、「円盤の上」では意味が通りません。 本来の語源となった英単語「desktop(机上、卓上)」は「desk」+「top」です。 この場合、「desk」を「デスク」と発音することについては異論がないでしょう。 それとも、「ディスクトップ」派の人は、「desk(机)」を「ディスク」と発音するのでしょうか?
>>668 昔ながらの分類だと
オープン系
Web系
組込み系
金融系
汎用機
とか?
ゲーム関係
とかも入るのかな。
>>672 オープン系
Web系
組込み系
金融系
汎用機
は全部業務系じゃね?組み込みはちと違うかも…
675 :
仕様書無しさん :2006/12/11(月) 19:45:13
逝けてるコーディングルール 気軽にキャストすんな。
気軽なキャストって何?
「よくわからないけど警告がでなくなるから」キャストしとくとか。
>>677 >「よくわからないけど警告がでなくなるから」キャストしとくとか。
こ、怖すぎる。訳の分からんアドレスにアクセスしたらどないすんねん。
出向先の会社で設計からお任せしますと言われたのでクラス定義してたら 「あとでメンテ出来なくなるので、オブジェクト指向は使わないでください」 って言われた
>>679 でも確かにオブ指にこだわりすぎると、デザパタの多用や継承関係の増えすぎで
「コード一箇所見て処理が分かる」っていう昔ながらの手続き型なコードではなくなるね。
まぁ、クラス定義もするな、ってのはちょっと・・・だけど。
GetWindowLongはキャストしすぎ。
>>677 SQLでなんかレコードがダブるので
DISTINCTつけときましたってのが
いたんだけど、それと近いですね。
勿論、本番で激重ですよ。
>>684 実はシステムの不具合で重複のあっちゃいけないレコードが重複してたり、とか
一意制約つけるとかは好みでしない人がいる・・・自称DBAは個性派そろい。
>>680 >「コード一箇所見て処理が分かる」っていう昔ながらの手続き型なコードではなくなるね。
今は、見る場所が違ってきているんだよ。
本物のオブジェクト指向なら、コードの中身ではなく、
「オブジェクトの定義」を見れば、
その振る舞いが分かるように書かれている。
>>686 > 「オブジェクトの定義」を見れば、
> その振る舞いが分かるように書かれている。
ダウト。
トラブル発生時の対応の早さでいったらどうなんだろうね? ・ 手順型言語開発したシステム ・ オブジェクト指向型言語開発したシステム おれは不幸にもまともなオブジェクト指向型言語開発したシステム、システム開発に出会った事ないんだ・・・ (Javaでふつーに手順型で開発してるのならよくあたるけど) 歳とった今思うのは、とりあえず客の要望を満たしてトラブルが少ないシステムなら 実装へのこだわりなど捨てられる、ってことかな。
>>688 そんなオサーンが書いたコードなんて、保守不可能なんでつねぇw
その時は顧客の要望を満たしていても、設変でボロボロなのねww
まぁ、ボロボロになるかならないかは、個人のコーディングの能力しだいな訳だが。
開発って自信家が多い? やる気あるやつ 他の奴がやらない=できないと思いどんどん自信家になってく やる気ないやつ どうせ「やる気あるやつ」がどんどんやるだろう、と出来るだけ自分の仕事増やさないようにする 幸せなのはどっち?(細かい分類するとやる気あるけどできない奴、やる気ないうえできない奴、とかもいるんだけど)
まあ、出来るやつはめったに居ない
個人のコーディングの能力しだいで 既存システムの保守の容易さは左右される。 ・・・自分にもその様に考えていた時期がありま(ry
できるけどしたくない したいけどできない
Cだけど、IFを使ってコメントアウトってツライな。 2、3行ならいいけど、数百行とかコメントアウト用のIF文が 入り乱れてたらもう、何がなにやら。
コメントアウトの方法じゃなくて、コメントアウトしたコードが大量に残ってるって時点で。
>>694 そういう場合は、関数丸ごとコメントアウトして作り直してる。
文句言う奴にはdiff見せているんだが、diffなんて信用できないという奴がいると鬱。orz
手作業の方がよっぽど信用できないと思うのだが。
オブジェクト指向は良いよ。 最初はなんだよこれ全然分からん!!だったけど 今となってはオブジェクト指向つかうなと言われると面倒だなあと感じる。
おまいはマ板で何を言っているのか
699 :
仕様書無しさん :2006/12/13(水) 22:23:55
マイタン(;´Д`)ハァハァ
700 :
仕様書無しさん :2006/12/13(水) 23:11:44
ダウンキャストすんだったら、せめてdynamic_castしとけ、コラ~!!!
>>697 おれは未だその境地に達せん。
自分の開発スタイルが悪いのか、全体的な開発方針が悪いのか。
702 :
仕様書無しさん :2006/12/14(木) 22:10:56
バグの修正を数十箇所に埋め込まれるのを直させられるよりは、一箇所直せば全部直るってほうがマシ。
1箇所のバグが数箇所にも出てきてしまうという諸刃の剣
もともと同じコードなんだから、それは当然だろう。 むしろ、バグを持っているところと持っていないところでバラバラな方が深刻だと思わないか?
ちゃんとコード書けばバグは局所化し収束する でたらめなコード書けばバグは指数関数的に増大する
706 :
仕様書無しさん :2006/12/14(木) 23:00:00
>>703 それがオブ指向だ。
書くのが人間なんだからバグが出るのは避けられんさ。同じバグの出現箇所が1箇所だろうと1000箇所だろうとバグはバグ。
怒られるのは変わんねぇし。むしろ発見できて良かったね。とすら思うわ。
1000箇所に同じ記述がしてあったら終わってるしな。
オブジェクト指向でも構造化指向でもそこは変わらないよ
追跡しやすければ、箇所の多少はどうでもいいよ
709 :
仕様書無しさん :2006/12/15(金) 22:40:20
Cで擬似オブジェクト指向にして作ってたら 「別の構造体型でのキャストは全面禁止、やってる行は全てコメントで理由を記述すること」 これにはキタ 擬似オブジェクト指向推進した俺が戦犯になって ひどいめにあった
710 :
仕様書無しさん :2006/12/15(金) 23:05:35
>>709 勝手にやるからだろ。
ちゃんと許可取ってからやれ。お前は頭いいけど他はバカなんだよ。
>>709 オブジェクトコンポジションなら問題ないのでは?
>>684 社会人になるまでは、こういうのって
ネタだと信じて疑いませんでした。
,j;;;;;j,. ---一、 ` ―--‐、_ l;;;;;; {;;;;;;ゝ T辷iフ i f'辷jァ !i;;;;; ヾ;;;ハ ノ .::!lリ;;r゙ `Z;i 〈.,_..,. ノ;;;;;;;;> ,;ぇハ、 、_,.ー-、_',. ,f゙: Y;;f. ~''戈ヽ `二´ r'´:::. `!
714 :
仕様書無しさん :2006/12/20(水) 19:14:55
「ネストは二回まで」 結構厳しい。
おー、無闇にネストするのを防ぐ効果はあるかもね 縛ることはまったく無意味だがw
再帰してまえ
717 :
仕様書無しさん :2006/12/20(水) 21:41:29
gotoつかえねぇ
719 :
仕様書無しさん :2006/12/20(水) 22:50:26
static使うやつって何考えてるんだろうか。
全部gotoだけで書け
>>720 30年近く前のソースをリバースしてるが、gotoだらけでクラクラするぜ。
メモリ無いから、1行でも短くなるようにgotoしまくって、本筋がどこかわからねぇ。
同じくメモリの制約で変数は3文字まで、1文字目がIなら整数型。
文字は英字の大文字しかないし、文字型なんて無いから整数型に。
もちろんコメントもインデントも一切ない。
ルーチン名も意味の無い数文字のコード名。
これにくらべれば、どんなソースも許せるとおもた。
BASICかいな
その種のことには下限は存在しないよ。 もちろん「再作成した方が将来的なコストも含めて安上がりになる」 という分岐点は必ず存在する。 貴方の担当しているソースはその分岐点を超えているようだけど。
724 :
仕様書無しさん :2006/12/21(木) 00:46:18
>>721 あまり元が酷いようだと、ソースのコンセプトだけ読み取って
ゼロから作成し、
「自作のキラリと光るな隠し仕様を入れる」のがクールで(・∀・)イイ
「いちおうC言語だけど4000行が一関数、その中を goto 制御文だけが飛び交う」
という奴を受け持ったときは
動作から仕様を類推し、かつソースを一読してゼロベースで作ったyo.
生データがバリバリ埋め込まれていたのは、全て構造体の配列に置き換え、
ちまちまとした goto 制御文は、スクリプト+スクリプト・インタープリターに置き換えた。
これで要求仕様が変わってもスクリプト変更だけで済んで楽々だね。(w
>>724 そういう修正が許される職場は決して多く無いと思うがねえ
ソースが汚いって理由で動いてるコードを書き直すなんてウチでは許されない
たとえバグが埋め込まれてあっても、そのバグは発動して表沙汰になるまではいぢっちゃダメ
仕様or動作通りに書き直す →バグ発生 →おまえのせいだ →( ゚Д゚)マズー
マクロを使っているJavaソース(gcc -Eとか使ってプリプロセス) Eclipseは勿論のこと、あらゆるJavaコードエディタ、IDE、ソース処理ツールが役に立たなくなる……
>728 >725
なるほど 自分が作ったバグでなければいいわけか
732 :
仕様書無しさん :2006/12/21(木) 08:25:33
>>726 そういえば、その酷いソースは「動いていなかった」な。
他社の作ったプロトタイプだった。
>>726 そういう場合は「動いているもの」と並行して、
「新しいもの」を作るのはどうよ。
もちろん、社内的な同意をとった上でな。
その後静かに「新しいもの」に徐々にユーザが移行するのを待ち、
ある時点で「酷いけど動いているもの」を消去する。
733 :
仕様書無しさん :2006/12/21(木) 09:35:51
リファクタリング
要は作り直しだろ
735 :
仕様書無しさん :2006/12/21(木) 11:42:21
CASEツールで 無 馬太..._〆(゚▽゚*)だし される。
736 :
仕様書無しさん :2006/12/21(木) 22:23:00
>>732 どこの現場でもみんな同じなんだなぁ・・
「社内的な同意」なんてぇものが 簡単に取れるようならこんなに話題にならんだろ。 ましてや発注元の同意が必要となるなら絶望的だ。 反対する人間の「品質管理の不備を隠したい」 という恥ずべき感情を覆す事は容易ではないぞ
>>737 うーん、その通りなんだけど、
でもリファクタリングはどっかでやらないと、仕様変更が来るたびに泣く羽目になるんだよなぁ。
>>738 追加案件が来たときに、元ソースが手の付けようのないほど激しくスパゲッティしてバグを持っていたせいか、
処理の入口で分岐させて追加部分だけを完全に別のロジックを実装した人がいた。
その気持ちはとてもよく理解できたのだが、項目追加するだけでも大変になったので、俺に回ってきたときに
思い切って意見具申して作り直してしまったよ。
>>739 まぁ、上司は客の都合で考えるから保守的になりがちだけど(動いてるものには触るな)、
プログラマは自分の後を引き継ぐ人の事考えて作るからな。
俺もおまいさんに賛成だぜ。変更するリスクはあるけど、
そういう提案できるやつは基本的にリスクを踏まえた上で発言してるやつのはずだからな。
>>739 >>740 禿同。
そして、その提案を理解して承認してくれた上役もしっかりしていて羨ましい。
動いているものは触るなという原則はアリだけど、
直さなきゃいけないときに直さない言い訳ではあかんわな。
742 :
仕様書無しさん :2006/12/22(金) 21:46:44
私は部下から作り直しの申し立てがあったら その部下の技量を見て許可か不許可を判断する。もちろんリアルな話で金と時間も考慮しますが。 許可にして問題発生したら、私が責任を取って取締役に報告しますね。 「私の判断で作業指示を出しました」と。 許可するってことはその技術者の技術力を信頼してるってことです。 信頼するかどうかを判断するのは私の能力ですから。 といっても許可を出すのは全体の20%ぐらいです。それが現実です。
743 :
721 :2006/12/23(土) 00:24:41
亀になったが。 このソースはこのまま使い続ける必要があり、 製造終了、維持部品の製造も終了したマシンを特別に作らせてまで使ってる。 こっちで勝手に直せない性質のシステムなので。 もうすぐ新バージョンが送られて来るんだが、環境から何からまったく変わるので 変更を把握するためにも現状の確認が急務なのよ。 長年安定して動いてるんだけど、それだけに資料が無くなっててね。 基本仕様だけなら単純なもんだから、簡単に作れるけど、独自言語の計算精度 まで含めて完全に再現は出来ないし。
744 :
仕様書無しさん :2006/12/23(土) 01:35:32
>このソースはこのまま使い続ける必要があり、 >製造終了、維持部品の製造も終了したマシンを特別に作らせてまで使ってる。 よっぽどの理由があるのですね。 計測系システムですか? >独自言語の計算精度まで含めて完全に再現は出来ないし うおー燃える、 漏れが担当だったら、 「独自言語の floating point 演算」を再現して完全移植を目指すだろう。 大学の頃に、定理の証明のために、 浮動小数点演算のソフトシミュレータを作っったことを思い出したよ。
>>743 もしかしてオンライン系のシステム?
そういう類のものだと、お疲れ様ですとしか言い様がないな。
資料がないのは全く納得いかないが。
98ってまだ作ってるのかなぁ?(ボソ
PC98?
(゜_゜)(。_。)PC-9801とかFC-9801。
マジレスすると、とっくに製造終わってる。 ただ、世の中には現役のマシンはそれなりに残ってるので、 商売として修理・再生してる中小メーカがいる。
750 :
仕様書無しさん :2006/12/24(日) 10:47:47
この混沌としたコーディングの世界で どうやって上手く立ち回るかがマの能力だと思うようになった。
751 :
仕様書無しさん :2006/12/24(日) 11:55:17
>>743 が言うのが N88BASIC + PC9800シリーズだったならば、
N88BASIC インタープリタが Win環境に移植されていれば、
問題が解決しないか?
動作環境と演算精度の両方の問題で。
エミュレータでええやん
いまどきリプレースできずに残ってるものは、それなりに特殊な事情が あるんじゃないかな。特定の拡張ボードに依存してるとか。
あーなんか誤解を招く流れになってるけど、わたしんとこの環境は とある海外製の専用CPUで動くシステムのサポート環境です。 サポート環境だから、当時としては汎用性のあった海外製の汎用機が中心。 ただし周りのハードウェアは当時の物なので、入出力もすべてワンオフ。 ターゲット環境が完全オリジナル環境で、その環境用のソフトとか入ってるけど それらも含めて日本では触れない事になってるから、置き換えは無理です。 これ以上はシステムが特定できちゃうので勘弁。 意外とこう言う環境は多いですよ。 具体例を挙げれないのが辛いとこですが。
755 :
仕様書無しさん :2006/12/24(日) 15:47:20
VAX?
一文字ごとに改行すること
いろんな現場を見てきて思うんだけど そろそろ1ライン80文字の制限は、なくしてもよいと思うんだが。 特にJava何かだとクラス名は、長いし、改行多すぎて見にくいのだけど。 スクリプトとかならまだしも、今時、ターミナル上でソースを修正することなんてあんの?
「一目で捉えられる」ということが重要なのだ。 確かにPCの画面は大きくなり、コードエディタのウィンドウは横にスクロールできるようになったが 人間の視界は拡がっていない。
>確かにPCの画面は大きくなり、コードエディタのウィンドウは横にスクロールできるようになったが すでに80桁越えてる。
760 :
仕様書無しさん :2006/12/24(日) 20:58:40
>>757 「1関数25行を目安に」なんてのも有ったような(w
80桁とか25行ってのは制限がきつすぎるとは思うけど まったくなしにするとやたら横や縦に長いソースを書くやつがいるからなあ。 妥当なところを決めるのは難しいねえ。とりあえず倍の160桁50行くらい?
関数が一画面に収まってると断然理解し易いってのはあるよね
763 :
仕様書無しさん :2006/12/24(日) 22:48:54
1行80文字、25行ってのは かつてのPC―9800シリーズの制約だったからね。 だからといって、それを金科玉条の如く永遠に語り継ぐのもオカシイ。 1280x1024dot/9point の世界に措ける「一画面に収まる」の定義であるべき。
>>762 そうでもないと思ふ。
先輩が割りとトリッキーな関数(21行)を作って見せてくれたが、とりあえず「動くが読めね」状態だた。
皆が読めるようなきれいな奴なら100行くらいでもいいと思う。
>>758 MSゴシックの8px推奨w視界が狭くてもたくさん文字入るお。
1440×900のワイドディスプレイを 縦にして「一画面に収まる」にしようぜ!
>>765 縦にするくらいなら、いっそのこと斜めにするか。
高さも横幅も増える。
>>762 そうともいえない。それが適切なまとまりならそうだけど。
無理に関数分けたような場合だと、かえってわかりにくい。
わかりやすさのためだけに関数分割するわけではなかろう。
印刷して見ることが、多いから一行は、長くても100~120くらいまでがいいと思う。
770 :
仕様書無しさん :2006/12/25(月) 07:58:55
一つの関数長いとコンパイル後のファイルサイズ増えるんだよな。 長い関数を小分けにしていったらどんどんサイズ小さくなっていったよ。
あれへんあれへん
あんまり関数が長いとオプティマイザも 読むのを途中であきらめる、とか。
面倒だからオーロラビジョン使え
if ((a == b) && (c == d) && (e == f) && (g == h) && (i == j) && (k == l) && (m == n)) { … } よりも if ( (a == b) && (c == d) && … (k == l) && (m == n) ) { … } の方が(・∀・)イイ!!でつねぇ。 特にSQLで select FieldA, FieldB, FieldC, FieldD, FieldE, FieldF, FieldG, FieldH, FieldI, FieldJ, FieldK… はやめれw select FieldA, FieldB, … FieldJ, FieldK from TableA inner join TABLE B on … 横スクロールって結構ウザイんだなぁ。
From区には大抵マスタをLeft joinってのがおおいけどな。 まぁ、SQLに関してはそうだな。
>>774 こんな条件判断をしなくちゃならんコードがすでに糞コードだと思うが・・。
一行にかけないくらい長いならメソッドに切り出せよ。
・コメントは必ずコードと同一行に入れること、 ・コードは39桁まで、空白一つ空けて41桁以降はコメント ・合わせて80桁を超えないこと ・一読性を保つため無闇に関数分けをしないこと、 特に別ソースを参照しなければならないような作りは極力避けること …かくして80桁×数千行の ちょっとずつ違うけど似たような処理をする関数が 量産されていくのであった
「一読性を保つため」ってのは初めて聞いたよ。いっそ素晴らしいなおい。
関数の粒度が揃ってて、上から順番に読んで行けば何しているかわかるなら、 200行くらいいいけど、関数のサイズをそろえるとキャッシュがうまく回る。 気がする・・。
>>774 見てて思い出したんだけど
こういう横に長いif文とか引数やたら多いメソッド呼び出し書いて途中に改行挟む時、
インデントはこうすべき、みたいな決まり事って存在するの?
中括弧のつけ方とかなら明確に派閥あるけど
この手のインデントって人によってバラバラな気がする。
まあ、
>>776 の言う通りそもそも書かないのが一番なんだけどさ。
>>779 >関数のサイズをそろえるとキャッシュがうまく回る。
>気がする・・。
これってどういう意味?
んなことないから無視汁
>>776 そこに反応しなくてもw
一行ソースが見づらいという例だろに。
細かいが、SQLなら、前カンマの方がいいと思うぞ。 select column1 ,column2 ,column3 from table1 inner join table2 on ...
いやーおれはどうもなじめないんだよなあ、前カンマ。 効能は判るんだけど、ぱっと見て 頭にすーっと入ってこない。慣れかと思ったけど、 慣れないねぇ・・・・うーん。 俺の周りでも結構意見が割れて、半々ってところ。
あと、WHERE句のANDの位置ね。 WHERE col = 'hoge' AND col2 = 'fuge' 考え方は前カンマと同じ。 追記しやすさを考えた結果。 気持ちはすんごく判るんだけど これも馴染めないんだよなあ・・・・。
ちゃんとインデントしてあればどっちでもいいよ派
789 :
786 :2006/12/26(火) 23:17:47
>>787 だはは、半角スペースが無視されるの
すっかり忘れてた。
>>781 同じ大きさのブロックでスワップしてフラグメンテーションがおこらない
ような気がしねーよな、やっぱりw
と書いてあるようだ
まてまて。そんな事はどうでも良いのでは? 大体、各関数の物理的なサイズに拘束されなければ仕様をみたせない なんていうプログラムは保守がほとんど不能だろ。 コードや構造を改善するより動作環境を改善すべきだろ。
792 :
仕様書無しさん :2006/12/28(木) 23:54:22
>779 > 関数の粒度が揃ってて、上から順番に読んで行けば何しているかわかるなら、 > 200行くらいいいけど、関数のサイズをそろえるとキャッシュがうまく回る。 > 気がする・・。 すまん。何回読んでも理解できん。 「~なら」の使い方が論理的におかしい気がする。 職業病だろうか。 頭が溶けてしまいそうだ。
>>792 「~から」に脳内変換してたから気づかん買った
794 :
仕様書無しさん :2006/12/29(金) 00:09:55
>>779 こういう事?
if ( 関数の粒度が揃っている && 上から順番に読んでいけば何をしているかわかる ) {
if (関数は200行未満) {
if (関数のサイズを揃えた){
キャッシュが上手く回る;
}
}
}
795 :
仕様書無しさん :2006/12/29(金) 00:10:44
>>779 こういう事?
if ( 関数の粒度が揃っている && 上から順番に読んでいけば何をしているかわかる ) {
if (関数は200行未満) {
if (関数のサイズを揃えた){
キャッシュが上手く回る;
}
}
}
796 :
仕様書無しさん :2006/12/29(金) 00:19:46
>>795 いや
>>779 を善意に解釈するとこういう事だろう
> 関数の粒度が揃ってて、上から順番に読んで行けば何しているかわかるなら、
関数の粒度が揃っているなら、上から順番に読んでいけば何をしているか分かる。
→関数を理解するのは人間である。
粒度は人間の視点から見た概念である。
粒度が揃えられれば、人間にとって理解が容易になる。
ならば
人間を機械とするならば、粒度はサイズである(この時点で論理がおかしい)。
>関数のサイズをそろえるとキャッシュがうまく回る。
関数のサイズが揃っているならキャッシュが上手く回る。
→関数を解釈して実行するのは機械である。
サイズは機械からみた概念である。
サイズが揃えば、機械に取って処理が楽になる(キャッシュが上手く回る)
797 :
仕様書無しさん :2006/12/29(金) 00:20:19
ゲームとはちょっと違いますが、誰かこの論文の日本語訳を探してください!!GENERAL CHARACTERISTICS OF MOLLUSCSがタイトルです!
798 :
仕様書無しさん :2006/12/29(金) 00:32:28
軟体動物の一般的な特徴
799 :
仕様書無しさん :2006/12/29(金) 13:33:35
休みの日まで論理的思考なんかしたくないわね。
引退しなされ
801 :
仕様書無しさん :2006/12/29(金) 22:10:42
部屋の掃除をしようとしたら、 どういう手順で作業を進めると効率が良いか アルゴリズムをくんでいる自分がいる。
802 :
仕様書無しさん :2006/12/29(金) 22:34:53
女は右脳で考えるから行動が早いんだよね。 男は左脳で考えるからリスクファクターばかり印象に残ってしまい、現状維持に努めようとする。
女は直感と感情で動く よくも悪くも動物と行動が同じ
男でも女のような感情だけで動くヤツはふつー居るし結構多い マには少ないだけ
感情で動いたら既存スパゲティの破壊衝動に衝き動かされるしなw
>795 その昔に日本語の通じない外国人技術者と仕事をしたことを思い出した。 コミュニケーション手段はC言語。
807 :
仕様書無しさん :2007/01/03(水) 11:01:20
新年あけおめ、 プログラマならば、紅白なんぞ見ずに三が日コーディング三昧でつよ。
あけおめ。自分はカフェドクリエで構想&設計三昧です。今日中にまとめて明日から業務中に|゚Д゚)))コソーリ!!!!実装する。
809 :
仕様書無しさん :2007/01/20(土) 10:06:53
↑がんがれ
>>801 部屋の掃除をリファクタリングと思ってる俺がいる。
基本は「捨てる」だな。
何処かのcpioのソースで1000行以上に跨る関数を見た記憶が…
812 :
仕様書無しさん :2007/02/11(日) 15:08:38
コメントを書かない。 修正によりコメントが偽りとなるから・・・・。
813 :
仕様書無しさん :2007/02/11(日) 15:27:51
たとえば if (x==y) DEBUG_PRINT ("Debug Msg\n"); {}なしにこんなの使うやつ死刑。
それなら自分は1万回以上死刑になっているな。 なんで死刑になるのかを書いてみてくれないか
>>811 むかしの8ビットマイコンのBASICは65535行までしか書けなかったが、
それをオーバーしそうになるケースが多々あった。
816 :
仕様書無しさん :2007/02/11(日) 15:58:04
>>814 DEBUG_PRINTみたいにビルドモードによって変わるものを{}で収まらないとそれがどうなるか分からない。
if (x==y) DEBUG_PRING ("Debug Msg\n");
x=z;
これをReleaseでビルドしたらこんなものになる。
if (x==y) x=z;
817 :
814 :2007/02/11(日) 16:04:32
わかったわかった。 VC(かなんか)の固有の仕様なのか
その例だと最悪でも if (x==y) ; (空文) x = z; とかにならんか?
DEBUG_PRINT の展開結果が複文だったら(ry
ふつー複文をマクロで関数っぽく定義する場合は do { } while (0) で囲んだ形で定義するよね。
ネタ
823 :
仕様書無しさん :2007/02/12(月) 00:02:09
>>817 アホカw
お前の頭の方が固有な仕様だ。
>>820 そんなことしなくても
{
}
でいいんじゃね?
826 :
823 :2007/02/12(月) 00:47:27
gcc の拡張マクロ使っちまえ
>>815 それ、行番号の最大値じゃなくて、行数のこと?
その行数だと、1行が1バイトしかなくても、ソースのサイズが64Kになってしまうが。。。
8ビットマイコンのBASICだと、プログラムが行番号込みの 中間コードで記憶されてたものだが、行番号の領域が2バイ トしかなかったというケースだろう。
830 :
仕様書無しさん :2007/03/02(金) 23:31:26
なんかあったらダウンキャストでオケ
Java 例外は全部その場でcatchして戻り値で返す。 エラーステータスは-1や0や1が混在している。
832 :
仕様書無しさん :2007/04/29(日) 00:28:37
1クラス1ファイル
>>831 人から引き継いだシステム、例外全部最上位までふっとんでいくんだが・・・
tomcat自体のキャッチらへんまで
障害でてログを追っても何がなんだかさっぱり分からん。
そんなおれからすると全部その他でキャッチして戻り値返し、までは許せるかな、と・・・
(C++もJavaも例外の仕組みはどうもスカン)
1クラス1ファイルは普通だろうが
Javaの1クラス1ファイル規定はいまや理不尽だよな
>>835 ・1ファイルに複数クラス記述したい
・1つのクラスを複数ファイルに分けて記述したい
どちらの要求に対する理不尽?
どちらでも同じことだろう IMEでどうにでもなることを言語仕様にしてるのが問題
IDE?
しーっ
>>833 最上位まで誰も補足せずに飛んだんなら、どこで例外が発生したか分かりやすくてそんなに問題にならないと思えるが?
最悪なのは
catch(FooException e){
throw new BarException("○○の処理で落ちた");
}
みたいな元となる例外の情報を握りつぶして上にアプリケーション例外を投げる事だな。
せめて
catch(FooException e){
throw new BarException("○○の処理で落ちた",e);
}
みたいにして例外の発生元だけは保持していて欲しい。
>>840 >最上位まで誰も補足せずに飛んだんなら、どこで例外が発生したか分かりやすくてそんなに問題にならないと思えるが?
どこで発生したかわかっても、何で発生したのかがわかりにくかったりするんじゃないか?
ループの中だと原因になったデータのキーが分からなかったりするし。
あと、ブラウザ上にスタックトレース丸見えはちょっとイヤだな。
> 元となる例外の情報を握りつぶして上にアプリケーション例外
共通のライブラリのメソッドが全部throws Exceptionになっていて、
何でもキャッチして、スタックとメッセージ握りつぶして…ハンドリングしない
っていう↓見たいな感じの規約&フレームワークなら見たことならあるな。
catch(Exception e){
throw new Exception("error");
}
C++でboost::shared_ptr等のスマートポインタ使ってると newやdeleteに対する制限をコーディングルールレベルで規定しないと駄目なんだな
844 :
仕様書無しさん :2007/06/12(火) 02:59:59
ロジックを持つクラスはインスタンスフィールド禁止。 インスタンスフィールドを持つクラスはgetter, setterのみ。
>>844 貧血症ドメインモデルと
ステートレスなロジッククラス
の組み合わせって事だろ。
そんなに悪いルールじゃないよ。
議論のしどころとは思うけど。
846 :
845 :2007/06/12(火) 03:52:36
あ、ごめん、この会社辞めようと思ったソースコードスレと 勘違いしてた。議論のしどころの話をするのねここは。
847 :
仕様書無しさん :2007/06/13(水) 00:47:28
>>845 >ステートレスなロジッククラス
んにゃ、文字通りインスタンスフィールドが禁止。
staticなフラグ+synchronizedメソッドはOKで、ステートレスになっててもロジッククラスの入れ子はNG。
Singletonモドキ、Monostateモドキが大量発生中…
848 :
845 :2007/06/13(水) 03:50:18
>>847 ああなるほど、参照先がステートレスだろうと
インスタンスフィールド一切ダメなのね・・・。
もういっそロジック、全部クラスメソッドにしちゃって
Cみたくすりゃいいのに。
今いるプロジェクトはgetとdoばっかりだ。 getterも計算するメソッドも設定ファイル読み込みも全部getHoge。 動作を表すメソッドは全部doHoge。 doExcecuteってなんだよ。JavaBeans使おうとしたらDB検索に行きやがるし。
>>849 「実行する」に対して
「実行を行う」ぐらいに思っときゃおk
それにしてもその職場バカスww
頭痛が痛くなるルールだ
do + 現在動詞で強めの表現になる。 文法的には間違ってないかもしれん…。
854 :
仕様書無しさん :2007/06/27(水) 10:44:07 BE:716073784-2BP(21)
typedef std::string mojiretsu; mojiretsu dame_na_bun_okikae(const mojiretsu& moto_no_bun, const mojiretsu& dame_na_bun, const mojiretsu& okikaeru_bun); やっぱり日本語だよね\(^o^)/日本語最高
( ゚д゚)、ペッ
引数名がしっくりこない
Executeって「処刑」の意味で使ってたり。w
>>849 doなんちゃらは抽象クラスのabstractメソッドにしか付けないな・・・
runとかexecuteとかoperateとかinvokeとか色々あるけど やっぱり()演算子に勝てるものは無いと思う
ローマ字で書くくらいならVBみたいに日本語で書いてくれた方が何ぼかまし
ひじょーに低レベルな質問ですまんのだけど こういう場合、どっちのスタイルで書いてる? int proc_1(int nA, int nB) { if (nA < 0) { return -1; } { 処理1 } if (nB < 0) { return -1; } { 処理2 } : こんな調子で続く return 0; } int proc_2(int nA, int nB) { int nRet; nRet = 0; if (nA >= 0) { { 処理1 } if (nB >= 0) { { 処理2 } : こんな調子でネストが延々 }else{ nRet = -1; } }else{ nRet = -1; } return nRet; }
あれ。段下げしない、すまんです。
returnは1箇所というルールがあるところもある
>>863 自分的にはどちらですか?
深いネストを許すか、return をひとつにするか
自分的には前者。
・条件文のネストは2重まで ・returnは1箇所、関数末尾のみ ・ラベル、goto 禁止 結果:フラグ乱立 こういうプロジェクトにいますたorz
>>865 ,
>>866 ありがとうございます
コードコンプリートの著者の S.McCONNEL は、確かに構造化で出口はひとつといっているんですけどね
try に相当する実装をするための goto は許してます
そして、フラグ乱立は厳しく禁止してますね
私的には前者なんです
ネストがなくても、不正なパラメータ条件を先に排除して、正規の処理を行いたい
ネストだいきらい
>>863 それはコーディングの問題ではなく、凝集度の問題では?
>>869 うーん、ネストが深くなるのは
メソッド分割があまい、って事?
そうとも言い切れないケースも
あるような気がするなあ。
極端な規定を設けると、その規定に合わせるために、他のところが極端になるよな。 ・return1カ所→フラグ大量発生 ・ネスト禁止→1画面ぐらいの関数が、8つに分割とか(これは実話。設計もまずいけど)
一律のルールってたいてい害悪だ 適材適所
フラグ乱立禁止 →ビット演算で各種フラグを実装,っていうプロジェクトに破魔ってます. 課税するフラグ=1 税込み表示するフラグ=2 総量計算するフラグ=4 とかで,1+2+4=...みたいな? そりゃ確かに変数の数は減るけどさぁ...
普通はマクロか関数でくるむよね? > ビット演算のフラグ
>>873 すみません、笑ってしまいました
>フラグ乱立禁止→ビット演算で
論理的には乱立と同じかとw
なんか、もうトンチじゃないんだからって感じですね
>>872 ホントにそう思います
いまはまっているので、書き込みました。。。
returnは、1ヶ所厳守、ネストはいくらでもOK のプロジェクト
前任者のコード、if が画面からはみ出そうです
>876 そのルールなら goto 使え ちょっとは見通し良くなるから
>>877 goto なんぞ使った日には、たぶん公開処刑ですねw
絶対に、完全に、なにかあろうと、死んでも、goto は許されないですょ(T_T
try ならいいんでしょうけどねw
あいにくCだし
ヒデェルールだな
当然 ループ内で break, continue も禁止
>>880 うむ、それが筋だな。
ルールとしては美しい。
出来上がるコードは知らん。
>>881 その美しいルールで書かれた既存のコードは、
1関数3000行のイベントとステートが90度入れ替わった「有限"イベント"機械」
もちろん、ネストは 5段以上
愚痴になってすみません。ミスを連発したので、凹んでます。
真剣にルールの改訂を求めた方がいいんでねぇか…
重要だけど些細な事「だけ」に拘ると 何が起こるかの実例を見た思いだ。
そのルールが無いと、もっとひどいのかもしれん…
>>885 コーヒー噴いた。考えただけでもおとろしいです。
Javaで、 ・メソッド内で使用する変数は、すべてメソッドの最初で宣言すべし。 ・メソッド内で使用する変数の宣言時は、すべて初期値を設定すべし。 ・メソッド内で使用する変数の初期値は、すべて定数として定義すべし。但しnullは除く。 if文やfor文の中でしか使わない変数もあるのに。 そんなにNullPointerExceptionを発生させたいのかな。
returnを一カ所にするためだけのフラグが存在するなら死んだ方がいいと思うが、 fp = fopen(); if (fp != NULL) { fread(fp); fclose(fp); } return; これならよくする。
>>888 fp = fopen();
if (fp != NULL) {
fread(fp);
fclose(fp);
return -1;
}
処理
:
return 0;
これはダメだそうです
fp = fopen();
if (fp != NULL) {
fread(fp);
fclose(fp);
nRet = -1;
}else{
処理
:
nRet = 0;
}
return nRet;
これが要求、たとえネストがどんなに深くなっても
もちろん、ループ内で、continue, break;, returnは禁止
fp = fopen(); if (fp != NULL) { fread(fp); fclose(fp); raise(SIGUSR1); } return 0;
>>889 後者のルールでnRetを上書きしてパニクる馬鹿を見たことあるんだが、
それはどう対策しているんだろう。
上書きしない
おれだったらnLastErrだな。 最後のエラーだから理由があれば上書きしてもよい。
894 :
861 :2007/07/14(土) 16:58:53
>>893 そういう言葉の意味を大切にするのはすごい好きです。
美しいコーディングルールも大切だけど一番大切なのは 人間の知性で御しきれるかどうかだと思うんだよな。 俺はネストが3以上、コードが50行越えたら 「悪いけど複雑すぎて分からないからシンプルに書き直して」 ってお願いしてる。 若い奴らはプログラマー自身がコードに深く潜りこまないと読めないような トリッキーなコードや、複雑なコードを 「俺はプログラマーとして上級な事してる。カコイイ!」 と思うみたいだが俺としては何より人間の感覚にマッチしてて、 短くて読みやすいコードを重視してるから 「このコードの変数名の意味を説明してくれ」 とか言って煙たがられてる。
>>895 >「俺はプログラマーとして上級な事してる。カコイイ!」
>と思うみたいだが
たぶんそれは買いかぶり
馬鹿の頭の中は、思ったより複雑
馬鹿だから複雑なのだよ
898 :
861 :2007/07/17(火) 16:04:55
>>897 だから、
「単純に return をひとつにすれば
ネストがどれだけ深くてもわかりやすいだろ?」
という理屈らしいのですが
わたし的には、逆に追えない。
>>861 >>898 だから、
int proc_A( int nA ){
if (nA < 0) { return -1; }
{ 処理1 }
return 0;
}
int proc_B( int nB ){
if (nB < 0) { return -1; }
{ 処理2 }
return 0;
}
int proc_1(int nA, int nB){
if (proc_A( nA ) < 0) { return -1; }
if (proc_B( nB ) < 0) { return -1; }
: こんな調子で続く
return 0;
}
こうでしょ?
900 :
898 :2007/07/17(火) 20:16:15
>>899 そう書きたいのですが
そこのルールは、
return はひとつ
if はelseが必須
ループにcontinue, breakはなし
ネストは制限なし
なんです
そうすれば、「間違いがなくなる」し「わかりやすい」という理由で。
嫌がらせとしか思えんな
昔
>>861 みたいなやり方した(+全体をdo{}while(false)で囲んでエラー時breakし、最後でreturn)。
その後、エラーが起きたらその場で抜ける方が可読性高くなる&ネストが減る、と考え
>>899 みたいに書くようになった。
更に、関数化するルールを以下のように決めて、
「汎用的な共通関数」「システム固有の共通関数」「ある程度機能的に分かれるサブフロー」
単純にステップ数どうこうで関数分けする、というのはやめた。
(まぁ、このやり方についても賛否両論いろいろあるだろうけど。)
ある程度の規模のアプリをサブシステム分けして複数人で作る時、
コーディングルールなしで個々人の自由にしちゃうと可読性その他めちゃめちゃ低下して
以降の保守/拡張も大変になるからルールを設けること自体は悪くないけど、
いいルールと思えないものをそのままずっと改定せずに使い続けるってのもどうかなぁ。
こういうルールを押し付ける人間はルールのよしあしを見ない(昔のPrjで使ったから、とか)
場合が多いからね。
とりあえずgotoを頑なまでに嫌うのは古いスタイルに凝り固まった証拠だという調べ方は結構使えると思う
リターンが1つでgoto禁止じゃなけりゃgotoでとばしちまえ。
905 :
898 :2007/07/19(木) 13:49:22
goto1つに目くじら立てるのはCマガとか診断室に洗脳されてる証拠だね
あれって10年以上前のスタイルなのに未だに引きずってるってこと
勿論
>>898 はそんな奴らの同類じゃないよね
いくつか失敗するかもしれない処理がある関数とかで、失敗したときは -1を返すときとかで、 if (res = リソースの確保()) { /*失敗*/ return -1; } if (ふふん) { /*失敗*/ リソースの開放(res) return -1; } とかってやりまくるより、 res = NULL; if(res = リソースの確保()) { goto failed; } if(ふふん) { goto failed; } failed: if(res) リソースの開放(res); return -1; ってやる方がはるかに分かりやすいと思うのは俺だけか?
>>906 診断室が藤原博文のヤツなら、あれはべつにgoto絶対禁止してないぞ。
p.380に末尾gotoしてfreeする話も載ってる。
909 :
898 :2007/07/19(木) 21:52:15
910 :
909 :2007/07/20(金) 02:27:30
try/catch構文は、あまりに便利だから導入されたの?
912 :
仕様書無しさん :2007/07/30(月) 00:11:13
913 :
仕様書無しさん :2007/07/30(月) 00:19:33
>>895 おまえに理解できるように書けってか?
50行越えたらってオマエ・・・ww
矛盾してるなぁ。馬鹿でも解るプログラムは
冗長になるはずなんだけど?
全メソッド50行以内にしようと思ったら、高度にOO化しないと無理だぜ?
高度にOO化すると理解し難くなるよなぁ?
何時のレスに返してるw
>>913 まぁ、丁度俺が本人なのでレスするが、別に高度にOO化する必要は無いよ。
丁寧に構造化したり、再帰や高階のテクニックを適用すればシンプルで読みやすいコードはかける。
(俺が言っているトリッキーとは、intを32個のフラグにしたり、変数を使いまわすようなこと)
馬鹿でも理解できるように書くわけではなくて「即座にコードの意味や構造が理解できるように書く」のが重要。
だから、変数名や関数名がhogeとか意味分からない名前になってたらだめ。
916 :
仕様書無しさん :2007/07/30(月) 01:29:06
917 :
916 :2007/07/30(月) 01:37:26
ただ、行数で判断するのはちょっとどうかと思う。
ここで 「識別子の種類数」 と言ってみようか
>>895 ネストが3以上でだめとか、50行以上がだめとか、ろくにコードを読み書きしたことねーだろ。
>>920 さすがに、印刷して行をまたいだり、
画面からはみ出るほどネストすると
書いた本人はいいかもしれないが
後から読む奴は読めない
読めるのを自慢するのは
目がいいのを自慢するのと変わらないきがする
もちろん、読めないというのは比喩で
正しくは
読みづらい、間違いやすい
実用的なシステムのコードで、ネストが全部2以下とか、ルーチンが50行未満とかありえないだろ。 無理にそんなことしたら、かえってコードがひねくれるよ。
桁数は80以内(苦笑)
>>923 その規定に合わせるために、
arg1 = network_data;
arg2 = max_retry_count;
arg3 = hogehoge_fugafuga;
arg4 = &error_checker;
...
ret = func(arg1, arg2, arg3, arg4, ...);
と涙ぐましい無意味なことをやってるコードを見たことがある。
>>924 それなら許しちゃうかも。w
一度だけ、はみ出てコンパイル通らないからという理由で
if~then~else~endifがガタガタになったコードを見たことがある。
もちろん、理由を聞いた瞬間張り倒した。www
そういう場合は俺なら func( network_data, max_retry_count, hogehoge_fugafuga, &error_checker ); ってするんだけどこれってあんまりよくないのかな?
引数が長いときはやる。
>>926 WindowsAPIなんかで、引数10ぐらいになってくると、カラム制限が無くても普通は改行するよね。
変数名が長いだけで、引数が4つとか5つなら、カラム制限がなければ1列に書く。
あとで、ぱっと見たときにどう見えるかって点からすると、ケースバイケースにしたいかな。
つか、一行80桁のところは、改行のしかたもあわせて決めてあるだろ?
そういう所に限って、変数名は8文字までとかクソルールが付いてくる、大抵。
さらに、 引数は3つまで。4つは許可制。 うんこ構造体増殖中orz
そんな雁字搦めの所で働いてたら 俺そのうち白目剥いて「キャッサバ!!キャッサバ!!」って叫びながらwe can fly!しそうになるだろうな
>>931 過去にやたらおおい引数の関数を多増させたやつがいたんでしょうね
たいていの規約は
「熱ものに懲りて、まなすを吹く」
になってる気がします。
まなす。これは新しい。
それと、熱もの、これも新しい。 普通に変換出来るので、きっと新しい。
936 :
933 :2007/07/31(火) 11:14:47
ドンマイw
938 :
仕様書無しさん :2007/08/05(日) 02:47:59
>>926 ひとつの目安は、デバッガでデバッグしやすいこと。
ステップ実行しても中身が分からないコード書くと自分の首締めるだけだよ。
ちなみに、おまいのは良い。
引数の多い関数に改行入れると、ステップ実行に関係があるの?
>>940 VS2005は横スクロールしたまま進むから
ネストしてたりすると行の途中からしか表示してくれなくてみづらい事があるよ。
そうやってその場限りの意味不明な構造体が増えていく・・・
いつものこと。
コメント日本語禁止。
>>945 /* That will mass-produce comments of english and roma ji no bimyou ni mixed. */
>>945 コメントで、アホなコメント書く奴いるね
if (nPropose == OK){
bDeathFlag = true;//フラグをONにする
}
とかw
見りゃわかるって
日本語コメントは、ツール通しにくいし、
文字化けしてコンパイラエラー起きるし、
コードが変わって差分管理が全滅するし、
海外出すときもトラブルの種。
ローマ字のほうがまだましダヨ。
>>946
>>948 日本語の通らない処理系なら日本語禁止
日本語の通る処理系なら日本語で
じゃ、いけないの?
今どき日本語に対応できない処理系って・・・
UNICODE使えばいいじゃん。
つーか半狩り案記法は恐ろしく読みにくい。
お前の当て字より読みやすい
ハンガリアンについて語るときはjoelのアレを一読してからな。
ハンガリアンチョーップ!!
ハンガリアン? カップヌードル
ハムスター?
アメリカ郷土料理?
ハンガリアンハムスター
>>959 あまりに、かわいそうなので、突っ込んでおこう
×ハ
○ジャ
ハンガリアンジャムスター こうですか?わかりません><
>>961 の文字列を正しいものにする処理を書きなさい
ってどう?言語は問わない。
String str = "ハンガリアンジャムスター"; str = "ジャンガリアンハムスター"; できたぞー
これじゃあんまりだからちゃんとやるぞ。 if("ハンガリアンジャムスター".equals(str)){ str = "ジャンガリアンハムスター"; } できたぞー
というか、この場合にかわいそうなのは960では?w
>>960 の仕様はジャンガリアンジャムスターだしな。
>>964 やっぱり "文字列".equals(str) の方が標準?
なんか俺のいる現場のJAVAソースって
str != null && str.equals("文字列") って書き方が多いんだけど...
書いた当事者が居なくなって初心者のおれが面倒見るハメに...
所詮ぬるぽ対策にすぎないからな
手順、文脈として正しいのは str != null && str.equals("文字列") 実際の業務用プログラムの作法として正しいのは "文字列".equals(str)
やっぱJavaはダメだな
"文字列".equals()には致命的な問題がある。 それは、直感的に「文字列定数がオブジェクトである」と思えないこと。 「使えるんだしそのほうが楽」というのは間違ってないんだが、 それをいってしまうと「コンパイルできればそれでいい」というのを肯定することになる。
>>972 むしろ逆だろ。
不勉強な奴は「あれ…"foo".equals(bar)って出来るんだ…」って驚くんじゃね?
それをきっかけに、どんなカスな本にも書いてある「文字列もオブジェクトです」に辿りつく、と。
974 :
972 :2007/11/16(金) 23:06:50
>>973 それこそ問題があると思う。
文字列型がオブジェクトであることと、文字列定数がオブジェクトであることは別の話だろう。
それに「どんなカスな本にも書いてある」といっても、それはJavaに限るんじゃないか?
他に「定数がオブジェクトである」言語があるなら教えてほしい。
他にないなら、これは「Javaでしか通じない表記」になる。
それに"foo".equals(bar)が直感的にわかりやすいなら可読性は下がらないが、到底そうは思えない。
ソースを読みにくくしてまで書く手間を減らすっていうのはナンセンスだし、
staticなString.equals(foo, bar)の方がよっぽど優れている。
ついでに言えば、オブジェクトを明示的に開放しないJavaにとって、
オブジェクト定数と非オブジェクト定数の違いはほとんどないんじゃないのか?
そこからメソッドを呼ぶことはできる以外に差がないなら、そこをプログラマが意識する必要もない。
言語特有の表記というのはいろいろあるけれど、その表記で可読性が落ちるなら使うべきではないと思う。
例えば、Cの三項演算子みたいに。
定数でなくてリテラルの事を言ってるんだよな。 リテラルが型を持って、その型の通り振る舞うのは大抵のプログラム言語に 見られる特徴だと思うが。
>>974 まあ落ち着け。
あんたの言いたいことは分からないでもないが、
>>973 の言いたいのは、あんたが問題視しているようなことも含めて、
そういった問題に目を向けるきっかけになるんじゃないの、ということじゃないかな。
最後にもう一回書いとくけど、落ち着けよ。
可読性を問題にしているのか、言語の欠点を論っているのか明確でないな。 コーディングルールの範疇ではどちらも考慮しなければならないと思うが、 必死(www)で理屈を披露したいのなら、焦点を明確にした方が良い。 …俺の理解力が足りないとか、下らないことぬかすなよ。
"foo"==bar が一番直感的だと思うけど・・。
文字列がなぜ基本型でないのかを論じるのが先だろ(笑)
逝けてる話が最近出てない・・・ 他の言語からJavaにうつる時、いきなり a==bだとオブジェクトが同じものかの比較、 a.equals(b)だと文字列比較、 って言われてもナァ。 演算子のオーバライドをしない、ってのは確かに複雑さをはぶく意味ではよかったんだろうけど 「絶対知ってなきゃいけない前提条件」を増やした、ってのはJavaのデメリットかと・・・
Cだってstrcmp使うだろ 別にJavaが最初じゃないし
>>982 VC触った当初からC++としてだったし、
VBも同様、
という事で、==(あるいは=)で考えてしまいますた。
==がNG、とかなら分かるんだけど、==でも比較できて(オブジェクトとして)、
でも実際文字列として見たければ.equals()使えよ、ってのがどうにも・・・
984 :
983 :2007/11/18(日) 00:58:20
あ、でもVC++でも文字列比較は.CompareNocase()とか使ってたわ・・・ ただの毛嫌いなのかしら。。。
実は他の組み込み型でもequalsを使うべきだとか。 int a; if (a.equals(3))
==をオーバーロードすればよし
==は左辺と右辺が同一か比較するもので、 左辺右辺共にオブジェクトなんだから、オブジェクトが同一か比較するって動きは 別に変じゃないと思う。 あくまでstringは文字列を保持するオブジェクトであって、「文字列そのもの」じゃないんだから。 ところがintとかは特例的に「数値そのもの」の色が強い(おそらくCからの流れなんだろう)から、 ==で「数値そのもの」の比較が出来る。
988 :
仕様書無しさん :2007/11/19(月) 22:49:03
not系の判定でandやorはしない。 if(a != 1 && a != 2 && a != 3){ ... } そりゃ考えれば分かるが、ぱっと見なんだか分からない。
>>972 への突込みところは
>それは、直感的に「文字列定数がオブジェクトである」と思えないこと。
という個人的な思い込みを前提に語りだしてる事だと思うがw
「直感的」はbuzzwordにすべき
991 :
仕様書無しさん :2007/11/21(水) 01:03:44
C++ではfunction generatorを利用した「流れるインターフェース(?)」っていうのがあるんだけど こういうのは仮に作っても使わせてくれないんだろうな… Colletcion | find_if(_1 > 0) | output;
どの言語使ってもメモリ上の実体の比較とコンテキスト毎の比較は別に必要だし、 オブジェクト指向してればセマンティック比較のメソッドがあるだろうけど 結局コンテキスト毎の比較の補助でしかないしなぁ
誰か、助けてくれ。 2byte文字の関数が大量に組み込まれたコードを手直ししてるんだ。 まさかとは思ったが、DBもテーブルも項目名も全角なんだ。 作ったのはウチじゃないんだけど、作った会社が飛んだらしいんだ。 最初に「1から作り直したほうが良いと思いますよ?」って提案はしたんだ。 でもなんか知らんけど修正の方向でGoサインが飛んできたんだ。 ・・・誰か、助けてくれorz
>>995 ちょっと待て、それは現在稼働しているソースか?
動いているんだったら2byte文字のままで動かす環境を整えたほうがいいと思うのだが。
それならそもそも
>>995 がSOSを出さないような気もするが。
.NETの功罪かな
>>983 同感。
Javaの==の仕様はおかしい、というか馬鹿みたい。
オブジェクトのアイデンティティを比較したくなることなんて
希だろうに。
演算子のオーバーロードが出来ない事が影響してる?
ヌル(・ω・)ポリーン
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。