プログラムの標準化

皆様は（皆様の会社では）、
プログラムの標準化として
どのようなことをされていますか？

実は私の会社では、基本的に１プロジェクト１人で作成しているのですが
自分の好きなように気の向くままプログラムを組んでいるため
他人が見ると訳が分からない
プログラミングの実力の差がによって
同じ成果物のものができない。
（出来たプログラムの信頼性・安定性などの完成度がマチマチ
バグの多い人・少ない人、早くできる人・時間のかかる人・・・
ひどいときだと、与えられた案件が完成しきれないなんて奴も居る）

変数やクラスの命名方法、判断処理やループ処理の書き方など
コーディング規約はあるのですが、
その他に、どのようなことをされていますでしょうか？

ウチの課長の出した標準化の目標は
・作った本人でなくても（そのシステムの開発に係わった人間でなくても）
　容易にソースが追え、トラブルなどがあった時
　作った本人でなくても対応が出来るようにしろ

・プログラム技術力のあるなしに関係なく
　同じ成果物のものが出せるようにしろ

教えてください

課長＝素人

>プログラム技術力のあるなしに関係なく同じ成果物のものが出せるようにしろ

無理

課長は１０年くらい前まで
プログラム開発をやってました。

俺たちと一緒にソフト開発はしていません

課長は、
「マクドナルドは、きちんと標準化されていて
それがマニュアル化されている
だから、入ったばかりのアルバイトの子でも接客できるし
いつもポテトを作っている○○さんが休んでも
変わりの人がポテトを作れる。

今、みんなが同じ成果物のものが出来ない
作った本人でないと分からないというのは
標準化されていないからだ
標準化すれば、みんなが同じ成果物のものが出来るし
作った本人でないと分からないということもなくなる」

と言っています。

自分は「そうかなぁ？」って疑問に思いますが・・・

まぁ、課長はその上の人から
「みんなが完成度の高いものが作れるようなんとかしろ！！」
って言われているみたいだが・・・

>１プロジェクト１人で作成

設計、コーディング、システムテストまで一人でやってるって事？
どういう会社だ。

>>5は>>1です

元請けは別の会社がやっていて
ウチは外注のソフト屋です
ＳＥはその元請け会社の社員がやっています。

といってもそのＳＥからやってくる仕様書は
機能概要が羅列してあるだけですが・・・

>>5
元マック店長候補だったプログラマーから一言。
マニュアルらしいマニュアルなどない。
入ったばかりのバイトでも接客はできるが、オーダーができん。
マック専用の短縮用語がわからんから。まぁフルネームでやりゃーいいんだけど。
ポテトはできるかもしれん、ボタン押すだけだから。
だけど分量分けや、塩の配分などは熟練の腕が必要。

マックがバイトで回るのはオートメーション化の結果です。

ていうか。。。
それがシステム開発の長年の懸案事項だったわけで。。。
ここで簡単に答えが出るなら苦労しないだろ。

>1
その課長は何もせんのか?
開発業務の標準化策定プロジェクトを発足して、リーダーは課長にさせてみたら?

基本的に固定メニューで、毎回同じ物を作るマックと一緒にしてどうするという気が。
接客だって、新人とベテランが同じレベルで行える訳でもないだろうに。
とりあえず、XPを勉強してみたら？

ソースコードレビューかな。現実的な方法は
ま、時間があればの話だが．．．

通常の産業の標準化が
誰でも同じモノを作れるようにすること、だとしたら
ソフトウエアはコピーすれば終わりだからなｗ

もし仮にマックにたとえるなら、
新しいメニューを決める際に
受けのいいメニューを誰でも考案できるように
思考過程を標準化できないか、と言ってることだからな。
そんなに簡単にできるわけがないｗ

・プログラム技術力のあるなしに関係なく
　同じ成果物のものが出せるようにしろ

はぶっちゃけ私も疑問に思っています
そんなこと出来るのかって

ただ、今、あるシステムがトラぶっていて
プログラムを作った人が会社を休んでいたりすると
対応できない
（緊急でなければ明日まで待ってもらい
緊急の場合は休んでいる作った人の携帯を鳴らして対応してもらう）
状態になっているので、
それはちょっとまずいのかなぁって思っています。

>>14
>プログラム技術力のあるなしに関係なく
>同じ成果物のものが出せるようにしろ

これができるならプログラマは技術職じゃないってことだよな。

CASEでも使って極力コーディングをなくすこったな

↑　ＣＡＳＥってなんじゃ？

>・プログラム技術力のあるなしに関係なく
>　同じ成果物のものが出せるようにしろ

仮にこんなことが可能になるなら
そんな仕事なんてつまんなくて、やめちまうだろうな。

実は社内でも、コーディングさせるからバグが出るのであって
コーディングは極力減らして
パラメータの設定だけで、目的のものを作る方法をという
話がでています。

しかし、パッケージソフトでもないのに
ユーザーの要望や仕様の違いにどう対応させるかとか
辛いものがあります。

>>1
DQNちっくだけれど、ウチの会社では暗黙の了解的に次の規約があります。
・ インデントの統一
・ ３項演算子は禁止
・ selectは避けて極力 else if
・ if や for, while が２行異常になる場合は必ず { } で囲む
・ メソッドには面倒でも必ずコメントを付ける
・ 変数の宣言は１行１変数にして同じ行に // でコメントを書く
　　→グローバル検索に引っかかるように
・ コメントは必ず // にする → /*〜*/ でいつでも殺せるように
「スマートなソース」よりも「初心者クサくてもいいから解り易いソース」の方が
他人が見ても、自分が見ても解り易いですよ。デスッた時にこういうのが
効いてきます（ｗ

コメントを書いたほうがイザという時に助けてもらえるよ、というのが浸透すれば
他のスタッフも自発的に書いてくれるようになるんじゃないでしょうか。

>３項演算子は禁止

こういうのはイヤだな

× ２行異常
○ ２行以上　　　．．．＿|￣|○

>>21
確かに私も新人の頃は抵抗ありましたが、実際読める人とそうでない
人が居ますからねぇ。。。

＞　コメントは必ず // にする → /*〜*/ でいつでも殺せるように

うちの標準に追加ｹﾃｰｲ♪　いただきますた。

>>24
if 0

end if

でいつでも殺せますが

>19
CASEやらERPやらを使えば確かに可能だし、無駄ではない。
だが、それは新しくも何ともない「何を今更」っつー話だって事を認識してるのだろうか。
第一、特殊な(JavaだC++だといったものに比べて)ツールを使ってしまうと、そのツールの
範囲内でしか仕事ができず、仕事の量が流行廃りにモロに影響を受けてしまう可能性が。

>>25
あ、それもウチでは禁止っす（ｗ

同じ事を実現するのに複数手法があると必ず混乱しますから。
select や ３項演算子を使わないのも同じ理由です。

「自分が使いやすい」よりも「バイトの学生クンでも読める」を優先しています。

>>20
> if や for, while が２行異常になる場合は必ず { } で囲む

すみませんが、理由の説明お願いします。
C系の言語ですよね？

>>28
if((hoge()==true || hogege()==false) &&
　(hogehoge()==false || hage()==true))
　　hoge();

もう何がなんだか（ｗ

if((hoge()==true || hogege()==false) &&
　(hogehoge()==false || hage()==true))
{
　　hoge();
}

コレでｽｷｰﾘ。

>>26 なんだそれ 晒し

>読める人とそうでない 人が居る

>同じ事を実現するのに複数手法があると必ず混乱する


この手の言い分ってよく見聞きするけどさ・・・
たしかにインデントとかコメントだとかを統一した方が
見やすいってのには同意なんだけど
↑のような規約まで出てくるとと
どうもレベルの低い発想だと思ってしまうんだけどな

この辺、海外とかではどうなってんのかな
とりあえずMFCのソースとかwindowsのヘッダ見ると
てんでバラバラな感じなんだけど

>>25
・ソース全検索ツールにコメント内除外機能（「//」「/*」「*/」）有
　それが使えなくなるのは困る。

