2 ：
仕様書無しさん：2010/01/24(日) 20:52:56
今から放送だからテレビつけろよ
24日放送の「NHKスペシャル」でREGZAやRYOMAの開発舞台裏を紹介
ファイル・ウェブ編集部
NHKは、「NHKスペシャル メイド・イン・ジャパンの命運」を1月24日午後9時から総合テレビで放映する。
番組内では、東芝やJVCケンウッドの商品開発や生産の舞台裏を紹介し、「『日本は今後どうやって食べていくのか」、
『日本人は何が得意なのか』と自問を繰り返す二つの電機メーカーの社運を賭けたプロジェクトに密着し、
メイド・イン・ジャパンの未来を見つめていく」（NHKの番組紹介より）という。
AVファンにとって興味深い話題が多く紹介されると予想されるこの番組、ぜひチェックをおすすめしたい。
ソース
ttp://www.phileweb.com/news/d-av/201001/22/25182.html どうみてもマルチポスト宣伝
5 ：
仕様書無しさん：2010/01/24(日) 22:13:44
>2
見たけどダメだな、ありゃ
バイデザインとセルレグザじゃ競争のレイヤが違うんだよ
ケータイのソ\\\フトと作り方一緒じゃん！
csvデータファイルの変換を行うプログラム。頭から書き直したくなった。
int i;
void main(){
fp = fopen(...
(略)
getOneLine(fp,buf);
for(i=0;i<320;i++){
getToken(buf,i,token);
switch(i){
case 0:
func0(buf);
break;
case 1:
func1(buf);
break;
(略)
case 319:
func319(buf);
break;
}
}
funcN()でiを弄ってたりしそうな勢いだ
8 ：
仕様書無しさん：2010/01/25(月) 19:55:04
public class ぬるぽ : NullReferenceException { }
すべて検索 "throw new ぬるぽ", 大文字と小文字を区別する, 完全に一致する単語だけを検索する, サブ フォルダ, 検索結果 1, "現在のプロジェクト"
(略)
一致した行: 339 一致したファイル: 65 検索ファイル総数: 2011
それ、ちゃんと処理しているだけマシだと思う。
すくなくともエンドユーザには不様な姿を見せてないもの。
えっ
throw new ぬるぽ
がたくさんちりばめてあるところだろ？
ほんとに ぬるぽ だったの？
実際は、NullPointerException だったんだろ。
NullReferenceExceptionはランタイムから飛んでくるもんだろ
ユーザが意図して投げるならArgumentNullException辺りが妥当じゃね？
あるいは
catch(NullReferenceException){throw new ぬるぽ();}
とかやってたんかな
// しかしC#て日本語でクラスかけるんだな
// 2年やってて気づかんかった
>>15 ソリューション名に日本語入れてデフォルトでウィザード終えるとクラス名から実行ファイル名までごっそり日本語ぶち込まれるんだよな。
流石Unicode
17 ：
仕様書無しさん：2010/01/27(水) 22:57:21
まぁ結局プログラマーなんて」ゴミみたいなもんだからな
どう押し間違えたらそこに」が入るんだろう
興奮しててENTERと一緒に押したの気付かなかっただけじゃね
>>17 こういうやつはいずれウィルスみたいな人に迷惑をかけるプログラムを書きそうだ
ヽ～ノ´Д`)ﾑﾘﾑﾘ
実力ないうえにすぐ飽きるかつ根性なし
そんなヤツには無理
>>6 こういうプログラムに限って、途中で
case 231:
func232(buf);
break;
case 232:
func231(buf);
break;
とかコメントもなくなっていて、
意図的なのかミスなのかわからないんだよなぁ・・・
>>23 あるあるあるあるｗｗｗ
思い出すどころか想像するだけでゲンナリする。
VBでコントロール配列使わず、100個ほどボタンを置いたフォームの
OnClickの群れの方が対照させやすい点でまだいいな。
まぁ今更VB自体使いたくないけど。
VB6はvistaで動作保証がある。
たぶん７でも問題なく動くケースが多いから、あと数年は確実に残るんじゃないか。
つ～か、この不況でvb.netやC#に移行する金が出せる企業は……
（言語本体は安いけど、サードパーティ製の各種コンポーネントが……）
>>24 唐突に思い出したんだが、配列が嫌いなプログラマが書いたコードがあった。
リングバッファの処理らしいんだが
void DetaSettei( int atai )
{
atai1 = atai2;
atai2 = atai3;
.........
atai255 = atai254;
atai0 = atai;
genIchi = ++genIchi % 256
}
うちでは技術力はあると言われている人
ちなみに、関数名とか変数名は若干いじったが、元も大抵ローマ字っぽい何かが多い
配列使ってても書き直せ馬鹿って言われるであろう計算量だな
>>27 計算量は変わらないだろ。メモリアクセスはかなり増えるが。
昔、配列 と memcopy で 26 のコードを見た事がある。
Verilog HDLで回路設計やってる人だったけど、
ゲートのシフトレジスタ・FIFOのイメージでと言ってた。
>>27 動いてればまだ多少は許せるのだが、この人たちのプログラムは正直、
アレなバグがやたら多いんだよね。
atai221 = atai220;
atai222 = atai220;
みたいな
直せと言われて、直すんだけど、大体配列なり、変なグローバル変数の使い方を改めると
１／３ぐらいそれで直る（笑）
そこまでしてこだわる理由を聞くと、配列使うより、こうした方が処理が早くなると言われるんだ。
その割に、デバッグビルド（最適化オプションなしか緩め）で客先に納品されたり、
なかなか間抜けなことが多い
組み込みやってる（やってた）人ならパイプラインのストールを嫌って
単純ループなプログラムを回避したと推測してみる
>>30 今のコンパイラならオプションである程度
展開してくれるから、そこまで変わらん
そのCPUでは、memcpyはどう実装するの？
>>26 そのバッファからデータを取り出すときって genIchi による switch 文を使うの？
case が256行並ぶのは壮観だろうなｗ
>>28 配列使えばデータを動かす必要無いと思うよ
>>29 『処理が早くなる』って言われたら気絶しそうだ
>>33 当然ですが、switch～case文が２５６個並びます（ｗ
バグを調査しようとしてたらしく、至る所にTRACEとかファイル（ログ）、
書き出しとかの残骸が転がってました。
２５６個のデータダンプするコードとかを全部ベタ書きしてたときは、
壮観というか卒倒しそうになった。
ファイルIOとかの処理挟んだら、処理が早くなるとか言ってもぶちこわし（ｗ
>>34 よく考えるとセット関数も書き込み位置インデックスによるswitch～case256行にすればデータをズラす操作は不要だね
書いた奴は相当頭が固いんだろうね
関数コール毎に256個のデータダンプ？
んなもん出したところでチェックするのは至難の業だと思うんだけど...
>>35 それって、配列でインデックスアクセスするのと何処が異なるの？
大差のないアセンブリソースが出力されそうな気が……
>>28 バッファ長をNとして、
>>26の例のようにデータを動かす場合、計算量はO(N)。
producerもconsumerもインデックスを動かせば、計算量はO(1)。
C言語でやる意味あるの？
>>36 確かめもせずに大差ないとか言ってませんか
>>36 switchは効率悪いからね、 else if の連鎖と同じアセンブリを吐くのが普通じゃないかな
一回のアドレス演算で済む配列とは雲泥の差が有るぉ
256個もcaseがあれば、まともなコンパイラはテーブルジャンプに変換します。
最近のコンパイラではアセンブル結果見た事ないからね、認識が古いかな？
どっちみちジャンプテーブルを確保したり無駄なジャンプが発生する以上、『大差ない』とは言えないよ
>26
似たようなのだが、16進二桁を数値化するのに、if 文合計272個、ってのが……
※C ですぜ
1個目が 0～F で一段目の if （これが16個）、
2個目が 0～F で、各一段目の中に16個ずつの if ……
※よって、16 + (16*16) = 16*17 = 272個
これでもソースレビュー通ってたらしい。
むろん、書き直したけどな。
組み込み屋とアプリ屋で話かみ合ってなくない？
>>44 組み込み用のコンパイラでも配列くらい使えるだろう
そもそも
>>30 はループなんて言ってるから問題点を理解してない気もするし
お前が３０の言ってる意味分かってないだろｗ
だからリングバッファにループなんて必要ないんだって
リングバッファを知らんのだろ。
46じゃないよ
>49
繰り返すけど>46
45のほうがかみ合ってないと思うんだが・・・
44なんだけど、リングバッファ知ってる人と知らない人で噛み合ってなかったのかな？
まあ俺は知らなかったよ
使ったこと無いし
>>30,42は速度の点を問題にしたのじゃないの？
あと
>>45はループの問題が分かってないのじゃないの
要る要らないじゃなく
分かってたらゴメンね
>>52 リングバッファも知らない人に馬鹿にされて く や し い で す！
54 ：
52：2010/02/23(火) 09:03:12
, -‐－-､ ヽ∧∧∧ // |
. /////_ﾊ ヽ＜ 釣れた！＞ ハ
ﾚ//ｊ け ,fjlﾘ / ∨∨V ヽ h. ﾟl;
ﾊｲｲﾄ､"ヮノﾊ // |::: ｊ ｡
/⌒ヽヾ'ﾘ、 // ヾ､≦ '
. { j｀ｰ' ﾊ // ヽ∧∧∧∧∧∧∨/
ｋ～'ｌ ﾚﾍ. ,r'ス ＜ 初めてなのに ＞
| ヽ ＼ ト､ ヽ-kヾｿ ＜ 釣れちゃった！＞
. l ＼ ｀ｰ‐ゝ-〈/´ / ∨∨∨∨∨∨ヽ
l `ー-､___ﾉ
ﾊ ´￣｀ 〈/‐-､
>>54 むしろ、初めてのほうが食いつきがいいんだよ？
>>54 くやしいねえ。
10年後にその書き込みをもう一度読む自分を想像してみ？
かなりくやしいねえwww
57 ：
仕様書無しさん：2010/03/03(水) 10:56:51
外の会社でやっているときに、修正してと言われたVBのソースが、case文が100個近くあるものだった事があるなぁ
これ「だけ」だったらまだ「汚いソースだな」と思うだけだったんだが…
・CASE文が1000行近くある。
・ほぼ同一のコードが、異なる条件式に「多数」存在する。
・似て非なるコードも多数ある、通らない条件式も多数あるが、条件が「ハードコーディングされている」のでどれが何だかわからない
・このcase文がある関数は、3000行近くある。
まだ、これなら「最低のソース」なのだけど、極めつけはこれ
・以前に修正したものらしきソースがコメントとして残されている。ほとんど5行おきに交互に。しかも大量に。
よくここまで非論理的で可読性を無視したソースが、たぶん全国にある某店のシステムとして運用できるものだと思ったよ
すまん。無駄に上げてしまった orz
そんなもんじゃ
>>1 区切りが全然ないとかかなあ。
しょっちゅう見かけるけど、何でコンパクトに分けないのかな？
まるで読書してるようで、とてもソースコードとは思えない。
カプセル化した方がとは言わないけど、丸で読書。
関数分けしてない人って、どういうソースの組み方なんだろう。
あとコメントが丸で無いから、分らなくて
一から読み直しかと思うと、苛々します。
バグ発見も、非常に邪魔臭いです。
時々でいいんです。後で触る人の事、思い出してください。
「細かく関数に分けると、処理があちこち飛んで読みにくい」
だそうです。
関数をしっかり作らないからあちこちに飛ぶ事になるんだ
しっかりってなんのこっちゃ
>>60 昔駆け出しの頃に、新人だからやっぱりスパゲッティソースを書いた事があって、そのときに超ベテランの人にこういわれたことがあったな
「ソースは自分のためにではなく、他人のために書く」
当時は何のこっちゃいと思ったけど、今はいろいろあってそれが根底になっているな
それでも汚いソースになることがあるから、まだまだなんだが
>>63 関数が機能として独立してないとかかな
中途半端にグローバル変数なんか使っていたりするとかなり泣きが入る
あるフリーソフトのソースを買いたいが、まず一部を見せてくれと言われたことがある（日本の会社ではない）。そのとき汚いなら買えないと言われた。
海外のほうが汚いけどな
＞中途半端にグローバル変数なんか使っていたりするとかなり泣きが入る
相等やばいな。流石に、それはなかった。
>>66 まさに”人による”部分が大きい。
大手でも、中小の自宅開発でも。
確かに人によるね。
綺麗に書く人はとことん綺麗に書く。書くんだが…
前にコメントを細かく書いてソースもそれなりに綺麗に書いてくれる奴がいたんだが、これがまた困ったもので
コメントを細かく書いてくれるのは結構なんだが、だからって関数内でコメント＞＞コードなものを書くなと
コードを見てすぐに分かる部分は一々書かなくて良いし、ただでさえ簡単なのやらせても遅いんだから、もっとシンプルかつスピーディーにコードを書いてくれと
自信満々に「自分のプログラムはバグ出ません！」と言われても、そりゃそうだ
君の代わりにこっちは同じ開発期間で8倍のPG組んで、おまけに仕様書が書けないSEの代わりにPGのロジック考えて、ついでに現地でテストも立ち会っているんだから('A`)
それで自分がバグだしたら意味無いんだが、それでももう少し納期や必要の是非を考慮する関数がコーディングされていれば、もうちょっと何か違ったのかなと思う
自宅開発なら良いPGだったのかもしれないけどね
プログラムを作る人は、時間的感覚が無くなってしまう事ってあるね。
でも無理な工程で作らせたり、動と静の共存こそ、バグの原因だと思った。
しかし変な話だよな。プログラマなら分ると思うが
オブジェクト指向が、作業全体ではなく、プログラムにしか適応されないのって
何でだろう？って思う事は多いね。
でも、頭で考える世界って、静止した世界なんだろうな。
地球はその間も絶え間なく動く、動の世界。
結局、動の世界がなければ、静の世界も認識できなくなり、I/Oと同じ仕組みが見て取れる。
という事は、バグは自然に作られる、イレギュラーという名の正規のものなのか。
と矛盾した事を考えてしまう。
バグは大嫌いだけど、そんな自分も実は地球のバグなのでは、と
仕事帰りに考えたり。
おまえ、自分でわかってないのかもしれないが、精神病じゃないか？
>>69 自然界ならバグは進化の過程といえる。
最近も新発見はバグ（失敗）が原因だったりする。
しかし、そふとうぇあの世界ではバグで新発見などない。
せいぜい誤変換や誤読で池沼などの言葉が生まれる程度。
あ、日本では鳥がさまざまな姿をしているという話は聞くね。
日本には謎の鳥がいる。 正体はよく分からない。
中国から見れば「カモ」に見える。
米国から見れば「チキン」に見える。
欧州から見れば「アホウドリ」に見える。
日本の有職者には「サギ」だと思われている。
オザワから見れば「オウム」のような存在。
でも鳥自身は「ハト」だと言い張っている。
それでいて、約束をしたら「ウソ」に見え
身体検査をしたら「カラス」のように真っ黒、
釈明会見では「キュウカンチョウ」になるが、
実際は単なる鵜飼いの「ウ」。
私はあの鳥は日本の「ガン」だと思う。
↑神！神！もっと評価されるべき！！！！１１１
73 ：
仕様書無しさん：2010/03/05(金) 10:13:12
ではやはりあげておくべきですね。
>中途半端にグローバル変数なんか使っていたりするとかなり泣きが入る
中途半端というか、完全に全関数に影響があったこともある。
以下、担当新人に言われたこと。
え～～～～
毎回ループ文書くときにint iって書くのメンドイじゃないっすか～？
だからグローバルでiを書いたんッスけど～？
何が悪いんスか～？説明してくださいよ！
(俺の説明)
あ゛～～！もう何言ってるのかワカンネーッスよ！
(レベル下げて再度説明)
・・・もういいから黙れクソが！
てめぇ何さっきから俺に説教タレてんの？
てめぇ偉いのかよ？何様のつもり？
>76
ガシッ！ボカッ！
新人は死んだ
>>76 昔派遣で行ったところが会社全体でそんな感じ
N88日本語BASICと同じ感じでCとかのプログラム組んでて、
本当にカウンタ変数をグローバルで定義してて、それを
複数関数で使ってんの
当然わけわかんないバグがてんこ盛りで、グローバル変数の
害悪やら何やら説明してリファインの必要を説いたけど、
そこで「使える」マですらその新人並みの反応だった
>>78 Nでしょ？汎用機上がりの部門は
今も変わらないよw
COBOLあがりならスコープって何って人も居るかも知れない
でも
>>76 のはCOBOL未経験と思われる新人だからレアなクソかと
そもそもループのカウンタに i のような無意味な名前をつけることですら、推奨されなくなっているのにな。
じゃぁなんて名前付ければいいのよ
cnt?
iが無意味だと？
Code Complete 読め。
手元にないからお前が読んで聞かせろ
今朗読したところだ。お前に届いてると良いが。
あ～？
聞こえんなぁ～
もう一度頼むわ
グローバルを絶対使うなとは言わないけど grep しやすいように長めの変数名にして欲しい
>i のような無意味な名前
悪しき風習？だろうが、既にデファクトスタンダードになってるからね～
あながち無意味とは思えないけどね。
悪しき風習なんてとんでもない。
昔の低機能エディタなら、「i」で検索するといっぱい引っかかって追いにくい
という理由もあったんだけど、今は分かりきった動作のただのカウンタに
counterなんてムダに長い名前つける意味無いよ。
そっちよりは、意味のある変数こそ、下手な省略しないで長い名前にして欲しい。
ループ変数を検索したければ
int +i
で正規表現健作すればいいだろ。
iをカウンタに使うやつは、二重にループするときはjにするんだろ。iとjでどっちがどのインデックスなのかが分かりにくくなって、そのコードに他人が手を入れ出したり、コピペしだすと崩壊が始まる。
外から順に i, j, k, l だよ
どっちがどのインデックスか分からないのは cnt1, cnt2 でも同じだろ
それとも array[ first_index ][ second_index ] みたいなループカウンタでも使うのか？
>>93 もちろんそんなのではだめだ。counterやindexという意味はiにもあるが、それだけの意味しない。
>>92 すべてのカウンタを無条件にi, j, k にするからそーなるんだろ。
シンプルに回数で回る奴に限定しとけばそんな問題はおきない。
というか、それで問題を起こす奴にソースコードをいじらせるな。
c++とかだったら
for(int i ; i <maxSize; i++)
とかでいいとおもうけどな。
>>96 うん。だからこーゆーのでこんがらがるってどういう脳みそしてるんだろうと。
こういうやつらが集まって、わけのわからないコードが出来上がる
> c++とかだったら
> for(int i ; i <maxSize; i++)
鼻から悪魔
どのへん？
こういうことで喧嘩になっているのか？
for (int i; i < 9; i++)
{
for (int j; j < 9; j++)
{
printf("%d*%d = %d\n",i,j,i*j);
}
}
for (int grpNum; grpNum < grpMax; grpNum++)
{
for (int manNum; manNum < manMax; manNum++)
{
printf("名前は%sでデスマッチ\n",Name[grpNum][manNum]);
}
}
とりあえず、０を代入しようぜ。
ごめｗｗｗ忘れてたｗｗｗ
iとかjじゃわからなくなるぐらいデカイfor文書く奴がいるから
一律でそんな変数名はやめましょうという話になるんだよ
106 ：
仕様書無しさん：2010/03/09(火) 05:02:50
レベル低っ！
配列の全要素に同じ処理を施したいって程度の
小さなループならiやjでも十分な気がする
ループカウンタの値によってループ内の処理が違うようなら
それなりに意味のある名前があったようがいいと思う
>>104 たしかにでかい多重ループが頻発するようじゃあ
そもそも設計が悪いとは言えるわな
{ から } までは５０行くらいに収めたいよな
そうなってれば変数名がうんぬんとか低レベルな話をしなくても済むから
変数名というくくりでの議論は低レベルじゃないよ
内容を矮小化しないでね
カウンタの変数名だよ、略したくらい判るだろｋｙ
112 ：
仕様書無しさん：2010/03/11(木) 10:06:26
ロジックの意味によると思うんだが…
単純に配列に格納したい場合や初期化する場合など
大まかに把握して問題ないロジックならi,j使って問題ないけど、
ロジック内で重要な部分や複雑なことしているのであれば
変数名に明確な意味を持たせた方が後々他の人が見たときに理解しやすい
そんな感覚で書いてる
ループ制御変数が単純な配列の添え字なら、i, j 以外の名前にするのは馬鹿げている。
for (int i = 0; i < a.size; ++i) {
do something on a[i]
}
>>112 でも
for( i = 0; i < hoge_max; i++ )
と書くと i が hoge に関するカウンタである事は自明でしょ、hoge_cnt にするとくどい気もするんだけど
もっとも for ブロックが巨大ならその限りではないけどね
カウンターに i, j を使わない人は転置行列を作成するときどんな名前のカウンターを使うのか謎
nmkoiu
俺様がいくら一文字変数が好きといっても
jとlだけは使わない。
この世界はまず、
集団真理によってゴミみたいなもんが是とされてて、うざい
それでもお前らゴミにヒントを与えてやろうかね
iとjはね、 見間違う見間違わないの問題じゃない。
パッと見たときの、認識速度だよ
aとi が違う文字だってのはすぐ分かるけど
jとi だと、 aとiとの違いを見つけるよりも、10～20倍の処理時間がかかってる
勿論、人間の処理速度は高速だから、目に見えて処理落ちするような事はないけれど
i、ｊ、ｌしか変数の無いコードをかいてるより
i、o、z、n なんかで構成したコードのほうが、疲れは少ない。
こういうのに本当は、誰でも気づいてほしいものだけど、
ゴミみたいな奴に限らず、 ほとんどの人間は問題を小さくみすぎてて、
実際は降り積もって大きな障害となってるのに、対処しない
3重ループになると、i、ｊ、ｌ とか使い出す奴もいるね
まぁゴミっていうより、 周りに合わせるのが良いこと だと教えられて育っちゃった奴だろうな
i、ｊときてl、 関連性はある。、 みんな似てる。 1番2番に似ているものを、3番目にもってきた。
そうなんだね。
二重ループでi,jを使わなく日が来るとすれば
ソースコードを読めるAIを誰かが作って、
その論文を誰か偉い人発表するときだろう
「AIを作ってみて分かった、カウンタは似ている文字を使ってはいけない」などと言葉をもらす
そして次第にそれが、ようやくゴミみたいなマたちの間にも広がって、
長きにわたるi,jの風習は終わる。
別に、i,jを使ってるのが貴様等がバカだからだとは思ってない
そういう流れなんだから仕方が無いよね。
ほとんどの人間は、流れに逆らえないってことは、このことからよくわかる。
さらにゴミみたいな奴は、このレスにたいし
フォントだの、色だの、視力だの、言ってきそうだが、そんな何も考えてないようなゴミみたいなレスはかかなくていい
>>114 たしかに教科書や論文に出てくる数式をそのままパクって実装するときは
符合していた方が間違いが少なくてデバッグが楽だった。
>>115 見難いっていうのは有るね
数学式で n, m は個数を表すものとして使用されて i, j がカウンタ変数として使用されていたのがそのまま使われたと思うんだけど
手書きでは識別しやすくてもフォントに起こすと識別しにくかったって事なのかな
でも i, k, o, p の順でループ作ると j, や l は何処に行ったんだと騒ぐ奴が出そう
>>116 『ソースコードを読めるAI』が何故視認しなければならないかが疑問だな
ネタにマジレスカッコ悪い、自分で書いとくわ
アホコテにマジレスは不要
本人が「ネタ」のつもりらしいから
ちょっとまえC#で仕事をしてるときのことだけど、.netのDB関連のクラスを
ラップして、ひとまとめにしたクラスを渡されてこれを使ってねって言われた。
コネクションのクラスとか、コマンドのクラスとか、トランザクションのクラスとか
そういうのを全部ひとつのクラスにぶちこんで、
hogeDb.Connect();
hogeDb.BeginTransaction();
hogeDb.sqlSql(".....");
hogeDb.setParam(...);
hogeDb.exec();
hogeDb.commit();
hogeDb.Close();
みたいに使うのな。
で、いまPHPで仕事してたら、グラフ作成関連の細かいクラスをやっぱ全部
一つのクラスにぶち込んでるようなクラスを使えって言われた。
なんでへぼいやつって、そろいもそろってこういうのが好きなのか。
こいつイラネ
>>121 は謎すぎる
こうゆうのってのが何を意味するのか教えてくれ
何でそうなっているのかが解らないんだろう
配列回すだけならarray.forEachとかある言語がいいよね
>>121,125
一人で開発している分には不要だと思うけど
多人数でやっている場合には、機能毎にある程度まとめてラッピングした共通クラスを用意しておいた方が、
いざDB周りなどの仕様を変えたいときに楽
同じ処理やらせるにしてもPG毎に方言は出てくるし、同一のコードを異なるソースに書くのは非常に無駄だし、
後の修正面考えたら非効率でもあるので、アプリのコードはアプリのソース、共通のコードは共通のソースと分けて、
コードの一律化をはかって、担当のPGにはそういうのを意識させないために用意するね
また大概は、DB周りはクリティカルな例外を起こすのでラッピングして、そのとき例外時のエラーメッセージ、中断処理なども仕込んでおくことも多いね
そもそも、そういう共通部分はPG毎にかかせたら、絶対に例外処理なんかをかかない奴が続出するの目に見えていて、
バグの元になるのは目に見えているしな('A`)
まぁ、なんでこんなの用意するんだろうと考えられるのは、ヘボもまともなコードになるように、
こういう部分をうまく隠してもらえているせいであって、ある意味幸せなPGだと思うよｗ
あ、一人で開発でもいるな。
いらないのは、1本のプログラムだけとかそういうときだけだな
2本以上のプログラムで、機能としてくくれる部分は、機能としてまとめるべき
>>121 結局どうしたいの？どうなっていて欲しいの？どういうのが理想だと思うわけ？
131 ：
125：2010/03/12(金) 22:19:01
>>128 ＞いざDB周りなどの仕様を変えたいときに楽
元の.netのDB関連のクラスも十分抽象化されてる
＞ヘボもまともなコードになるように、
>こういう部分をうまく隠してもらえているせいであって、
標準のDB関連クラスと処理の粒度がおなじで、まったく隠してないだろ。
処理を共通化したいなら、もっと粒度の大きいレベルでやれ。
>>121みたいなクラスを使って標準クラスに比べてなんかコードの質がよくなる要素があるのか。
だいたい、DBへのコネクションとかトランザクションとかそういう下請け的な処理で、
内部で勝手にエラーメッセージだすとか、筋が悪すぎるだろ。
エラーが起きたら例外も中でつぶして、リターン値で判定させるとか考えてんの？
ほんとうにダメすぎ。
手続き型的に処理を上から下に並べるしか考えられないおっさんの発想だろ。
>>121とか。
>>132 粒度が同じでもラップしてログ（正常系を含む）を埋め込む事に意味は有るよ
ログ出力を重視しない処理系なら関係ないだろうけどね
そもそも
>>121 のグラフ作成関数なんかだと粒度も大きいと思うけどね
エラーや例外が起きたらログを出力した後に上位にリターン値で伝播するのは非常に一般的な手法だけど何故『ダメすぎ』なの？
納品したシステムが不具合を起こした場合、客先から得られる情報はシスログだけだったりする
シスログを見ただけで問題点を発見するには細かいログが必要だから下位関数がだんまりだと困るよ
>>128の日本語訳:
「だって、いっぱいクラス覚えるの面倒なんだもん」
グラフ作成のクラスライブラリも、表示エリア、プロットデータ、マーカー、座標軸とか細かく分かれてない？
おれもそんなにたくさんしらんけど、そういうタイプのを一つにまとめるなって文句言ってるんでしょ。
あと、エラーメッセージとか扱うならフレームワークみたいな役割のクラスに任せるのがいいと思う。
下請けみたいなクラスにやらせるのはどうかね。
DB 関連の処理にログを吐かせるのも無くはないと思うけど、クラスを一個にまとめちゃうのとは別の話だよね。
136 ：
仕様書無しさん：2010/03/13(土) 16:39:53
> DB 関連の処理にログを吐かせるのも無くはないと思うけど、クラスを一個にまとめちゃうのとは別の話だよね。
別な話だよ、粒度が同じでもラップする意味は有るって書いたんだけど理解できなかった？
>>121 は言語の方で用意されてる機能ならコメント一切書かないとかやりそうで怖い
>>134 アンカーミスってない？
>>121 じゃないの？
>>121 が言っているラップクラスは元のライブラリに接頭文字を付けた程度だから『いっぱいクラス～』って指摘も的を射ていないけどね
>>121 は若い人だと思う
無駄な事してるって考えるのは良い事だけど、何故そうしてるか問わないのはどうかな
明快な理由が帰って来なかったその時始めて罵倒すれば良いと思う
hogeDb.Connect();
hogeDb.setParam(...);
hogeDb.getParam(...);
hogeDb.Close();
これでおｋ
がんばってね
>>136 別な話をあたかも反論のように書いてたのか。
>>136 だから、一個にまとめなくてもラップはできるじゃん。
ラップするのと一個にまとめるのとは別の話で、一個にまとめるのを避難してるカキコに
「ラップするから一個にするのも意味がある」って反論しても意味ないだろ。
(この場合はせっかく抽象クラスが用意されてるからラップよりそれを使う方がいいか)
>>121 は一つのクラスにまとめる事を否定してるのか？粒度の低い抽象化を否定してると思っていたけど
もっとも
>>121 は問題点が明確ではないし、粒度について触れているのは
>>132 だったね
「ラップするから一個にするのも意味がある」なんて誰が何処に書いたの？
では『まとめる』事について
DB関連の例だとほとんどのメソッドは使用されるはずなので一つのクラスにまとめるデメリットは無いはずだ
グラフの例だとC++なら共通メソッドのみをスーパークラスとしグラフ種毎にサブクラスを作成するべきだけど、
サブクラスのソースが短い場合はファイル管理の都合上、複数をまとめる可能性も有るだろう
そもそもPHPに派生って概念が有るか知らないけど
実際100ステップ程度のソースが山ほど有ると管理が面倒くさい
オブジェクトサイズのデメリットが気にならない環境なら、ファイル管理効率の為に類似処理を一つのソースに
まとめる事は大きな問題では無いよ
>>144 「ひとつにぶち込んでる」→「ヘボいやつ」って書いてあるな。
>>144は始まりに過ぎなかったのだ・・・
Pre粒度...
148 ：
144：2010/03/14(日) 20:09:53
俺の読解力が話題の中心にシフトしてるなｗ
>>121 の文章から『まとめる』事を問題視してると感じなかったのは何故『まとめる』事が『ヘボい』のか理由が書かれてないからだ
ちなみに
>>125 も俺なんだが
>>121 が何を問題視してるか全くわからなかった
それに対して
>>128 がラップの有用性を説いたが、
>>132 が反論として粒度について触れた
俺は問題点を粒度と捉えて
>>133 や
>>135 を書いたんだが
>>143 がトンチンカンな反論してきたので
>>144 で答えた
まぁ経緯はどうでも良いけど
>>121 及び同調する奴は『何故まとめる事はヘボい事なのか』を書いて欲しいな
それぞれ役割ごとに分かれるクラスを一個にまとめるのやつがへぼい
↓
ログとかエラーメッセージとか出させるからラップするのは有用
↓
ラップするのと、分かれてるクラスを一個にのは別の話だろ。
(分かれたままでもラップすることはできる)
って流れなんで、
>>143は頓珍漢でもなんでもない。まっとうな指摘。
151 ：
135：2010/03/14(日) 20:59:45
とりあえず後だしじゃんけんするなとだけ言っておく
>>150 全く分かってないな
>>133 で『粒度が同じでもラップする事に意味が有る場合も有る』って書いたのは粒度について触れた
>>132 に対するレスだ
そもそもその段階では『まとめる』事が主題だという意識は無いしね
アンカーってなんの為に付けてるんだろう...
>>150 細かい経緯なんてどうでも良いんだよ
俺が知りたいのは関連処理をクラスにまとめる事を何故ヘボいと感じるかなんだよ
もしくは何のデメリットを危惧してるのかとかね
>>121 ってもう居ないの？
>>154 細かいことはいいなら、最初から頓珍漢とか言うなよ。
>>151 なんで名前が135なんだ。なんかのミスか。
159 ：
151：2010/03/14(日) 21:54:14
自己主張したけりゃコテ付けろやｗ
>>158 技術的な話じゃなくて、おれはそんなことを言ってるつもりじゃないとか、
ああいった、そういうつもりじゃないとか、そんな話ばっかりだもんな。
もう辞めた方がいいよ。
>>159 そりゃ逆だろ。なんで自己主張したいってことになってるんだ。
>>160 うん、知りたいのは
>>121 の意図だけなんだ
もし
>>121 が現場を知らないだけなら良いんだけど、我々が気付かないデメリットについて危惧してるのならば知りたいよ
関数一つをラップする事も使われないメソッドが山ほどぶら下がったクラスが存在する事も現場では何の疑問も持たないよね
それは理由も知ってるしデメリットが小さい事も知ってるからだ
それに対して不満を持つフレッシュな感覚から出た危惧点なら少しは意識すべきではないかなと思う
我々が気付けない問題点を教えて貰えれば、それが有効な考えであるか否かを論じれるし、有効であれば自分の実装にも生かせると思う
まぁ、後者にはほとんど期待してないけどね
>>162 なんのメリットもないのに、デメリットがないってだけで同じ機能のクラスを作ってたらふつーにだめでしょ。
（デメリットはあるけど）
GUIで、ウインドウクラスやら、ボタンクラスやらテキストボックスクラスやらぶち込んでまとめちゃったら
さすがにだれでもアホだって気づくはずだけど。
DBとかグラフ作成のクラスでそれをやっちゃう人がいるってのは、具体的なものをオブジェクトとして
扱うのはわかるけど、トランザクションとかコマンドみたいな状態とか抽象的なことをオブジェクトと
して認識するのに抵抗があって、そういう構成のクラスライブラリを使いにくいって感じちゃうんだろうね。
>>130 >>164 ひとつにぶちこんでるのをdisってるから、そうしないのが理想なんだろ。
それ以外に解釈のしようがあるのか。
その理想とやらがさっぱり浮かばないなぁ
なんというか、ラッピングとか上等な話じゃなくて、
>>121だと単に「ろくに仕様がわかってないんだから、こっちで用意したものを使ってくれ」ってことで用意されたものだろ
てｓｔ
>>163 『ふつーにダメ』は理由と呼べないな
先に示したログの件も有るし、抽象度（粒度）の高いメソッドを実装する予定があって派生（もしくは作成）したかも知れない
その辺の意図は作った人に聞いてみれば良い
『GUIで～ぶち込んでまとめちゃったら』ってどうやってやるの？多重継承？
例え作るのも知識が無いと苦しいよね
最後のブロックは何を言いたいか不明なのでレス不可
トランザクションもデータの一種なのでクラスを適用してる現場も有るよ
169 ：
168：2010/03/15(月) 21:17:08
×例え作るのも知識が無いと苦しいよね
○『例え』を作るにも知識が無いと苦しいよね
>>166 それなら処理の粒度をあげたのを渡さないと。
元の.netのライブラリとおんなじような粒度で、だた一個にまとめただけじゃ意味がない。
元のを使えないと、使えないようなライブラリ渡して「これで使いやすくなっただろ」とか
言ってるから、ヘボいって2chに書かれてる。
>>168 ＞『GUIで～ぶち込んでまとめちゃったら』ってどうやってやるの？多重継承？
＞例え作るのも知識が無いと苦しいよね
最初にだしたDBクラスと同じように作るってこと。
このDBクラスって筋が悪いねってたとえ。
>>121のクラスの筋の悪さがわからないあんたでも、GUIで例えたら無理なクラスだって
一発でわかったってことは、すごい適切な例だったことだな。
>最後のブロックは何を言いたいか不明なのでレス不可
>トランザクションもデータの一種なのでクラスを適用してる現場も有るよ
それはわかってるよ。
それがわからないような人だらか、適切なクラスで作られたクラスライブライブラリを
一つにまとめるなんてことをしてるんじゃないかって推測してるんじゃん。
その推測はおかしいって反論ならわかるけど、俺が言ってることと同じことを繰り返して
反論ってのはおかしいよ。
172 ：
168：2010/03/15(月) 22:34:10
>>172 反論ができないから、わざとピンぼけの受け答えをしてるのか、
まじで読めないのかわからないからやめろよ。
いつも言い訳ばっかりしてそうだなｗ上司に嫌われるタイプ
本人じゃなくてもいいから、誰か簡潔に
>>121の改善案を出せよｗ
むしろ
>>121のどこがいいと思ってるのか説明しろよ。
↓ガイシュツの説明は反論済みだから繰り返さないでね。
理由 ラップしてエラーメッセージやログ出力を組み込むんだよ
反論 こんな下請けクラスにメッセージ出させるなよ
ログは、まあ、なくなないけど、こんな不格好にひとまとめにしなくてももとの構造を
保ったままラップできるだろ
あとラップより抽象クラスつかったほうが筋がいいね
理由 おまえみたいな低レベルでもつかえるようにしてやってるんだよ
低レベルが何人もいる現場なら処理のやりかたが統一できるしな
反論 もとのクラスに比べてぜんぜん簡単になってないだろ。
ぎゃくに使い勝って悪くなってる。
処理の粒度がおなじだから、統一の役にもたたねえ
理由 はぁ、なんか
>>121を使うデメリットあるのか
反論 メリットがないのに、独自クラスとかそれ事態だがデメリットだよ
177 ：
仕様書無しさん：2010/03/15(月) 23:21:53
>>176 これに対する反論が無いようだね
理由：抽象度（粒度）の高いメソッドを実装する予定があって派生（もしくは作成）したかも知れない
抽象クラスの概念を理解していないようだけど大丈夫？
>>176 誰か書いてくれるかなと思ってずっと書かなかった理由もそろそろ書こうかな...
理由：DBアクセス関連で構築するコード群にポータビリティを持たせたい
その為には環境依存であるクラスメソッドを直接コールしないでラップクラスをコールして実装し、
環境によってラップクラスを変更する事で対応すればコードの修正量が減少する
>>177 粒度と抽象度は別の概念だけど、どっちのことだろ。
抽象クラスはもうあるから、あらたに作る意味がわからない。
あとで粒度の高いクラスを作るつもりでも、今現在、標準クラスの構造を変える意味がわからない。
>>178 ポータビリティーをもたせたいなら、標準の抽象クラスをつかったほうがいいね。
あらたに使いにくいクラスを作成する意味がない。
>>179 メソッドに対して用いるなら粒度も抽象度も同じ概念だよ
１メソッドに多くの処理を含む＝粒度が高い＝抽象度が高い
抽象クラスが既に有るって何の話？標準クラスとは？
標準クラスがライブラリで提供されているクラスを意味するならその構造を変える事はできないよね
できるのは標準クラス(?)から派生させたクラスにメンバ・メソッドを追加することで
>>121 にあるラップクラスがそれだろ
標準の抽象クラスって何？
抽象クラスで検索する事を強くお勧めする
>>180 ＞メソッドに対して用いるなら粒度も抽象度も同じ概念だよ
処理の粒度って書いてるだろ。
つられておれも「抽象度」ってかいちゃったけど、抽象度って言葉が急にでてきたな。
抽象度じゃなくて抽象クラスって言葉しか使ってなかったけど。
> できるのは標準クラス(?)から派生させたクラスにメンバ・メソッドを追加することで
>
>>121 にあるラップクラスがそれだろ
>>121は標準クラスから派生させていない。みればわかるだろ。
こんなのが標準クラスだったら、MSはおしまいだ。
＞標準の抽象クラスって何？
あるだろ。
(abstractクラスじゃなくてinterfaceだとか、そういう揚げ足とりじゃないよな。
どっちでも論旨は同じだし）
>抽象クラスが既に有るって何の話？標準クラスとは？
>標準クラスがライブラリで提供されているクラスを意味するならその構造を変える事はできないよね
>できるのは標準クラス(?)から派生させたクラスにメンバ・メソッドを追加することで
>>121 にあるラップクラスがそれだろ
っていうか、こういう認識で
>>121がいいとか言って絡んでたのかよ。
ひでえ。まったく時間の無駄だった。
まあ、時間の無駄は最初からわかってたからいいか。
まともな感覚なら
>>121がいいとか言わねえもんな。
元のクラスがどうなってて、
>>121とどう違ってるかとかも認識してなくて
わかったような口ぶりでへりくつ言ってたんだもんな。
>>181 抽象度は抽象化の度合いね、抽象クラスとは全く関係ない
>>121 が標準クラス（MSで提供してるクラス？）からの派生かどうかを
>>121 見て判断できるのか？
>>121 は単にメソッドを並べてるだけだから判断はつかないよ
もっとも派生クラスであれ定義したクラスであれたいした差は無いけどね
ポータビリティを考えると基底クラスのメソッドを直にコールする馬鹿が出ない様にあえて派生させていないかも知れないし
インターフェイスクラスの事を抽象クラスって呼ぶんだ、ふーんｗ
とにかくポータビリティの為にラップクラスをかませる事のメリットに対する反論は？
>>121 のラップクラスがどんなにクソクラスでも直に標準クラスのメソッドをコールするより良い場合は有るよ
>>182-183 罵倒だけには反論のしようが無い
ステイトレス
AOP
なんでこの板ってIDないんだろ
人数少ないから。
サロン扱いだからだよ馬鹿
法学の奴らの会話みてーだな
もっと論理的にビシッといけよ
>>184 >
>>121 は単にメソッドを並べてるだけだから判断はつかないよ
おまえの技術力がよくわかった。コテハンつけてくれ。NGするから。
>>192 派生クラスに他のクラスをメンバとして追加する事も、それを使用したメソッドを追加する事もなんら珍しく無いと思うけど？
君の言う『標準クラスの構造を変える』って事はそういう事を指すのかな？
>>121 に強いてケチをつけるなら大文字と小文字の使い分けに疑問が有るかな
もっとも実装を見れば何らかの意図を汲み取れるかも知れないけどね
>>180 > できるのは標準クラス(?)から派生させたクラスにメンバ・メソッドを追加することで
>>121 にあるラップクラスがそれだろ
↑この人は
>>121の「へぼいやつが作った関連クラスを一つのクラスにぶちこんだクラス」ってのをみて
class HogeDB : IDbConnection, IDbCommand, IDataReader…
みたいなクラスを思い浮かべて、これのどこが悪いって暴れてたんだ。
よくオブジェクト指向の入門書なんかにのってる継承と集約の説明で、車クラスなんかを例に
だして、タイヤクラスやエンジンクラスは車の部品だから、車クラスに集約してあつかうみたいな
説明があるけど、この人は、タイヤクラスやエンジンクラスを継承して車クラスを作っちゃう
センスなんだ。
>>184 >>121 が標準クラス（MSで提供してるクラス？）からの派生かどうかを
>>121 見て判断できるのか？
普通のセンスだったら、上のコードのような実装はあり得ないから、派生クラスでないって判断できるね。
>>121のコードより数段ひどい。
現場で見たら失笑もんだよ。
> インターフェイスクラスの事を抽象クラスって呼ぶんだ、ふーんｗ
この話題のばあい、抽象クラスとインターフェースと厳密に区別する意味が
ないんで、まとめて抽象クラスって言ってもまったく問題ないですね。
逆に、C++のように言語仕様上インターフェースがない言語でも、話題に
よっては、インターフェースと抽象クラス使い分けるし。
まあ、でもこの件は
>>176-179 のまとめで終わりだな。
あとは、ことばの定義どうこうみたいな、論旨とは関係ない
揚げ足とりしかでてこないだろうし。
こんなんじゃオブジェクト指向が普及しないわけだ
俺の職場にこのへんの議論を理解できる奴、一人もいないわ
>>194の説明でやっとある程度見えたけど
>>194 それは誤解だね、そもそもインターフェースクラスからの継承イメージは無く、例えばOBDCクラスからの継承をイメージしていた
class Hoge : OdbcConnection
{
private OdbcCommnad mCommnad;
private OdbcDataReader mReader:
...
みたいなのをイメージしてた
継承しないなら private OdbcConnection mConnection; がメンバに追加される事になるだけの違いだ
>>193 を読めば判ると思うけど
>>197 集約で作ってるのに、OdncConnectionだけ継承って意味がわからない。
あと、DBとロジックを分離させたかったら、具象を継承するんじゃなくて
抽象クラス（インターフェース）を使った方がいいね。
より疎結合になるよ。
クラスも独自に作って構造を変えちゃうより、標準のやつを使った方がいい。
> 継承しないなら private OdbcConnection mConnection; がメンバに追加される事になるだけの違いだ
その違いは（本質的には）大きな違いじゃないか
今の文脈だと確かにどうでもいいかもわからんが
>>198 まぁ理由が有るとすれば手抜きだね
Open() とか Close() を定義しなくても良いから
最初にそう感じたのは
>>121 で Connection 関連メソッドだけ大文字だったからなんだけどね
疎結合にする目的ってポータビリティだよね
でも実はこの目的って C# の現場で必要有るのかって気がする（移植先なんて有るのか？）
>>178 で嫌々書いたのはそんな理由なんで
>>121 のケースだと気にしなくて良いと思う
標準のクラスをラップしただけだとバカチョンクラスにならないからじゃないのかな
世の中にはSQL書けるだけの人も居るからそういう人でも使える様にって
『バカチョンクラス』も『SQL書けるだけの人』も侮辱する意図は無いよ（バカチョン自体は差別語だけど）
>>199 勿論、用途によって使い分けるべき、
>>121 を何故判別できないかの理由として書いた
>>200 > でも実はこの目的って C# の現場で必要有るのかって気がする
>（移植先なんて有るのか？）
DBを変更する場合は考えられるね。
DBも変更する可能性もOに近いときでも、具象でも抽象でも使う手間は
変わらないんで抽象をつかうほうがベター。
(DBはSQLの方言とか、どうしても吸収しきれない所もあるけど)
>
>>178 で嫌々書いたのはそんな理由なんで
>>121 のケースだと気にしな
> くて良いと思う
>>121の作りはポータビリティー理由で正当化されるって説は引っ込めることっすね。
了解です。
> 標準のクラスをラップしただけだとバカチョンクラスにならないからじゃないのかな
>>176-179のまとめでも書いたけど、
>>121の場合、処理を元のクラスと同じような
粒度でメソッドにしてるんで簡単にはなってないね。
逆に、usingとかつかえなくなって、クラスを利用するのがめんどくさくなってる。
バカちょんクラスなら、もっと思い切って簡素な使い方にしてあげないと、
かえって学習コストが高くなりそう。
C#ならこーゆーのはジャマなだけだと思うなあ
PHP(フレームワークなし)とかならまだ利用価値があるだろうけど
世の中、クラスがある言語ばかりではない。
>>201 今時 M$ のクラスに適合しないDBなんか有るのかね
具象と抽象の実装コストは抽象の方が高いよ
DB使ったビジネスアプリにそんな手間かけるのはナンセンスてのが大方の見解じゃないの
可搬性もビジネスアプリにｗｗ
簡単になってるんじゃないの
hogeDB のメソッド呼ぶだけで事が全部足りるんだから Query定義クラスがどうのとか知らなくてもSQL文法だけ知ってれば使えるよ
>>121 以上に粒度を上げると対応できないケースも出てきそうだ（Connect() と BeginTran() はまとめても良いかもしれんけど）
粒度を上げたもっとバカチョンなメソッドを用意しても良いかも知れないね
学習コストは低いだろ、引数あるメソッドが setSql() と setParam() しかないんだから、せいぜいリターン値くらいか
>>204 > 今時 M$ のクラスに適合しないDBなんか有るのかね
最初からそれは問題になってない。
具象だと適合してるDBでも変更のコストはかかるね。
> 具象と抽象の実装コストは抽象の方が高いよ
ほとんど変わらないよね。
徹底的にやろうとすると、ちょっとファクトリメソッドやらファクトリクラス
やらがいるかもしれないけど。
> 簡単になってるんじゃないの
なってないよ。
標準のクラスを使って書いた場合とコードの複雑さは変わらないか
よけい複雑になるか。
> 学習コストは低いだろ
高いね。
こからこのクラスに関わる人は全員このクラスの使い方を新たに調べなきゃならない。
標準クラスだけで作ってたら、そのクラスに関するは知識が使い回せる。
ドキュメント、資料もばっちり。
っていうか、
>>176-179でまとめてるんだから、反論するなら
繰り返すんじゃなくて、べつの視点とか、詳細にするとか
してほしいよね。
俺は詳細な突っ込みがきたら詳細に反論するけど、おんなじ突っ込みを
繰り返してるのには、おんなじ反論しかしないから、ループするだけだよ。
もうちょっとがんばって勉強してほしい。
>>205 簡単になってるとか学習コストに関しては対象者のフレームワークに関する知識が関係する
フレームワークに精通している人にとっては標準ライブラリのクラスを使用した方が楽かも知れないけど、
C#とSQLの文法だけ知ってますってレベルの人にとっては hogeDB の方が圧倒的に簡単だ
どんな現場か知らないけど派遣が入ってる現場だとプロジェクトメンバーの質はまちまちだから、
プロマネはフレームワーク未熟者にも対応できるインフラを用意しなければならない
フレームワーク精通者は『こんなクソクラス使わせるな』と不満を感じるだろうがそれだけの話だ
未熟者を切り捨てるか？未熟者レベルに合わせるか？ビジネスアプリではどっちが一般的だろう
この件に関しては水掛け論にしかならないからこれで止めるよ
> 具象と抽象の実装コストは抽象の方が高いよ
前も、なんかいろいろわかったような口ぶりでいろいろ書いてたけど
結局、標準のクラスと
>>121のクラスがどのくらい違うか知らないで
書いてたし、↑これもDBの具象クラスと抽象クラスを使って書いた場合
どのていど違うコードか把握しないで、勘で書いてるんでしょ。
（で、こういう突っ込みを入れられてから慌てて調べるとか）
こんなんにつきあわされる身になってほしい。（とか言ってみる
>>207 > C#とSQLの文法だけ知ってますってレベルの人にとっては hogeDB の方が圧倒的に簡単だ
C#の文法を知ってれば標準のクラスも簡単でしょ。
サンプル見れば一発のレベル。
hogeDBは別に標準クラスに比べて簡単じゃないよ。
標準クラスの使い方を知ってないと使えないレベル。
よけいめんどくさい。
> この件に関しては水掛け論にしかならないからこれで止めるよ
水掛け論に入る前に、hogeDBが簡単って前提が間違ってるしな。
>>206でも書いたけど、hogeDBで書いたらこんなに簡単になるとか
もっと踏み込んだ論証で反論してほしいよね。
>>121以降ここまで
>>121書き込んでないと思うんだけどどうよ？
>>121はコレ使えって言われた後メリット聞くとかデメリット説明してクラスの使用をやめる方向に持って行くよう説得するとかしてないんだろ？
121は文章読んでもわかるとおり
はいはいと従うしかない立場だろJK
>>121 が簡単簡単言われてるけど、まさか
>>121がそのまま
使われてると思ってないよな。
エラーチェックとか例外とかループとかなしで一直線にメソッドを並べてるだけとか。
これは、うろ覚えで、こんな感じですよってのを適当に打ち込んだだけだ。
こんな細かさでメソッドが作られてて、
>>121みたいな使われ方はできないだろJK
念のため。
上のほうで、connect()とbeginTran()をまとめてもいいかもとか
書いてるから、
>>121のコードがそのまま使われると思ってるっぽいな。
>>210 >>212 は
>>121 みたいだけど説得する立場には無いんだろうな、ちゅか昔の現場の話かな
>>212 戻り値チェックが無いコードはお遊びプログラムだけだし、このスレには仕事でコード書いてる人しか居ないはずだよ
引数が少なくて
>>121は使いやすいとかって発言とか、メソッドの
大文字小文字もおかしいとかってあるけど、
うろおぼえで適当にかいたから、もちろん、そんなもん適当に書いてるよ。
>>209 HogeDBが簡単かどうかが水掛け論になるって話だよ
HogeDB を用いたらこんなにステップが短くなりましたって話はしてないよ
一つ断言できるのは HogeDB を使って書いた部分は誰が書いても同じような個性の無いコードになるだろうね
これはライブラリを直に叩いても同じかもしれないけど HogeDB を使った方が確実だ
>>213 処理ごとにエラーチェックして戻り値でステータス返すのは抽象化の基本だけどね
>>216 > これはライブラリを直に叩いても同じかもしれないけど HogeDB
> を使った方が確実だ
同じでしょ。
大昔、Pascalがはやったとき、Pascalは教育用の言語でシンプルだから
誰が書いても同じコードになるとかデマが流れたけど、そんなん大嘘だったし。
こんなので無個性化は無理。標準と同程度。
> 処理ごとにエラーチェックして戻り値でステータス返すのは抽象化の
> 基本だけどね
connect()とbeginTran()がまとまる話との関連がわからない。
めんどくさくでなかったらでいいけど、詳しく。
>>216 > HogeDBが簡単かどうかが水掛け論になるって話だよ
水掛け論にはならないよ。
ほげと標準でコードを書いてみて、ならべれば一発じゃん。
やらなくても考えればわかるけどね。
同じ粒度の処理で、同じように処理したら、コードも同程度の複雑さになる。
hogeはusingとか、便利な構文が使えないから、よけい行数が増えると思われる。
＞HogeDB を用いたらこんなにステップが短くなりましたって話はしてないよ
ああ、検証不能だけど、ヘボい人たちにはきっと使いやすいはずだって話かな。
むしろヘボい人たちって、コード行数とか目に見えて減らないと、使いやすさ
を実感できないと思うよ。
>>217 >>213 がまとめてエラーチェックも何も無いコードを書くつもりかって読めたからそんなコード書く奴は居ないだろって事
>>214 でも同じ事書いたな、寝ぼけてきたかも知れん
>>218 HogeDB の仕様が無いから並べられないよ、検証方法がないから水掛け論だって
>>220 仕様は
>>121で十分でしょ。
標準クラスつくって、やるのと同じような粒度。
エラー処理は、リターン値か例外かわかんけど。
いままでずっとその前提で話が進んできたし、それもあやふやで
だめだって話なら、なにかも仮定ができないから、まず自分の「簡単だ」
って前提もすててよ。
「簡単だ」って言うくらいだから、ある程度自分でも仕様の
イメージあるんでしょ。
>>218 using 使う局面もそんなに無いと思うよ
HogeDB 以外に生成するべきオブジェクトは無いし、DBみたいな資源オブジェクトは上位で作成して下位は使いまわす事も多いからね
行儀は悪いけど効率は良い
>>221 >>207 については？
君の言うヘボの目から見て簡単かどうかは擬似サンプル並べたって判別できないでしょ
C#をほとんど知らないヘボに見てもらわないとね
粒度とかは関係なく、ヘボの目から見れば対象クラスが一つであるというだけで
「使いやすい」と思えるものじゃないかな
で、現場ではそういうヘボのために hogeDb のようなクラスが量産される
悲しいかなこれが現実
>>222 > using 使う局面もそんなに無いと思うよ
> HogeDB 以外に生成するべきオブジェクトは無いし、
usingを使いたい局面はおなじだよ。
内部に各種クラスのインスタンスを抱え込んでるんだから。
でも、それを外側からユーザーがメソッド越しに操作する必要があるから、
使いにくいって言ってる。
> 君の言うヘボの目から見て簡単かどうかは擬似
> サンプル並べたって判別できないでしょ
> C#をほとんど知らないヘボに見てもらわないとね
判断不能だけど
>>121は標準クラスに比べて簡単だって思ってるんでしょ？
簡単だってのは根拠のない自分の思い込みってこと？
>>223 ま、そうかもね。
でも、Javaとかの現場で、ヘボが大量にいるところとかでみてると、
ヘボも、すでにできているコードをコピってちょろちょろ改造とか
けっこう適応力はあるもんなんだけどね。
>>224 外側からメソッド越しに操作する必要はないだろ
HogeDB 内部で生成してエラーを検出したら例外なりエラーコードで返すんだから
もう思い込みでも何でも良いよ
ここのスレタイを思い出してくれよ
クソだと言う人と擁護する人が半々くらいで延々と100レスくらい消化してる
これは大したクソではないということ
例えてみればKOTYにFF13をエントリーさせようとしてる様なもん
徹底した議論がしたいならIDが出る板へ行った方が良いよ
ネットでコーディングルタイルの話をしていて、こういう書き方ひでーな
みたいなことを言ってると「おれは人を使ってる立場だ、
こういう書き方はヘボを使うのに有効だ」みたいなことを言って暴れる人って
よくいるんだよね。
分かってるけどあえてやってるみたいな。
で、おれも仕事だから不本意なコーディングルスタイルで書かされる
ことはしょっちゅうだけど、そのスタイルがネットでバカにされているのを
発見しても、べつにムカつきはしない。
逆に、そうそう、あれはダサいよなって同意する。
ヘボを使うためにやってるみたいなことを言って暴れる人って、絶対
仕方なくやってるとかじゃなくて、本人がヘボくて、それまでそんなこと
考えたこともなかった奴だって思ってるよ。
>>226 擁護が半々って言っても、ヘボじゃないって根拠は、ヘボい人には使いやすいって
ことで、それも本当に使いやすいかどうかは自分の思い込みのみ意外に根拠がない
ってことでしょ。
じゃ結局
>>121の書き方はヘボいってことで決着ですね。
了解です。
>>226 いま、ネットでいろいろ見てみたら、DB関連のクラスって
あんがいusingを使わないもんだね。
いぜん、使ったときには、なんかすごい使ったような気がしたんだけど。
なんであんなに使ったか思い出せない。
アンマネージリソースはちゃんと解放しないと気持ち悪くね？
俺の居る会社で作られたコードにはUsingもDisposeもなければ
Try～Finallyも無い。Catchでエラー捕まえたら、わざわざ-1とかの戻り値にして・・・
さらに
>>121のような(自称)自社製フレームワーク完備＆アドホッククエリ強制
できる限りステートレスにするからだろ。
そもそもＤＢ使うこと自体をひっくりかえされるかもしれない
そういうときにhogeDBにしといてよかったと思うんじゃないか
hogeDBは標準のDBクラスをメソッドの呼び出しに
置き換えただけなんで、hogeDBの中身をいじって対応できる
程度の変更なら標準のDBクラスでもおk。
どして？
ラッパーを修正するのと標準クラスを使ってる部分を修正するのとでは量が全然違うと思うけど
ラッパーが一箇所でしか使用されてないなら別だけどね
>>236 hogeDBはそれの中身だけ修正して、呼び出し側は修正なしでいいってこと？
標準クラスも、お作法どおり作っていれば、呼び出される側だけ修正でおk。
>>237 ラッパーの呼び出し側に修正が必要ならそれはラッパーとは呼ばないよ
標準クラスもお作法どおりってのは派生したラッパーを用意しとけばって話だろ、論点が違うよ
>>238 だから呼び出される側だけの修正でおkって言ってるじゃん。
新参の人なのか。
上のほうで発言してる人は、そこらへんはつっこんでこなかったんで
分かってるっぽかったけど。
>>239 呼び出される側ってのは具体的に何を意味してるの？
>>242 OdbcConnection とかの事？
>>243 そう。↓みたいに使う。
IDbConnection conn = new OdbcConnection();
conn.open();
IDbCommand select = conn.CreateCommand();
select.CommandText = "SELECT …";
using(IDataReader reader = select.executeReader()) {
while(reader.read()) {
Console.Writeline(reader[0]);
}
}
new OdbcConnection();の所とか接続文字列をファクトリメソッドやら
ファクトリクラスにやらせるようにすれば、ロジックとDB関連を完全に切り離せるね。
SQL Serverでも、Oracleでもすげかえられる。
インターフェースの実装を自前でやれば、DB以外でもおk。
SQLの方言は吸収できないけど、それはhogeDBおなじ。
245 ：
仕様書無しさん：2010/03/19(金) 01:56:18
>>244 > new OdbcConnection();の所とか接続文字列をファクトリメソッドやら
> ファクトリクラスにやらせるようにすれば、ロジックとDB関連を完全に切り離せるね
それの事を
>>238 で書いたんだけどね、派生クラスではなく仲立ちクラスって方法論は異なってもラッパーを噛ませるって本質は同じ
ラッパーを噛ませる事の有用性を議論してたのにラッパーの優劣の話にすり替えちゃダメだよ
>>244 みたいなコードが量産されたらdb変更に伴う修正量は非常に多いって事は認めるよね
>>245 > 話にすり替えちゃダメだよ
すり替えてないよ。
起点にファクトリメソッドをかませるってだけで、hogeDBと同じ扱い?
> みたいなコードが量産されたらdb変更に伴う修正量は非常に多いって事は認めるよね
いや?
hogeDBとかわらないんじゃない?
むしろ、hogeDBの中でOdbcConnection()とか直で使ってたら、hogeDBのほうが
修正量おおくなりそう。
非RDBに変更するとか、むちゃな変更だと、ちょっと大変そうだけど、
それはやっぱりhogeDBでも同じだし。
>>246 hogeDBも OdbcConnection() を直でコールしないって観点ではファクトリクラス/メソッドを噛ませるのと同じだろ
>>244 みたいに OdbcConnection() を直でコールしてるコードは全部直さなければならない
hogeDB 内部では OdbcConnection() を直にコールしていてるだろうけどそこだけ直せば良い
どうして変わらないなんて言えるの？
>>247 だからnew OdbcConnection()のところにファクトリメソッドかませれば、
いいって最初から書いてるじゃん。
上のコードはサンプルだから、適当に直書きしたけど。
>>248 直書きしたコードを示されたからこんなコードだと修正量が多いと書いただけ
ファクトリを噛ませたコードを示されたらこれってラッパーと同じでしょって書くよ
結局
>>238 で話は終わりさ
何この流れ・・・
>>249 そもそも
>>121は、関連クラスを全部ひとつにぶち込むのってへぼいよねって話。
で、それに対する反論で、hogeDBのようにラップしていればDBを切り替えられるって話がでた。
それに対して、
>>121みたいに不格好にひとまとめにしなくても標準の
仮想クラスをつかえば、簡単に切り替えられると反論。
一つのクラスにぶち込むことは正当化できてませんねって結論。
最初からラッパーの否定なんてテーマになってない。
勝手に相手はラッパー全否定と、レッテルはって
「はいファクトリーメソッドつかったね、ラッパーまんせー」って勝利宣言とか
ずれすぎてる。
>>249 っていうか、よく読んでなかっただけかよ。
俺は
>>121 の優劣に対して議論してるつもりは無いよ
なんらかのラッピング手法を用いて標準ライブラリ呼び出しを隠蔽する事に意味が有るって書いてるだけ
>>121 優劣（というよりクソ度）を議論するにはコードが出てこないと水掛け論にしかならないと（俺は）思ってるし
>>253 じゃ、
>>232で、hogeDBとか名前出すなよ。
途中から
>>232と変わったのか?
じゃ、すこしくらいアンカーをさかのぼって何が争点になってるか確認しろ。
ヘボいやつに限って、これは水掛け論とか宗教戦争とか言い出すな。
自分に理はないのに、どっちもどっちみたいな口ぶりで。
256 ：
253：2010/03/19(金) 03:24:01
俺
>>232 じゃないけどね
もう少し突っ込もうか？
>>244 を
IDbConnection conn = CreateConnection(); //new OdbcConnection();
conn.open();
IDbCommand select = conn.CreateCommand();
select.CommandText = "SELECT …";
using(IDataReader reader = select.executeReader()) {
while(reader.read()) {
Console.Writeline(reader[0]);
}
}
とファクトリメソッドを組み込んで修正したとしよう
これで標準の ????Connection() を切り替えるのは簡単だ
だが DB 自体が独自のストレージ機構に置き換わったって標準クラスでは対応できなくなった場合はどうなるのか？
IDbConnection, IDbCommand, IDataReader のインターフェイスを持つクラスと必要なメソッドを全て実装しなければならないし、
それらインターフェイスの関連が独自ストレージにそぐわない場合は非常に面倒な実装となる
完全なラップを考えるのならIDbConnection, IDbCommand, IDataReader も隠蔽するべきだ
それを実現するには？
hogeDB が優秀な設計かどうかは知らないが隠蔽という意味では hogeDB 以外のクラスを意識しなくても良いという点は評価できる
>>256 さんざん言ってるけど、hogeDBは、対応するクラスと同じ粒度で
メソッドに置き換えただけだから、置き換える手間は標準クラスと
大差ないよ。
そこらへんもへぼいと言ってる要因。
>>257 粒度および利便性については評価していない
標準クラスの隠蔽についてのみ評価した
ま、変更ってのが非RBDを想定してるなら、この作りのクラスで、
ライブラリの内部だけの変更ですまそうっては無理筋だわな。
>>259-260 確かにRDB操作手順を反映してるから非RDB環境になったら対応しきれない可能性は高いな
そこまで高度な隠蔽を実装するには概念的な設計が必要とされるけど現場のインフラ如きにそこまで要求するのは...
From: [562] デフォルトの名無しさん <sage>
Date: 2010/03/13(土) 09:11:34
ソフトウェア業界はたまーにこういうのが潜んでるから面倒だよね。
一見わかってるふうだからたちがわるい。
_________________________________________________________________________________
From: [563] デフォルトの名無しさん <sage>
Date: 2010/03/13(土) 09:21:22
>>562 簡単な見分け方がある
「？は駄目だ」と言う奴は99%役立たずの勘違い馬鹿
コイツの戯言は何一つ聞き入れる必要が無い
「そこは？にすると良い」と言える奴は99%有益な意見を持つ人間
この見分け方は別にソフトウェア業界に限らない
ラッパ談義になってるあたり、羨ましい環境の人が多いようで・・・
>>121が今でもここ見てるかどうか知らないが
こんなサンプルコードとセットで渡されたりしなかったか？
//stringでSQLを組み立てるのは遅いので禁止
StringBuilder sb = new sql();
sb.Append("SELECT hoge\n");
sb.Append(",hoge1\n");
sb.Append(",hoge2\n");
sb.Append("FROM foo");
string strSql = sb.ToString();
hogeDb.sqlSql(strSql);
>>263 したり顔でそんなサンプルコードよこされたら確かにいやになるな
何とかは駄目だというヤツは99%駄目だ。
そいつのいう事は何一つ聞き入れる必要はない!
↑こいつクレタ人っぽくね?
複雑な SQL を発行させたくない、という理由でラッパを通してしか DB アクセス禁止になり、
俺にそのラッパ製作のお鉢が回って来たことがある。
利用者は同じフロアーの近所に座っている人たちなので気楽に考えていたら、
テーブル名引数にサブケリーを埋め込んで呼び出された。
267 ：
263：2010/03/19(金) 12:51:39
>>264 実際にあった話。具体的には俺の勤め先。
そして、これをヤバイと感じられる同僚が居ないという冷たい現実。
ちょうど今目の前に良いコードがあるな。
hogeTextBox.InputChar = "1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
正規表現の使えない自社製入力文字制限。
なお、コーディング規約では、わかりにくいので正規表現は使用禁止とされている。
>>266 いっそのことストアド以外のSQL禁止しちまえｗ
ストアドなんか使ったら整合性が取れなくなるって言われるのに100ペリカ
ストアドは時代遅れ
272 ：
仕様書無しさん：2010/03/19(金) 19:47:40
ここまでスレタイに沿った書込みがない件
>>26 と比べてみろよ
横綱と十両くらいの差が有るぞ
横綱と十両、どう違うの？どっちも外人でしょ？
えっ
>>263 javaの仕事をしたとき、プロジェクトに入る前に意見があったらくださいって、
コーディングルールがくばられた。
文字列の連結はパフォーマンス悪いから+じゃなくて、StringBuffer()を使えっ
てのがあったんで、javaのドキュメントみせて、+はStringBuffer()に変換さ
れますよって言ったけど、StringBuffer()使う慣習だからって却下された。
でも、さすがにみんな、常にStringBuffer()を使うのはめんどくさかった
らしくて、文字列の連結はconcat()使ってんのな。
おれは最初は規則どおりStringBuffer()使ってたけど、べつに周囲も
コーディングルールで注意されてないみたいなんで、途中からconcat()
使うようになった。
素直に+使わせてたよりパフォーマンス悪くなってるじゃん。
おれもいまいち相撲の階級がわからない。
281 ：
仕様書無しさん：2010/03/20(土) 01:26:37
さすがにそろそろStringBuilderが常識になって欲しい。
>>281 新規の案件なのにjavaの1.4だった。
strutsも古いバージョンで、ネットでいろいろ検索してたら、
「未だに検索してくる人がいるってことは、まだこのバージョンが
使われているってことですね」みたいなことが書いてあるページが
ヒットして悲しかった。
>>279 素直にStringBuffer.append() を使えばパフォーマンスは上がってたんじゃないの？
String+ がStringBuffer に変換されるってのはワークのStringBufferを作成して結合処理をした結果を StringBuffer.ToString() で
書き戻すって話じゃなかったっけ？
効率の悪さでは一番だよ
String.concat() はワークを作らないから String+ よりパフォーマンスは上がってるんじゃないの？
String は操作を行なうごとにメモリの確保を行なうけど StringBufferr はサイズがはみ出ない場合はメモリ確保を行なわないはず
よって StringBuffer.append() の方が String.concat() よりも速いんじゃないのかな（未確認だし状況によると思うので自信無し）
君の現場で配られたルールは間違っていないと思うけどね
284 ：
283：2010/03/20(土) 05:05:04
君の現場で配られたルールは間違っていないと思うけどね
の続きは有るな
String+みたいな便利な書き方を禁止してまでnsecオーダーのパフォーマンスを優先するプロジェクトなのかって思うから縛りすぎ
. ゴクリ・・・ |
|
∩＿＿＿∩ |
| ノ _, ,_ ヽ |
/ ● ● |
>>283 | | ( _●_) ミ
彡､∪ |∪| ノ
/ ヽノ⊂入
/ ∪ （ ）
/ /
>>29 >その割に、デバッグビルド（最適化オプションなしか緩め）で客先に納品されたり、
>なかなか間抜けなことが多い
そういうプログラムって、最適化ビルドすると動かない事もあったりするから
さらに困るｗ
>>283 こういう文章をよめないタイプは突っ込むとめんどくさそう。
ループとかで結合するときは、StringBuilderで、
結合する回数が固定のときには+って定石だろ。
議論するレベルの話じゃない。
>>289 そうはいっても
>>279 の現場とか、
>>283 とか、まるで中身を理解してないで
金科玉条のごとく StringBuilder(Buffer) を信奉（ていうか "+" を敵視）
している人・現場は残念ながら山ほどあるからね・・・
>>290 1.4の頃、+とSBでベンチマークとってみたけど有意な差はなかった。
（雑誌に差はないと書いてあったので確認したら本当に無かった。）
ごちゃごちゃと屁理屈を並べる前に、走らせて確認しろよ。
+使っても、コンパイラが勝手にStringBuilder使うように最適化してくれる。
だったら、それぞれの状況で、読みやすく保守しやすいほうを選択すればいい。
それすら知らずにStringBuilder使えとばかり言うアフォは業界から足を洗ったほうがいい。
ぬるぽをプログラム開始早々freeしているソースに出会ってしまったわけだが。
とりあえずｶﾞｯしとけ
>int main(void) {
> char * p = NULL;
> free(p);
> /* ... */
>}
こんなソースがあったら、問題はないけどイヤになるかもしれん
ｶﾞｯしないとねえ
（ ・∀・） | | ｶﾞｯ
と ） | |
Ｙ /ノ 人
/ ） < >__Λ∩
＿/し' ／／. Ｖ｀Д´）/ ←
>>296 （＿フ彡 /
//15kai kurikaesu
for(j=0;j<15;j++)
{
・・・・
//表じ更新
}
これ書いたの、日本人デスカ
変換結果ほとんど見ないでコメント書いただけだろう。
これでスレタイ通りのことを思ったなら気が短すぎるｗｗｗ
誤変換で辞めたくなるとかどんだけ…
そういう細かいところが配慮出来ないヤツのコードはバグってるという定説を信仰されてるかたなのでは
誤変換より「15kai kurikaesu」のほうが衝撃的だな。
短気には同意。新人ぐらいならやりそうだ。
その2つのコメントが同時にあるというのがよくわからんね
書いたのは違う人とか
批判しているお前らはちゃんと TestCase 書いているのか？
すぐに動かなくなるきれいなコードよりも、汚くても動くコードの方がいい。
>>305 >すぐに動かなくなるきれいなコードよりも、汚くても動くコードの方がいい。
汚くて動いてるけど、たまーに動かなくなるコードならたくさん・・・orz
307 ：
仕様書無しさん：2010/04/26(月) 22:25:42
JSPにDBアクセスのコードがそこら中に書いてあった。
保守性ゼロ。
動いてるのが不思議なくらい。
いっぺんしね。
308 ：
仕様書無しさん：2010/04/29(木) 03:28:01
>>265 ＞265 ：仕様書無しさん：2010/03/19(金) 12:17:08
＞何とかは駄目だというヤツは99%駄目だ。
＞そいつのいう事は何一つ聞き入れる必要はない!
＞
＞↑こいつクレタ人っぽくね?
安心しろ、そいつは残りの1%だ。
ソースの一行一行にコメントがあった時は本当に辞めたくなった。
しかもそのコメントが「ここで1を加算」とか「FALSEの場合は関数を抜ける」とかばかり。
スパゲッテーよりましだろ
一定時間おいてから自分で読み直すと、良し悪しが時間できるんだけれど
自分の書いたコードなんて、読みたくないものの筆頭だしなあ
うちじゃ何かコードを書いたり修正があったりするたびに「関数や変数を組み込みたい」という申請をさせられる。
そして関数名・変数名には、……そのとき発行された管理番号を使うんだ。
その結果コードは↓みたい暗号になる。
int F_PJ0001_XXX0000( ... )
{
……省略……
return V_PJ0001_A0001[ V_PJ0001_N0001 + V_PJ0001_N0001 ];
}
もし本当の関数名・変数名を知りたいならば EXCEL で書かれた [管理番号と変数の関連づけ一覧] を調べる必要がある。
誰が考えたんだ、こんなクソ制度……
おっとミスった。
> return V_PJ0001_A0001[ V_PJ0001_N0001 + V_PJ0001_N0001 ];
は
return V_PJ0001_A0001[ V_PJ0001_N0001 + V_PJ0001_N0002 ];
と書くつもりだった。
なんで変数名付け替えスクリプトって定番ツールになっていないんだろうな・・・？
心に余裕のあるうちなら軽く作成できる気がしなくもないのだが
人間アセンブラか
>>312 良く会社生き残っていられるな。かなりヤバくね？
過去のデータが残らないの
過去のデータを表示したいなら
一番古い方から全部引く作業を行ってる
>>310 コメントの話をしてんのに”スパゲッテー”てw
>>312 なんか似たようなレス前に見たぞ。
同じ会社かそれともそういう会社が他にもあるのか。。
発行された番号を使うって事は、その申請してからじゃないと新しい変数使えないんだよな？
とにかく面倒くさそう。
>>322 けっこうデカイ会社だから同じ会社か同じグループ会社の人なのかも。
こんなアホなこと他にも（独自に）やってる所があるとは思いたくないなぁ。
>>312 大型汎用機の世界だな。
大昔、識別名の桁数制限が５桁とか７桁だった時代に大量の変数を使用するには
連番でつけて台帳管理するしか方法がなかった。
# 形骸だけが残ったんだね。
A3の紙いっぱいにフローチャート書いた時代か
ローカル変数っていうものがないもので巨大なプロジェクトをやるとそうならざるを得ない
N-BASICとか変数は2桁だったよな
if (v == null && v.equals("")) {
return;
}
がいたるところにある
「||」になっているところもあるんだが、同じように直さないのかな
( ´∀`)＜ぬるぽ
333 ：
仕様書無しさん：2010/05/05(水) 03:04:51
>>331 > if (v == null && v.equals("")) {
> return;
}
* vがnullのときは条件式の右辺でぬるぽ発生
* vが非nullのときは条件式の左辺が偽になり、&&演算が短絡で偽になる
のでこのreturnには絶対に到達しないわけで、コンパイラに未到達文
があるぞと怒られる気がしたが、試してみたら言われなかった。
||なら問題なかったけど、
そもそも""と等しいかチェックするあたりイケてない。
同じコードを繰り返すのもイケてない。メソッドにするべき。
どうでもいいけど、Eclipse使っててメソッド抽出しらないとか
現場がそんなんばっかりなんだが、全員殺したいよう。
教えてあげればいいじゃん
教えてないとでも思ったか？
毎度毎度教えるのはさすがに疲れるよ。
チーム内にメール1回出せばいいだけだよな
現場ごとに空気読まずにしろと？
スレタイ通りのこと思ってんなら出来るだろ？
やめたいやめたいばっかり言ってるだけなのか？
いや、もう辞めた。
341 ：
仕様書無しさん：2010/05/20(木) 03:12:12
>>71 【赤松】外遊先でゴルフ
ttp://tsushima.2ch.net/test/read.cgi/news/1274289979/ > 赤松大臣は口蹄疫の発症が確認された後の４月３０日から５月８日まで、キューバやメキシコなどに出張しました。
> 複数の民主党幹部が１９日夜に赤松大臣のこの時期の長期出張について「問題だ」との考えを示したうえで
> 外遊中に海外でゴルフをしていたことを明らかにしました。
> （20日01:39）
> 8 名前： アロサ(愛知県)[] 投稿日：2010/05/20(木) 02:28:53.82 ID:eiWoTSxR
> アルバトロス
> 11 名前： ホテイウオ(東京都)[] 投稿日：2010/05/20(木) 02:29:39.13 ID:XA1lo79p
>
>>8 > 阿呆鳥だっけか
>>332 だれもガッしてなかった件
すごい長い間放置されていたな
343 ：
仕様書無しさん：2010/05/22(土) 22:08:58
344 ：
342：2010/05/22(土) 22:49:15
俺かよ！
-- project.resource.txt
SOME_VALUE = 入力が間違っています。
-- app.config
<appSettings>
<add key="ProjectResource" value="project" />
</appSettings>
--とあるクラス
const PROJECT_RESOURCE = "ProjectResource";
const SOME_VALUE = "SOME_VALUE"
public void hoge(){
Resource resource = ResourceFactory.get(ConfigurationManager.AppSettings(PROJECT_RESOURCE));
string fuga = resource.getString(SOME_VALUE);
}
こんなの出来たんだけど（泣
346 ：
ぬる：2010/05/24(月) 12:55:21
えぇい
347 ：
仕様書無しさん：2010/06/01(火) 07:09:56
1 ：名無しさん＠どっと混む：2009/12/14(月) 20:45:15 ID:unnBMLw10
高根社長のＳＭ趣味サイトＭａｓｋＲと
副業のＳＭクラブ銀座プレジス・動画配信専門リアルミストレスばかり語られるが
高根社長の本業コムラッドについても語ろう
銀座プレジス
http://www.prezis.jp/top.htm ＭａｓｋＲ
http://maskr.com/ プレジスを語ろう
http://set.bbspink.com/test/read.cgi/sm/1246009466/ 動画配信専門リアルミストレスってどうよ？
http://set.bbspink.com/test/read.cgi/sm/1249183350/ 9 ：名無しさん＠どっと混む：2010/01/03(日) 18:27:00 ID:RSEbBiG0O
高値はもう大麻やめたの？
10 ：名無しさん＠どっと混む：2010/01/04(月) 05:15:29 ID:A3l1qdv+O
タカネ社長ってどうやってばれないように脱税してんだろ？
億単位で脱税して億ション暮らしなんて凄いよな
監査役の奥さんもグルなのか？
12 ：名無しさん＠どっと混む：2010/01/05(火) 01:47:06 ID:KAHwqMrBO
株式会社Comrade株式会社コムラッド株式会社Comrade株式会社コムラッド株式会社Comrade株式会社コムラッド株式会社Comrade株式会社コムラッド株式会社Comrade
株式会社Comrade株式会社コムラッド株式会社Comrade株式会社コムラッド株式会社Comrade株式会社コムラッド株式会社Comrade株式会社コムラッド株式会社Comrade
13 ：名無しさん＠どっと混む：2010/01/05(火) 01:47:47 ID:KAHwqMrBO
高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉
348 ：
仕様書無しさん：2010/06/01(火) 07:10:47
18 ：名無しさん＠どっと混む：2010/01/07(木) 09:26:06 ID:5NL2jyJpO
高根はMASKRでレイプ仲間募集するのやめたんだね
mixiで募集中か
21 ：名無しさん＠どっと混む：2010/01/10(日) 19:36:45 ID:FdRwgXUTO
風俗店やってるってことは高根社長は暴力団と繋がってるんだね
どこの組にいくらみかじめ料払ってるんだかw
23 ：名無しさん＠どっと混む：2010/01/23(土) 03:43:12 ID:Pdcv8aq0O
ﾀｶﾈ社長未成年に酒飲ませてﾚｲﾌﾟ
24 ：名無しさん＠どっと混む：2010/01/29(金) 18:16:06 ID:zMwtdkIsO
高根社長のレイプ趣味は病気だから治らない
25 ：名無しさん＠どっと混む：2010/02/01(月) 01:39:32 ID:uaH5mo2nO
前科者
26 ：名無しさん＠どっと混む：2010/02/09(火) 00:52:46 ID:JwGmN2cG0
>>25 容疑はレイプ？買春？管理売春？公然猥褻？薬物？脱税？詐欺？傷害？
28 ：名無しさん＠どっと混む：2010/02/14(日) 22:56:30 ID:lykq8x1VO
どこかのスレで人を死に追いやったと書いてあった
33 ：名無しさん＠どっと混む：2010/03/04(木) 12:49:19 ID:J8YxaRGO0
金がないって脱税がばれて追徴課税でも来たか？
せっかく脱税の隠れ蓑にプレジス営業してるのに残念だったなｗ
38 ：名無しさん＠どっと混む：2010/03/12(金) 21:09:53 ID:L0W4+sivO
首吊り首絞めプレイ大好き高根英哉
349 ：
仕様書無しさん：2010/06/01(火) 07:11:34
53 ：名無しさん＠どっと混む：2010/05/17(月) 13:14:06 ID:E/7OZVtz0
>>18 高根英哉blogでレイプ仲間募集中
私とともにマスクの女どもを弄ぶ仲間を募集する
急に思いついたら連絡をして、集まれるような仲間だ
だから、複数名募集するし、いついつという日時があるわけでもない
条件は以下のとおりだ
・SMを実践している、または興味がある
・マスクを用意できる
・都内でイベント参加できる
・イベント内容およびこの仲間を通じて知りえた情報を口外しない
・成人男子である
・携帯電話および携帯メールアドレスを私に公開できる
・酒が好きである
希望者は私宛にメールを送ってほしい
全員が参加できるわけでもないので、こちらの選択に任せてもらう
なるべく想いを書いてもらうほうがわかりやすいし
経験や顔写真も歓迎。
ｒ2007@maskr.com
maskr_2008@yahoo.co.jp
hide@comrade.co.jp
>>339 それ、結局捏造だったわけだが、
お前はデマを流した責任をどう取る気だ？
351 ：
◆t11zgaSFtY ：2010/06/12(土) 20:10:33
>>331 言語によって、
0、Null、Emptyの扱いは違う
おそらくそれは、同じソースコードで複数の処理系でも動くことを考慮したソースコードなわけねえから死ねカス
真意を理解しろよ
そういう問題じゃねえんだよ
お前は俺のやりたかったことを理解しろよ
>>331のソースコードをみたら100人中99.9人が「死ねｗ」って思う
それを弁護してやろうとしたけど無理だった死ねカス
つうか俺には
「同じソースコードで複数の言語処理系でも動くことを考慮したソースコード」
を生成するという構想がある
はいはい支離滅裂 しちめつれｒつ
ねむいだよカス
>>353 誰が見ても、&&と||の間違いとはわかるけどね。
""でもそれ以下のコードが正常に動作するので、気がつかないんじゃないか？
不要なチェックだったってことだな
>>354 もしこれが正しいとしても
if (v == null || v.equals("")) {
return;
}
NullかEmptyのチェックなら
Rubyのblank?のようなメソッドを作るべきだし、
それを作っていない時点で書いた奴は素人
だから、その部分だけは記述冗長してるけど && で正しい可能性もあるから
結論をいえば
NullとEmptyがイコールになる言語かどうかで見解が違ってくる
イコールにならない言語で、勝手に＆＆を｜｜にしたら
>>331の条件は逆になってしまう
たしかに、そういう無意味なチェックって見過ごされがちだよな。
一度メンテナンス期に入っちゃったら、動作に問題ない部分は見ないことが多いから。
if (x >= 5 || x <= 10) {
// 数十行のコードブロック
}
else {
// ほとんど同じ内容のコードブロック
}
みたいなの。
>356
&&はありえない
誰も言わないから不安になってきたんだが、&&だとNullReferenceExceptionが発生しないか？
>>360 もちろん発生する。
再現性を良くするために、
敢えて確実に発生させているのだろう。
れっつぽじてぃぶしんきんぐ
assert代わりなんじゃないの？
>356
> && で正しい可能性もあるから
ねえよ
バカなの？
!$omp parallel
do i=1, imax
>>365 "ｶﾞｯ"
end do
!$omp end parallel
「おかしい・・・どうして速くならないんだろう・・・」
367 ：
仕様書無しさん：2010/06/22(火) 11:33:46
# use strict;はエラーで止まるから禁止。
ウソみたいだろ・・・間接的だが人命に繋がるシステムなんだぜこれ
コメントアウトしてるつもり？
370 ：
仕様書無しさん：2010/07/07(水) 17:48:26
条件分岐があるとひたすらロジックが枝葉のように広がり
同じコードが書いてあるソース
if (条件1)
if (条件2)
if (条件3)
処理A
else
処理B
else
処理B
else
処理B
みたいなのか
Fortranではそれが普通
だからFortranは速いのかぁ
COBOLでもそんな書き方するよ
ええい同じコードを2度以上書くな
COBOL案件の手伝いに行った時、if文の中でperform呼んだら怒られた。
構造化してはいけないらしい。
あとGAME屋は、わざとループを展開して書くよね。
人間がやらんでもコンパイラがやるだろ
java StrutsのActionメソッドで2000行。
SQLを発行するのにCreateStatementだったりPreparedStatementだったり、独自拡張だったり
それで動いてるから困ったわｗｗｗ
解読するのに3日近くかかったｗｗｗｗ
>>331 これってべたに書くものなのか？
StringUtils.isEmpty(v) とか使うものだと個人的に思ってたけど、上司は使ってなかったな
もちろん存在は知ってたけど
boolean bool = true; if(bool == true){}
も普通かな？
個人的には
boolean bool = true; if(bool){}
こう書くけど
>>378 Struts作ってる人ってガチで馬鹿だと思う
なにあのモジュール群、なにあのドキュメントの不親切さ
そんなだからへんてこな実装でよく分からないものが動いてるって状況が生まれる
Strutsってフレームワークにしては緩いし、拡張もしやすいから使い勝手がいいかも知れないが
不必要なモジュールが多数あり用途が定まらない。
結果あれこれやっているうちにソースが汚くなって行くって感じがする。
V+MCになってくるよね。
個人的にはドキュメントやサンプル等がネットに落ちてるから実装しやすいけどね。
因みに1.x系ね
Struts２．Xは少ししか触ったことがないがMVCを1系よりも分けやすくなっているため
多少よさげなきがする。
確かに書きやすさという意味では多少マシにはなってるけど
モジュール群のカオス具合は変わらんな
383 ：
仕様書無しさん：2010/07/19(月) 22:22:10
VMwareをインストールしたらプログラムの挙動がおかしくなった。
ソースを調べてみたらこんなコードが！
ipconfigの出力結果を行と列を決め打ちして切り取ってる！
こんなコードがたくさん散りばめられているんだが・・・
system("ipconfig >ipconfig.txt");
fp = fopen("ipconfig.txt", "r");
for (i = 0; i < 8; i++) {
fgets(buf, 256, fp);
}
for (j = 44; buf[j] != '\n' && buf[j] != '\0'; j++) {
ipaddress[44 - j] = buf[j];
}
fclose(fp);
system("del ipconfig.txt");
384 ：
仕様書無しさん：2010/07/19(月) 22:24:33
>>383だけど訂正
× ipaddress[44 - j] = buf[j];
○ ipaddress[j - 44] = buf[j];
でもFTPクライアントとかオークション管理ソフトとかって、大体決め打ちじゃないの？
387 ：
仕様書無しさん：2010/07/20(火) 00:29:58
>>376 >COBOL案件の手伝いに行った時、if文の中でperform呼んだら怒られた。
>構造化してはいけないらしい。
それで怒られるのは変だと思うけど
if文の中でperformを呼ぶことを構造化と言うのかというと
それもまた違うのでは
>>387 同じ処理を行うとこを１箇所にまとめたんだけど？
（分岐数10程度のif文だが、大半が同じ処理）
はっきりした見解をお持ちのようなので、
COBOLのモジュール内で可能な「構造化」について、是非とも御意見を頂きたい。
（できればサンプルソース付で）
>>383 本当に客先環境が変わらない保証があれば、そういうのもアリなんだけどね。
下手すりゃWindowsUpdate当てただけで変わる可能性があるのはちょっとなあｗ
>>383 DHCPから固定IPに変えただけで動かなくなりますな……
でも何でipconfigを使うんだ？
素直にgethostbynameとか呼び出した方が簡単なのに。
とりあえずコピペで何種類か作れるからなねえかな
忙しいが口癖のPM
ふぉｒ（印ｔ胃＝０；胃＜＝下賃ｓｔ「ん」；＋＋い）｛
印ｔ いんｓってｍｐ＝０；
ｗひぇ（！いんｓｔｆぁｇ）｛
いんｓてｍｐ＝すんまいん。ｍ＿；
画面見ろ
すんまいんがすんませんに見えた
変換ボタンもちゃんと押してるのかな
スペースキー押してるだろ
>>392 こうか？
for(int i=0; i<=getinst[n]; ++i){
int insttemp=0;
while(!instflag){
instemp=sunmain.m_;
つーか、PMまで動因してそんなの打ってるPJは、１０年前ならともかく、
現代においてはPJ終わってるだろう。
書けるから作業してるか、書けないから管理してるか
PMってこの二種類しか見たことないわ
PMは、自分が打たなければ間に合わない場面に出くわした場合、
自分で打つよりも、なぜ自分が打たなければ間に合わなくなっているかの、
根本原因に対する対策を考えるべきである。
しかもその対策は、遅くなればなるほど腹水盆に還らず度が増すので、
まず打ってから対策などもありえないはずなのである。
＞腹水
そんなものが盆に返っても困るw
あなたのご先祖は「腹水」なんですか？
どこの盆でだよ
四国か？ｗ
こっちでは先月帰ってきました
VC++のreleaseとdegubで動作が異なるソースがあった
原因：
char *hoge(…){
char ret[100];
（省略）
return ret;
}
結構使われてる関数だから修正もできない…
どう動作が異なっているのかわからんが、問題があるとしたら
hogeを呼び出してるほうに問題が出るんじゃないのか？
hogeはスタック範囲内のアドレスを返すだけだろ
debugだときちんとアドレスが返って、releaseだとNULLが返るのか？
staticにしちゃえよ
こんないい加減な戻り値で仕様にしちまってる時点で終わりだろう。
こんなんじゃ似たようなことやってるとこ他にもありそうだな。
全部調べてサッサと修正して回るべきだな。
膿を出すなら早いうちの方が、結果的には被害が少ない。
素早く終わってくれるアプリなんだったらmalloc書くだけで万事解決しそうだな。
あー、こいつもfreeしやがらん。ぐらいで済みそう。
>>406 デバッグ情報を積むかどうかでスタックフレームのレイアウトがかわるんだろ。
>>411 スタックフレームのレイアウトが変わっても、指しているポインタは同じはず。
うまく動かないのは、使う前に使われちまってるんだろうな。
どちらにしても、これを放置するような会社はつぶれたほうが世のため。
グローバル最適化とかリーフ省略とか
スタックフィルとか、原因はいろいろ
ありそう。
>>413 auto変数は、ブロックスコープ。
ブロック外で参照してはいけない。
>>413 ローカル変数は、そのスコープから外に出ると消えてしまう。
関数の復帰値として、ローカル変数で定義した配列の先頭アドレスを返した場合、
復帰した瞬間に、配列本体が消えてしまう。
戻り先で、配列を参照しようとしても、配列の内容は保証されない。（不定になる）
>>413 おい……
ローカル変数は関数抜けたらなくなるだろ？
だから、char ret[]は、関数を抜けたら意味がなくなるのに、戻値として返してるとよろしくないじゃないか。
strcpyみたいに引数にもらうとかしないといかん。
418 ：
413：2010/08/12(木) 23:35:35
みなさん、即レスありがとう。
で、わかんないのは、releaseとdebugで何が違ったのだろうと・・・
コンパイルした結果が違ったって意味ではなかったのですかね？
たまたま動作が違ったってことなら了解です。
リリースビルドしたら、コンパイラが適当に端折ったり、メモリを効率的に使うようになったりする。
>>418 大抵の場合、デバッグモードでは動きます。
リリースモードにすると、スタック上の変数領域に獲得に余裕がなくなるので、
デバッグモードでは『運良く保存されていた』データが、リリースモードでは破壊される事が多々あり……
>>418 デバッグモードで動作したのは全くの偶然。
コンパイラのバージョンを変えたり、プログラムをちょっと書き換えただけでも動かなくなる可能性がある。
デバッグモードのときはフフフで埋められるからな。
Java や C# ばかりを相手にしてるとたまに C, C++ をさわったときに
>>405 のパターンではまりそうで怖い
>>405 やるとしてもこうだろうか。
使い終わったらどっかでfreeしてくれ。
char *hoge(…){
#if 1
char *ret:
ret = malloc(99+1);
if ( ret != null ) {
#else
char ret[100];
#endif
（省略）
#if 1
}
#endif
return ret;
}
mallocとfreeが直感的に結びついてないコードは高い確率でリークする
mallocした領域を返す関数には、名前に _alloc という接尾辞を付ける、という
かったるそうなコーディングルールを導入してはどうだろう。
char* hoge_alloc() { ... }
#define hoge_free(p) free(p)
仕組みが分からないまま「動けばOK」で、仕様としてOKにしちゃうってこと自体が、大きな問題点だと思う。
Java/C#のメリット->GC
Java/C#厨->自分でメモリ管理もできないDQN
C/C++厨の実態->メモリリークどころか解放したメモリを参照しても動けばOK
メモリー管理を全部手動でやれば最高のパフォーマンスが得られる
という理由にてC++では只管メモリーの手動管理に拘ってきたわけだが…
得意とする言語に関係なく、世の中は自分でメモリー管理できないDQNばかりである。
答えは出てるんだよ。C＃でそういう結論に達したということだろ。
でもGCって意外なときに走ったりするからウザい。
一回VB.netで機械と話すときに、結構タイミングがシビアな部分があって再現ししづらくて悩んだ。
Win32のリソース(Form)とかはdisposeしないとうまく開放されないとかあったし。
結局disposeいるんじゃん。って思った。当たり前だけどな。
Cで書いたほうが万倍シンプル。
>>425 ヘ？API側で確保するから、caller側で解放してね、ってよくあるパターンだろ…
よくあるけど、駄目なほうのパターンだよ
まさにVB世代の徒花。
>>430 VBの場合、動的に資源を取得しては駄目。
プログラムの最初で全資源を確保し、それを使い回せ。
（要するに処理のメイン部分では解放しない。生成しない。）
VBで実装するような処理で何万件も処理するようなケースは滅多に無いので、これで十分。
>>435 まじで？？
俺、普通にメモリの生成・解放やってるよ。
Function Foo(...) as Boolean
Dim ret as Boolean
Dim objHoge as clsHoge
Set objHoge = New clsHoge
...
Set objHoge = Nothing
Foo = ret
End Function
みたいな感じでさ。
Nothing代入したら本当にメモリが解放されるかはしらんがな！
>>425 一番いいのは呼び側でメモリ確保なんだが、
>>424の戻り値をみた感じそれをやると結構な工数がかかりそう。
>>435 GCがないから解放されないと思っているのかな？
参照カウント方式でやってくれる。循環参照しているのでなければ、GCよりもいいことが多い。
VBはデータベースで多用されているので、巨大なデータを扱うことが多い。
というか、VBで最初に全資源を確保ってどうやってやるんだ。
巨大バッファを確保して、自前でメモリ管理！
リファレンスカウントはGCじゃないと思ってる人がGCを語ってるスレはここですか？
>>438 画面フォームの生成→破壊を繰り返すと、何故かメモリが減る現象が発生した。
原因は不明。
画面フォーム類を起動時点ですべて生成し、非表示にしておき(WIN32API利用)、使用する時に表示状態を切り替えるようにしたらリークしなくなった。
大き目のワーク領域はWIN32APIでとる。
ＤＢはOO4Oを使用。
ややこしい処理はストアドにするか、サーバ側バッチ処理にする。（極力VBでの処理を減らす）
>>440 リファレンスカウンティングはGCの実装に使われることがあるアルゴリズムのひとつ。
COMがリファレンスカウントでGCを実行しているわけではない。
>>441 VBのランタイムがオブジェクトにアロケートしたメモリ領域を解放することと、
OSがVBのランタイムにアロケートしたメモリ領域を解放することは
別物だから注意するように。
つか、．ＮＥＴ自体がメモリーをリークしている（つまりバグ）だと俺は思っているｗ
↑自分で馬鹿を告白
おまえらVB.net馬鹿にするけどな、未だに6が現役で使われてるシステムあるんだぞ。
まだマシだ。
あと俺も何故か、VB.netでCIntとか入ってるDLLを参照すると、かなりリークしたことがある。
MSに言うと、それは参照するな、と。
馬鹿かと思ったわ。
おまいら、
「ＭＳ製品上で動作＝ある程度ちゃんと動かないのは許容範囲」
というノリがバックボーンにあるってのは、
ありがたいＭＳの親心なんだぜｗ
ＭＳ製品が、ちゃんと動いてると仮定するなら、
「ちゃんと動かないのは全部アプリのせい」
というクライアントの意識の下で仕事することになる。
精神的に全然違うぞｗｗ
アホ言うな
アプリのバグかMS提供のDLLのバグか特定するほうの身にもなれ
>>447 MSがどうだろうが、どのみちクライアントは
「ちゃんと動かないのは全部アプリのせい」
と言ってきて瑕疵責任で修正させるついでに
新しい仕様までネジ込んでくる罠。
>>446 > VB.netでCIntとか入ってるDLLを参照すると
よくわからんなあ。参照しないことはできるのか？
それとも、別のCIntか？
>>451 プロジェクトの参照設定からはずせるよ。
VisualBasic.dllかなんか。
Integer.parse使えってさ。
>>405 static char ret[100];
に修正すると期待する動作にならないって話なら重症だな
static？char？ret[100];
にするなら当然
static char *hoge(…){
だろ。
これでつまり大幅な仕様変更だ。
マルチスレッドまで考慮してるなら、仕様変更は没決定。
おいおい、半角スペースを変なコードで書くなよ。
コピペしたら変になっちまったぞい。
>>454 関数内の変数のstatic コンパイル単位(≒ファイル)レベルの変数／関数のstatic 説明してみようか?
>>457 わかりにくい文章だなｗ
でもまあ、454が説明できるわけないじゃんｗ
constと混同してるわけでもなさそうだし、454の脳内で何が起きているのか本当に謎だ。
>>458 454のコードの方が「この会社……」だな。
>>454 は静的メンバ関数の static と混同してるんじゃないかな、いや自信は無いんだけどね
マルチスレッドを考慮してスタックを返すのなら return 直後に確保された領域にコピーすれば
ちゃんと動くかも知れないけど、かなり危険だね（hogeの引数が十分に多ければ大丈夫？）
シングルスレッドで static char ret[100]; にすると期待する動作にならないって場合は非常に重症
何か不明なモノに上書きされたスタックで正常動作してるってのは、もはやプログラムとは呼べない
>>460 multi-threadで排他制御なしにstaticな領域に書き込みしている時点でアウトだろ。
>>461 ？？？マルチスレッドなのかも不明だし、問題のコードはスタックを使用しているよ？？？
何が言いたいの？
>>462 454のコードがスレッドセーブでない点について論じている。
元のコードは、スレッドセーフのことなんか語ることもできないような、糞コードだけどね。
シングルですら落ちないのが奇跡的だなw
別にコア吐くようなバグではないよ
期待した文字列が得られないから変な動作になるけど
>>466 なわけないだろ。返値をそのままどこかの関数に渡してたりしたら、任意のコードを実行される危険性だってある。。
バグの重要性を現象面でしか把握できない奴に開発させんなよｗ
>>467 任意のコードを実行させる危険性って何だよ？抽象的すぎるぜ
バッファーオーバーランの危険性が有るからコアを吐く可能性が有るよってツッコミを期待してるのにガッカリだ
>>467 現実に動作しているらしいんだから、
実際にそんな危険はなかった、ってこと。
ダメプログラマですね
char* hoge(・・・)
使うほうも、引数で渡してるんじゃなかったら、このリターン値の
バッファはどこで取ってるんだって気になるはずだけど。
すでにあちこちで使われたら、あえて指摘しないで気づかないふりして
使おうってことになるのかな。
>>472 これがC++ならstd::auto_ptrが使えたり……
auto_ptr（）笑
auto_ptr使ってアドレス渡してインスタンスは消去、と
>>469 この場合、バッファーオーバーランしなくても、危険になるのだが、理解できてないみたいだな。
>>476 うん解らんな
バッファオーバーランによるスタック破壊が生じなければ、コアを吐く様な状況には陥らないはずだ
hoge() の戻り値が関数ポインタを char* にキャストしたモノであるとかの特殊な状況でなければ、
任意のコードを実行させる様な現象は生じないと思うんだが
説明よろ
478 ：
477：2010/08/19(木) 05:23:12
hoge() の戻り値に書き込みを行なってもスタック破壊が生じるけど、これも特殊な状況だよ
>>477 もう一度、
>>405 を見てスタックの状態とスタックポインタと返値のポインタが指しているところを考えてみたら。
>>478 const 付いていないのに、なぜ特殊なのだ？
こうやって辞めたくなるコードが生まれるという好例
>>453 hoge()から戻った後に、特定の無関係っぽい関数を呼ばないと期待した動作にならないとか？怖すぎる…
>>479 hoge() の戻り値に対する書き込み、hoge() の戻り値を strcpy() 等の src として使用した時に生じるかも知れない
オーバーラン、この二つしかスタック破壊の可能性は無いと思うんだが、それ以外に有れば教えてくれ
>>480 いくらなんでも書き込みを許す領域を返す関数にスタックは使わないと思うんだが...
まぁ俺の常識が通用するならあんなコードは生まれないか
>>483 その関数の仕様を見た人が、戻り値がすでに巻かれたスタック上にあることを予期できると思う？
その関数を実装した時点では返り値の領域に書き込む予定がなくても、
後々の改修でとんでもない地雷になるぞ。
すでに破棄されている領域を指しているものを返しているという時点で、どのような不具合が発生する可能性があるかを考えられない人もいるんだな。
解放したスタックは、参照する前に割り込みで使われてしまう場合がある。
よし、strを参照する間は割り込みと関数禁止してもちろんスレッドも全部停止。
str関数のことならマルチスレッド対応版にすれば
489 ：
仕様書無しさん：2010/08/21(土) 12:24:05
strtokをマルチスレッドで多用してるせいか、頻繁に落ちます。
まあテスト用ツールだからまだいいんだけど、リスタートがめんどくさい。
スレッドセーフなstrtok無かったっけ？名前忘れたけど
リエントラントにすることでスレッドセーフにするものがある場合、
_r が名前の末尾についている。
492 ：
仕様書無しさん：2010/08/21(土) 12:48:57
組み込み用だし、今の環境じゃstrtok_rを自作しないといけない。めんどい。
>>492 strtokに一枚皮被せて排他制御すれば？
494 ：
仕様書無しさん：2010/08/21(土) 21:33:41
>>493 タスクAでstrtok使ってる途中で、
優先度の高いタスクBが起き出してstrtok使って、
タスクBの仕事が終わったらタスクAに戻る。
そんな状況で排他制御なんか解になるかよ。
_beginthreadex() でスレッドをスタートさせれば、strtok() って勝手に
スレッドセーフになるんじゃなかった？
>>494 489の
｜テスト用ツールだからまだいい
という文はスルーですか？
497 ：
仕様書無しさん：2010/08/22(日) 08:54:56
>>495 CRE_TSK()でそんな高級なことやってるんかいな。
MT 用のライブラリをリンクした上での話しだな
工夫して使えばええがな
#include <stdio.h>
#include <string.h>
int main()
{
const char *delim = " \t";
char str[] = "om mani padme hum";
char *end = str + strlen(str);
char *pp, *p = strtok(str, delim);
while(p) {
printf("%s\n", p);
pp = p + strlen(p) + 1;
if(pp >= end) break;
p = strtok(pp, delim);
}
return 0;
}
次のライブラリ関数は、static 変数に結果を保存して返すので、スレッド・セーフではない。
getlogin() readdir() strtok() asctime() ctime() gmtime() localtime() rand() getgrgi() getgrnam() getpwuid() getpwnam()
らしい
String flg;
(中略)
if(flg == "1")
String型でフラグ宣言するのって実際どうなの？
１かブランク以外使わないならbool型じゃダメなのって思うんだけど。
あとよく会社の人が処理の流れを「ロジック」って言ってるけど
「アルゴリズム」とどう違うのだろうか、前者は回路的な論理だった気がするんだけど
シーケンス？
>>502 異なるプラットフォーム間でやりとりするなら文字列を使うのは結構良い方法だよ
>>504 同じプラットフォーム間でかつVCだったらどうなるのっと
別に気にするほどのものでもないような。
それよりflgって名前のほうがなんかいやだ。
前に居た会社はがっつりそんな感じで文字列でフラグ立ててた。
dbに落ちてる、ゼロ詰めアルファベット混在の謎のフィールドなんてのもあったからかな。
フィールド名はyobi。まだ何桁目が何か大体覚えてる。
なんで手遅れになる前にalterしない？ とか最初は思ってたけど、麻痺した。
転職して、正気を取り戻したけど。
プラットフォームの設計はDBの項目設計が全て。
プラットフォーム間はどの項目を転送するか？の設計に尽きる。
みたいな古の考えの元に動いてるプロジェクトは多いからなあ。
大量の設計者、会議、コーダー、工数を武器に、
大金掛けて作るのなら、それでも良かったんだけどな。
時代が変わったっての理解出来ない人が多いのが、
日本のこの業界のダメなところ。
>>502 アルゴリズム∈ロジック じゃね？
特定の問題を解くためのロジックがアルゴリズム
>>510 昔はそういう風にしかできない場合もあったし、高速化のためにやっていたのかもしれないので、叩くほどのこともない。
しかも、関数一個作れば、普段は気にしなくてもいいはず。
貧すれば鈍す
>>511 MSSQLで、substringでselectするんだぜ。
信じられんかったよ。
それは辞めてもいいと思う
そういうダメな作りがいつまでも生き残るのは、既存の技術者がわざとそうしているためだ。
例えば関数化していちいち気に無くても済むように工夫をすると、
誰でも入ってこれるようになるので、自分の立場が危うくなる。
あくまでも、自分しか触れない領域を確保したいがためなのだ。
望み通りサッサと辞めて上げるのが吉
>>513 まあ仕様がきっちり決まってるならビュー１個作れば解決な気もするな。
糞重いビューができそうだな
扱いやすくはなるかもしれんが実行速度はお察しだな
RDBではない時代に設計されたんじゃないのか？ 単純な方法でランダムアクセスできるから、用途によっては非常に高速。
昔、パンチ屋さんに入力を頼むと、そういう固定長で返してきたな
アンケートとか名簿入力で万件単位だったけど
>>522 汎用機のデータフォーマットは、たいてい固定長だよ。
COBOLと相性が良いため……というか、COBOLが開発された時代に大量データを扱うには固定長しか選択枝がなかった。
CSVやXMLはPCやunixのフォーマットだと思った方がいい。
>>523 どうやったら選択枝って変換になるんだ？
変換辞書にいたずらされてるのか？
運輪省とか国士交通省とか
>>524 Google IMEの4番目の候補にありやんのw
さすがに選択肢のほうが上だったけど。
”選択枝”でググってみると「役所の文書で「枝」が使われていることがあるが、
当用漢字に『肢』が入ってなかったせいかもね」といった推測もあった。
Google IME(笑)
（微笑）
たしかにInputMethodEditorっちゃInputMethodEditorかな
ATOKでよくね
ATOKは金掛かるけどGoogle IMEはタダだから薦めやすい。
MS-IMEに文句いいながら使い続けるくらいならGoogle IMEのがなんぼかマシ。
ま、俺はATOK使うけど。
そういうあなたに百度IME。無料だよ。
よっぽど糞なIMEでもなけれまMSIMEより悪いってこたあないだろう。
どうせMSIMEも中華製だしな。
万が一最高の変換精度を誇るほどのモノであったとしても
百度には絶対に手を出さないわ
>>533 WJEベースの頃はまだマシだったんだけどね。
やっぱり男は黙ってSKKだ。
最近はemacs vs viって聞かないなぁ。
T-codeいいよ
間違えないしね
>>535 私の最初はegg だったなぁ。
そして、なんで vi なんか使ってるんだろうと不思議に思ってた。
いまだにいるぞ
「俺はスーパーハッカーなんだぜ」的な顔で鼻穴をヒクヒクさせながら得意げにviを使っているがき
本番機にはviすら入っていませんでした…… orz
edは入っていたのでコレで何とかしましたが……
vi と ed は使えるようにしておかないと困ると思いました。
（使うコマンドは５つ位なのでメモを持ち歩けば十分かな？）
540 ：
537：2010/09/24(金) 00:14:23
確かに使いこなせなくとも全く使えないのはマズイと知るのにそう年月はかかりませんでしたね。
もし ed すら入ってないとしたら、、、あなたならどうする？
>>539 あるある。
echoとheadとtailで一生懸命ごまかしたことがある。
>>540 cat > file
くらいか‥‥‥。
DOS端末（？）でcopyコマンドでバッチファイルを組んでた先輩の目はいきいきしていたのお
メクラ打ちで全部打って、間違えがあったら死ぬので、
１行づつファイルにしといて、最後に copy + だな。
つか、edlinすらなかったのかよ。
つか、今vistaで試したが、未だにedlin入ってんだなｗ
vistaのedlinのメンテとかしてる人ってどんな気持ちだろうなｗ
「あなたには新Windowsの開発に参加していただきまます」
「このedlinのバージョンを・・」
うほっ
楽な仕事回ってきた
どうせ誰も使ってないし
バグも糞もないよな
>>544,545
存在すら忘れてたけど、まだ入ってるんだな。
でも、それを使う状況って考えたくねぇよｗ
edlinは、
昔のバッチファイルで、パイプでedlinにつないで、テキストファイルを編集しているものがあるので、残っていたのだろう。
しかし、７でとうとうなくなった。
と思ったが、64bitに入っていないだけ？
>edlin
どうせ仮想86で動かすんだから
コンパイルしなおすだけじゃねーの？w
うむ。
>>545 が言う開発の仕事というのも、ヴァージョンを書き直してリコンパイルするだけだろうなｗｗ
>>537 おれも昔はviのよさがぜんぜん理解できなかったけど、
仕事とでつかわざるをえなくって、使ってみたらすごいよかった。
今はVSを使ってるけど、VSにviのキーアサインがあったらそれ使ってるとこだよ。
具体的にはviのどういうところがいい？
使ってみようかなとは思うんだけど、仕事では使う機会無いし、
なかなか踏ん切りが・・。
踏ん切りってなんだ。
vi自体の良し悪しはさておき、Linux/Unix使うなら常識的に使えるべきエディタだろ＞vi
「Linuxは超詳しいですけどviは使ったことないっすｗｗ」なんて人間は有り得ない。
Linuxのセットアップすらしたことがないと自爆してるようなもんだ。
Linuxってvi使えないとセットアップすら出来ないの？
>>556 emacsが使えれば、99.99%の用事が
すむけどな。ｗ
viなんて基本スキルの一つだろ
使えない事を自慢してもいいこと無いぞ
10年前はvi派だったけど、久しぶりに使ってみると
さすがに古いエディタだなぁ、と思うよ。
範囲選択して削除するだけで:.,+23dとか、やってられない。超しんどい。
vimしか使ったことがない俺にemacsとの比較を頼む
>>561 差はあまりないぞ。どちらもコマンドを入力すると各コマンドの実行モードになる。
viはコマンドの数が少なく、キーバインドの変更が面倒なだけ。
変更する必要性が無いと思うが
>>560 そりゃそんな使い方してたらしんどかろうよ
普通24dd
範囲に依っては .,/}/d とかで済むし
vi は i、w、q、x、: と ESC だけしか知らないけどなんとかなっている
貴様！カーソルキーを使っているな！
マークも使えよ。
ma23jd'a
20年以上使ってるけど、
マークとかタグとか使ったことねえw
yyp
viは、
* cw とか d/ は編集コマンドと移動コマンドの組み合わせ
* コマンドの前にアドレス指定できる
* .
あたりを知ると目の前にいろいろ開ける感じ。
俺は/etc/passwdや/etc/hostsも含め、
ほとんどのファイル編集作業をeclipseでやってるなあ。
575 ：
仕様書無しさん：2010/10/09(土) 19:51:27
俺はsambaでつなげてWindowsクライアントから秀丸で編集してたなあ。
7年前の思い出。
秀丸と卓駆がTurboLinuxにあればなぁ…と思ったのも懐かしい思い出
viを使うのは、ほかの便利な
エディタが入ってないからってだけ。
昔DOSでedlinを使ってたのと同じ理由。
>>577 何を言っているんだ、君ぃ？
viがなくたって、edがあるじゃないか！exもあるじゃないか！
>>577 viってのは、UNIXの標準エディタでね。
とりあえず、vi使えれば、大抵のUNIXはなんとかなったもんだ。
初めて仕事で触ったのがSolarisでね、
もちろん、GUIなエディタもあったけど、
telnet接続でも使えるってのはよかったね。
最初は面倒くさいと思ったけど、
実際はよく練られてると思うよ。
いまでも使ってるし。
exとviは同じもんだろ
exだけあってviがない環境などありえない
おまいらがうらやましいよ。
俺の周囲では、変数のないクラスを作るヤツが平均的。
使用するときは外で変数定義してねって。アホすぐるｗ
>579
今のviは残骸。
本当はずっと機能豊富だったのに度重なるハードウェア故障でソースが失われ、
やる気を失った作者がバックアップが残っていた何世代か前のソースでケリつけたもの。
>>579 そうか？
俺がUNIX触り初めた時には、
rootはviが使えない状況でも編集できなきゃいけないということで
edとexも必須だった。
まさか、viはいつでも使えると思っているほど「ゆとり」世代なのか？
viが使えない理由がterminfoが死んでるからならexは使えそうだけど、
/var/tmpがマウントできてない場合はexも無理?
>>573 俺はカーソルの移動だけで開けた感じがした。
>>584 そゆんじゃなくて、
emacsがなくったって、viはあったってことでふ。
>>587 そうじゃなくて、
viが使えない状況というのもあるのだから、
viさえ使えれば絶対というわけでもない。
はっきり言って、今時ならviもemacsも大差ない。
SELinuxの場合、タイプラベルをきちんと扱うエディタはVimが無難とか。
今はどれだけ増えたか知らないけど。
vi 使えない状況で思い出したが、ls を消してしまったときはどうしようかとｵﾓﾀよ
SunOSの 4.1.3 くらいの頃のマニュアルに、非常手段の例として
ファイル一覧を見るには echo *
ファイルを作るには echo ... > outfile
ファイルを表示するには while read ... ... < infile
みたいなのが載ってた希ガス。
１０年くらい前に emacs 禁止の現場が有ったな
理由はメモリ消費量だったんだが、あの頃のマシンってどのくらいのメモリ積んでたんだろ？
unix系マシンのメモリは高価だったので必要最小限しか積んでいなかった筈。
ヘタすると128MBとか256MBとかだったり……
emacs禁止は多かったね。
vi厨を生んだ原因。
10年前にはもうemacsぐらい問題にならないぐらいメモリ積んでたろ。
20年前ぐらいのSun3とかの時代にはemacsの禁止には意味があった。
>>595 10年前の時点での最新機種ならば、問題にならなかったろう。
開発機が、その時点での10年モノだった可能性は？
・開発機はコンパイルとテスト実行だけできればよいという観点でメモリをケチるケースが結構あった。
本番機はそもそもemacsが導入されていないケースが多い。酷い時はviすら入っていない……
>>596 えっと、Y2K問題まっさかりの頃に、開発機がemacsが動かないスペックだったの？
それはかなり少数派だと思うよ。
いや少数派というか偽装ハケンやら３重請負とかそういうところならあるかも。
>>596-598 開発マシンは ultra-sparc（スペル正しい？）だったかな、Emacs が動かないスペックでは無いよ
正にY2K対応の現場だったんだけど、とにかく人数が多い現場で一つのマシンに20人くらいぶら下がってたからかなぁ
>>599 ultra sparcなんて十分に贅沢なマシンじゃねえかw
俺の知ってる現場じゃ、68kのsunでemacs普通に使ってたぞ。
emacs禁止は、シェアしている場合のルール。
専用ならそんなルールはできない。
ぶら下がっている奴が多ければ、今でもあり得る。
602 ：
仕様書無しさん：2010/10/17(日) 17:52:42
>>600 CPUの問題じゃないからねぇ
68000 使った sun なんて何時の話だよ、20年前でも 68020 だった記憶が有るんだけど
603 ：
仕様書無しさん：2010/10/17(日) 19:13:47
いま使っているUNIX鯖はemacs入ってないな。viだけ。
若干修正するには使えるけど、これでコーディングとかは
無理だなぁ。
>>601 emacsのフットプリント計測してみろ。それがどんなナンセンスなことかわかるから。
俺のタイピング速度にCPUが付いていけないからなあ
ｯﾀｰﾝ！
その5文字だけで笑えた。アレ凄いな
609 ：
仕様書無しさん：2010/10/26(火) 15:39:59
最近よく奴隷化だ奴隷化だって、さも正論のようにのたまうドヤが多いが
じゃあ、なんなら奴隷じゃないと言えるのか
人間社会、利権を主張するヤツしかいなかったら回らんよ
これは日本に限ったことじゃないし、会社に限ったことでもない
そして、どうしようもない環境に立たされている人間が
それでも幸せに生きようと自分を騙してまで頑張ることに対し
誰がそれを間違っていると言えようか
1億総奴隷化
日本に生まれたからには、９０％以上の確率で奴隷としての生涯が確定するわけだよ。
こんな国は、アフリカも含めて、現代では日本だけだろう。
いやいや、何をもって９０％とか言ってるのか意味わかんないし
何をもって奴隷としてるのか定義してないから説得力ないよ
とりあえず
>>612は早く会社やめられるといいね
奴隷なら仕事をやれるという自由もないはずなんだが、日本にそんなところあるのかなあ？
借金重ねたやつは、死ぬまで働け
>>614 ＞借金重ねたやつは、死ぬまで働け
今の引退前後世代と国会議員と役人どもに言ってくれ
人間の馬鹿さ加減に失望した書き込み
>>615 インフラ使わずに生活してるのか？
その書き込みのために使った電力インフラと通信インフラとPC入手までの流通インフラは無料で整備されたのか？
列島改造計画があったからこそのインフラ整備、国債残高。恩恵を享受してる現代世代に文句言う資格はない。
つまるところ人類が害悪である
地球から消滅すべき
アンゴルモアさんが仕事サボってるってことだな
北の将軍様が出前の仕事さぼってんだよ
if [ !-e ${foo} ]; then
echo -e "" > ${foo}
fi
>>620 何そのキモイ書き方……。
逆に興味出てくるわ……。
えっ
正解はこう
if [ !-e ${foo} ]; then
touch ${foo}
fi
624 ：
仕様書無しさん：2010/12/05(日) 06:16:20
>>405 これと同じようなのFで見たな。
strtokモドキ作っておきながら中身がこんなやつｗ
ン10年前に造られた奴らしいから下手にいじれないとか言ってたけど、
とりあえずプロファイラ通したら超腐ってたｗ
かなり昔のコンパイラだったからretarn(0);っとかあったな。
C# なコード
private void Giko(Mona mona)
{
if (mona == null)
throw new ArgumentNullException("mona");
// 以降monaはまったく使用されない。
}
----
これって何がしたいの？
monaを削除しても問題なく動くんですけど……
C#関係ないじゃん
>>625 mona != null っていう条件で使われてるじゃん
>>625 最初は使っていたのがいらなくなったか、使うところまでインプリメントできていないか。
引数無しの同名のメソッドが存在してないか？
たぶん、そっちと区別するためにダミーの引数を……
答えは仕様書の中にある。
仕様書があればだが。
フレームワークが自動で呼び出す類のメソッドだったりかな
>>626 確かに関係なかった、すまない。
>>627 いや……それは関係ないんだな。
>>628 素直に、これが正解だと思うけど。こゆのってどうやってデバッグしてたんだろ。
デバッグしてる時に気づくよね？
>>629 探してみたがなかった。
>>630 予測していると思うが仕様書はついてなかった。
マジでいったいどういう経緯で書かれたソースなんだろ。
書いた人本人は読んでるのかなぁ……
>>631 うんにゃ違う。
あと、実際にはmonaだけじゃなくて、
５つ引数があって、２つはnullチェックだけ、１つは使ってない。残り２つはちゃんと使ってる。
あとわかれば教えていただきたいのだが、
この手のデッドコード（っていうの？）はどうやって探せばいいのかね。
静的解析ツールとかで、向いてるのないのかな。
Resharperと、VSULTIMATEを合わせ技で使っても、nullチェックだけってのは検出できないのよね。
同じエラーメッセージでも、
「、」：「，」とか「。」：「．」の組み合わせで発生箇所を把握できるようにしてるパターンあるな。
エラーメッセージまで仕様書で指定されてたら、行頭・末尾スペースの数とか。
メッセージボックス表示中にCtrl+Cでコピーできるから確認できる。
>>633 その引数を、引数定義から外せば何故か落ちるという素敵仕様だったりする
かもしれないので、触らぬ神に祟りなし。
気持ち悪ければプロジェクトでdefineするか、ラッピング関数を作る方針で。
DBの不明カラム(どうやら文字列で0～Fのフラグ16桁)も同じく。
リファクタリングツールを使うと、無意味な引数があるメソッドができてしまうことがある。
遙か彼方でこの引数につっこむヤツが再利用されるが
そこでnullだとこのメソッドが完走しようが何の意味もない
そこで先に呼び出されるであろうこのメソッドの中で
例外吐いて終了させればいい！
なんて気持ち悪い超やっつけコードだったりしてね
638 ：
仕様書無しさん：2011/01/05(水) 02:44:11
>>625 monaのnullチェックを兼ねてるとか。
それにしても、やり方ってもんがあるだろうとは思うが。
ぺてん師「王様、このプログラムには馬鹿には見えないコードで書いてあります」
>>633 その2つの引数が共にnullでない時だけ処理をしたい、
いずれかがnullの時には例外を投げたい、
ということだろう。
例えば、銀行の振り込み処理で、口座に振り込み金額を加算する時、
振込人の名前と振り込み受付者は、口座残高への加算には何の関係もないが、
法律上の関係で振り込み人と受付者がないと加算してはいけないという制約があり、
念のためにnullかどうかチェックして、nullだったら例外を投げなければならない、
というのはあり得るかもしれない。
その他、いろいろとそのオブジェクト内の制約も、他のオブジェクトにもまたがった
制約もあり得るから、そのメソッドが動いているからといって、nullチェックを外して
いいとは限らない。
それってnullチェックの場所がおかしいんじゃねーの？
>>641 Giko()処理とmonaに設計上の制約関係があり、
それを確実にやらないほ非常にマズいのであれば、
if (mona != null) Giko();
else throw new MonaException();
を100箇所に書くよりも、
100箇所の呼び出し側は
Giko(mona);
にしておいて、Giko()内で
if (mona == null) throw new MonaException();
したほうがマシなこともある。
繰り返すが、これはあくまでGiko()処理とmona != nullの
間に設計上の制約関係が必須の場合な。
>>639 馬鹿には見えない仕様書とか、合意文書と言うのはあるな
いや、ないのか
糞野郎の頭の中にしかないわけだ
蛸壺屋の同人誌に出てくる唯ならかわいいから許せるが
糞野郎は存在するだけでヤニとハグキの臭いを発散させるクリーチャー
死ねばいいのに
>642
なるへそ。
でもそのケースならGiko()にパラメータを渡して判断させるよりも
-----
if (mona != null) Giko();
else throw new MonaException();
-----
をメソッド化しないか？
>>644 ヒント： Giko(mona)とGiko()が併存していたとして、君ならどっちを使う？
Giko(mona)の方が安全だろ
メソッド側で広域変数を勝手に読めってのは恐ろしすぎる
こんな実装したらクビにするよ俺は
その程度でクビとかどんだけ
参照できる広域変数が存在する時点ですでにおかしいだろ
>>642 概ね理解した。
しかし、１点理解できない部分があるので教えてほしい。
＞繰り返すが、これはあくまでGiko()処理とmona != nullの
＞間に設計上の制約関係が必須の場合な。
これって、実際上ほとんどあり得ない場合じゃないかな。
そして、あり得たとしても推奨できない場合じゃないかな。（つまり、設計見直しが必要になるということ）
このような設計上の制約関係が必須であり、かつ、それが設計上推奨されるような場合って想像つかないのだが。
>>646 お前さん、事の発端となったコードを勘違いしている。
＞メソッド側で広域変数を勝手に読め
>>625を見りゃわかるが、メソッド側ではnullチェック以外で読んでない。
>>642 その場合、Gikoを別クラスのメソッドにしたほうがいいと思う。
Yaruo yaruo = new Yaruo(mona);
yaruo.Giko();
----
で、
public Yaruo(Mona mona)
{
if (mona == null) throw MonaException();
}
>>651 それじゃGiko()を呼ぶたびにnew Yaruo(mona)しなきゃならない。
はっきり言って、最低。
この話って、monaがずーーーっと先で使われてるかもしれんってこと？
よーわからねーけんど、
Giko(mona); //ここではnullチェックのみ。
/* ずーーーーーーーっと先 */
MonaTsukauMethod(mona); //nullだとダメ。
ってことだよね？ だとすると、
Yaruo yaruo = new Yaruo(mona); //ここでnullチェック
yaruo.Giko(); //ここではmona使わない。
/* ずーーーーーーーっと先 */
yaruo.MonaTsukauMethod(); //ここでmona使う。
ってことなんじゃね？
いずれにせよ糞コードである事は間違いない
見も蓋も無いこというなｗ
たまには保守しやすいVBAのコードを見てみたいです
まあ所詮VBAなんて
「作業楽にするために組んでみました」
「アレもできると便利だな、組み込んじゃえ」
「おいおい便利なの使ってるじゃないか、独り占めしてないでチームに展開しようぜ」
「というわけでプロジェクト正式ツールに採用しますた」
みたいな感じで話が広がってくもんだから
保守性とかコードの見やすさなんて最初っから考慮されてないんだろうな
で、泣きを見るのは正式採用後にメンテさせられる人達。
>>657 それを同一のguiでクラウドに載せろと言われる。プロでも涙目。
クラウドｗｗｗ
660 ：
仕様書無しさん：2011/02/17(木) 16:52:18
>>660 やだ・・・・全部見せろだなんて恥ずかしい
>>660 見ても分からんだろうし、そんなものに価値はない。
プログラマなら分かるはず。
この仕事で本当に価値があるのは、頭の中であって、成果物ではない。
663 ：
仕様書無しさん：2011/02/18(金) 16:21:02
これから先のプログラマには難読化する技術も求められるようになるなw
コメントを削除したり変数関数名を無意味な文字列化するツールがいるなw
関数名は連番で台帳管理ですよ
obfuscatorって最近何を使うのかなぁ
ソースなんて、馬鹿どもには良い目晦まし。
技術者は、既に次のステップに入ってる。
C言語。
gotoで処理をあっちゃこっちゃに飛ばすのは辞めて欲しいなぁ。
ラベルで処理の内容を示す所まで行って、なんで関数にする事は頭に浮かばないんだ。
ループ開始か
深いネストから飛び出すにはgotoが一番。
だって繰り返すんだぜ
無限ループって怖くね？
daemonは無限ループだぜ。
winだったメッセージループはくるくるまわってるぜ。
C++なんだが、これってどうよ？
int hoge = true;
C++にtrueなんてあったっけ？
ある。
あるけど、boolという型もあるのだな。
#define true (int)~0
とかできるのかな？
糞みたいなソースを読んだほうが練習になる事がわかった
人のふり見て～ってやつだな
そう思っていてもいつの間にか
朱に交われば～
になってたりして
>>680 CはTRUEとかFALSEとか定義しないで素直に0かそれ以外使ったほうがいいな。
定義してあるとたまに
#define TRUE 0
#define FALSE -1
だったりするから油断できない。
まぁ 耳タコかもしれんが
if(fp) と return 0
の関係ね。
0が正しいのか 1がＴＲＵＥなのか
途中でどっちにしたっけ？ となる。
enum FLAG_ON_1 { ON_1 = 0, OFF_1 = 1 };
enum FLAG_ON_0 { OFF_0 = 0, ON_0 = 1 };
てのを思い出した。何の嫌がらせかと
// 初期値をオンに設定
SetIntParameter(ID_XXX, (int)ON_1); // ××は負論理
SetIntParameter(ID_OOO, (int)ON_0); // ○○は正論理
...
// もし××が0なら
if (GetIntParameter(ID_XXX) == (int)ON_0) ...
みたいにあちこち取り違えてて、項目表でどっちの論理か確認しながら直さないといけないし
つか、そこ0って書かれたらオンオフどっちにしたかったのかわからんだろ
_Bool とか stdbool.h の立場はどうなる?
>>684 > #define TRUE 0
> #define FALSE -1
移行するプログラムにこれと同じのがあった。
さらに、そのソースから呼んでいる関数があったのだが、そこでは
#define TRUE -1
#define FALSE 0
とか定義されてるし。疲れた
正常終了の０ と
ｉｆ文の０以外が真 は
不条理だよね。
どこかで何かがねじれたんだね。
インド人が０なんか発明するからいけないんだぁぁぁ
ｲﾝﾄﾞｼﾞﾝｶﾞｰ
インなんとか人
そこでハンドルを右に
public void getHoge
public String setHage
もう嫌
久々に
boolean huragu = false; // ××するフラグ
C言語で日付の加減算を自前でコーディングしてあった。
2012/02/30, 2012/02/31 とかありえない日付を出力してくれるし。
さらに1日加算すると2012/03/03と出力する素敵な作りorz
#うるう年のテストパターンで発覚
納期が「2月末」のシステムだったに違いないw
char hoge[256];
memset(&hoge, (char)NULL, sizeof(hoge));
strcpy(hoge, "fuga");
直そうかと思ったが、いっぱいあったのでスルーした
どこにセットされるんだろw こわ～
案外普通に動くんじゃない？
どこにhogeが出来るかの問題ではないよ。
正しく動作するけど、内容を理解しないまま書いてるコード
よくある間違いだな
配列だと hoge==&hoge なん？
処理系依存？
問題は２点。
memset() の第２引数に NULL を使っている。
memset() によるゼロ埋めは直後に strcpy() するならおそらく不要。
仮にゼロ埋めが必要だったとしても char hoge[256] = {0} で済むところ。
・・・で、合ってるかな。
てかstrcpyだけでいんじゃね？
>>710 ふつうはそう。
それを許さない阿呆な規約で運用しているところが、世の中にはある。
つうか、strcpyなんて使わなくても初期化子で十分だろw
もし"fuga"がリテラルでなく変数ならば、strcpyはバッファオーバーラン注意報。
>>709 ＞char hoge[256] = {0}
先頭要素が0になるだけ。
ゼロ埋めにはならん。
gcc 4.5だと0埋めしてくれるけど
>>713 全ての要素がゼロクリアされるコンパイラもありますが、保証は無いね。
VC++ 2003以降では、全ての要素がゼロクリアされます。
ゼロクリアされることは規格で保障されとるがな
>>716 そうだったんだ。それは知りませんでした。
そうならないコンパイラが過去にあったので、勉強になりました。
ﾌﾌﾌﾌ
ﾌﾌﾌはMSCだっけ?
デバッグでコンパイルしたら入るんじゃなかったっけか
0xcc で初期化されるんだっけな
初期化が入ってないときだけだよ。
寿司食いたいﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ
725 ：
仕様書無しさん：2011/04/01(金) 03:57:57.38
>>716 自動変数は保証されないんじゃないの？
静的変数なら保証されるけど。
それとも、C99では保証されるようになったのか？
>>725 配列サイズに満たない初期化子がある場合の話
> &hoge
問題点はここでしょ？
配列だと hoge==&hoge なん？
処理系依存？
>>699 > (char)NULL
やっぱこういう記述があるようなところは何から何まで全部ダメだな
多分
>>711なんだろうし、新人の教育上非常によろしくない
>>701 そういう職場ではむしろそう書かないとコードレビューで袋だたきにならないか
元あったのを直すどころか死んだ目をしながらそういうの量産してるよ
>>724 ガリでも食ってろﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ
>>701 strcpyのほうは&を付けない理由を問い詰めたい
>>736 memset に & つけてる理由を聞けよ
memsetの方はvoid *で
strcpyの方はchar *だから
と予想してみる
お前は何を言ってるんだ
文字列をmemset()で0で埋めるのって、やってる人はこれで安全になるとか
信じ込んでるよね。
>>740 昔の固定長レコードやってた頃は余分な領域は 0 埋めしないといけなかったりした
その名残じゃないの？
今でもそういうシステムが生き残ってたりしたら
不用意に書き換えると懲罰もんだなｗ
C言語で組んだのは3年前が最後だ
たまにはCやりたいな。
メモリをダンプした時に場所が分かりやすいとか、メモリリークが分かりやすいとか。
恩恵にあずかったことはないが。
>>743 あと不定値を参照してうまくいったりいかなかったりと結果が不定になるのを避けやすくなる
でもそのへんを目的とするなら0x00じゃなくて'ﾌ'とか他であんまり使わない値を使うべきと思う
>>741 今でもヌル終端の文字列をmemset()で0で埋まってるって前提で固定長レコードとして
参照する八百長野郎がいるから迂闊なことしないほうがいいだろうな
>>741 いや、単純にバグが少なくなるとか安全だとかしか考えてないよ。
memset()で0埋めする人。
>>701 &hogeって配列全体のアドレスだっけ？
答えはK&Rに書いてある
「大昔から決まってる」ってこった
#define begin {
生で見たのは初めてだ……
国宝級だな
うう しりまへんなぁ。
もとのコードがPascalのコピペなのでは
な～る
そんならむしろ s/{/begin/とかなんとかやってくれと
うわぁ逆w
テメーなにやってんだｗ
もちろん
#define procedure void
#define function int
というのも一緒に書かれてるんですよね
#define private public
もご一緒に
もう変なdefineやめてー><
#define defines defining
らめぇぇ
え～い 全部グローバル変数でいいのだ
#define int static int
これ便利
再帰できねえ
再帰不能
#define long static long
そ～れ！
#define BEGIN {
#define END ;}
#define THEN BEGIN
#define ELSE END else BEGIN
#define ENDIF END
#define DO do BEGIN
#define ENDDO );
#define WHILE END while(
#define ENDWHILE END
#define REPEAT DO
#define UNTIL WHILE!(
#define ENDREPEAT )ENDDO
#define ENDFOR END
#define NEXT END
#define LOOP for(;;)BEGIN
#define ENDLOOP END
#define ENDSWITCH END
で？
v7unixのshのマクロ定義なんてこのスレ見てるならみんな知ってるだろうし。
>>770 昔 そんなマクロで便利に書こう という
Cの本がありましたね。
「プリプロセッサパワー」だったかな…
#define break exit(0)
やめてくれ
考えただけで、気絶しそうだ
777 ：
仕様書無しさん：2011/05/19(木) 15:57:49.46
スレチかもだけどさ、同僚が鬱って今日交代で開発現場に入ったんだが、
のっけからこんなコメント見つけたんだ
//可読性さがるからポリモーフィズムとアップキャストの使用禁止
OOPの一番の肝を潰して何が得するんだろ……
抽象思考能力の低いPGでも人手として使えるようになるというメリットが
c++の大規模なソースならすげー同意
凝りまくるやつと理解があやしいやつを混ぜるな危険
最近の補助輪フレームワーク付き言語ならどうでもいい
カバーできる範疇
つうかさあ、C++をOOPだと言うの、やめないか？
案外Javaだったりしてな
C++がOOPだなんて誰もいってないじゃん
oops!
teleporter?
in the stone
…でいいの？
どの石なのか分からないのだからtheはいらない、のはともかく、
stone じゃなくて you are in rock! のようだ。
「英語ってのはなぁ、俺が使った後に文法がおいついてくるんだよ！」
・・・実際、そういう傾向のある言語だから困る。
OOPもできるC++という事で。
789 ：
仕様書無しさん：2011/05/26(木) 01:56:39.42
Perlのソースなんだが、
my $data = "";
my $arr_len = @arr;
my $cnt = 0;
while($cnt < $arr_len){
$data = $data."～";
$cnt = $cnt + 1;
}
これは一体何なんだ。
こんな感じの記述が、同じソースのあちこちに散らばってるから困る。
このくらいなら読みづらいとは思わんが
そういう話ではないのではなかろうか
$data = '～' x @arr;
かね。
Perl忘れてる…
793 ：
仕様書無しさん：2011/05/26(木) 22:18:57.84
まあ、別に読みづらくはない。
バグがあるわけでもない。
でも、そういう問題じゃない。
配列長の取り方に違くね？
ただのインクリならforでよくね？
つうかforeach知らないの？
ゴミはif(0)か#つけようよ
Perlならそもそもループ組んで回すような処理じゃない。
どの言語でも同じ様にしか書けない奴がいる。
という話だよね。
$data = join('～', @arr);
のことかーっ
>796
@arrの中身は使わない。使っているのは要素数だけ。
void hoge2(string x){
}
void hogeapi() {
char hoge[4 * 1024 * 1024];
string x;
x = hoge;
printf("%s\n", x);
hoge2(x);
}
勘弁してくれ
な 何が起きるの？
何をしたいの？
if(hoge==(char *)0) { /* NULLが(void *)0で定義されていると警告が出るので */
char *hoge と宣言されてる。
2～3年前のソースなんだが、Cコンパイラは何を使ってたんだ?
20年前の間違いじゃないのか
if(hoge==(char *)NULL)
じゃだめなのか
NULLってなにさ
>>800 スタックサイズが小さい場合、スタックオーバーフロー起こす可能性がある。
stringをそのまま%sで表示させんな。c_str()使え。
if (hoge == 0) でいいのに。
hogeをstatic宣言すればいいんだヨ！
if (!hoge) だとわからない人いるからと怒られた
if(!(hoge?TRUE:FALSE))
わからないって言ったら
得意げに三項演算っていうんですよー
って言われた
ふーん凄いねって言っといた
これはｶｯｹｰ
どこからつっこんでいいかわらなくて言葉を失うレベル
三項演算子禁止のプロジェクトがあるのも仕方ないと思うレベル
(Cの)switchには必ずbreakを書くというルールがあってfall throughできない
ってのは切れるレベルだろうか。
バイナリやキャラクタに
case当てる時致命的だね
VBで得意げにIIf使ってたら重くなるから止めろと言われたあの頃
Cのswitchはcaseのところに変数が置けないんだね
値をハードコーディングしないといけないレベル
>>801 コンパイラはC++、ヘッダはCだったのでは？
>>817 C++コンパイラかぁ
ちなみにファイル名は～.c、中身もC言語だった
他の言語は出来るの？
switch( a )
{
case 0:
{
int i;
}
break;
}
どうだね？
var vatiable = 1;
var anithervariable = 2;
switch (a) {
case variable :
// do something
case anothervariable :
// do another
}
みたいなことが出来ない言ってるんでねーの？
何に使いたのかわからんけどね。
switch {
case a<0:
case a==0:
case a<2 && !b:
default:
}
「if-elseif-elseで書けよ」「いやswitchでこう書けた方がいい」
みたいなことじゃね？
C言語もできるようになった気がしたけど、まったく自信なし。
俺が使っているのは古いから、関係ねぇ。
出来たら便利かも・・・
便利な事もありそうだが…混乱の元になりそう
各caseが同値になったらどうするとか考え始めるとカオス
break 抜け case 内で a が書き換えられるなどの多重ミスで
わけわからんところに飛ぶようになっていて
受け継いだ人が涙目でバグ取りやってる姿が見えました
for
( ; ; )
{ }
// ﾎﾞｸﾊｲｷﾙﾉﾆﾂｶﾚﾏｼﾀ ﾄｳｻﾝｶｱｻﾝ ｵﾔｺｳｺｳﾃﾞｷｽﾞｺﾞﾒﾝﾅｻｲ
突然音信不通になったPGのソースを一通り舐めてたらでてきた。
使わせてもらうw
使うって、おまえ自殺するのか？
>>829 コンソール出力した方がインパクトあるのに
無限ループで止まったプログラムの原因を調べるためにソースを開くと・・・
default の綴り間違いで苦労した人 挙手
スレチ
>>829 そんな事言うなよ！生きろよ！
for
( ; ; )
{break;}
//
体の中壊してまで生きて働けと言うのか
perlだったら ... or die とかdie if ...と直接入っちゃうな
>>842 or die
使うやつきらいなんだ
昔それで会社辞めた
dead or alive();
dead() xor alive()
なにそのゾンビ判定演算ｗ
てか、それだと両方評価されてしまうし
--
（（（（（（（（（（（（（ 使うやつきらいなんだ ）））））））））））））（キリッ！！！！キリッッッ！！！キリッッッ！！！ッッッッ
------------------------(キリッ！！！キリ!!!キリ
--------------
（（（（（（ 昔それで会社辞めた ））））））（きリ!!!キリッッ！キリッッッ!キリッ！ッッ！！！！
死ねよゴミ
未だに内の会社で見るバグ
COBOL
PERFORM VARYING I FROM 1 BY 1 UNTIL I > 5
～～
PERFORM VARYING I FROM 1 BY 1 UNTIL I > 10
～～
END-PERFORM
～～
END-PERFORM
外のループは絶対５回は回らなきゃいけないのに、
追加したコードがそれをぶち壊し…
一体、何回同じバグを繰り返せば身に染みてくれんだろう…orz
COBOLINTを作るんだ!w
COBOLってブロック内変数とかって出来ないんでしたけ？
なら怖すぎますね。
汎用機の頃からガリガリ書いてるはずなのに、未だに
>>848のザマだよ！
直した本人は外出中で居ねぇ
おまけに特定の顧客の時のみ爆発するというスグレもの
>ブロック内変数
COBOLまだ中途半端にしか把握してないし、
少なくとも会社のソースにブロック内変数なんて見た事ねぇ
GOTOの入ってる関数コピペして、そのGOTO先を直さずに…
ってこれも何回目だ、くそがあﾞあﾞああああ！！くぁｗせｄ
>850
構造化なんてもんがない時代に作られた言語に何を期待するかね。
とはいえ、COBOL-78（第3次国際規格の元）でスコープの概念が導入されてるけどさ。
COBOL 2002、第4次国際規格だとオブジェクト指向すら組み込んでたりするから怖いが。
むか～し N-BASICって言語で開発したけど、
変数ぶつからないようにするのが工数のほとんどだったなぁ。
今 思い出しただけでも怖いっす。
>>850 END-PERFORM があるなら、あっても良さそうな気がしますけど。
（cobol65しか経験ないので、よくわからない）
デバッガで値を見るためだけにグローバル変数が定義してあって1000個くらいある。
グローバルスコープそのものが悪いとは思わない。
ブロックで閉じた空間を作れないのが最悪かと。
ある関数のそばのグローバル変数が変わると遠くのソースで竜巻が起こる
バタフライモデルだな
友達の友達はまた友達だ
みんなで作ろう副作用yの輪...
循環参照ですね。わかります
かくしてエントロピーが増大していく。
function 列を削除する(削除列){
for(全ての行){
if(削除列==1){
2列目の値を1列目にコピー;
3列目の値を2列目にコピー;
4列目の値を3列目にコピー;
5列目の値を4列目にコピー;
}else if(削除列==2){
3列目の値を2列目にコピー;
4列目の値を3列目にコピー;
5列目の値を4列目にコピー;
}else if(削除列==3){
4列目の値を3列目にコピー;
5列目の値を4列目にコピー;
}else{
5列目の値を4列目にコピー;
}
5列目の値を削除;
}
}
【変更仕様：入力列を5列から60列に増やす】
近頃のエディタなら楽勝で変更できるな
findとfindstrを組み合わせるだけでもたぶんいけるよな
というかsedとか知らないんだろうか
そして
>>861のコードを動的に生成するスクリプトを書いて
どんなに仕様変更が来てみビクともしないぜ！という
あさっての方向に突き進むのだ。
メタプログラミングであさっての方向へ突き進め。
>>853 俺もやってたよ
しかも結構大きい奴なんで chain で30本くらいのプログラムを繋げて動く奴
C言語の仕事をする様になってからは一切触れていないけど、今なら絶対に書けない自信が有るよ
.
テスト
>>866 書けない以前に、話を聞きたくないよねw
「ｘｘのような、仕様作成時点で考慮されていなかった改修が発生してしまい」
って言うと必ず「ｘｘね、あー、それは簡単だから」
って言って工数増加を認めない上司がいる。
おまえ、開発した事ないだろ（年齢と立場的に）。
お前がやってみろ、って言いたい
残念ながらスレ違い
作成日：1996年8月○日
辞めたくなるようなことか？
ただの甘えでしょ
>861
面白いw
...モレだったらもう一つルーチン作るかな
function 列をコピーする(削除列,最終列){
for(X = 削除列+1 ～ 最終列){
(X)列目の値を(X-1)列目にコピー
}
}
#↓最終列を定義するか、パラメータを増やして渡す
function 列を削除する(削除列){
for(全ての行){
"列をコピーする(削除列,最終列)"を実行
最終列目の値を削除;
}
}
// 2011/09/8 dareka2 引数追加
// 2009/08/4 dareka1 引数追加
//obj.setparameter("aaa bbb ccc ddd eee fff ggg hhh iii jjj kkk");
//obj.setparameter("aaa bbb ccc ddd eee fff ggg hhh iii jjj kkk mmm");
obj.setparameter("aaa bbb ccc ddd eee fff ggg hhh iii jjj kkk mmm nnn");
の繰り返されてる所見ると、最初に改修した奴がどうしてこういう風にしなかった、と思う・・・
obj.setparameter("aaa bbb ccc ddd eee fff ggg hhh iii jjj kkk"
+ " mmm"
)
>>877 こういうのなら見掛ける。
// 2011/09/8 dareka2 引数追加
// // 2009/08/4 dareka1 引数追加
// // #define D_PARAM "aaa bbb ccc ddd eee fff ggg hhh iii jjj kkk"
// #define D_PARAM "aaa bbb ccc ddd eee fff ggg hhh iii jjj kkk mmm"
#define D_PARAM "aaa bbb ccc ddd eee fff ggg hhh iii jjj kkk mmm nnn"
[途中省略]
obj.setparameter(D_PARAM);
うちが良く受注するところの規約はこうだな。
// 2011/09/8 dareka2 引数追加開始
//// 2009/08/4 dareka1 引数追加開始
//// #define D_PARAM "aaa bbb ccc ddd eee fff ggg hhh iii jjj kkk"
//#define D_PARAM "aaa bbb ccc ddd eee fff ggg hhh iii jjj kkk mmm"
//// 2009/08/4 dareka1 引数追加終了
#define D_PARAM "aaa bbb ccc ddd eee fff ggg hhh iii jjj kkk mmm nnn"
// 2011/09/8 dareka2 引数追加終了
何故バージョン管理システムを使わないのか？
使わない理由が理解できない。
バージョン管理システム使っててもパッと見で改変が分からないのはやっぱ
嫌だ、っていう人もおおいよ
まあ、コメントアウトしててもぱっと見では分からんがなｗ
>>880 うちでは使ってるが納品先が使わない。
使わない理由は、コードを見ただけで変更履歴がわからないからだそうな。
納品したコードをまともに確認する所なんてあるの？
>>885 その後の保守を社内や別ベンダでやる事もあるからね
まあ、実際の作業上は邪魔になってるだけでしょうよ
888 ：
仕様書無しさん：2011/09/14(水) 22:51:16.51
規模にもよるけど持つべき機能が分かっていればソースの変更点なんかどうでもいいな
いちいち変更点を残すのって初期段階でほぼ完璧なソースであることが前提じゃないか?
今後5年10年20年、そのソースに関わる全員がそうだったら変更点なんか知らなくてもいいんだがな
↓ ここでTDD信徒が一言
↑ 矢印厨
このスレみたらプログラマになれる気がしてきた
名刺作るだけだろ
プログラマになるのはとても簡単だ。
しかし幸せなプログラマになるのはえらく困難だ。
>>879 まさに今そのコメント規約だがコメントアウトの量が実ソースより多い関数とかざらにあってだな…
マジで勘弁しろ
{
// まずここに入ることは無い
}
>>879 Cでそれは、なかなか良く考えられている規約だ。
>>896 デッドコードが無いと通せない規約でもあったんだろ
>>896 基本呼び出すAPIがエラーを返す可能性がある、という作りになってるものなら
エラーハンドルいれないとね。
実装側にエラーが１か所もなくても
ってうかC、C++系だとエラーも例外も返さない事になってる処理が
Exception返したりするから最上位とかでCatch(...)で
全エラーの可能性をハンドルしてたりするわ
>>899 どういう規約？
>>900 エラーの処理ならログくらいは埋めるはずだ
そもそも、『ここに来るはずはない』場所にはバグ検出の観点からログを埋めるべきだよ
902 ：
あぼーと：2011/09/22(木) 19:36:00.91
あぼーと
アサート嫌いなんだよね
ＭＳのコード自体が出ないはずのアサートがばしばし出る。
>901
例えば
・if には必ず then と else の両方のブロックを書かねばならない
という規則だったとして、
・ある条件が成立するときにはこの処理をする（成立しなければ何もしない）
なら、else ブロックが空になるわな。
あるいは select ～ case で、default になることはあり得ない（全ての可能性が case で潰してある）
場合とか。
その規則が妥当かどうかは別として。
if(isXXX(a) != false)
ふん、まだその段階か
if (isXXX(a) != true)
boolean IsNotXXX(xxx a) {
if (IsXXX(a) == true)
return false;
else
return true;
}
10年くらい前にこんなのがあったのを思い出した
無駄な関数作った しな人、どうしてるかな
実はそんな規約があったとかじゃないよなｗ
すまん 見てるだけで頭が禿げてくるんだが。
isなんとかって使った記憶ないなぁ。
自分でif文でやってたのかなぁ。
1秒で直せるものを直さずにブータレるほうがカス
if文は等号の比較のみ許可、偽の場合の処理は else節に記入するという規約があった。
結果、こんなコードが大量に。
if (isTestXxxx() == true) {
;
} else {
...処理...
}
請負開発の会社にバイトで入ったら
ほんとにそんな規約の塊で
欝になりそうだぜw
そんなことしてどうするの
水増しする為の行数稼ぎかね
１行で出来る処理も１００行で書いた方が客の目には頑張っているように見えるらしいし
一文ないと処理の書き漏れと区別つかないからじゃね？
コメントでも書かないと意味ねーけど
デバッガで追えるなら
if(xxx){
}
だけでいいんだけど、今のとこログでしか処理を追えないパッケージ（どうなのそれって？）なので
if(xxx){
// 正常
log("正常");
}else{
// 異常
log("異常");
return;
}
みたいに必ず正常／異常のどっち通ったかログはかせてるわ。ログがないからOKっていうほど甘くないので
カバレージ通すために必要な場合もあって
>>904 そんな狂った規約が有ったらその段階で辞めようと思うなｗ
switch() で有り得ない default を書くのは普通じゃね？
>>908 それ凄いな
>>908 コピペで済ますでなくIsXXX作ってるのは偉いし
IsNotXXXでちゃんとIsXXX呼んでるなんて立派なもんじゃないですか
あー会社辞めたい
>>914 「空行を書け」という規約もあったんだよ。
>>912 そして、isTestXxxx()関数がtrue/false以外の値を返すと正常に動作しないというバグ発生。
いやそれはバグというか…
フリーダムコードの俺もキチンと静解析ツールを使うと、ええ加減に書いては
ダメなのと、社内のCMMに通過しない為、俺はこれらに引っ掛からないような
コーディングに合わせたが、お金貰っての仕事なので、これはこれで仕方がないかと。
この文章力ならフリーダムコードとやらも、さもありなんという感じ。
義務教育を受けてきたとは思えないほどの酷さだな
PHPerだけどCが出来る人は、どんな言語でも適応出来るイメージがあっけど
そうでもなさそうですねｗ
>>928 言語なんて関係ないよ
単純にものを作るだけならリファレンス片手で十分対応できる
問題は、オブシだデザパタだにこだわりだした時だ
Cできちんとした命名ができたり、可読性を意識したコーディングが
できているかどうかによる気がする。できてる奴は他の言語にいっても
適応できる。
本当に可読性まで意識して出来ている人は
何の言語を今やっているとしても対応出来そうな気がする
可読性を意識しすぎて変数名などが長くなってしまいます。。。
名前で対象変数の意味や目的を全て表そうとしてしまうからそうなってしまうようです。
そういうのは宣言時のコメントに書くようにして名前は適当に短くした方がいいかなぁ
変数の名前が長くなりすぎるってのは、あんまりピンと来ないな。
iで済ますところをindexForLoopStartAtZeroToSizeOfListMinusOneとかにでもしてんのかと邪推。
エンティティAbrakadabraってのがあったとして、その名称を表すフィールドに
abrakadabraNameとかは見るけど、nameで十分だろと思うことはあるな。
status
ループ変数などどうみてもテンポラリなものはは短く、
論理的に重要なものは長くそしてコメントを書く。
ってな感じでいいのでわ？
規約を作って守る事ですよ。
forLoopNoHensuudesu
変数の名前が長くなりすぎたら逆に可読性落ちる
コメントで補ったりを考える前に、上手な人やOSSのプロダクトの
ソース呼んで命名の感覚身につけるほうが先。
と言われたので、このモジュールの完成は3ヵ月後になります
androidのソース真似して、全フィールドの頭にmを付けたらバカにされました><
>>939 メンバ変数の変数名に「m_」とか「_」っていうプリフィクスを付けるのは、そんなに珍しい事では無いと思うけど…？
たまに何の略か分からないprefixとかあるな。
変数名にしても何の略か分からない文字がよく含まれてる。
リソースが少なかった時代の名残で、微妙に一文字だけ省略した略称とか使われるとちょっと腹立つ。
>>941 っていうかプリフィイックスつけるな、って言われる(´・ω・｀)
>>943 何故付けてはいけないのか聞いてみたら？
つけない理由より付ける理由の方が妥当ならルールを変えればいい。
メンバ関数作ってるとメンバ変数かどうか忘れるので
プリフィクスかサフィクス付けた方がいいかなと思いますけど。
m_data とか _dataとか data_とか。
m_を付けとかないと、ローカル変数と見分けがつかなくなるぞ。
（賢い開発ツールなら見分けてくれるけど）
ハンガリアン記法は古い
this付けるって手もあるけど、アンダースコアの方が簡潔でいい気がする
ここは初心者スレか？
ははは そらそだ。
でも まぁ基本って一番大切かと。
m_付けないとメンバ変数て、すぐわからないの？
静かな戦い
‥‥‥‥ certain.cpp ‥‥‥‥‥
#define private public
#include "others.h"
...
‥‥‥‥‥‥‥‥‥‥‥‥‥‥
‥‥‥‥‥ others.h ‥‥‥‥‥
...
#ifdef private
#undef private
#endif
class MyClass
{
public:
...
‥‥‥‥‥‥‥‥‥‥‥‥‥‥
>>951 実装してる時は頭に入ってるからいいけど、後でみた時にぱっと見で解りにくくなるよ。
それは開発環境がヘッポコなだけ。
ざっと見て分からないコードは構造化をやり直せという理想論
エディタが色分けすればいいだけ
んー固定環境ならそれでいいんで無いの。
自分しか触らないなら。
っていうかthisポインタとかは必ず付けてほしい
命名規則でDBの項目と同じ名前つけろとかいうところだったりすると
同じ変数名混在でSetterとかどっちがどっちか分からなくなってしまう
XXXXCodeという名前のプロパティと
setXXXXCodeという名前のプロパティ（XXXXCodeのセットという意味）
１つのクラスに混在させんな
private DataSet dt;
public int Count() {
int i
for (i=0; i < dt.Tables[TBL_NAME].Rows.Count; i++);
return i;
}
>>957 色々な環境でそうすればいい。
他の開発者もそれぞれ自分にあった色分けをすればいい。
みんながエクリプスを使って、みんな同じ設定とか、
一体どこのドカタよ？
H(の下請け)には、マイクロソフトの提携会社で日本一の技術力と自称しながら、
全部大文字を重要変数とか、メチャクチャいう規約を作ったクソがいます。
毎日連絡なしでコーディング規約を変えたり、毎日契約外の仕事をタダで押し付けようと一日中電話をかけ続けたり。
マイクロソフトの品質管理にサンプルコードの全てをダメ出し否定されながら、「わかってやっているから問題ない」
栃木に本社を持つ東日本なんちゃら。
マイクロソフトが、今もなおサイトにあの会社の名前を本当に載せていたのを見て、
神は死んだと悟った。
客寄せパンダは姿消したけどね、あそこ
>>964 ゑ？
あそこに、客寄せパンダになれる技術者が存在したの？
ベテラン社員も何もかも当時大卒1年目の俺以下というか、
技術的にも人間的にもゴミクズしか在籍していないと思っていたが。
本家の方
ジョブズみたいに華々しく引退ということはなかったけどね
>947
『スコープをあらわす接頭子』もハンガリアンと呼ぶの？
ハンガリアンと呼ぶのは、型や用途を省略したものだと思ってたのだけど。
付与された接頭辞が結果的にスコープを判断する材料となった、という場合をどうとらえるかによるだろうな。
ハンガリアンの厳密な定義を求めているなら、多分にスレ違いな結果を向かえるだろうな。
//081112 wada XXXXXXX write
//for(int i=0; i<N; i++){
// int custom_No[size];
// ...
//}
//081201 itoh XXXXX write
//int custom_No[size];
//for(int i=0; i<N; ++i){
// ...
//}
//090323 wada XXXXXXX write
//for(int i=0; i<N; i++){
// int custom_No[size];
// ...
// string baka = "itoh";
//}
//090512 itoh XXXXX write
int custom_No[size];
for(int i=0; i<N; ++i){
...
//string baka = "itoh"; //wada write
}
>>967 違うんじゃないか？
昔から行われていた習慣をマイクロソフトが広めたって記憶が有るんだけど
971 ：
仕様書無しさん：2011/10/04(火) 20:15:19.23
とりあえずハンガリアンを語るならジョエルの記事くらい前提にしてほしいわ。
そして今はマイクロソフトが非推奨としている。
Windowsのソースとかその場で死にたくなるほど酷いんだろうな・・・
バッチファイルを毎週出しているくらいだもんな。
修正不可能なセキュリティホールがいくつも発見されてそのまま放置されているんだろ？
Appleの元開発者もOS Xは古いコードやらなんやらで、糞の山だから書き直すべきだと言っていたな。
Linuxだってリーナスみずから作ったといわれるコアを除いたらクソでしょ
大人数で作るシステムってそうなる運命だよね
どんなにルールを設けても個々人のクセで作り上げられていくから
コアがクソだったという話は聞いたがｗ
978 ：
仕様書無しさん：2011/10/06(木) 19:57:08.11
コアこそ386べったりのクソコードだったんだが…
結論：世の中全部クソ
まともに管理できる限界を超えると急速に糞化が進むよね
マジメ子が開き直ってチャラ子になるように
いやそれはおかしい。
まあ、大規模になれば管理できなくなるのは自明の理。
大規模は管理じゃなくて下への押し付けだからね
作業量過多、ストレスで下は壊れるし
プロジェクト崩壊も目に見えてる
しかし、どうにかなってしまうのが不思議なところ