- PR -

プログラムの書き方でご指導お願いします。

投稿者投稿内容
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2005-11-10 13:50
引用:

がるがるさんの書き込み (2005-11-10 12:12) より:

このあたり、trueとfalseがそれぞれ「何を意味
しているのか」というのを丁寧に理解することは
とても大切だと思うです。


Is 〜、Has 〜、Can 〜 などに付いている後の単語に対して、
「何を意味しているのか」は考えるまでもなく理解できるのがブール値なのではないでしょうか?

引用:

特にC言語の場合、戻り値がfalse(これが0なのか
−1なのかでまた論争が起きるのですが(笑))


C 言語の場合? 言語に関係なく FALSE は概念的に 0x00000000 です。
つまり、TRUE を無理に表現するとすれば、!FALSE なので -1 です。

# しかしながら、"FALSE 以外は TRUE" という考えが本来正しいです。(0 以外は TRUE)
# そもそも、「論理値」を「数値」で表そうとすることが無意味ですけど。

引用:

# 実際には1で合致、0で合致せず、−1以下で
# エラー、とかって作りが多かったと思うですが。


このがるさんの例は、2 値ではなく「状態ステータス」を表しますよね。
数値だけでは理解できない、特別の意味がある数値ですよね。

とどのつまり、

引用:

このあたり、trueとfalseがそれぞれ「何を意味
しているのか」というのを丁寧に理解することは
とても大切だと思うです。


「丁寧に理解する」のであれば、true, false での表現は厳しいのでは?

読み違いがありましたら、ごめんなさい。(*_ _)

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
未記入
ぬし
会議室デビュー日: 2004/09/17
投稿数: 667
投稿日時: 2005-11-10 14:11
引用:

int money = 100; というコードがあってというお話がありましたが、これは「変数に値を設定する」場合ですよね? んで、今回はメソッドの話なので関係ないのかなぁ、と。


「変数」と「メソッド」だから今回の話とは関係ない、という認識しかできなかったのですか。本当にバカですね。あなたが、動いているものに修正を加えないのがセオリーだとおっしゃるので、修正を加えずにそのままコンパイルできてしまうほうが危険なこともある、という例を出したつもりなのですが・・・。

引用:

DB から Select した値を設定するのであればテーブルデータにパッチを、とか moneyTmp = 100 にして、 100 で割った値を money に設定する、とか色々と対応がありそうですけど )


なんだ、ちゃんと分かっているじゃないですか。プログラムコードが変更されていなくても、上記のように各所でさまざまな対応が必要になるわけですよね。is_true() の場合も同じです。is_true() のプログラムコードはそのままでも戻り値の意味が変わったら、各所でさまざまな対応が必要になります。そして、それはとても危険なことなのです。
がるがる
ぬし
会議室デビュー日: 2002/04/12
投稿数: 873
投稿日時: 2005-11-10 14:18
がるです。
一応軽く。
# ちなみに認証に対する考え方は、私は小僧さんと大体同じです。
# 「true 以外 ( まぁ、順当に考えて false ですが ) の場合は「認証 OK 以外」 」
# ですね。

引用:

tarnwoさんの書き込み (2005-11-10 13:28) より:
2005-11-08 19:40 のがるがるさんの書き込み(ソースで)
コード:
// 判断
  if (cobj.is_true()) {
    // 承認OK
  } else {
    // 承認NG
  }



とあります。


んっと…これは「こういうコメントだからfalseは「承認されていない」を
明示的に意味している」
という意味合いでしょうか?
だとすると、違うです。まぁ誤解されても仕方がないのでしょうが。

処理で「明示的にOKである」と「それ以外は取り合えず全部はじく」
っていう流れっていうのは…あまりないんでしょうか?
私の周囲では比較的多いのですが。
ですので、私のコードの書き方を深読みすると
・明示的にOKだったら処理
・明示的にOKではない場合、とりあえずまとめて処理
っていう流れになるです。
# 処理的に「OK以外ははじくから詳細には処理をしない」っていう仕様は
# 少なからずあるかと愚考いたしますがいかがなものでしょうか?

で、私はそれをさして「承認NG」というコメントを書いてます。
…という説明をせめて「質問して」いただけないものでしょうか?
# 明確でない事象に対する「質問もせずに断定」にちょっと食傷気味。
# 「常に確認と質問」は、特にクライアントと打ち合わせをするSEに
# とっては重要なスキルだと思うのですが。

あと。
引用:

あと、C言語でtrue, falseの二値判定の場合、0以外はtrue、0はfalseと判定ですね。
値で処理を分けるのは別の話では。