・明示的なコメントはエディタ上で色が変わる。

・コーディングは新人さんだし、お客さんもソース読むので、if使うより明示的な
　コメントの方が混乱を招かない。

・無用なインデントが増えるのが嫌だ。

などなど

>>20
二次元配列を受け取るメソッドのプロトタイプはどのように書いてますか？

>>31-32
んだから、あくまで「暗黙の了解」であって、強制では無いッス。
他の人のを手伝うときにはその人なりの規約に従いますしね。
でも、基本的には動けばおっけーです（ｗ

ただ、他の人にヘルプお願いする時には、経験的にこのようにした方が
レベルに関係無くすぐに手伝ってもらえます。

>>32
＞・明示的なコメントはエディタ上で色が変わる。
私は秀丸だし、師匠はMIFESだし、今手伝って貰ってる外注さんはTeraTermです。
ウチではエディタは統一してません。使い慣れた奴の方が効率いいですしね。
んだから、エディタに特化した規約は排除してます。
＞グローバル検索に引っかかるように
コレだけちょっと例外だけれど。

>>33
すみません、言語仕様についてはできるだけム板でおながいします。
因みに私は (char**) って書いてます。

>>29
納得しました。
条件式の部分が二行以上の時　なわけですね。

/*
　　てっきりif節のことかと思って何でそんな規約を作る
　　必要があるのかと疑問に思ったことは内緒。
*/

>>35
うちは開発前が暇だったので、開発援助マクロいっぱいつくりました。
・エディタは秀丸（もちろん購入）で統一。
・Javaコンパイラも秀丸マクロ。
・サーバへのうＰも秀丸のマクロ（とVBS）。
　（classファイルだけうＰしないようにjavaとclassを指定フォルダへ同時転送）
・サーバのログ取得も秀丸マクロ（とVBS）。
・定型文言選択も秀丸マクロ
に組み込みました。

まぁほとんど新人さんだったので。

>>36
漏れも最初同じこと疑問に思った。

>ただ、今、あるシステムがトラぶっていてプログラムを作った人が会社を休んでいたりすると
>対応できない（緊急でなければ明日まで待ってもらい緊急の場合は休んでいる作った人の携帯を鳴らして対応してもらう）
>状態になっているので、 それはちょっとまずいのかなぁって思っています。

俺もそんな感じの会社にいた。
休日平日昼間深夜早朝関係なし。毎夜、携帯電話を握り締めて寝る日々だった。
他の課は、コンピューターの連中はOPにまかせてるから宿直がなくて楽でいいと言っていた。
すっげーむかついた。
宿直は、日にちが決まってるからソコだけ耐えればいいが、障害はいつくるかわからないから精神的に休めないんだ！！！

ここで言ってることは割と形式的なレベルなんだよな。。。

オレ的ルールでたとえば

・30行以上の関数は書かない
（ただし、初期化の時など処理を並べるだけの時は例外）

・引数を4つ以上にしない
（WinAPIはどうなるんやー、という突っ込みは禁止）

・ifやwhileのネストは3つまで

とか。。。
ただオレがあんまり複雑なプログラムを書いたことがないからか？ｗ

>>29 ま、趣味の問題だけど
> if((hoge()==true || hogege()==false) &&
> 　(hogehoge()==false || hage()==true))
> {
> 　　hoge();
> }
if((hoge()==true || hogege()==false)
　　&& (hogehoge()==false || hage()==true))
{
　　hoge();
}
次の行の先頭に論理演算子を持ってきた方が好み

オレ的ルール

・5行以上同じことをする時は必ず関数で括り出す

・publicメソッドから同じクラスのpublicメソッドを呼ばない
（オーバーロードの時以外）

もう既に、件の課長の望んでるところから話がずれてるね
課長の思惑は、目的としては非常に高度でありながら、
非常に低レベルな思考に基づく「無い物ねだり」だからね

>>42
課長をバカにすんなよ！

なんかメッサ良すれじゃねーか？（ｗ

俺的ルール。

・基幹関数と機能関数にわける。（基幹関数＝関数をコールする関数、機能関数＝実処理関数）
・基幹関数には、条件とループ以外の処理を書かない。
・機能関数ないでは、標準関数やAPI以外の関数をコールしない。
・１関数＝１機能
・グローバル変数名をソースに書けるのは基幹関数から機能関数への引数としてだけ。
・グローバル変数を使用するときは、宣言した横に値をいじる関数名を明記しておく。「それ以外でいじるなよ！って」
・関数の前にコメント（引数や戻り値、ヒープ利用した戻り値の場合は注意）
・複雑な関数には必ずコメントを全面的に入れる。長さはあんま関係なし
・constなどは必ずつける。
・引数は６個以上のときは、再考する。（どしてもだめなときもあるけどさ）
・ifネストは３以上ボツ。
・スタックメモリを一度に1kbyte以上使いそうなときは、ヒープで行う。

>>43
がんじがらめだな

口火を切ると他の人のオレ規約が聞けてウレシイ♪

これまたＤＱＮ規約というか、オレ規約なんだけれど、
　if(strHoge.subString("xxx",0).equals("test"))
なんてのは
　String work;
　work=strHoge.subString("xxx",0);
　if(work.equals("test"))
なんていう風に分解して書いてます。この方がデバッグしやすいですしね。

>>46
おれもそうする。
ifの中で関数をコールするやり方は昔やってたが、今は絶対にやらない。
if((hoge()==true || hogege()==false))
{
　　hoge();
}
だとどっちが失敗したのかとか知りたいとき泣くことになるし。

>>47
そんな冗長な書き方なんてしねーよ

if(hoge() || !hoge())
　　hoge();

プロはこうさ

>>48
ちゃうちゃう。
boolean hoge_ret,hogege_ret;

hoge_ret = hoge();
if(hoge_ret == true || hogege_ret == false)
　hogen();

が俺の書き方。

>>49は失敗
boolean hoge_ret,hogege_ret;

hoge_ret = hoge();
hogege_ret = hogege();
if(hoge_ret == true || hogege_ret == false)
　hogen();

>>48
//　if(hoge() || !hoge())　//　ソースはよく読むように。
　　if(hoge() || !hogege())

>>49
それじゃwarningがでちまうぜ、コボラーさんよ

宗教や好みの問題はどうでもいいッス。

皆さんの経験から来るテクニックをいろいろ聞きたいなぁ〜っと。

>>44
> ・スタックメモリを一度に1kbyte以上使いそうなときは、ヒープで行う。
最近は平気で数k以上使ってるな．．．
さすがに数Mbyteになったら考えるけど

・ifでネストする前にreturnできるなら例外なくreturnしてしまう

以上

>>54
処理速度やリソース量なんか、ホント気にしなくなりましたねぇ。。。
ウチはカリカリチューニングよりも「まず動くこと」が求められる
開発案件が中心だからなんだけれど、いい時代です。

>>55
あぁ。。。それも禁止にしてますねぇ。。。

↓のようにして、絶対にメソッドの途中で return や exit をしないようにしてます。
String MyFunc(){
　String retmsg="";
　　：
　return retmsg;
}
こうしとくと return の前に1箇所だけデバッグ出力埋めれば簡単に戻り値を確認
できますし。

//　なんだか私のはデバッグのテクニックばっかですねぇ。。。

>>57
まっはreturnの利点はデバッグよりバグを防ぐことだとおもうでよ。

処理対象外になったのにずーーっとreturn値を保持しつつ関数のラストのreturnまで行くより、
処理対象外ならさっさとreturn FALSE；とかしてしまうって技。

boolean ret = false;

ret = hoge1();
if(ret == false){
　ret = hoge2();
}
if(ret == false){
　ret = hoge3();
}
return ret;

より

boolean ret;

ret = hoge1();
if(ret == true){
　return ret;
}
ret = hoge2();
if(ret == true){
　return ret;
}
ret = hoge3();
return ret;