この話は「if文などでの論理演算の結果としてのtrue/false」ですね。
それについてはまさにその通りです。
if(0) は偽となり、if(1) や if(-1) など、0以外は全て真となります。
その点については特に異論もなく同意いたしますが。

ただ、出来たら文脈やら前後の単語やらを読んでいただけると、と
思うのですが。
私は「特にC言語の場合、戻り値がfalse」と記述しています。

関数の戻り値ということで考えると、まずboolean型はC言語に存在
しないです。ですので、戻り値がtureやらfalseやらで帰ってくる
ことは絶対にないです。
で、まぁ多くの場合intで復帰してくるのですが。C言語の関数を
色々と知っている方だとうなずいていただけると思うのですが、
成功なら1、失敗なら0を返す
成功なら0、失敗なら−1以下を返す
という仕様がごちゃまぜになってるです(苦笑
# 未だに関数リファレンス必須ですね。

ですので、通常多くのboolean型を持つ言語が関数の戻り値として
falseを返す(==その関数が失敗した)ケースをC言語に当てはめた場合に
「0がもどるんだか−1がもどるんだか」という話をしているだけなのですが。

ちなみにこのあたりの戻り値の話は思いっきり「雑談レベル」の
お話です。懐古レベル…って言ったら現在進行形でC言語メインの
方々に怒られるかな?
# 「お前さんメインC++だもん似たようなもんジャン」とかいう突っ込みはなし(笑

…で。
出来うれば「お互いが半歩づつ引いて冷静にお互いの話に
耳を傾けつつ双方にとって、また掲示板なのでほかの人にとっても
有益な議論が出来る」ととても嬉しく思うのですが。
まぁそう思って毎度長文になってしまうのもそれはそれで
気が引けるものではあるのですが(苦笑
小僧
大ベテラン
会議室デビュー日: 2005/06/24
投稿数: 122
投稿日時: 2005-11-10 14:23
こんにちは。

コード:

// 判断
if (cobj.is_true()) {
// 承認OK
} else {
// 承認NG
}


ぇぇ、理解しています。 ( つもり? )
しつこいですが、私は
・is_true の結果が true の場合は承認 OK
・is_true の結果が false の場合は承認 OK 以外 ( 明示的に承認 NG とはしていない )
と認識しましたが。。。

個人的には、
・is_true の戻り値が false の場合、承認 NG
という内容の場合、
コード:

// 判断
if (cobj.is_true()) {
// 承認OK
// 書き方がわからないですけど、イメージでこんな感じ?
} else if (cobj.is_true() = false ) {
// 承認NG
} else {
// 通常ありえない
}


となるのではないでしょうか?
( それが「明示的に is_true の戻り値が false の場合、承認 NG と判断する」という
仕様に対応したメソッドになるのでは?と思いますが )
( このコードを最適化した結果、最初の提示のコードになるのでは?と思いましたが )

実際、こういうコードを書くかどうかは別として、コードを見た場合、私はそう思いますが
どうでしょうか?

<書いている最中にレスが来たので>
修正を加えずにそのままコンパイルできてしまうほうが危険なこともある
一応、認識しているつもりです。
ただ、それを言い出すと「修正を加えずにそのままコンパイルできてしまうほうが安心なこともある」という
日本語もあると思いますが?
なので、「Case By Case では?」となってしまう気がするのですが。。。

is_true() のプログラムコードはそのままでも戻り値の意味が変わったら、各所でさまざまな対応が必要になります。
上でも書きましたが「is_true の結果が false の場合」の挙動として
・承認 NG
・承認 OK 以外
と取れると思っています。 ( 私だけ? )

で、私は「承認 OK 以外」と認識しました。
なので、私の場合、「臨時承認」の仕様が追加されても、
is_true の戻り値の意味は変わっていない、と思っています。
( 結局「臨時承認」のコードを追加するので当該メソッドを記述している箇所で
「さまざまな対応が必要になる」のは理解していますが )

<編集>
BB コード失敗 orz
あと、がるがるさんの返信は見れていません
</編集>


[ メッセージ編集済み 編集者: 小僧 編集日時 2005-11-10 14:27 ]
がるがる
ぬし
会議室デビュー日: 2002/04/12
投稿数: 873
投稿日時: 2005-11-10 14:31
がるです。
連続で恐縮です。

引用:

じゃんぬねっとさんの書き込み (2005-11-10 13:50) より:
Is 〜、Has 〜、Can 〜 などに付いている後の単語に対して、
「何を意味しているのか」は考えるまでもなく理解できるのがブール値なのではないでしょうか?


んっと。trueについて明確なのはそうだと思うのですが。
falseは「tureではない」という程度の意味合いしか持たないように
感じているです。
数学でいう逆とか不完全性定理とかそーゆー面倒なジャンルに
突入してしまうのですが(苦笑
そのあたりが、明示的であるtrueに対して、falseをもうひとつ信用して
いない理由なのかもしれないです。
# まぁ「ある集団」と「それ以外」という仕様も多いので、
# else句もよくつかうのですが。

引用:

C 言語の場合? 言語に関係なく FALSE は概念的に 0x00000000 です。
つまり、TRUE を無理に表現するとすれば、!FALSE なので -1 です。
# しかしながら、"FALSE 以外は TRUE" という考えが本来正しいです。(0 以外は TRUE)
# そもそも、「論理値」を「数値」で表そうとすることが無意味ですけど。


このあたりは前述したですが。
ちと疑問なのが「!FALSE なので -1」でしょうか?
これはつまり
not 0x00000000 = 0x11111111 = 補数で考えて-1
という発想でOKですか?
# うわぁビット演算久しぶりにやったかも(笑

引用:

引用:

# 実際には1で合致、0で合致せず、−1以下で
# エラー、とかって作りが多かったと思うですが。


このがるさんの例は、2 値ではなく「状態ステータス」を表しますよね。
数値だけでは理解できない、特別の意味がある数値ですよね。


ですねぇ。特に1以上と-1以下にはそれぞれ特別な意味が割り当てられて
いることが多かったです。

引用:

引用:

このあたり、trueとfalseがそれぞれ「何を意味
しているのか」というのを丁寧に理解することは
とても大切だと思うです。


「丁寧に理解する」のであれば、true, false での表現は厳しいのでは?


んっと。「詳細に」理解するのであれば必ず+αの情報が付随している
ししていないと困る、ってのはYesだと思うです。

で、上述の話はどちらかというと
「falseは"trueではない"状態であって、多くの場合それ以上を
 意味するわけではない」
って事を書きたかったです。
…っていう書き方で伝わりますでしょうか?
だから、私にとってtrueというのはとても限定されたステータス
なのですが、falseは場合によっては「とんでもなく広がる
もやもやした」ステータスなんですよね(苦笑
なにせ「想定外まで含めてtrue以外全部」なので。

って、こんな話を書いていて思い出したのですが。
そういえば昔このあたりで随分躓いたなぁ、と。
もしかすると、とても大切で重要で面倒なのかもしれないです。
この辺の話題って。

よかったら、またわからない部分とか変な部分とかいろいろ突っ込んで
いただけるととてもうれしいです。
tarnwo
ベテラン
会議室デビュー日: 2002/10/25
投稿数: 58
投稿日時: 2005-11-10 14:50
こんにちは。
引用:

引用:

tarnwoさんの書き込み (2005-11-10 13:28) より:
2005-11-08 19:40 のがるがるさんの書き込み(ソースで)
コード:
// 判断
  if (cobj.is_true()) {
    // 承認OK
  } else {
    // 承認NG
  }



とあります。


んっと…これは「こういうコメントだからfalseは「承認されていない」を
明示的に意味している」
という意味合いでしょうか?
だとすると、違うです。まぁ誤解されても仕方がないのでしょうが。



しょうがないと書いてあるあたり、認識していると思いますが、
「承認NG」の部分は「承認OK以外」と書くべきでしょう。
誤解を招くコメントはトラブルの元です。
コメントだけを見ると、
・承認OK(の処理をここで行う)
・承認NG(の処理をここで行う)
です。

#業務のプログラムでは、承認OKという表現も何がOKであるケースかを明記しますが。
#↑当然同じ認識と思います。


引用:

…という説明をせめて「質問して」いただけないものでしょうか?
# 明確でない事象に対する「質問もせずに断定」にちょっと食傷気味。



その前に誤解を招く表現をしないで。
がるがる
ぬし
会議室デビュー日: 2002/04/12
投稿数: 873
投稿日時: 2005-11-10 14:53
がるです。
…三度失礼いたします。
ちぃと気になったので。

引用:

小僧さんの書き込み (2005-11-10 14:23) より:
しつこいですが、私は
・is_true の結果が true の場合は承認 OK
・is_true の結果が false の場合は承認 OK 以外 ( 明示的に承認 NG とはしていない )
と認識しましたが。。。


これでよいと思うです。少なくとも私はこのスタンスですし。
そも、ただの一度たりとて
引用:

当初、is_true() が false を返した場合は「承認されていない」を意味していました。


などという発言は私はしていないですから。

引用:

・is_true の戻り値が false の場合、承認 NG
という内容の場合、


を例えば私が明示的に書くのであれば、多分…

コード:
bool bflg_is_true = cobj.is_true()
// 判断
  if (true == bflg_is_true) {
    // 承認OK
  } else
  if  (false == bflg_is_true) {
    // 承認NG
  } else {
    // 通常ありえない
  }


こげな感じですかねぇ?
なんとなく「メソッドを複数回call」が気になってしまう
貧乏性なのでつい変数使いますが(笑
# メモリコストが気にならんでもないですが。

引用:

is_true() のプログラムコードはそのままでも戻り値の意味が変わったら、各所でさまざまな対応が必要になります。
上でも書きましたが「is_true の結果が false の場合」の挙動として
・承認 NG
・承認 OK 以外
と取れると思っています。 ( 私だけ? )

で、私は「承認 OK 以外」と認識しました。
なので、私の場合、「臨時承認」の仕様が追加されても、
is_true の戻り値の意味は変わっていない、と思っています。


Yes、です。そも「コード全体の仕様変更」とは何度も言ってますが、
やはりただの一度たりとて「既存コードの意味の変更」とは言ってません
し。
っつか「既存コードの意味が変わる」んならメソッド名含め全部変えます :-P

falseの意味が変わるのはまぁ「コード量増えれば当然」なので
(true「以外」という条件である以上、全体が増えれば意味も増えるです)
配慮しません。
# だから「明示的にfalseを掴みたい」んならそーゆーコーディング
# したほうが仕様変更に強いんですね。

引用:

( 結局「臨時承認」のコードを追加するので当該メソッドを記述している箇所で
「さまざまな対応が必要になる」のは理解していますが )


これもまぁ言わずもがなですがYes。

ちなみに端的に実例を。
Web系でよくあったのが「パスワードがわからなくなったときの一次ログイン
ステータス」。
この場合、「一時パスワードでログインOKなPageのところだけ書き換え」を
するです。
まぁ正確には「一時パスワードを考慮したクラスをもうひとつ作って、該当
Pageはそのクラスからの継承に切り替える」んですがね。

なんとなくコンセンサスが(取れる人とは)取れてきたのかな?
未記入
ぬし
会議室デビュー日: 2004/09/17
投稿数: 667
投稿日時: 2005-11-10 15:06
工工工エエエエエエェェェェェェ(゚Д゚)ェェェェェェエエエエエエ工工工

前提ひっくり返しという大技を出しますか・・・。そうですか。言い訳というか取り繕いも、そこまでいくとスゴイですね。執念というか怨念を感じます。前提ひっくり返しという大技を出しても論に穴が開いてるあたり、がるがるさんらしいですけど。

引用:

これは「こういうコメントだからfalseは「承認されていない」を明示的に意味している」という意味合いでしょうか?だとすると、違うです。まぁ誤解されても仕方がないのでしょうが。



is_wait() は仕様変更時に追加されたメソッドですが、is_false() は、はじめから存在していましたよね。なぜ、はじめから存在する is_false() を使っていないのですか? true を信じるスタンス、二値が拡張される可能性を想定するスタンスであれば、is_false() をはじめから使っておくのが自然だと思います。

なぜ、is_false() の then 節を使わずに、is_true() の else 節を使っているのですか? うっかり書き損じてしまったのでしょうか。普段から二値が拡張される可能性を想定してコードを書いている人が、うっかり else 節を使ってしまうなんてことはないと思いたいですが・・・。

引用:

処理で「明示的にOKである」と「それ以外は取り合えず全部はじく」っていう流れっていうのは…あまりないんでしょうか?


ありますよ。良くあります。「それ以外は取り合えず全部はじく」って文言を変えてごまかしているけど、それが「承認されていない」ということでしょ。is_wait() が追加されたあとも同じ。「はじく」詳細理由を確認しているに過ぎない。なぜなら、is_true() の else 節にぶら下がっているのだから。

でも、がるがるさんはその解釈すらも否定しましたよね? is_wait() は詳細ステータスではなく同等な第3の値であると。そんなデタラメを言い出すから余計に綻ぶんです。

引用:

ですので、私のコードの書き方を深読みすると
・明示的にOKだったら処理
・明示的にOKではない場合、とりあえずまとめて処理
っていう流れになるです。


この主張を認めてあげてもいいですけど・・・。これって「OK」と「OK以外」の二値しか考慮していないということになりますよ? がるがるさんのおっしゃる二値が拡張される可能性を考慮するには「とりあえずまとめて処理」なんて危険なマネはできなくて、積極的に is_false() を利用しなくちゃいけないはずなんです。

引用:

特にクライアントと打ち合わせをするSEにとっては重要なスキルだと思うのですが。


がるがるさんって論理的に説明が付けられなくなると、いつも技術論を捨ててビジネス的にどうのこうのと逃げを打ちますね。面白いです。

スキルアップ/キャリアアップ(JOB@IT)