>>5
この辺って、要するにﾃﾞｻﾞﾊﾟﾀとか
Strutsなんかのﾌﾚｰﾑﾜｰｸ周辺の話になるんじゃない？
それでも技術レベルに無関係に、とは行かないけど。

＞・作った本人でなくても（そのシステムの開発に係わった人間でなくても）
＞容易にソースが追え、トラブルなどがあった時
＞作った本人でなくても対応が出来るようにしろ

言語実装にもよるが、変数名に 2byte を許可して、目的を明確にする。

ex.)
boolean 条件○○が起こらなかった、或いは起こったもののユーザにダイアログで問い合わせた結果無視して構わないことになったときに真となる;

条件○○が起こらなかった、或いは起こったもののユーザにダイアログで問い合わせた結果無視して構わないことになったときに真となる = true;
if (条件○○が起こったとき真を返す関数()) {
　ダイアログのコンストラクタ(ｒｙ

誰でも同じ物が作れるようになったら
賃金も上がらなくなるぞ。

ベテランも新人もみんな同じ最低賃金だ。

＞・プログラム技術力のあるなしに関係なく
＞同じ成果物のものが出せるようにしろ

これはかなりのレベルまで可能だよ。引き換えとなる条件があるけど。
デバッグ等で生産効率がめっさ下がり、
かつ成果物の動作速度もめっさ下がる。
それでよければ、知ってることだけ駆使させればよい。いつかはできる。
リソース占有か何かで問題が出る分は、
技術力のある奴が、どんな問題でも回避できる OS を書けばよい

>>61
＞誰でも同じ物が作れるようになったら
誰でも同じ物が作れるようにする方法を考えるのは
誰にでもできるわけじゃ無いっす。

その方法さえ確立しちゃえば実装はコーダさんにでも
任せちゃえばいいんじゃないかなぁ。単価安いし。

まあ無理だな。
できたとしてもクソみてーなのしか作れねーよ。
くだらねーことに時間つぶさねーで、フレームワークとデザパタでも
勉強するんだな。

>>1
> ウチの課長の出した標準化の目標は
> ・作った本人でなくても（そのシステムの開発に係わった人間でなくても）
> 　容易にソースが追え、トラブルなどがあった時
> 　作った本人でなくても対応が出来るようにしろ

コーディング規約を作るのは当然として、それに加えて。
(1)エラー発生時のログ出力の標準化。発生モジュールの特定と、条件などの把握ができるように。
(2)リバースツールの使用。（詳細設計情報の散逸を防ぐ、呼び出しツリー図などのプログラム構成図の
自動生成など最初に使うと決めておけば、労力よりメリットが大きいと思う）

> ・プログラム技術力のあるなしに関係なく
> 　同じ成果物のものが出せるようにしろ

技術力のないメンバーでもそれなりの成果物を、という意味にとれば、
フレームワークの採用ということになるのだろうか。
（フレームワークの導入or開発にそれなりにコストがかかるが）

プロジェクトごとじゃなくて、テクがいる部分といらない部分で
担当分けるのはどう？
基幹関数はテクない人が担当、機能関数はテクある人みたいな

> ・プログラム技術力のあるなしに関係なく
> 　同じ成果物のものが出せるようにしろ

そんなことしたら、技術力のある人のモチベーションが下がる。

>67 なぜに？

メンテを多少意識した規則を作ったところで、ﾓﾏｴが設計した
糞システムの保守なんか、だれもしませんよ。

お客さんもブチ切れですから、納品したらサヨナラだろ。
どうせ捨てられるだけなんだから、無駄なエネルギー使わせんな。

>>69
言葉尻をそのままで送ったとすれば、お前社会人として相当イタイな。
あらゆる意味で。

>>1
スレ違いかもしれんが、プログラムの標準化の他に
・設計書(フォーマットの有無)
・進捗管理(フォーマットの有無)
・打ち合せや問合せ(顧客や社内)の議事録(フォーマットの有無)
・これらのドキュメントや納品物の保存、管理方法(紙ベース/サーバに集中)
この辺について課長さんは何か言ってましたか？
障害対応で他人のコードしか参照できないはつらそう。

>>70
思うだけです。誰にもいいませんよ。

プログラムの標準化じゃなくて、プログラムを作るプロセスの標準化、定型作業化を
検討するのが遠回りのようで実は近道だと思います。

プログラムのラフな設計構想できた時点で、特定の経験者にレビューして
もらってからコーディングに着手することを徹底するだけでも
プログラムの形はかなり整うと思います。

コーディング規約を守るためにチェックリストを作って、コンパイルアップした
プログラムをチェックする、なんてこともしてみましたが、
「せっかくコンパイルアップしたプログラムをたかがコーディング規約のために
直したくない」気持ちがあるから直されなくなる可能性が高いです。

プログラマーが修正指示を受け入れてもいいと思える段階のうちに
修正をさせるとか、テンプレートを活用して初めから標準形式しかならないように、
といった工夫をする必要がありますね。

>>73
プログラマの心理を良く知っている発言。すばらしい。

ふぁっ、くしょん！

硬直した標準化はむしろ状況を悪くする。押し付けにしないことだ。

>>76
はげどー！！

それに多くのプログラマは自分なりのポリシーなり美学があるからね。

コーディング規約みたいなものをコンパイラオプションとして
与えられる機能とか欲しいな。そんな機能がついてるコンパイラ見たことある？
任意の機能をパーサに追加できるというか

LISP

>>78
VBとか（ｗ

勝手にインデントしてくれちゃったり、引数の前後にスペースを入れて
くれちゃったり、大文字小文字を勝手に直してくれちゃったり。
まるでお行儀の悪いMS-Officeみたいで二度と使う気になれん。

・・・が、VBもMS-Officeも使い続けているという罠。

>>44
TRUEで比較すんな



誰かﾂｯｺﾝﾃﾞやれよ

>76
>77

そうなんだよねー。
ルールは一度作られると、
それを形式的に守ることが最優先になってしまう。
「ゆるやかな標準化」ができないもんか？

三項演算子って知ってるつもりでここまでは知らなんだ。

ttp://hp.vector.co.jp/authors/VA010341/conditional.html

え？

>>83
調べないと解読できないコードの記述は避けるべきなんじゃないかなぁ。
名梨産の思想に従うと。

>>83
そんな乱暴な使い方をしてはいけない。
大体、else if のように使う場合、expressionN の型が違うと警告が出る処理系もある。

>>78
indentコマンドを使え。makeに書いておけばoK

indentはCでしか使えない

>82
その辺はやっぱりXPじゃないの？

っつぅか、標準化や業務プロセス以前にそのｶﾁｮｰをどうにかする必要があると思われ

標準化をするのは問題ないと思う。

ただ、標準化を現場を知らない人間が勝手に作って、それを押しつけられるのが問題。
では標準化を現場の人間の話し合いで作ればいいかというと
現場の人間にはそんな時間がないのが現実

まずは標準化の前にゆとりを作りましょう。

つまり課長を富士の樹海あたりに(略

>>71,>>73,>>90
禿げるほど同意！

（オレ的注意事項）
・開発環境の構築方法を明確にする（文書化しておく）
・ビルド方法を明確にする（文書化あるいはスクリプトにする）
・ソースコードのディレクトリは絶対パス固定にしない
＃こんなことすら徹底されてないところもあるのよ

>>81
TRUEで比較したらあかんの？

>>83 のリンク先、
「余計なお世話だ莫迦」としか思えない。

二次元配列を受け取るメソッドのプロトタイプはどのように書いてますか？

にじげん（*array[],int number_of_array)

>>>93
FALSEのみ0だと定義されている。
TRUEは!FALSEなので・・・厳密には1ではない。
よって、処理系によってはTRUEで比較すると引っかからない。
言語仕様を理解すればこんな比較は避けるべきだと思えるようになる。



誰かﾂｯｺﾝﾃﾞやれよ。

>>97
44の書き方ならぜんぜん問題じゃないじゃん。
if(ret)
でやってたらあかんかもしれんけど
if(ret == true)
ならなんも問題ないんでは？

>>98
もれもそう思うが・・・。なんか問題あるんけ？
問題のあるソース例きぼーん。

>>83
デバッグ用にこんなのはよく作るけどな。
ヘッダに書けるし配列使うのと比べて安全だから便利だよ。

#define enum2str(e) (\
　e==enum1?"enum1": \
　e==enum2?"enum2": \
　e==enum3?"enum3": "enum?" )

FALSEが0なら!FALSEは1ですが

#define truep(test) ((test) != 0)
#define falsep(test) ((test) == 0)

template<class T> bool truep(T test) {return test!=NULL}
template<class T> bool falsep(T test) {return test==NULL}

真偽値をさらに比較するのって冗長。
if( (n > 19) == TRUE )
こんな書き方してるコード見たら変だと思うだろ。

>>104
それと、
boolean a=true;
....
if(a == true)
はぜんぜん別物だろ。

ってか無理やり変にみせるためにやってるだけやん。

C/C++しか知らないで、Java言語仕様を知らない知ったかが約１名いる

>>106
納得させる例題だせば？

>>105
つまらんネタをいつまでも引っ張るなよ。

>>105
同じだよ。


あと、暇があったら、有名なオープンソースのソフトのコードでも調べてみ。
そういう書き方してるのって、ほとんど無いと思う。

>>108
じゃー納得できる例をだして結論づけて。肯定否定どっちでもいいから。

>>109
有名なオープンソースのコード＝お手本になるコードの書き方・・・？

enum bool {false,true} ;

#define IsTrue(exp) ((exp) || ((exp)==TRUE) || (((exp)==TRUE)==TRUE) || ... )

C++ でも Java でも、

　　n > 19

の値は true または false しか取りえないから、

　　(n > 19) == true

というのなら問題ない。見やすいかは別として。

>>111
まあ、机上の空論でなくて実際にプロジェクトを成功させてる人たちの
書いたコードだしね。

みんな・・・。もうこのネタやめへん？
肯定派も否定派も相手にとどめを刺す例だせないみたいだし。
俺は、if(a==true)って書く派だけどさ。「定数の値によって動きが変わるプログラムはくまん」

話題は変わって、派生ってうざくない？

粘着sage

>>115
ならコボラーをみならおうっ！！

もしaが真であることが真であるならば・・・

> 俺は、if(a==true)って書く派だけどさ。「定数の値によって動きが変わるプログラムはくまん」

意味不明

>>119
おまえ読み方偏りすぎ。ふつーに
もしaがtrueならって読め。（ｐu

>>120
#defineで定義された値が変わったからといって、挙動が変わるプログラムはくまんってことやろ。
まぁ、116当たり前すぎること言ってる。

C++やjavaのtrueが1なのは周知の事実だけど、
Cで作られたものやライブラリなどで再定義されてる真偽値型には
#define TRUE (!0)
なものもある。だから、「真偽値で真なら1だ」と決めつけるのは危険だ、という話だろ。

まぁ普通滅多に見ないけどな。条件文で定数を右項に書くのと同じようなもんだ。

>>81,>>93
がアホなことやってっから糞スレになったじゃねーか。

> 俺は、if(a==true)って書く派だけどさ。「定数の値によって動きが変わるプログラムはくまん」

delphi では、 true は、0xFFFFFFFF。
C++ では、 1。

貴方のやり方では矛盾が発生します。
物を考えるときは、『ゼロ(NULL)』を基準に考えるべきです。

if(a!=false)

これがコードを補完する正しい書き方です。

>>122
> #defineで定義された値が変わったからといって、挙動が変わるプログラムはくまんってことやろ。

それと

> 俺は、if(a==true)って書く派だけどさ

これがどう結びつくの?

>if(a==true)
こんなコード見かけたらこれ書いた奴は
文法に不慣れなんじゃなかろうかと不安になるね。
それにこんな事故中な工夫をしてるってことは
他にもわけ分からん俺ルールをたくさんもってそうだな。

> まぁ普通滅多に見ないけどな。条件文で定数を右項に書くのと同じようなもんだ。

これも、ダメテクニックの代表格じゃん。

>>125
delphiでもC++でもtrueはtrueだよ。
数値じゃない。

>>123
> Cで作られたものやライブラリなどで再定義されてる真偽値型には
> #define TRUE (!0)
!0はCの規格では1であることが保証されています。

このくだらないネタやめたいのに･゜･(ノД`)･゜･

>>125,>>126
boolean a=true;
if(a==true)
でええやん。
boolean a=true
if(a!=false)
めんどっ！
trueの存在価値がねーやん。
trueをぶっこんでるかfalseをぶっこんでるかで判断してーなら、素直に
if(a==true)かif(a==false)でかきゃーいいだろが。

>>116
覚えた言語の順番と一番得意な言語を教えて。

物事を判別するときは、あいまいな物を基準に判断するのは、移植性に
問題が生じます。　ですから、true,falseのような論理値では、false
がゼロであることを保証する値なのでそれを基準として判別すべき所です。

>>132
C→アセンブラ→C++→COBOL→Java→その他
でいいか？

得意言語？はて？仕事でやんのに言語レベルで得意も不得意もねー。

a = true;
if(foo()) a = false;
if(bar()) a = baz() and (b > 19);

if(a) or if(a==true)

の場合はどう書くんだろう???
三行目が後から追加されたら判定式も書き換えるんだろうか???

>>131
くだらないと思うならやめればいいのに。

if not initialized then 。。。
if (isNumber(n)) {。。。}

↑たとえば、こう書いたほうが素直なんじゃない?

>>133
Cみたいな論理値が存在しない言語ならともかく
論理値が存在する言語でtrueを使わないことはナンセンスです。

あなたはCOBOLにローカル変数がないんで移植性の為に
ローカル変数を使用禁止にする人ですか？

if(a==true) とかくのが良くないです。
if(a) と書きましょうよ。

>>139
では、 if(a==false)と書くべきところでは
if(!a)と書いてください。

>>140
それは、どちらの書き方でも問題ないとおもいますが？

むかし、malloc()とfree()のちょっとだけまともな論争があったが、こっちはくっだらねー論争だな。

>>136
真偽変数にand演算子の結果なんかぶっこむな！

>>137
価値観だろ・・・。

>>139
お前はすべて正しいんだろうな。

じゃ！言いたいこといってバイバイキーン

誤動作の議論は無意味だろ。基本的にしない。
N88BASICにでも移植しない限りはな。
問題はif(a==false)が読みやすいと感じる脳神経の論理的構造にある。

if(a==false)が読みにくい読みやすい、と熱くなる脳神経の論理的構造に問題はある。

コーディング規約
http://pc2.2ch.net/test/read.cgi/tech/1056716338/

論理値比較に一番問題が生じやすいのは、別の言語で生成されたＤＬＬの
BOOL比較のエクスポート関数を呼び出した時に発生します。

>>146
説得力あるな。こーゆー具体論がほしいね。

まぁ、普通false以外の値ってわざわざ書いてくるから、通常そういう場合はtrue比較はしないでしょ。

>>146
それをこの論理値比較の問題に当てはめるのか？

146=VB厨

>>146
単にそのDLL使う側が仕様を理解してないだけでは・・・

漏れは if (a == true) 派

Win32APIのBOOLは0がfalse非0がtrueだよ。

VBならTRUEは1だろ？
なんで146=VB厨なんだ？

むしろDelphi製DLL呼び出しで起こる問題なんじゃね？

俺は if (a) if (!a) 派

!a() && die();

真偽値論争スレはここですか？

自作関数でのbooleanなら
if(a==true)でもif(a)でもif(a==false)でもif(!a)でもええやん。

外部関数なら
if(a==false)かif(!a)
でやりゃーいいんやろ。

その点おさえておけばええやんなんだって。

昔、某MLで延々と繰り返されたな・・

ポインタ値やWindowハンドルみたいな、
NULLかそれ以外を返す場合はどうする？

a = create();
!a && die();

だろやっぱ。

まとめ
1. a==true派は一人
2. a==trueの目立った実害はない
3. 2.==trueである以上協調性皆無なa==true派を説得するのは困難
以上

BOOL値を返すWinAPIの中で、FALSEは0だけど、TRUEは1でもないものが
返されるものがあります。

>>161
具体例きぼん

Ｋ＆Ｒ、ストラウストラップの錦旗が立てば
大勢入れ替わるんだろうな。

>>162
ttp://www.aa.wakwak.com/~dragoon/true.htm

>>161
それはTRUE/FALSEを返す関数なのかと(ry

>>164
>たとえば、こんな関数があったとします。（あくまでも例です）
　　あ　　く　　ま　　で　　も　　例　　で　　す

>>161
具体例きぼん
つーか、「具体例」って意味、判ってる？

>>164は単なる真偽値がわかってない馬鹿の例なので・・。
不具合として障害票には乗りそうだけど。

MSのAPIは0かそれ以外が返されるとしか書いてないけどな。
TRUEの時は1だと言い切るのもどうかと。

>>164
まともに考えると、
>TRUEで比較しちゃ〜〜〜ダメ ダメ(^^;A
って結論には辿りつかないと気が。
この人は、使う変数を最初に全部0に初期化する人と考え方が似ている。

>>164の
BOOL CMyWnd::isChild()
{
　　　return GetStyle() & WS_CHILD;
}

これは、明らかにバグを埋めこんでいるとわかる。
正解は
BOOL CMyWnd::isChild()
{
　　　return (GetStyle() & WS_CHILD) == WS_CHILD;
}

>>159
(a = create) || die();

標準化されているかどうか、という判断基準で考えれば、
真偽値の扱い方、判定方法がどっちがよくてどっちがよくないか、
なんてことはどうでもいい話だと思います。

むしろ気にするべきは、やり方をそろえるかそろえないか、だと思います。

ソースレビューする人が「そろってないと読みにくい、デバッグしにくい」とか、
コーディングする人が「どっちがいいのか迷ってしまう」とかの意見がでるのなら、
どっちかでそろえればいい話だと思います。

コーディングスタイルの話は宗教戦争になることもあるので、
「どうでもよさそうな部分はどうでもいいことにする」というのも
標準化のひとつのありかただと思います。

そもそも「真」とはどんな状態なのか？
それは、ゼロ以外の全ての状態を表す。
この状態をTRUE値一つで決め付けるのは、
自殺行為に合い等しい。
TRUEという値は、単に変数への代入を
明示的に示すためだけに用いられる
特殊な値に過ぎず、比較するなんて
大それたことをしてはいけない。

>>169
BOOL型を返す関数でもか？

1と決めつけるのは良くない（・Ａ・）/ｲｸﾅｲ

>>174

>>164

「真」は「真」
「偽」は「偽」

>>176
>>170

処理系に依存しているという事実に立ち向かう勇気が必要です

>>173
条件式で使える真偽値と、真偽値型を混同していませんか？

どうでもいいや

>>170
>>179

>>160
a==true派でーす。
私の知ってる限り、==trueって書き方するひといっぱいいまーす。

a==trueよりせめて、
a == trueって書けよ

!!a
この値は何になる？

if(a)派でーす。
だってこんなうんこ議論に巻き込まれずに済むからね。

>>182
>>170

a != 0 派です。

>>188
a != falseの方がいい

>>182
>>179は>>170宛て？
残念ながら処理系には依存しません。

BOOL マクロなんか使わなければ OK。

ジャコバン派？

>>191
君はBOOLを返すか引数に使うAPI使用禁止ね。

どうでもいい事を議論して現実逃避ですか？

>>164はうちだと障害です。

false == 0(数値のゼロ)
true != false
こういう風に理解してるよ。
if(func() == true) これの何がいけないのか
分かりそうで分からない。。。。
あと、自分の作った奴見るとたいてい
if(func()==false)かif(func()<>0)になってる。
レビューとか受けたことないのに！！

>>190
真の値は言語規格で決められていなければ処理系に依存します。

>>161
で、具体例まだー？

>>196
<>
VB厨?del厨?

>>197
だからC言語の規格で決められてるじゃん。ANSIでもJISでも。

>>200
三項演算子が妙な動きをするｸｿ処理系も多いことを知らないｸｿｶﾞｷ

>>200
実際、VC++とかはどう処理されるん？
コンパイラと対応規格の対応表を誰か書いてくれ。

>>201
>三項演算子が妙な動きをするｸｿ処理系も多いことを知らないｸｿｶﾞｷ
恐らくキミは条件演算子の優先付けを知らないだけかと思われ。

>>201
なにそれ

>>202
VCは a=!0==1; a==1だよ

組込系ショボコンパイラでも三項演算子は妙な動きしないだろ

>>203
それは知っとる

hoge = (fuga == tako);

が動かんのもある


>>204
PCの世界から出てみろ

>>207
どこの田舎コンパイラの話ですか？
規格に対応してるの？

>>205 ｻﾝｺﾝ!

boolは２値だ

>>200 いつの規格からだ？

>>208
>規格に対応してるの？
「ほぼ準拠」らしい

まぁ田舎コンパイラの話だから流してくれや

ｷﾀｰ
何年何月何時何分何秒・・・

幼稚園児の喧嘩スレはここですか？

intに変換されるときtrueは1に、falseは0になる。
その逆の場合、0はfalseに、非0はtrueになる。

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

ってかtrueの値が１でないのはdelphiだけ？

C++でtureは1って決まってたっけ？

まちがえたtrue

>>193
そんなライブラリは使ってないから。

もし a なら
もし not a なら

よりも

もし a が 真 なら（もし a が not 偽 なら）
もし a が 偽 なら（もし a が not 真 なら）

の方が
読んでても気持ちいい

NYの停電はBooleanで落ちたに違いない！

>>218
true を整数型に変換すると 1 になり、true と 1 との比較は常に true と決まっている。

>217 しったかヤメトケ
型だろ

>>217
true の値は 1 でも 2 でも 0 でもなく true です。

>>1　では

> 変数やクラスの命名方法、判断処理やループ処理の書き方など
> コーディング規約はあるのですが、
> その他に、どのようなことをされていますでしょうか？

というふうにコーディング規約はあるようですね。
でも、規約が思いつきの集合体であるケースもありますし、
規約そのものについて一度見直したほうがいいのかもしれません。

個人的には、守っても意味のない規約は作るだけ無駄ですし、
規約を作るなら守る仕組みも要りますし、
規約を指導できる人を育てることも必要ですね。

とりあえずお前ら、腕立てふせやれ。

およねこboolean

プログラムの標準化を言うのなら、コーディングの元となる仕様書の
レベルの標準化は避けて通れないと思います。

この人はコーディングがうまいから仕様書は適当に書いてもいいし、
あの人は新人だから仕様書も細かく書かないと・・・と、
今後保守する仕様書についてレベルがばらつくと保守する側が大変。

仕様書の記述レベルは一定にして、コーディングする側のスキル差は
サポートの大小で吸収できれば理想的なのですが、現実はそうもいかないですね。

少し、落ち着いたか...

年食っているヤシ程、頭堅いから困るのよ。

↑勘違いは解けたか？

厳密に比較しろ
真は真、偽は偽でしかない

＞◆QgDrmJH4.k
考えてみれば、このアホが諸悪の根源だったな・・

ここでは厨房がtrue比較を推奨しているように感じたが...

漏れは if (a == true) 派

>>234
退役軍人が偉そうに…

trueと比較でも!0でもべつにかまわないけどなあ

他の言語だと〜とか、処理系依存だとか、
とんちんかんな話題を持って来たりな。

真か偽なんだからtrueかfalseと比較汁

好き嫌いや個人的な慣れあいでコーディングするなっつー話なんで。
ルール決めて守れるようになった場合のメリットとルール覚えるまでの
デメリットを話にはさむといくらでもこじれるだろう。

実践して欲しいので、１はさっさとルール策定して会社に投入しる！

>>239 それはとんちんかん違う

>>161
で、具体例は？

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

>>164の糞サイトじゃなくて、WindowsAPIでの具体例ね。

if (0 == a) 反対！！左辺に値反対！！

if (a == true) は別におかしいと思わないけど
俺、正常ならなんもしないで次、の方針で作ってるから
if (a1 == false)
if (a2 == false)
...
自然とこう並ぶ。

じゃあ、次はmalloc free論争でも。
mallocしたらfreeは必要か否か？だっけ？

mallocやreallocに0を渡したらNULLを返すか否か。

>>248
必要でしょう。DOSとか普通にメモリリークするし。

GCを使う。

>>250
そういうスワップも持たない昔のOSは、この論争では除外だと思った。

newしてもdeleteしませんが?

作ったら責任とってね

>>253
そもそもdeleteあるの？

allocator<T> を使え。

Javaのライブラリのソースを調べたら、
if(hoge == true)のところもあったけど、
if(hoge)のほうが圧倒的に多かった。

malloc/realloc は古い。

◆QgDrmJH4.kはﾀﾞﾒPG

OSがプロセスの仮想アドレスを適切に開放するので
終了時のfreeは必要ない。
という反論が来るのを期待。

そう、注目すべきは終了時のfreeなんだよ。

結局どいつもこいつも

クラス内部を全自動変数化してやれば、deleteの必要はない。

goto使いますか?

C++でexitを呼ぶのはまずい。

デストラクタで例外を送出しようとするバカがいる。

longjmpは？

if SUCCEEDED(hr)
if FAILED( hr )

>>265
exitはCの関数ですが？

longjmpは、コンパイラを最適化した場合に、自動変数参照の問題が発生する
場合がある。

こういうTIPS集を本にして売り出す
ボロい商売だケケケ

MFCのソースを調べたら、
if(hoge == true)のところもあったけど、
if(hoge)のほうが圧倒的に多かった。

そりゃCマガ特集の手口だな

>>267
longjmpはCの関数ですが？

freeしないで一時間に一回abort()します。

>>272
LinuxやFreeBSDのカーネルでもそうだと思う。

つまり問題はC++でCの危険な関数を使えてしまう所にある。
警告を出すコンパイラはあるか？

阪神まけちーた。
完封負け・・・・

やべー誤爆した

exit()はC++の関数だね。

誤爆er

if(b==true)　みたくbool値で比較してるコードって激しく素人くさい。

全言語のページからif(a)を検索しました。 約324,000,000件中1 - 100件目 ・検索にかかった時間0.37秒
全言語のページからif(a==true)を検索しました。 約2,370,000件中1 - 100件目 ・検索にかかった時間0.62秒

>>277
gccは警告ださないかな・・・
ださねーな多分・・

　　　　　　　　∩
　＼　　　　　 (　)　　　　　　　　 　 　 　 　 ∩　　　　　　　　 ／
　　 　 　 　 　 | |　　　　　　　　　　 　 　 (ヨ　）
　　　　　(　｀Д)|　　　　　　　　　　　　　　　＼ (Д´　)
　　　　　/⌒ 　 |　 　 ＼ 　 ﾎﾞｯｷｱｹﾞ　／　　 (　　⌒ヽ
＿　 　 <　く＼　＼　　　＼　　　　　／　　　　ﾉ　).ﾉ＼＼＿__
　　　　　＼( ﾖ　､ つ　　　　　　　　　　　　　⊂　　）　　＼ 　 ）　─
　　　　　　 ／ ／/　　　　 ヽ(`Д´)ﾉ　　　　　ω　＼　 　 ￣
　　　　　／ ／ ./　　　　　　 ( ∩ )　　　　　　　ヽ＼ ＼
　／　　（　￣） ￣）.　　　　 ／ω＼　　　　　（￣（￣　 ）　　＼

>>280
適切な使い方を理解していればその認識でもいいけどね。

また山崎か・・・

C++は素人が使っちゃいけない。

Cの関数を使えなくするオプションないの？

そういやOpenGLだかのC++ライブラリはmainLoopがexitで抜けていたな。あれはどうなんだろう。

C++でexitのなにがまずいかって、autoの全デストラクタすっ飛ばして終了。
排他制御やOS管理外のリソース掴んで呼び出すと深刻な問題発生

そういうことか。

>>291
C++だとスレッドのロック機構は普通スタックに作るよね。
あれも駄目なの？

>>245

BOOL GetMessage(
LPMSG lpMsg, // メッセージ情報
HWND hWnd, // ウィンドウのハンドル
UINT wMsgFilterMin, // 最初のメッセージ
UINT wMsgFilterMax // 最後のメッセージ
);

...

戻り値

WM_QUIT 以外のメッセージを取得した場合、0 以外の値が返ります。
WM_QUIT メッセージを取得した場合、0 が返ります。
エラーが発生した場合、-1 が返ります。たとえば、hWnd パラメータで無効なウィンドウハンドルを
指定した場合や、lpMsg で無効なポインタを指定した場合は、エラーが発生します。拡張エラー
情報を取得するには、GetLastError 関数を使います。

警告 GetMessage 関数は、0 以外の値、0、-1 のいずれかを返します。したがって、
次のようなコードは避けてください。

while (GetMessage(lpMsg, hWnd, 0, 0)) ...

このようなコードを作成すると、GetMessage 関数が失敗して -1（0xFFFFFFFF、つまり TRUE）が
返った場合、ループが持続し、致命的なアプリケーションエラーを発生させる可能性があります。

Win9x系のメモリモデルの話か...。

Windowsの場合はカーネルリソースなら問題ないけど、
GDIとかはまずいかも。特に9xは。

セマフォやファイル管理でもだめだろうな。あとはハードウェア関係。

それって、unexpected(),terminate()を使ってbad_exception例外を送出するのもやばいって話か？

いや、例外だから、スタックは解放されたはず...

うちのプロジェクトexit使ってますが？
やばいの？

try/__finally セッションに破棄コード持ってきて、terminate()で終了させれば問題なさそう...。

>>300
>>291

で、一番上のメイン関数にtry/_finallyの_finallyにエラーの値を返すようにしてやれば
exit()と同じことが出来そうだが...

>>296
参照カウンタ系も駄目っぽいな。
COM関係とか。

__finally じゃなくて catch(exception &e) か

だからビジャンはあんなに禿げてるのか。

>>300
GUI系のアプリでそれやってると危険かもな。

C++の時代は終わった。
これからはSmalltalk。

十基ネット離脱しようぜ。

class MyException : public std::exception
{
public
　int result ;
　MyException(int value) : std::exception() {result = value ;}
};

#define MyExit(value) throw MyException(value)

WINAPI WinMain(...)
{
　try {
　　WinMainInner();
　} catch(MyException &e) {
　　return e.result ;
　}
　return 0 ;
}

とかやればいいだけなんじゃないのか？

今回のウィルス騒ぎで什器ネットの問題が露呈したな。

>>310
単スレッドならそういうのでいいかもね。

スレッドの場合は、メインスレッドに伝えるトリガーか何かを用意せんといかんな。

ひまだな。

十基ネットの端末が感染した報告はないけど、
なぜか全端末電源OFF。
専用端末にしろよ・・・

>>315
こういうのは銀行のシステムを見習ってﾎｼｲね。

やっぱりVBがアレな感じ？
http://members.tripod.co.jp/scs7/tips.htm

C++だとtrueは1らしいんだけどね。
http://www.microsoft.com/japan/developer/library/vccore/_langref_bool.htm

>・プログラム技術力のあるなしに関係なく
>　同じ成果物のものが出せるようにしろ

無理。
それが可能なら機械使ってライン化できる。

>>318
システム・ノウハウを一般化して底辺の底上げを試みるのはとても重要だよ。
開発は職人芸だとか勘違いして
独自ルールのわけの分からんコード書いている奴のなんと多いことか。

>>318
だからそれをやりたいのだといっている浜省。

>>319
自分に理解できないものをクソコード呼ばわりしてるおまえも同類だろうと言いたい浜省。

プログラマの幸せを奪うつもりか？

オナニーくらい自由にさせてくれ

プロジェクトチームに目安箱を設置する。
イントラ上ではなく、物理的なやつだ。
目安箱開帳は毎週月曜のミーティングに行う。

>>324
一枚目「残業代払えよ！」
二枚目「サービス残業はやめてください」
三枚目「残業を何時間したかによってプロジェクトリーダーの評価を下げてほしい」
四枚目「定時で帰ってもいいですか？」
五枚目「明日、労働監督所にいきます」
六枚目「探さないでください」
七枚目「みんなとお仕事できて、たのしかった・・・」
八枚目「やきのり」

毎回チーム各員が１枚以上紙を入れる様にすれば、
誰が入れた等の目撃問題解消。

筆跡で丸わかりな罠。

>>245出てきて

それは例外かMSの糞バグと言われる罠

ホットなスレだね。

>>324
九枚目「健康保険書」
十枚目「退職届」

>>66みたいに分けるのがいいと思う。
まずは「人＝プロジェクト制」を廃止するのがよかろ>1
それやってると知識や技能の流通がなくなるからオサキマックラ。
これをやっているうちはどんな規則を持ち込んでも効果無し。
その制度の元では無意味なので各々ストレスが溜るだけ。

それから、デキル奴を実プロジェクトから外して、ライブラリなりフレームワークに回す。
実プロジェクトだとどんなにできる奴でもやった分しか成果が上がらないが、ライブラリなら使う奴の数だけ成果が上がる。
できる奴の仕事の倍率を増やして、できない奴の仕事の倍率を減らすっつーワケ。
ライブラリなりフレームワークなりが整備されてそれが行き渡るまでは生産性も品質もガタ落ちなんだけど。

>322 まずは「人＝プロジェクト制」を廃止するのがよかろ
ｺｰﾀﾞはｺｰﾃﾞｨﾝｸﾞのことだけしか考えなくていいから楽しそうだね。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　|l*l＼（（从⌒从*））:::::|
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　＼�曝ｸ　　∵　━（（　：　∂ ））　　／
そして、壊す…　粉々に…　　　　　　　　　　　　　　　　　　　＼　（（　§　）　⌒；　　lll　;从 （・）／　　三
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　*　�煤@;　　）　（（　‡　*　　　ζ 　　　三
　　　　　∧∧　　　　　　　　　　　　　　　　　/／　　　　　（（　§　）　⌒；　（（从⌒从*））；　　lll　;（・）／
￣￣￣（　 ﾟ∀）￣￣￣￣￣￣￣￣￣￣.|三三三三三三（（从⌒　）　⌒；　　lll　;｀　从　　　　） ）―
＿＿__f ⌒ヽ ＿＿「　　〉＿＿＿＿＿＿__|三三三三三三#（（　　::　）　（　⌒　ζ　*｀　从　　　　¢） ）―
　　　 i　'　　 `ヽ.／ 　/　　　　　　　　　　　＼｀　　　　　　： *�煤i（　从　 （（　　））　（（　§　）*ヽ＼　ヽ・
　 　　|, '　＼　　´　　/　　　　　　　　　　　　　　　　　　　　　：　／　／ ・（（　;　　：　　））　（　 ζ＼*
　　　　|　　　　_ヽ､＿, '　　　　　　　　　　　　　　　　　　　　／ ・（（　从　 （（　　））　*ヽ＼　ヽ・ヽ＼
　　　　ｉ　 ､　　　　　 ヽ　　　　　　　　　　　　　　　　　　　　　　　　∵　／　／ ／::lX:l:::l|::::::::| 　　　　;　　　　　∵
　＿,,　┘　 「`ー-ｧ　 　ｊ　　　　　　　　　　　　　　　　　　　　　　　　　／|l:::lXl:::l::l:::l:::l:::l|::::::::|
ｆ"　　　　　ﾉ　　　｛　　/　　　　　　　　　　　　　　　　　　　　　　　　／　 |l:::lXl:::l::l:::lXl:::l|::::::::|
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿M$＿＿＿＿＿＿

>>333
ん〜。逆だな。コーディングの事しか考えない香具師が、コーダになるんだよ。

>332 335
とことんめでてーな。
まいったよ。

>>332
悪くないと思われ。
出来る人間がﾌﾚｰﾑﾜｰｸの設計やら
既存の解析やらを行いノウハウを蓄積する。
で、それを他のメンバーに使ってもらいつつ機能やライブラリを整備する。
ノウハウも周囲に展開して全体の能力の底上げを図る。
一度できれば、出来る人間も稼ぐ方に回せる。

>>336
文句を言うならおまえもアイディアを出してみろ、ｶｽ。

↑フレームワークってナニ？
よく出てくるけど・・・

CASEツール使ってるとこある？
コーティングしたくないなら、あれでいいんじゃねえの？

http://homepage.mac.com/maki170001/

>337
で、おまいらみたいなクズはブラックボックスをありがたく
使わせてもらって一生くずコーダってわけだな。
いいじゃんそれｗ

ブラックボックスを使うとくずコーダになるという理屈がわからん。

>342
なぜおまいらはVB房は激しく批判するんだ？

▼　▼　▼　▼　▼　▼　▼　▼　▼　▼　▼　▼　▼　▼　▼　▼
　☆★ 無修正ＤＶＤ★☆なら 新宿歌舞伎町直送 ☆★

人気爆発新作ベスト９入荷
　 堤さやか引退特集　憂木瞳　プロジェクトX　No８　ベイビーフェイスをやっちまえ
　白石ひより・愛葉るび　SNAPSHOT　地下映像陵辱援交　すぎはら美里痴女教師
　店頭販売の売れ筋のみ厳選してみました　安心の後払い
　　　　 http://book-i.net/moromoro/
　　　白石ひとみ　小森詩　山田まり　長瀬愛
＠＠　及川奈央　レジェンド　＠＠　堤さやか　東京バーチャル　依然大好評
　　　　
　　サンプル画像充実　　見る価値あり 　最高画質
▼　▼　▼　▼　▼　▼　▼　▼　▼　▼　▼　▼　

>>343
話が繋がってないよ・・。
顔真っ赤ですか？

>>338
アプリケーションのスケルトンみたいなもの。
フレームワークの中身を見ないで組めるのが良いフレームワークだと思う。
# ↑この価値観を適用するとスケルトン内部にコーディングさせるMFCはカス

>>341
ソースコードを閲覧できないわけじゃあるまい？
これがブラックボックスに見えるのは向上心のないカス野郎だけだな。
それこそ一生くずコーダなわけだがｗ

>>346

漏れは、ソースコードが公開されてないフレームワークの上でコーディングは、絶対やりたくない。

マクドナルドを一つのアプリケーションとして考えて
マクドナルドの従業員を１プロシージャと考えればいいと思う。
で、マクドナルドのシステムを作り上げた立場の人が、プログラマ。

課長は、プログラマと従業員を同等に例えるから無理があるのだと思う

>>338 ちょっと補足
ユーザーの組んだコードからXを呼び出して使う場合、Xはライブラリ。
ユーザーの組んだコードがXから呼び出されて使う(使われる？)場合、Xはフレームワーク。
別の表現をすればXがmainっぽいコードを持ってればはXはフレームワーク。

てな所だと思う。

またわけのわからんことを・・

>>347 そりゃそうだ。

>>347
なるほど。個人的な趣味の問題か。

（Photoshop プラグインのような単純な構造ならともかく）
複雑な構造をもったフレームワークの上でソフトウェアを
書くには、内部構造の理解が不可欠で、その際はソース
コードを読むのが一番だ。

何かフレームワークの上でソフトウェアを書いたことがあ
る人なら分かると思う。密接な関係をプログラミングするときは、
プログラムがどう連携しているかを解析しなきゃいけない。
そこで、ソースコードが見れないことになってしまったら、
本当に時間がかかる仕事になる。

ソースコードが公開されていて、それが整理されたいいコード
があれば、いいプラグイン開発ができる。（文章で説明されて
いてもよいが、なかなか表現しきれないし、文章化するコスト
は大きい。文章化するよりは正しいコードを書くほうが優先さ
れる。）ソフトウェア開発を最も効率化させたいならば、フレー
ムワークを整備し、そのコードを公開することだ。

商用だと無理

自分流のやり方で、自分の実力を発揮できる奴がいる
その半面で、それだと何も出来ない奴もいる。
きっちり標準化されて、窮屈だ、やりにくい、つまらない、嫌だと思う奴もいれば
そうしないと、仕事の出来ない奴もいる

プログラマーの適性が無いのに何で入社して来るんだ
って俺なんか思うのだが
まぁこれが、大工や板前などの職人と
サラリーマンの違いなのだろう・・・

ウチの会社でも、ブラックボックス化して
それを使って出来るようにしろって

怖くて使えないですよ

ここはオープンソースのOSしか使わない奴らのスレですか？

>>357
ドライバから全部組んでる、組み込み系だろ。
>>356
おまえ、自作のライブラリやドライバから全部組んでるの？
他人の作ったものを使っているなら、いままでとなんらかわらないわけだが。
ソース毎ブラックボックス化するわけでもないだろうに、なんでいちいち拒否
反応だしてんの？　おまえ一人でやったほうが効率いいのか？

>>357
洩れの場合自宅ではそうだな。debian+KDEだ。

>>356
そりゃ黒箱で使えるようなブツは優秀だがその分開発は難しい。
白箱から始めて使いながら育てて黒くしていくしかないだろよ。
未来の全案件をカバーできる仕様を起こせるってんなら別だが、
そんな香具師はいないだろ？

「未来の全案件をカバーできる仕様を起こせるってんなら別だが、
そんな香具師はいないだろ？」

はあ？

332=沢村

>>361 って誰よ。

>>360
おいおいその程度も判らんのか。
新規で発明されたデバイスが出てきたときにも対応できるブラックボックス化
したフレームワークを準備は早々出来ないって話だろ。
まあ、１００年後も通用するフレームワーク作ってブラックボックス化する必要
はないと思うがなぁ。

むぅ。カキコに省略が多いな。
そんな香具師はいないだろ？→そんな事ができる香具師はいないだろ？
だと思ってくれい。>360

>>1
プログラムよりプログラマを標準化してくれ

ソースレベルの標準化だったら、
・でっかい関数はつくらん
・if文のネストは極力少なく
・コメントをできるだけ仕様っぽく
・変数の使いまわしすんな
くらいかな。

結局は設計レベルの標準化の方が、
可読性はあがると思うけど。

ま、標準化に固執しすぎて納期に間に合わない方がヤバげだが。

マジで、有給や出張などで
会社にいない人が担当した、システムがトラブった時
どうやって対応するんですか？

>>1
自分よりも優れた人間のコードを素直に受け入れる人間だけを
集められれば可能かと...。しかし、それはそれでまた、別の問題が
生じるし、難しいな...。

>>367
お客様に説明する場合、
「担当者は休んでおりますが、他の者が対応します」は通じるけれど、
「担当者が休んでおりますので対応できません」は通じません。

ウチの会社では他の人間でも対応できるように休みの前日には
ドキュメントと最新ソースの場所を伝達してるですよ。それさえ用意
しておけば、どんなトラブルであっても休みの日には会社は絶対に
連絡を取って来ません。
逆にその人の脳内にしか無い情報があれば休暇だろうが深夜だろうが
容赦無く呼び出されます。

>367
そうならないような仕組み作りをするのが会社というものなのです。
本来は。

>>368さんのところは、
プログラムはきちんと標準化されていて
他の人が読んでも、意味がわからない
なんてことはないのでしょうか

>>369

どうやって？

もちろん緊急度と伝達の不備の程度を見てのハナシですが、
メール、ケータイに始まり最悪の場合、電話、電報、直接押し掛ける、
などなど、なんでもアリです。
よっぽど酷くなきゃそこまではしませんが、どれも過去にやってます。
「快適な休日は自分で守る（しっかり伝達をしておく）」が基本です。

>>1
レビューしろ。

以上。

同じモノだと誰が測定して評価するんだろ？
まずは計測の仕方、標準を策定からだな。

>>367
ISO9001とかとってなさげな会社のようだな。
それに対する取り組みしてたら、他の会社は如何してるのなんて質問なんか
しないだろ。

>>376
まぁまぁ、学生ｸﾝかもしれないじゃないか。

>>376

ISO9001とかとってなさげな会社の社員に
どういうものか、
教えてあげりん

>367
一番ベストなのは、一人しか知らない、一人しか担当がいないという状況を作らない事。
ドキュメントをしっかり作る、XPする等して、とにかく仕事を分散できるようにする。
たまーに、一人で仕事抱え込んで休みも取らず黙々とやっている奴がいるが、それは
決して誉められた物じゃない。

よいプロジェクトに参加していると、リリースされたくないあまり
仕事を抱え込んでしまう香具師がいるのが問題だな

説明は一度、質問は一切受け付けません。

一番ベストってなんですか？

>>381
やる気のない説明だな。

>382
best of best

>>384
the best of best なら意味が通じるが。

最良な獣？

The best bests a beast.

>>1
つか、「１プロジェクト１人で作成」ってのがおかしいだろ。
せめて「２プロジェクト２人で作成」にならんのか？

とりあえず、>>374の言うことは理解できてるか？

>>388
私は現在研修中の身なんですが、説明お願いします。

そもそも、ＰＣのファイルとかフォルダの置き方からして
他人の奴触るの嫌ジャン？

>>390
それ、抱え込みの初期段階だぞ。

会社標準に対して文句があるやつは、裏付けと人間関係をうまくやれ。
「技術とは、規則を破ることで洗練されてゆく。」

>>392
就業時間の規則は破っているので、技術は洗練されています。

　　　　　　　　　　

標準化する奴が開発のことをまったく知らん上に
知る必要はないって居直るんだけど。
困る。

まず標準化を制定する者の標準を決めろ。

>>396
魔柳さんに頼めばいいよ。
社内標準があるとか言いつつ実はなかったという上司のことを魔柳さんという。

プロセスもしくはスレッドの最上位の関数以外はすべて
・いつでも同じ入力に対して同じ出力をする
というルールを徹底してほしいです！
下層モジュールまで大域変数を参照・更新するヤシ多すぎ

つまり関数型言語で作れと。

>>398
そうそう。いつでも time() 関数の入力値が NULL の場合、いつでも同じ値を
返してもらわないと。

>>398
全部テーブルで作ると速そうだな。最上位関数以外は全部テーブル参照。
つかグローバル変数禁止がマトモ。その場合。

標準化といっても所詮はハードやコンパイラの制約、DBアクセスの方法などによって
はじめから縛られているわけであって．．．

言語レベルでの標準化って利害得失考えると、あんまりやりたくないなあ。
1ルーチン何行以内とか、インデントがどうとか。

1案件一人でつくるって標準化？も変わってるね。
いくら自社開発でも、まず、そこを変えないといい標準化はできないんじゃないかな。

標準は人それぞれ。極論すると主観のかたまり。

その体制規模なら、命名規則とコメント、ドキュメントあたりで十分じゃね？

仲間で見なきゃならんなら、読みにくいコードを書くﾔｼだけ、レベルが合うように
しつけるとか。

>>402
> 1案件一人でつくるって標準化？も変わってるね。
> いくら自社開発でも、まず、そこを変えないといい標準化はできないんじゃないかな。

同意。

> 仲間で見なきゃならんなら、読みにくいコードを書くﾔｼだけ、レベルが合うように
> しつけるとか。

１案件１人ならそうだようなあ。
下手な標準化押し付けるより、そのプロジェクトでの最適化を計ってもらうほうがいい。
駄目駄目君だけ矯正すれば、よさそうだね。（しかし、現実には駄目駄目君にいうこと
聞かせるには標準という大義名分があると便利なのも確か）