なして、文字列が解らんとや
tabe
田部です。
春です。
今ごろ、新人達は
Ｃ言語の初歩をやっている頃でしょう。
気分を変えて、新しいスレッドを立ててみました。
現象：
char cs[1024] ;
if(cs[0] == '\0') {
}
と、記述すべきところを
unsigned char ucs[1024] ;
if(strcmp(((const char *)ucs,(const char *)"\0") == 0) ==1) {
;
}
と、記述する人がいます。
疑問：
(a) なぜ、文字列に unsigned を付けるのか？
(b) なぜ、キャストを好んで大量に付けるのか
(c) なぜ、１文字比較にstrcmp()の関数を呼ぶのか？
(d) なぜ、文字列の末尾にプログラマが自分で￥０を書くのか
(e) なぜ、「０と等しい事が真ならば」としつこく書くのか
上記の(a) ～(e)の
どれかに当てはまるコーディングを、
見たことがある方、
なぜ、
「無意味に書いて、無意味に遅いコード」が、
後を断たないのでしょう。
――――――――――――――――――――
以上
見て、勝手使って http://rec.ncos.co.jp
Shin-ichi TSURUTA
"tabe" <ta...@mug.biglobe.ne.jp> wrote:
> 現象：
> char cs[1024] ;
> if(cs[0] == '\0') {
> }
> と、記述すべきところを
どういう理由で「べき」なのかを書かないと、
> unsigned char ucs[1024] ;
> if(strcmp(((const char *)ucs,(const char *)"\0") == 0) ==1) {
> ;
> }
> と、記述する人がいます。
こちらの問題点はわからないと思います。
> 疑問：
> (a) なぜ、文字列に unsigned を付けるのか？
そのバッファがunsigned charとして扱われることがある時は、
それで良いかと思います。私の場合、char型は極力排除し、BYTE型
を扱うようにしています。日本語を処理したり暗号化や乱数に関係
する場合は、BYTEにした方が使いやすいこと、処理系によってchar
の扱いが異なり酷い目にあったことから、charは使わないようにし
ています。それ以来、その手のバグを減らせています。
> (b) なぜ、キャストを好んで大量に付けるのか
少なくとも私は、暗黙のキャストよりは、明示的に記述する方が良
いと思っています。なので、キャストがあること自体は問題は無い
と思います。
> (c) なぜ、１文字比較にstrcmp()の関数を呼ぶのか？
この場合は無駄ですが、将来、"HOGEHOGE"と比較する可能性がある
場合、とりあえず""と記述しておくのもありだと思います。文字列
との比較であることを強調するには良い方法だと思います。
> (d) なぜ、文字列の末尾にプログラマが自分で￥０を書くのか
この場合は無駄ですが、区切りを'\0'にする場合、終端を表すため
に"aa \0 bb \0"のような記述が必要な場合があります。
> なぜ、
> 「無意味に書いて、無意味に遅いコード」が、
> 後を断たないのでしょう。
ただの勉強不足でしょう。特に初心者が無駄に書いてしまうのは、
コンパイラに通すため、ウォーニングを出さないようにするために、
その場しのぎの試行錯誤で書いてしまう場合が多いように思えます。
こういった問題を根本的に解決するためには、診断ツールのような
対処療法に頼るのではなく、いろいろな種類の良いコードをひたす
ら大量に読み、多くの種類のプログラムコードを書いたり設計をし
たりしていくと良いと思います。
コンパイラや診断ツールが文句を言わなければ良いと安心するのは、
奇々怪々なコードを生み出す原因になり、危険だとも思います。
____________________________________________________________
Name : Shin-ichi TSURUTA 鶴田 真一 (as SYN)
E-mail : s...@emit.jp
URL : http://www.emit.jp/
Junn Ohta
ta...@mug.biglobe.ne.jpさんは書きました。
> char cs[1024] ;
> if(cs[0] == '\0') {
> }
> と、記述すべきところを
私は
if (!*str) {
...
のように書くことが多いかな。
if (!str || !*str) {
...
もよくやります。
> (a) なぜ、文字列に unsigned を付けるのか？
テキスト処理をしていると文字コードの大小比較をした
いことが多いので、そういうときはたいていunsignedを
つけます。
> (b) なぜ、キャストを好んで大量に付けるのか
処理系やlintの警告を減らしたいという理由でそうする
可能性がありそうですね。
> (c) なぜ、１文字比較にstrcmp()の関数を呼ぶのか？
> (d) なぜ、文字列の末尾にプログラマが自分で￥０を書くのか
> (e) なぜ、「０と等しい事が真ならば」としつこく書くのか
(d)は必要ならやりますが...。あとは知りません。教え
た人や使った参考書が悪いんじゃないですかね。
だいたい、たとえばstrcmp()が中で何をしているかわか
っていればそれを1文字比較に使おうなどとは思わない
はずですし、strcmp()を教える場面ではそれぐらいのこ
とはふつうするでしょう。例のような使いかたをする人
がいるとしたら、strcmp()について何かへんな教えかた
をしたとしか思えないです。
> なぜ、
> 「無意味に書いて、無意味に遅いコード」が、
> 後を断たないのでしょう。
レベルの低いプログラマーが淘汰されず、そういう人が
新人を教えたりしてレベルの低いプログラマーを拡大再
生産しているからではないでしょうか。私自身はそうい
う現場をほとんど知らないのであくまで想像ですが...。
--
太田純(Junn Ohta) (株)リコー/新横浜事業所
oh...@sdg.mdd.ricoh.co.jp
Hideki Kato
In article <a9cusu$3ul$1...@bgsv5906.tk.mesh.ad.jp>, tabe wrote:
>
>田部です。
> (c) なぜ、１文字比較にstrcmp()の関数を呼ぶのか？
私自身のこれまでの（乏しい）経験からは，一般に「文字」と「文字列」の
違いが分からない／違いを知らない人が多い様に思います．「文字列」は分
かり易いようですが，「文字」は「数値」と同様に扱える，という事が直感
的に納得できないようです．んで，何でも「文字列」として扱ってしま
う（＝一文字の比較でも strcmp を使う）．．．
＃昔，かなり有名なフリーソフト（名称失念）でこのパターンを見た記憶が
＃あります．
以前，Lisp の教育を担当したスタッフから，Lisp は全部関数なので（Ｃと
違って）コストが分かり難いという相談を受けた事がありますが，これはそ
れ以前．．．(^^;;)．
--
Hideki Kato <mailto:ka...@pop12.odn.ne.jp>
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
H.Yamaguchi
$ Newsgroups: fj.comp.lang.c,fj.jokes
$ Followup-To: fj.comp.lang.c
"WiH" <w...@geocities.co.jp> wrote in message
news:a9e6mt$kcj$1...@ml.accsnet.ne.jp
>
>> > (c) なぜ、１文字比較にstrcmp()の関数を呼ぶのか？
>
> っていうか、これは一文字比較じゃないだろ（初っぱなが\0だから、文字列として成
> り立ってないじゃん）
Ｃ言語の標準ライブラリの文字列とは '\0' を終端文字とする、
文字の集合ですから、終端があれば正常な文字列ですよね。
この場合の１文字とは、終端文字の事でしょう。
# Pascal型の文字列を自前で操作することも
# 良くありますけどね。(^^;
>> > (d) なぜ、文字列の末尾にプログラマが自分で￥０を書くのか
>
> 文字列が終わっているんだよ！って強烈に宣言するため
DOS の環境変数の終端なんかが \0\0 ですね。
>> > (e) なぜ、「０と等しい事が真ならば」としつこく書くのか
>
> それ以前に、真とは０以外の状態を指すので、==1を「真ならば」と解釈するのはお
> かしいのでは？
> （よく見るプログラミングにif(a==1)とかif(a==TRUE)とかあるけど、全部間違いだ
> べ）
先の例では、if(a==1) では無くて、if((a==0)==1) ですよね。(^^
Ｃ言語の等価演算の結果は、整数で０または１のどちらかですから
間違いではありませんが、確かに冗長で不注意な感じがしますね。(--;
# BASIC なんかの論理演算の結果は０、非０でしたね。(~~?
--
山口@福岡 <hy...@mx7.tiki.ne.jp>
Takashi SHIRAI
In article <a9cusu$3ul$1...@bgsv5906.tk.mesh.ad.jp>,
tabe <ta...@mug.biglobe.ne.jp> wrote:
>田部です。
>春です。
春になると色んな人が出てきますなぁ。
> char cs[1024] ;
> if(cs[0] == '\0') {
> }
> と、記述すべきところを
この「べき」が諸悪の根源だと思います。どうしてそうすべきな
のか全く説明がありません。多分、書いている本人も理解していな
くて、「そういうものだ」という思い込みしか持っていないからな
んじゃないでしょうか。
ここひと月ばかりの投稿を見ている限り、問題の本質はこの投稿
者本人にあると思いますよ。
> なぜ、
> 「無意味に書いて、無意味に遅いコード」が、
> 後を断たないのでしょう。
多分、この投稿者のような中途半端な理解で本質を見極めてはい
ない人が教育者の側に少なからず存在することが元凶なんだと思い
ます。
ちゃんと理解している人って、丁寧には教えてくれずに「自分で
考えろ」といった厳しい教え方になってしまうことが往々にしてあ
ると思います。
実際の効果を考えると、その教え方は意地悪どころかむしろ当人
のためになることが多いのですが、折角そういう厳しい教育者に恵
まれて成長しようとしているところを、横から無知なお節介者が親
切顔で中途半端な教え方をしてしまうと、本質を理解せずに表層的
な理解に終始してしまいます。
受験戦争の詰込み教育で丸暗記が流行ってますからね。かけ算の
理屈を知らなくても九九を憶えれば答えは出せるので、そういう近
道に逃げたがるのもむべなるかなとは思います。
＃ C に限らず、coding に唯一無二の正解なんて滅多にあるもん
＃じゃありません。そんなものがあると思い込むのが間違いの元。
--
しらい たかし
Junn Ohta
shi...@nintendo.co.jpさんは書きました。
> ここひと月ばかりの投稿を見ている限り、問題の本質はこの投稿
> 者本人にあると思いますよ。
しらいさん手厳しいなあ。
とはいうものの、ここしばらくの田部さんの投稿を拝見
していると、さまざまな面でガードが甘いような気がし
ます。他人に読ませる文章を書くのもあまりお得意では
なさそうですし。
# しかし私は田部さんの実証的な姿勢(ちゃんと実行時
# 間を計測してみるとかですね)や継続的に問題提起し
# ようとする態度がわりと好きなので、あっさり見捨て
# る気にはならないのですけどね。
> 多分、この投稿者のような中途半端な理解で本質を見極めてはい
> ない人が教育者の側に少なからず存在することが元凶なんだと思い
> ます。
私の経験でも「うちの若い連中はプログラム書くのが下
手で」とぼやいているところって上から下までみごとに
揃ってスキルが低い傾向があるように思います。
初期教育にも問題があるのでしょうが、それよりはOJT
で美しいコードを鑑賞する機会がないとか、自分の書い
たプログラムに適切なフィードバックが得られないこと
のほうが重要かもしれません。教育者よりもそういう環
境をどうにかできない管理者の問題かな。
ワインバーグみたいな人をつかまえてきてコンサルテー
ションしてもらったら、こういう環境は劇的に改善され
そうな気もする...。
# くさかべさんを導入するとよいかも。:-)
Junn Ohta
hy...@mx7.tiki.ne.jpさんは書きました。
> この場合の１文字とは、終端文字の事でしょう。
strcmp()を使うかぎり'\0'は「比較」されないと思いま
すが...。
Tadamasa Tamura
tabe wrote:
> 現象：
> char cs[1024] ;
> if(cs[0] == '\0') {
> }
> と、記述すべきところを
>
> unsigned char ucs[1024] ;
> if(strcmp(((const char *)ucs,(const char *)"\0") == 0) ==1) {
if((strcmp((const char *)ucs,(const char *)"\0") == 0) ==1) {
となってませんか？
> ;
> }
> と、記述する人がいます。
> 疑問：
> (a) なぜ、文字列に unsigned を付けるのか？
これは全体を見ないとコメントできん(^^;
可能性としては、(b)同様、「そのように教えられているから」
じゃないかな？
> (b) なぜ、キャストを好んで大量に付けるのか
これはwarning消しのテクニックとして教えられている
可能性が高いですね。（そうでないと、わざわざキャスト時にまで
constを付ける理由がないと思う。）
> (c) なぜ、１文字比較にstrcmp()の関数を呼ぶのか？
これが、部分なのか、全部なのかによって解釈が変わります。
if ( strcmp((char *)ucs,"xxx") == 0 ) {
} else if ( strcmp((char *)ucs,"yyy") == 0 ) {
} else if ( strcmp((char *)ucs,"zzz") == 0 ) {
と続く記述の一部であれば、若干容認したい気持ちも(笑)
この方が、全体としては見やすいから…。
（よって、必ずしも「べき」では無いと思う）
ただ、その場合は、
if ( '\0' != ucs[0] ) {
if ( strcmp((char *)ucs,"xxx") == 0 ) {
} else ………
と直せと言うかもしれない(笑)
> (d) なぜ、文字列の末尾にプログラマが自分で￥０を書くのか
strcmp((char *)ucs,"")と書くと、何か不安に襲われるから(笑)
他の文字列のところではやってました？＜最後の'\0'
> (e) なぜ、「０と等しい事が真ならば」としつこく書くのか
すいません。
if( ! strcmp())派なので、もっと判りません(爆)
(更に言うと、個人的に書くときは、以下の場合もあり(笑))
int i,j ;
if (( 0 == i ) && ( 0 == j )) {
}
↓
if ( ! ( i | j )) { ←頭の中では、完全にアセンブラで見てる奴(^^ゞ
}
あえて解釈するなら、== 0 (すなわち、falseに見える)で
then節に入るのが嫌だからとか？
とりあえず、こんな感じじゃないかな？＜書いた人の意識
miho
>
> unsigned char ucs[1024] ;
> if(strcmp(((const char *)ucs,(const char *)"\0") == 0) ==1) {
> ;
> }
> と、記述する人がいます。
疑問:
(f) なぜ、strcmp に引数を一個しかわたさないのか
> (e) なぜ、「０と等しい事が真ならば」としつこく書くのか
私のレベルが低すぎるんでしょうが、論理学を初めて教わったころ、
たとえば、「A」という論理式を「Aが真」と書きたくなったことが
ありました(たぶん)。どうしてそんなヘボいことをしたのかは、今
となっては、推測するしか無いのですが、「が真」が式の最後に現
れると安心だったのでしょうか、だとしたら、「Aが真が真」と書か
ないことの説明にもなりそうです。
これから強引にこじつけると、このプログラムを書いた人は、0は数
値、1 は真理値のつもりだったのでしょうか。でも、プログラムの
字面からだと ...==0 という式が真理値を持ちそうにみえるので、
この解釈はやっぱりボツですね。おさわがせしました。
--miho
Tadamasa Tamura
Junn Ohta wrote:
>
> fj.comp.lang.c,fj.jokesの記事<a9edk5$io2$1...@nntp-kyusyu.tiki.ne.jp>で
> hy...@mx7.tiki.ne.jpさんは書きました。
> > この場合の１文字とは、終端文字の事でしょう。
>
> strcmp()を使うかぎり'\0'は「比較」されないと思いま
> すが...。
実際の実装として、'\0'までが比較対象であるほうに1票。
（各種ライブラリが存在するから、一概に「これ」という答えが
ないのかもしれないけど…）
私なら、↓のように書くかな？＜strcmp
int strcmp(char *c1,char *c2) {
int i = 0 ;
int rtn ;
do {
rtn = *(c1 + i) - *(c2 + i) ;
} while (( rtn == 0 ) || ( *(c1 + i) != 0 ) || ( *(c2 + i) != 0 )) ;
return rtn ;
}
というように、不一致時のリターン値計算のために、
都合上利用しちゃったり(^^ゞ
Kazuo Fox Dohzono
Tadamasa Tamura <ta...@coral.ocn.ne.jp> writes:
> } while (( rtn == 0 ) || ( *(c1 + i) != 0 ) || ( *(c2 + i) != 0 )) ;
好き好きかも知れませんが, 最後の条件は無駄ですね.
while (*p == *q && *p)
p++, q++;
return *p - *q;
# この場合 p, q は unsigned char * にしておかないと駄目かな.
--
Kazuo Fox Dohzono / doh...@hf.rim.or.jp
IKEDA Kenji
doh...@hf.rim.or.jp (Kazuo Fox Dohzono) writes:
> 好き好きかも知れませんが, 最後の条件は無駄ですね.
それ以前に、i が変化しないんで話になりません。
--
池田研二 稲城駅前在住
Hideo Sir MaNMOS Morishita
In article <86r8lgs...@poe.mob.or.jp>,
iは変らないものだと信じているんです。若いねぇ。
--
___ わしは、山吹色のかすてーらが大好きでのぅ
[[o o]] ふぉっふぉっふぉ
'J' 森下 お代官様 ＭａＮＭＯＳ 英夫＠ステラクラフト
PGP Finger = CD EA D5 A8 AD B2 FE 7D 02 74 87 52 7C B7 39 37
Narita Takaoki
<squ7kn8...@stellar.co.jp>の記事において
man...@stellar.co.jpさんは書きました。
> In article <86r8lgs...@poe.mob.or.jp>,
> IKEDA Kenji <noro...@mob.or.jp> writes:
:
> > それ以前に、i が変化しないんで話になりません。
>
> iは変らないものだと信じているんです。若いねぇ。
経験を積んで i が変るようになっちゃっても、あのままじゃ i が極ま
って、一転憎悪に(負に)転じるですね。おお恐い。まぁ、そこまで多情
もないかもしれんけど。(^^;
# んで、愛の多重災害事件が起こってプロセスは殺される、と落ちが付
# く？うむ、昼メロな strcmp だ。
--
成田 隆興 ＠ エー・アイ・ソフト株式会社ソリューシュン開発部
E-mail tak...@aisoft.co.jp
『十分間で決断し、短い理由を添えよ。』
Narita Takaoki
<a9etiu$67v$1...@ns.src.ricoh.co.jp>の記事において
oh...@src.ricoh.co.jpさんは書きました。
> 私の経験でも「うちの若い連中はプログラム書くのが下
> 手で」とぼやいているところって上から下までみごとに
> 揃ってスキルが低い傾向があるように思います。
>
> 初期教育にも問題があるのでしょうが、それよりはOJT
> で美しいコードを鑑賞する機会がないとか、自分の書い
> たプログラムに適切なフィードバックが得られないこと
> のほうが重要かもしれません。教育者よりもそういう環
> 境をどうにかできない管理者の問題かな。
上から下まで見事に揃って良いプログラムとはどういうものかとか、美
しいプログラムとはどういうものかとか、考えたこともないってのに一
票かしらん。
# まぁ、上の方の良いプログラムや良いプログラマの定義がコワレテル
# 可能性も高いかもしれないけれど。
tabe
田部です。
"miho" <mihoga...@yahoo.com> wrote in message
news:6500ebba.0204...@posting.google.com...
> "tabe" <ta...@mug.biglobe.ne.jp> wrote in message
news:<a9cusu$3ul$1...@bgsv5906.tk.mesh.ad.jp>...
> 疑問:
>
> (f) なぜ、strcmp に引数を一個しかわたさないのか
それは、
#include <string.h>を、
記述する習慣が無いからでーす。
＃よく、strxxxのプロトタイプ宣言を自分で書いちゃう
人がいるけれど、★駄目★。
> > (e) なぜ、「０と等しい事が真ならば」としつこく書くのか
>
>
> これから強引にこじつけると、このプログラムを書いた人は、0は数
> 値、1 は真理値のつもりだったのでしょうか。でも、プログラムの
> 字面からだと ...==0 という式が真理値を持ちそうにみえるので、
> この解釈はやっぱりボツですね。おさわがせしました。
＝＝０ がstrcmpの返却値で、
＝＝１ が真偽値です。
実はこれは、ＦＱＡなのでした Ｃ－ＦＡＱ９．２です。
http://www.catnet.ne.jp/kouno/c_faq/c9.html#0
だから、それほど珍しい考え方ではないと。
--
tabe
田部です。
"Junn Ohta" <oh...@src.ricoh.co.jp> wrote in message
news:a9etiu$67v$1...@ns.src.ricoh.co.jp...
> fj.comp.lang.cの記事<a9epi3$ifu$1...@nsvn01.zaq.ne.jp>で
> shi...@nintendo.co.jpさんは書きました。
> > ここひと月ばかりの投稿を見ている限り、問題の本質はこの投稿
> > 者本人にあると思いますよ。
>
> しらいさん手厳しいなあ。
まったく。
shi...@nintendo.co.jpさん、
田部が、どこかの誰かを不幸にする、
「中途半端な理解で本質を見極めてはいない」
発言をしていたならば、
具体的に、「ここ」とご指摘下さい。
スパルタで、「全部」ってのは無しで
お願いします。
>
> とはいうものの、ここしばらくの田部さんの投稿を拝見
> していると、さまざまな面でガードが甘いような気がし
> ます。他人に読ませる文章を書くのもあまりお得意では
> なさそうですし。
とりあえず、自己弁護。
得意か、得意でないかと言えば、
得意ですよ。
私が書いている、
★ http://rec.ncos.co.jp は、
ＭＳＮ：カテゴリ > コンピューター > ソフト > プログラミング > 汎用言語 >
C
にも、
Lycos / コンピュータ・インターネット / プログラミング / C・C++
にも、
そして、そして
http://www.pro.or.jp/~fuji/information/revlinks.html
にも、リンク張ってもらってますから、
それほど、分け解らん、って事ないと思います。
--
Shin-ichi TSURUTA
"tabe" <ta...@mug.biglobe.ne.jp> wrote:
> 田部が、どこかの誰かを不幸にする、
> 「中途半端な理解で本質を見極めてはいない」
> 発言をしていたならば、
そうではなく、本質を見極めていると思われる発言や、十分な理解
をしていると思われる記述がないから、そう書かれるのではないで
しょうか？少なくとも私はそう思いました。あと、ご自分で「俺は
中途半端でなく本質を見極めている！」と思っていらっしゃるので
しょうか？まぁ、私のような未熟者が言うことではないかもしれま
せんが…。
> とりあえず、自己弁護。
> 得意か、得意でないかと言えば、
> 得意ですよ。
これはあなたが出来ることの中でと言う意味でしょうか？それなら
ばわかります。ただ世間一般での水準と比較すると、他人に読ませ
る文章の完成度としては、少々難があると思います…。
> にも、リンク張ってもらってますから、
> それほど、分け解らん、って事ないと思います。
リンクは関係がないでしょう？例えば、ネガティブキャンペーン的
なリンクを張られたら、素直にダメだと思うんですか？
Takashi SHIRAI
我ながら暇なんだなーと思い入ったり嘆いたり :-)
In article <a9h5ci$fa2$1...@bgsv5906.tk.mesh.ad.jp>,
tabe <ta...@mug.biglobe.ne.jp> wrote:
>田部です。
>> しらいさん手厳しいなあ。
>まったく。
敢えて辛辣な切口にしたのはそれなりに理由があって、ある種試
した部分があるのですが、田部さんは見事にそれに乗っかってくれ
まして、この反応自体が傍証になっていると思います。
他の人もそれとなく諭してはくれているのですが、依然変わらぬ
投稿ぶりを見る限り、聞く耳を持たないというこの季節にはありが
ちの症状をお持ちなんだと思います。
ある思い込みに対して、共感が欲しくて投稿したのに思いのほか
理解を示して貰えないために、満足が得られずに手を変え品を変え
次々と命題を出し続けているのではありませんか？
多分、純粋に技術的な回答が得たいのではなく、酒場の親父と同
次元の愚痴に近いモティベーションが基底にあるのだと思います。
> 田部が、どこかの誰かを不幸にする、
> 「中途半端な理解で本質を見極めてはいない」
> 発言をしていたならば、
> 具体的に、「ここ」とご指摘下さい。
お決まりのパターンなんですが、まず第一に前提や背景を全く示
さずにいきなり端的な「実例」を挙げている点です。
このことから判ることは、一つにはそういった環境情報の重要さ
が理解出来ていないであろうということです。重要な前提条件なら
書き忘れるなんてことはないでしょう。
そしてもう一つ判ることは、これは初心者にありがちなんですが、
自らの現状を説明する能力に欠けているということです。他人とは
別の個体である以上知識の共有には至れない訳で、どこかで説明す
る必要があるのですが、その気がないのか「自明」と思い込んでい
るのか、とにかく結果的にコミュニケーションに破綻を来していま
す。
酔っ払いが「運ちゃん、オレんちまでやってくれ」だけで済ませ
ようとするのと理屈はおんなじですね。他の人にとって、その「オ
レんち」についての local な情報がどれだけ大切なのかが理解出
来ていない訳です。
そして第二に、挙げられている例がどれも中途半端な例で、一般
論にまで発展させた場合には必ずしも誤りとは言い切れないものが
殆んどであることです。
このことから判ることは、一つには可能性の枠を広げて類推する
能力に乏しいであろうということです。その全然なっちゃないと思
っている実例に対し、ひょっとしたら妥当性があるかも知れないと
いう可能性に考えが及べない訳です。
そしてもう一つ判ることは、その実例の書き手に対する思いやり
が足りないということですね。「思いやり」と言ってしまうと情緒
的過ぎますが、要はその書き手の身になって考えてあげることが出
来ないために、何故そういう実装をしてしまったかに思いを馳せる
ことが出来ないのでしょう。
「べき」と言い切れるような定石など存在しないという主張は他
にも何人かの人が言ってくれていると思います。そういう意味では、
田部さんのような人には C FAQ みたいなものはむしろ有害になっ
てしまうかも知れませんね。
更に第三に、自己の投稿への反応に対して歩み寄りを見せようと
はしていない点です。「こういう場合にはあり得る実装だ」という
反応は既に幾つも出ていると思いますが、そういう見解に対しては
殆んど無視していて聞く気がないかのように見えます。
このことから判ることは、一つには自己の主張の正しさに確固た
る自信を持っているということです。言い替えると思い込みですね。
自分の理解が間違っているとは思わないし思いたくもないのでしょ
う。
そしてもう一つ判ることは、では何のためにこんな投稿をしたの
かということを考えてみると、これは質問の形はしているものの実
際は他人の意見など聞きたい訳ではなかったということです。冒頭
で愚痴と書いたのはそういう点を指しています。
田部さんにとっては証明の必要が無い程自明なことなのに、どう
してこれ程までに共感が得られないのか、自分でも不思議に思って
いるのではありませんか？さて、それは一体何故なのか、改めて冷
静に見つめ直してみては如何でしょう。
>> とはいうものの、ここしばらくの田部さんの投稿を拝見
>> していると、さまざまな面でガードが甘いような気がし
>> ます。他人に読ませる文章を書くのもあまりお得意では
>> なさそうですし。
>
>とりあえず、自己弁護。
> 得意か、得意でないかと言えば、
> 得意ですよ。
そう、そして第四には自信過剰ということですね。必要以上の自
信は往々にして真実を見えなくしてしまいます。多分、その馬鹿に
している部下の方々に対してもそういう態度で接してらっしゃるの
ではありませんか？
自分は上司であるし経験も豊富なので、ぺーぺーの部下の言い分
に妥当性があるなどとは考えたくもないのでしょう。でも、人間の
コミュニケーションはまずは相手の話を聞くところから始まるので、
無意味だと思っても一度相手の言い分を聞いてみればいいんです。
そういう歩み寄りを見せないから、自分のスタイルと合わない実
装は押しなべて謎の存在にしかならないんだと思います。
色んな人の source を読んで、色んな OS の実情を見て、色んな
coding style を知って、見識を広げていけば、もう少しは C 言語
や programing の本質が見えてくるんじゃないでしょうか。
結局ね、田部さんの本質を捉えられていない点というのは、木を
見て森を見ずなんですよ。
挙げられている「間違った実装」なんてのは実際取るに足らない
些細なミスであって、如何に素晴らしい coding をするかという目
標に辿り着くにはもっと別の観点から見ないといけない訳です。
個々の実装を「木」とするなら、「森」はトータルデザインに相
当すると思います。そういう巨視的な視点でのアプローチをしない
ことには、少なくとも美しい program は書けないでしょうね。
尤も、美しい program が全てだという訳ではありませんが。
>私が書いている、
> ★ http://rec.ncos.co.jp は、
> ＭＳＮ：カテゴリ > コンピューター > ソフト > プログラミング > 汎用言語 >
>C
> にも、
> Lycos / コンピュータ・インターネット / プログラミング / C・C++
> にも、
> そして、そして
> http://www.pro.or.jp/~fuji/information/revlinks.html
> にも、リンク張ってもらってますから、
> それほど、分け解らん、って事ないと思います。
んー、やっぱりドツボにはまってる印象を受けますね。お山の大
将と言うか井の中の蛙と言うか。
人間が書くものである以上、間違いはどうあがいても完全には防
ぎ切れないんですよ。間違いをゼロにする努力を重ねるよりは、間
違いが出てきても recover 出来るシステムデザインを心がける方
が幸せになれるんじゃないでしょうか。
部下のミスを容認出来ないというその田部さんのスタンスは、職
場や project という場のシステムデザインとしては、failsafe と
か foolproof とかいった考え方から程遠いところにあるのではな
いでしょうかね。
--
しらい たかし
Junn Ohta
ta...@mug.biglobe.ne.jpさんは書きました。
> とりあえず、自己弁護。
> 得意か、得意でないかと言えば、
> 得意ですよ。
思っていることを文章に過不足なく表現するという意味
ではそこそこのレベルにあると思いますが、文章そのも
のの品質はかなりひどい部類に入ると思いますよ。それ
は自覚されておいたほうがよろしいのでは...。
ざっと目についたサンプルをいくつか挙げておきます。
<a6o08p$gav$1...@bgsv5906.tk.mesh.ad.jp>
| 深夜の３時まで仕事するからかな。。。
| コンパイル通るんですね。。。これ。switch文の中での話。
「。。。」って日本語の書きかたじゃないですよね。そ
うかと思えば文末に句点のないところもあるし。
| もう．。、「ｄ」で始まる未使用ラベルは、「done:」以外全部スペルミス
| と断言できます。
「．。、」って何だろう?
<a6qksn$32p$1...@bgsv5905.tk.mesh.ad.jp>
| 河野 さん、フォロー有難うございます。
名前のあとに空白をあけるのも読みづらいし。
| ＝＞ こんなコードを見ると、[かーーぺっぺぺ]て言いたくなるんです。
[]で囲んだのはどういう意図なんだろう。
| 以上：
「以上」のあとにコロンがあるのも意味不明。
とにかく、ひとりよがりの表記方法がそこかしこにあっ
て、読むほうとしては無用に頭を使わされます。要する
に、ひどいCプログラム(田部さんが初心者が書きがちな
例として挙げられたようなもの)の文章版のようなもの
なんです。人間は計算機ではないのでコアダンプしたり
はしないですけどね...。
<a7ahb6$bvm$1...@bgsv5906.tk.mesh.ad.jp>
| 下で解説しますが、
| ここで、言いたかった事は、Ｃ言語の仕様として
| const を付けれ、
| 関数内でも、
| 関数外でも、
| static を付けようが、付けまいが
| 静的エリアにデータを割り付ける仕様であれば
| 良かったのになー。
| と言う私の希望です。
意味は通じないこともないけど、私だったら絶対に書き
たくない悪文です。
<a7ckkk$8tl$1...@bgsv5906.tk.mesh.ad.jp>
| gccの場合は、 gcc -Wall -W -Oで十分です。
| solarisの場合は、 ｃｃ －ｖで警告が出るかと思ったのですが、
ここに限らず2バイト文字と1バイト文字の使い分けが行
き当たりばったりでとても読みにくい。
| この理由として、SolarisのＬＩＮＴが非常に優秀なため、
| ＬＩＮＴを使用して欲しいとの意図と私は思っています。
これも悪文かな。
tabe
下記の件は、
http://news.dinf.ne.jp/news/fj/comp/lang/c/msg00035.html
でも、言われているので、
気が付いた所から修正し行きます。
――――――――――――――――――――
> fj.comp.lang.cの記事<a9h5ci$fa2$1...@bgsv5906.tk.mesh.ad.jp>で
> ta...@mug.biglobe.ne.jpさんは書きました。
> > とりあえず、自己弁護。
> > 得意か、得意でないかと言えば、
> > 得意ですよ。
>
> 思っていることを文章に過不足なく表現するという意味
> ではそこそこのレベルにあると思いますが、文章そのも
> のの品質はかなりひどい部類に入ると思いますよ。それ
> は自覚されておいたほうがよろしいのでは...。
tabe
"Shin-ichi TSURUTA" <s...@emit.jp> wrote in message
news:a9d84u$4u6$1...@nwall2.odn.ne.jp...
> tabeさん、こんにちは、鶴田です。
こんにちは、鶴田さん。
以下にも関連して、意見を述べます。
>そうではなく、本質を見極めていると思われる発言や、十分な理解
>をしていると思われる記述がないから、そう書かれるのではないで
>しょうか？少なくとも私はそう思いました。
> "tabe" <ta...@mug.biglobe.ne.jp> wrote:
> > 現象：
> > char cs[1024] ;
> > if(cs[0] == '\0') {
> > }
> > と、記述すべきところを
>
> どういう理由で「べき」なのかを書かないと、
「文字列が空ならば」の表現は、
慣用表現を使用すべきと言う意味です。
何をもって慣用表現とするかは
Ｋ＆Ｒ２が望ましいです。
> > unsigned char ucs[1024] ;
> > if(strcmp(((const char *)ucs,(const char *)"\0") == 0) ==1) {
> > ;
> > }
> > と、記述する人がいます。
>
> こちらの問題点はわからないと思います。
「問題点『は』わからない」？
「問題点『が』わからない」？
if(strcmp(((const char *)ucs,(const char *)"\0") == 0) ==1) {
の、記述に問題があるとは、
一概には言えないって意味ですか？
> > 疑問：
> > (a) なぜ、文字列に unsigned を付けるのか？
> そのバッファがunsigned charとして扱われることがある時は、
> それで良いかと思います。
>私の場合、char型は極力排除し、BYTE型
> を扱うようにしています。日本語を処理したり
文字列に対して
1.char jap[] = "日本語" ;
2.unsigned char jap[] = "日本語" ;
の２つを考えた場合、
１を採用した方が、キャストも少なくてすみ
事故が少ないと思いますが、いかかでしょうか？
ただし、一文字づづ操作する時は、
unsigned char *japｐの方が、安全だと僕も思いますので、
一筋縄ではないですね。
> 暗号化や乱数に関係
> する場合は、BYTEにした方が使いやすいこと、処理系によってchar
> の扱いが異なり酷い目にあったことから、charは使わないようにし
> ています。それ以来、その手のバグを減らせています。
酷い目にあったのは、
文字列の時ですか？
ＨＥＸ列の時ですか？
短いサンプルを乗せて頂けると助かります。
> > (b) なぜ、キャストを好んで大量に付けるのか
> 少なくとも私は、暗黙のキャストよりは、明示的に記述する方が良
> いと思っています。なので、キャストがあること自体は問題は無い
> と思います。
キャストは無い方が良いと思います。
使わなければ、使わないほど良いです。
キャストがあること自体が、何かの問題を示唆しているのでは
ないでしょうか？
例：
char buf1[1024] ;
char buf2[1024] ;
memcpy((void *)buf1[0],(void *)buf2[0],sizof(buf1) );
memset(buf1,(int)NULL,sizeof(buf1) ) ;
論拠1：
Ｃ－ＦＡＱ１３．９の最後
http://www.catnet.ne.jp/kouno/c_faq/c13.html#0
論拠２：
Ｃプログラミング診断室
http://www.pro.or.jp/~fuji/mybooks/cdiag/cdiag.4.3.html
> > (c) なぜ、１文字比較にstrcmp()の関数を呼ぶのか？
> この場合は無駄ですが、将来、"HOGEHOGE"と比較する可能性がある
> 場合、とりあえず""と記述しておくのもありだと思います。文字列
> との比較であることを強調するには良い方法だと思います。
これは、
if(strcmp(str,"abc") == 0||
strcmp(str,"ab") == 0||
strcmp(str,"a") == 0||
strcmp(str,"") == 0) {
の様な時、
"a"まではいいとして、
””は、やはり問題を含んでいると思うのですが。
＃問題の事例として、「未完成」とか。
> > (d) なぜ、文字列の末尾にプログラマが自分で￥０を書くのか
> この場合は無駄ですが、
ほとんどの場合、無駄です。
>区切りを'\0'にする場合、終端を表すため
> に"aa \0 bb \0"のような記述が必要な場合があります。
これは、以前 「sprintf(src,"\0") の意味」で
僕がスレッドを立てて話題になりましたから
特異な例である事は知っています。
>
> > なぜ、
> > 「無意味に書いて、無意味に遅いコード」が、
> > 後を断たないのでしょう。
>
> ただの勉強不足でしょう。特に初心者が無駄に書いてしまうのは、
> コンパイラに通すため、ウォーニングを出さないようにするために、
> その場しのぎの試行錯誤で書いてしまう場合が多いように思えます。
はい。
その多くの場合が、キャストの多用です。
>
> こういった問題を根本的に解決するためには、診断ツールのような
> 対処療法に頼るのではなく、
診断ツールの言う事を素直に聞くのも良い方法だと思います。
カーニハン博士が、プログラム作法の中で、
ソースコードを複数のコンパイラに入力したら、
さまざまな、警告が出て参考になった、
と書いていますから。
>いろいろな種類の良いコードをひたす
> ら大量に読み、多くの種類のプログラムコードを書いたり設計をし
> たりしていくと良いと思います。
これは、同意。
>
> コンパイラや診断ツールが文句を言わなければ良いと安心するのは、
> 奇々怪々なコードを生み出す原因になり、危険だとも思います。
これも、同意。
tabe
しらいさんへ、
「鏡」
"Takashi SHIRAI" <shi...@nintendo.co.jp> wrote in message
news:a9hg0b$d6k$1...@nsvn01.zaq.ne.jp...
Shin-ichi TSURUTA
"tabe" <ta...@mug.biglobe.ne.jp> wrote:
> > "tabe" <ta...@mug.biglobe.ne.jp> wrote:
> > > 現象：
> > > char cs[1024] ;
> > > if(cs[0] == '\0') {
> > > }
> > > と、記述すべきところを
> >
> > どういう理由で「べき」なのかを書かないと、
> 「文字列が空ならば」の表現は、
> 慣用表現を使用すべきと言う意味です。
早速付帯条件がつきましたね。これ(cs)が文字列であり、かつ'\0'
で空とし、それを比較するものであることがようやく判りました。
しかし、まだ不十分です。扱う文字コードの種類が不明だし、
char cs[1024];
は、ローカルなのかグローバルなのかも不明。ローカルでこのプロ
グラムどおりの流れだと、csは初期化されていなく、直後にifが来
ること(読み出しを行うこと)自体が問題になる。途中の何らかの処
理が省かれていると思われるが、そう言ったことを含めて、読み手
に対する情報提供が不十分であり、日常会話ならともかく、NetNews
で議論するには余りにもお粗末であると言わざるを得ないです。
> unsigned char ucs[1024] ;
> if(strcmp(((const char *)ucs,(const char *)"\0") == 0) ==1) {
> の、記述に問題があるとは、
> 一概には言えないって意味ですか？
もちろん幾つかの問題点はあるように思えますが、おっしゃられた
幾つかの点のどこに問題があるかとなると、状況次第で変化すると
思われます。この場合の一番の問題は、初期化を行っていない領域
を読み出していることでしょう。
> 文字列に対して
> 1.char jap[] = "日本語" ;
> 2.unsigned char jap[] = "日本語" ;
> の２つを考えた場合、
> １を採用した方が、キャストも少なくてすみ
> 事故が少ないと思いますが、いかかでしょうか？
それは、プログラム全体で、この部分がどのように利用されるかに
よるでしょう。
> ただし、一文字づづ操作する時は、
> unsigned char *japｐの方が、安全だと僕も思いますので、
> 一筋縄ではないですね。
はい、そういうことです。
> > 少なくとも私は、暗黙のキャストよりは、明示的に記述する方が良
> > いと思っています。なので、キャストがあること自体は問題は無い
> > と思います。
> キャストは無い方が良いと思います。
> 使わなければ、使わないほど良いです。
それを言うのなら、プログラムコード自体が無い方が良いです。
少なければ少ないほど「良い」です。
> キャストがあること自体が、何かの問題を示唆しているのでは
> ないでしょうか？
いいえ。無駄なキャストは確かに問題です。「無駄」なのですから。
しかし、必要なキャストと言うものも当然存在するわけで、キャス
トの存在からだけでは、それが無駄なものか、必要なものであるか
判断することは不可能でしょう。
> 論拠1：
> Ｃ－ＦＡＱ１３．９の最後
> http://www.catnet.ne.jp/kouno/c_faq/c13.html#0
http://www.catnet.ne.jp/kouno/c_faq/c13.html#0
>一般に、"コンパイラーを黙らせる"だけのためにキャストをつけるの はいい考えではない。
▲▲▲▲ ▲▲▲▲▲▲
> 論拠２：
> Ｃプログラミング診断室
> http://www.pro.or.jp/~fuji/mybooks/cdiag/cdiag.4.3.html
http://www.pro.or.jp/~fuji/mybooks/cdiag/cdiag.4.3.html
>キャストして、型変換を明示的にすることにはそれなりの価値がありますが、
>今回の例では、そのような個所はほとんど見当たりません。
▲▲▲▲▲▲
キャストが必要な場合を暗示しているのがわかりませんか？
> > > (c) なぜ、１文字比較にstrcmp()の関数を呼ぶのか？
> > この場合は無駄ですが、将来、"HOGEHOGE"と比較する可能性がある
> > 場合、とりあえず""と記述しておくのもありだと思います。文字列
> > との比較であることを強調するには良い方法だと思います。
> これは、
> if(strcmp(str,"abc") == 0||
> strcmp(str,"ab") == 0||
> strcmp(str,"a") == 0||
> strcmp(str,"") == 0) {
> の様な時、
> "a"まではいいとして、
> ””は、やはり問題を含んでいると思うのですが。
> ＃問題の事例として、「未完成」とか。
非常に可読性が高く、寧ろ「良い」例に思えます。最後の行だけを
別の処理で判定されると、読みにくいです。
> > ただの勉強不足でしょう。特に初心者が無駄に書いてしまうのは、
> > コンパイラに通すため、ウォーニングを出さないようにするために、
> > その場しのぎの試行錯誤で書いてしまう場合が多いように思えます。
> はい。
> その多くの場合が、キャストの多用です。
おっしゃる通りですが、それは、「コンパイラを黙らせるだけのた
めのキャスト」の場合です。
> > こういった問題を根本的に解決するためには、診断ツールのような
> > 対処療法に頼るのではなく、
> 診断ツールの言う事を素直に聞くのも良い方法だと思います。
> カーニハン博士が、プログラム作法の中で、
> ソースコードを複数のコンパイラに入力したら、
> さまざまな、警告が出て参考になった、
> と書いていますから。
何か勘違いされていないでしょうか。この場合の「素直に聞く」の
と「参考になる」とは全然違うでしょう。そもそもコーディング技
術が完成の域に達した人間と初心者では、情報の受け止め方、利用
の仕方が異なる場合が多いです。
カーニハンの「警告が出て参考になる」と言うのも、言語仕様を考
える上で「参考」になるという意味にも聞こるぐらいで、言語の設
計者と利用者を同列に扱うのは不適切であると思います。
もちろんケアレスミス等を未然に防ぐため、警告やツールの分析結
果を利用するのは良いことだと思います。しかし、それは従うべき
という意味ではありません。
あらゆるバグは修正されなければなりませんが、正常に動作した上
でのコーディングスタイルの優劣については、置かれている状況に
より変動するため、簡単に判断できることではありません。
Junn Ohta
ta...@mug.biglobe.ne.jpさんは書きました。
> 田部です。
> しらいさんへ、
> 「鏡」
> 以上
こういう反応しかできないのでは、田部さんと議論して
もやっぱり無駄ということかなあ。
Hideki Kato
In article <a9ijvh$ava$1...@ns.src.ricoh.co.jp>, Junn Ohta wrote:
>fj.comp.lang.cの記事<a9i6i6$f58$2...@bgsv5906.tk.mesh.ad.jp>で
> ta...@mug.biglobe.ne.jpさんは書きました。
>> 田部です。
>> しらいさんへ、
>> 「鏡」
>> 以上
>
>こういう反応しかできないのでは、田部さんと議論して
>もやっぱり無駄ということかなあ。
その決め付けは（気持ちは分かりますが）ちょっと言い過ぎでしょう．
田部さんは（田部さんなりに）真面目に学びたいと思っているように感じ
ます．
ただ，
まだニュースに於けるコミュニケートの仕方に慣れておらず，
かつ思い込みが（かなり ^^;;）強く，
プログラミング言語に対する知識が不足している
＃（本は読んだりして勉強しているけど理解がずれてる，という感じ？）
だけなんだと思います．
Shin-ichi TSURUTA
Hideki Kato <ka...@pop12.odn.ne.jp> wrote:
> 田部さんは（田部さんなりに）真面目に学びたいと思っているように感じ
> ます．
私はソフトの宣伝の比重が高いように感じました。
> まだニュースに於けるコミュニケートの仕方に慣れておらず，
> かつ思い込みが（かなり ^^;;）強く，
> プログラミング言語に対する知識が不足している
> ＃（本は読んだりして勉強しているけど理解がずれてる，という感じ？）
> だけなんだと思います．
コード品質検証ツールを作っている人がこれではねぇ…。
Hideki Kato
In article <a9iqb0$24gh$1...@nwall2.odn.ne.jp>, Shin-ichi TSURUTA wrote:
>加藤さん、こんにちは、鶴田です。
>
>Hideki Kato <ka...@pop12.odn.ne.jp> wrote:
>> 田部さんは（田部さんなりに）真面目に学びたいと思っているように感じ
>> ます．
>
>私はソフトの宣伝の比重が高いように感じました。
あらら，全然気が付かなかった．．．（笑
＃ここで宣伝しても無駄だと思いますが．．．？
>> まだニュースに於けるコミュニケートの仕方に慣れておらず，
>> かつ思い込みが（かなり ^^;;）強く，
>> プログラミング言語に対する知識が不足している
>> ＃（本は読んだりして勉強しているけど理解がずれてる，という感じ？）
>> だけなんだと思います．
>
>コード品質検証ツールを作っている人がこれではねぇ…。
お言葉を返しますが，現実には良くある話なんですよ．．．
＃国レベルでのプログラマの育成を真面目に考えないといけないのか？
Junn Ohta
ka...@pop12.odn.ne.jpさんは書きました。
> お言葉を返しますが，現実には良くある話なんですよ．．．
> ＃国レベルでのプログラマの育成を真面目に考えないといけないのか？
というと、加藤さんは田部さんが挙げられたような低レ
ベルのプログラマーもけっこういるとおっしゃるのかな。
私は田部さんの話を聞いてもぜんぜん実感がわかなかっ
たのだけど、ああいう例ってのはやはりそれなりに実在
しているってことですかね...。
Junn Ohta
ka...@pop12.odn.ne.jpさんは書きました。
> その決め付けは（気持ちは分かりますが）ちょっと言い過ぎでしょう．
無駄というのは「私にとって無駄」のつもりでした。わ
かりにくかったのでしたら申し訳ありませんが、でも私
にとって無駄かどうかについて「言い過ぎ」ということ
はないと思いますよ。:-)
> 田部さんは（田部さんなりに）真面目に学びたいと思っているように感じ
> ます．
それは私も感じるのですが、自分に都合のよい部分だけ
学ばれるのではちょっとね...。
いずれにしても、「初心者はどうしてこう書きがちなの
か?」という疑問に対して「べつに初心者だからそう書
きがちなわけではないと思う。教えかたが悪いだけなん
じゃない?」という反論が来ているわけですから、田部
さんはその反論をきちんと検討すべきだと思います。そ
れをせずに自分の主張をさらに展開しても意味がないし、
それこそほかの人たちの時間を無駄に使うことになりま
すから。
梅津高朗
以前は、「究極のプログラマ」=「0.5クロックでも短い時間で終了する
プログラムを記述できるプログラマ」だと信じていました。
信じるついでに、「できる」を変に解釈して、
「何があっても常にそうする」と思いこんでいました。
プログラムの優劣はコンパイルされた
バイナリコードでのみ計られる物である、とか。
引数で指定されたファイル名をあれこれ処理するのにも
str系の関数を多用せずループをごりごり書いたりしていました。
今では世間ずれして堕落してしまい、問題になるほどでないなら
多少スピードの遅いプログラムになっても良いか、と気楽にやっています。
「究極のプログラマ」の条件として上の条件が含まれるに違いないけども、
「究極のプログラマ」なら「必要もなく特定の事項にこだわらず、
臨機応変に対応すべき」と今は思っています。
> これは、
> if(strcmp(str,"abc") == 0||
> strcmp(str,"ab") == 0||
> strcmp(str,"a") == 0||
> strcmp(str,"") == 0) {
> の様な時、
> "a"まではいいとして、
> ””は、やはり問題を含んでいると思うのですが。
> ＃問題の事例として、「未完成」とか。
今の私は、この通り記述して落ち着くと思います。
見やすさは言わずもがなですし、コーディング量に関しては、
「strcmp(str,"") == 0 ||」をコピー&ペーストするのが一番楽そうです。
意味的なことを考えると、個人的には、
strcmp(str,"") は、
「strに格納されうる文字列集合に空文字列が含まれ、
strはそれを格納している」
で、str[0] == 0 だと、
「strに格納されうる文字列集合に空文字列は含まれず、
strは妥当な文字列を格納していない」
というニュアンスに思えます。
上記の例ですと、"abc"と""が同列のように見えますので、
strcmp(str,"")を使う方が好みです。
同列でないなら、
if(str[0] == 0){
/*例外処理*/
}else{
/*正常*/
if(strcmp(str,"abc") == 0||
strcmp(str,"ab") == 0||
strcmp(str,"a") == 0){
}
}
こう書きたくなります。
あくまで趣味の範囲ですが。
#高級言語的に解釈しすぎて、「str[0] == 0は文字列の
#内部表現に依存しているから駄目」とか言いたくなったりもします
ところで、「場合によって使うスタイルはいろいろ」という人々に
「特定の完璧なスタイルがあって常にそれに従うべき」という意見で
戦いを挑んでも勝ち目がないように思います。
#国際難解Cコードコンテスト優勝という目標を掲げることを
#妥当と認めるならいかなるコーディングスタイルも
#場合によっては非常に有用だと言わざるを得ませんし
----
梅津高朗
um...@ist.osaka-u.ac.jp
red brick
>「究極のプログラマ」なら「必要もなく特定の事項にこだわらず、
>臨機応変に対応すべき」と今は思っています。
だけどチームで仕事してるとそうも言ってられないのです。てゆーか臨機応
変に対応しなきゃいけないようなプロジェクトはほぼ確実に失敗すると思うの
です。
--
赤煉瓦
Junn Ohta
shi...@nintendo.co.jpさんは書きました。
> ある思い込みに対して、共感が欲しくて投稿したのに思いのほか
> 理解を示して貰えないために、満足が得られずに手を変え品を変え
> 次々と命題を出し続けているのではありませんか？
> 多分、純粋に技術的な回答が得たいのではなく、酒場の親父と同
> 次元の愚痴に近いモティベーションが基底にあるのだと思います。
私はそういうモチベーションによる投稿もあまり否定す
る気がしないんですよね。ようするにネタを提供できて
それがいろいろな人が参加できる議論のベースになって
くれればそれでよい。
> お決まりのパターンなんですが、まず第一に前提や背景を全く示
> さずにいきなり端的な「実例」を挙げている点です。
これもいいんじゃないのかな。しらいさんのおっしゃる
ことは正しいと思うけど、そういうもろもろのことをわ
かったうえでやるならOK。まあいまのところ田部さんが
「わかってやってる」と思える根拠はほとんどないです
けど。
> そしてもう一つ判ることは、これは初心者にありがちなんですが、
> 自らの現状を説明する能力に欠けているということです。
能力に欠けているのか、説明しようという気がそもそも
ないのか、どちらかといえば後者では...。
> そして第二に、挙げられている例がどれも中途半端な例で、一般
> 論にまで発展させた場合には必ずしも誤りとは言い切れないものが
> 殆んどであることです。
私はどうでもよいと思う。一般論としては誤りと言い切
れないものでも、ある環境では誤りと言い切ってよいこ
とは多いでしょう? で、その環境をるる説明せずに誤り
の部分だけを切り取って提示したって間違いではない。
ただ、そういうやりかたをするには、表から見えない部
分についても投稿者が誠実に判断し、誠実に取り扱って
いるだろうと信頼できるだけの基盤が必要ですね。
そのあたり、田部さんのやりかたはあまりうまくないけ
ど、それはいまのところ「田部さんが口ベタだから」で
すませてもいいと思う。
> そしてもう一つ判ることは、その実例の書き手に対する思いやり
> が足りないということですね。
「こういう実例が書かれたのは誰かがひどい教えかたを
したからだ」という視点がないのはたしかですが、それ
を「思いやり」と呼ぶのはどうかな。
> 更に第三に、自己の投稿への反応に対して歩み寄りを見せようと
> はしていない点です。「こういう場合にはあり得る実装だ」という
> 反応は既に幾つも出ていると思いますが、そういう見解に対しては
> 殆んど無視していて聞く気がないかのように見えます。
これは同感。
> そう、そして第四には自信過剰ということですね。必要以上の自
> 信は往々にして真実を見えなくしてしまいます。多分、その馬鹿に
> している部下の方々に対してもそういう態度で接してらっしゃるの
> ではありませんか？
前半は同感。後半はうがち過ぎかな。
できれば田部さんはご自分で書かれたソースをいくつか
示されたほうがよいと思います。しらいさんや私が書い
たソースはいくつか公開されているので、それらを読ん
でいただければどういうレベルのプログラマーか判断で
きるでしょう。田部さんも同じ土俵に登ってみてはいか
がですか。
Shin-ichi TSURUTA
御二方とも十分にわかっていらっしゃる気がするのですが、まとめ
ると、プロジェクト内で臨機応変を強いられる状態は危険であるが、
全く別のプロジェクト「毎」には臨機応変に対応するのが良いとい
う事ではないでしょうか。
梅津高朗
> >臨機応変に対応すべき」と今は思っています。
> だけどチームで仕事してるとそうも言ってられないのです。てゆーか臨機応
> 変に対応しなきゃいけないようなプロジェクトはほぼ確実に失敗すると思うの
> です。
すみません。ちょっと省略しすぎました。
もちろん、その場合は、勝手気ままに規則を無視してまで臨機応変に
対応するのではなく、プロジェクトへの参加時点で
「プロジェクトでどんな規約が定められていても
臨機応変にそれに従いつつ参加できるだけの柔軟さ」を意図していました。
---
梅津
Kazuo Fox Dohzono
oh...@src.ricoh.co.jp (Junn Ohta) writes:
> 私は田部さんの話を聞いてもぜんぜん実感がわかなかっ
> たのだけど、ああいう例ってのはやはりそれなりに実在
> しているってことですかね...。
うちと取引のある地場企業のある人は, 「私が信用できる外部のソフト屋さん
は三人しかいない」って言ってました.
# 幸い私も含まれていました :-)
以下は数年前出向でとある (世界的にも有名な) 企業にしばらく詰めた時の話
です.
そこでの仕事は, ある仕様を満たすプログラムを与えられたライブラリを用い
てこなすというもので, 「多分こんな感じ」というライブラリを拵えて事前デ
バッグまで終えていました.
ところが, よくある話でうまく動かない.
ライブラリのソースを見せてもらってトレースしてみると, 未初期化変数があ
りました. 逆アセンブルしたところ, それまでは直前に実行された環境の影響
から偶然動作していたに過ぎないことも突き止めました.
でも, 直させてくれませんでした :-|
# 理由はうろ覚えですが, 書類がどうの, 外部の人間だとどうの, とか.
結局迂回路を作ってしのぎました.
いつか書いた「ほとんど昇順であることがわかっているデータを整列するのに
二分木に突っ込んでいた」のもここで見たプログラムです.
まあそういうことがあって, あちらの担当者と飲んだときに「プログラマとは」
とか「ソフトウェアとは」とかそういう話をしたのですが, 後日向うの上司か
ら「変なことを吹き込まないでくれ」とか言われました :-|
# 彼の言葉を要約すると「プログラムなんていうのは下々のものが作るもの」
# なんだそうで :-(
私が以前居た会社にも酷い人がいたそうで, まずソフトウェアは部品扱い (ま
あこれはわからんでもないんですが), しかも原材料費がないので無料という
考え方で, 納入される数億のシステムのうち数千万円のソフトウェア代金を
「どうせ無料なんでしょ?」とか言って値切ろうとして横にいた友人はとても
恥ずかしい思いをしたそうです.
あ, これはプログラマの話じゃないや.
Junn Ohta
doh...@hf.rim.or.jpさんは書きました。
> ライブラリのソースを見せてもらってトレースしてみると, 未初期化変数があ
> りました. 逆アセンブルしたところ, それまでは直前に実行された環境の影響
> から偶然動作していたに過ぎないことも突き止めました.
> でも, 直させてくれませんでした :-|
> # 理由はうろ覚えですが, 書類がどうの, 外部の人間だとどうの, とか.
これはまあありがちかな。ひとつのソースで責任者をご
ちゃまぜにするとあとの管理がたいへんですからね。バ
グが発見されたことを記録してオリジナルの責任者のほ
うに伝えてくれるのであれば、現場でそういう対応にな
ってもしかたがないかも。
> いつか書いた「ほとんど昇順であることがわかっているデータを整列するのに
> 二分木に突っ込んでいた」のもここで見たプログラムです.
それ、プログラミングスキルよりはもうちょっと上の問
題かもしれませんね。
> # 彼の言葉を要約すると「プログラムなんていうのは下々のものが作るもの」
> # なんだそうで :-(
かつては計算機関連の大手企業がこぞって「ソフトウエ
ア工場」のような部門を作っていましたし、ソフトウエ
ア産業そのものがそういう方向に向かうべきものとされ
ていたわけでしょう。創造性はもう少し上のレベルの設
計段階で発揮して、開発フェーズはできれば機械的に行
ってしまいたいというか。
いまではそれは無理という考えかたのほうが優勢だと思
いますが、背景を考えればそういう主張にも意味がない
わけではない。
> 私が以前居た会社にも酷い人がいたそうで, まずソフトウェアは部品扱い (ま
> あこれはわからんでもないんですが), しかも原材料費がないので無料という
> 考え方で, 納入される数億のシステムのうち数千万円のソフトウェア代金を
> 「どうせ無料なんでしょ?」とか言って値切ろうとして横にいた友人はとても
> 恥ずかしい思いをしたそうです.
これはよく聞く話だけど、ほんとうに「どうせ無料」と
思っているのか、それとも値切れるところはヘリクツを
こねてでも値切ろうとしているだけなのか、ちょっとわ
かりませんよね...。
というわけで、どれも田部さんが問題にされているよう
な例とはちょっとレベルが違うような気がしないでもな
いです。(^^;
Kazuo Fox Dohzono
oh...@src.ricoh.co.jp (Junn Ohta) writes:
> > いつか書いた「ほとんど昇順であることがわかっているデータを整列するのに
> > 二分木に突っ込んでいた」のもここで見たプログラムです.
>
> それ、プログラミングスキルよりはもうちょっと上の問
> 題かもしれませんね。
でも, そのプログラムがどうやらそういう仕様のものらしいということを知る
のに三日も費やしたのです (/_;)
Hideki Kato
In article <a9issl$dfr$1...@ns.src.ricoh.co.jp>, Junn Ohta wrote:
>fj.comp.lang.cの記事<3cbcd...@binarykiller.newsgroups.com>で
> ka...@pop12.odn.ne.jpさんは書きました。
>> お言葉を返しますが，現実には良くある話なんですよ．．．
>> ＃国レベルでのプログラマの育成を真面目に考えないといけないのか？
>
>というと、加藤さんは田部さんが挙げられたような低レ
>ベルのプログラマーもけっこういるとおっしゃるのかな。
>
>私は田部さんの話を聞いてもぜんぜん実感がわかなかっ
>たのだけど、ああいう例ってのはやはりそれなりに実在
>しているってことですかね...。
田部さんの例は組込みを対象にしていらっしゃるようなので，私は経験して
おりません．＃苦労は想像できます．
どの位前でしょうか，メインフレーマも開発言語としてＣを使い始めた頃に
（スキルを持っていたのは研究所の人間だけだったため）よく引っ張り出さ
れましたし，同僚からも話を聞いたりしました．他には某国家プロジェクト
とか．．．
私が知っている範囲では，事業部や子会社あるいは独立系ソフトハウス等で
きちんと教育を受けた人間はそれなりに基本を学んでいるので，そんなに酷
いコードは書きませんが，その下請け（のアルバイト社員）や，研究所の新
入社員（きちんとした教育は受けていない ^^;;）が書くコードは酷く，ま
たそれ以前の問題として，プロ意識というか向上心が欠如した人が多いのに
困らされました．
＃手取り足取り※しないとダメ．しかも同じミスを繰返す．．．
※よーするに具体的なコードを教えるまで質問し続ける ^^;;）．
別（逆）の例としては，なまじスキル（＆プライド）があるために，協同
（分散）作業である事を無視するとか，テスト担当の部署を敵対視する，の
も困りますね．
また，最近はノウハウ本などの普及のお陰（皮肉です）で，皮相的な理解で
（半可通と言いますね）知ったかぶりをする人も増えているものと思いま
す．こういう人も困りものでしょう．
いずれにせよ，ある言語を使いこなせるようにするためには，言語仕様（文
法など）は後回しにして，「どういう場合にどういうコードを使うか，そし
てそれは何故か※」という実例をなるべくたくさん覚えさせる，事から始め
るのがいい（＆それしか無い）のではないかと感じています．
※これが大事．
＃（実用的な）英語を教えるのと同じです．
とは言え，ある言語を使いこなせるようになるのは（私自身の経験からも）
大変時間がかかる事ですし，個人差も大きいので，個別の会社で対応してい
るのではもう無理なのではないかと思います．ちょっと極端かも知れません
が，義務教育のうちから「きちんとしたコンピュータ教育※」をしないとダ
メなのではないでしょうか．
※インターネットを使わせる，という様なのではなく．
＃教えられる人がいない，という話もありますが．．．
これだけ人類がコンピューター（つまりはソフトウェア）に依存している時
代ですから，信頼度を上げる方法をきちんと考えないと．．．
Takashi SHIRAI
In article <3cbcd...@binarykiller.newsgroups.com>,
Hideki Kato <ka...@pop12.odn.ne.jp> wrote:
>加藤＠ＯＤＮです．
>>> 田部さんは（田部さんなりに）真面目に学びたいと思っているように感じ
>>> ます．
>>
>>私はソフトの宣伝の比重が高いように感じました。
いやぁん。折角本人の口からボロを出させようとしてたのに :-)
>あらら，全然気が付かなかった．．．（笑
>＃ここで宣伝しても無駄だと思いますが．．．？
と言うか、明らかに negative campaign になっていると思いま
すね。本人が努力すれば努力するほどお里が知れてしまって、信用
を失墜させる結果になってしまっていますから。
私だっていつもこんな意地悪な訳じゃあなくて、見込みのありそ
うな相手ならもっと親切丁寧に指導してるんですけどね。
>＃国レベルでのプログラマの育成を真面目に考えないといけないのか？
コンピュータ技術の発展と共に過ごしてきた世代ってもう新しく
は現れてきませんよね。そういう時代を経ていないと、hacker タ
イプの資質は顕現しにくいんじゃないかと思っています。
だって生まれた時から身の回りに既に完成された PC 環境が溢れ
かえっているんですもの。
＃ しかも大抵は Windows．．．。
--
しらい たかし
Takashi SHIRAI
田部さんって多分経験が少ないだけじゃなくて、不幸な目に遭っ
た回数も少ないんだと思う。幸せなんだなぁ。
In article <a9iun1$e06$1...@ns.src.ricoh.co.jp>,
Junn Ohta <oh...@src.ricoh.co.jp> wrote:
>> 多分、純粋に技術的な回答が得たいのではなく、酒場の親父と同
>> 次元の愚痴に近いモティベーションが基底にあるのだと思います。
>
>私はそういうモチベーションによる投稿もあまり否定す
>る気がしないんですよね。ようするにネタを提供できて
>それがいろいろな人が参加できる議論のベースになって
>くれればそれでよい。
ネタとしては構わないと思いますけどそれでも程度問題でしょう。
あれだけ連発されると「そろそろ気づけよ」って思えてしまいます
から。
>これもいいんじゃないのかな。しらいさんのおっしゃる
>ことは正しいと思うけど、そういうもろもろのことをわ
>かったうえでやるならOK。まあいまのところ田部さんが
>「わかってやってる」と思える根拠はほとんどないです
>けど。
これね、実は売り口上の前振りなんじゃないかとずっと穿ってる
んです。
ガマの油売りが、「こんな傷もたちまち．．．」という展開に持
っていきたいがために自分の腕を切るという場面で、その傷が全然
大したことないように見えてしまっては話が先に進められませんよ
ね。
田部さんの切口として、「こんな傷もある、あんな傷もある。痛
いよねー」と言ってまずは共感を呼びたかったのに、何故かそこで
そっぽを向かれちゃったんで慌ててる訳です。
書いている内容に中身が無いのは、実は全然「実例」なんかでは
ないからなのではないかという気すらしてしまいます。
そういう意味では「わかってやってる」のかも知れません。
>そのあたり、田部さんのやりかたはあまりうまくないけ
>ど、それはいまのところ「田部さんが口ベタだから」で
>すませてもいいと思う。
単なる口下手で済ませていいのか疑問です。口下手というより、
直面する問題へのアプローチとか、話の持っていき方とか、文章の
表現とか、そんな辺りが技術系の切口ではないような印象を受けま
す。
どちらかと言うと、自己啓発セミナー系と言うか、霊感商法系と
言うか、ガマの油売り系と言うか。少なくとも純粋な技術論を語る
語り口ではないように見えますね。
凄く浮いて見えます。初心者の教えて君の方がよっぽど技術者ら
しく見えるくらい。
>できれば田部さんはご自分で書かれたソースをいくつか
>示されたほうがよいと思います。しらいさんや私が書い
>たソースはいくつか公開されているので、それらを読ん
>でいただければどういうレベルのプログラマーか判断で
>きるでしょう。田部さんも同じ土俵に登ってみてはいか
>がですか。
open source っていいですよねー、って、そういう目的で公開し
てる訳じゃあないので、みんなで寄ってたかって赤ペンチェックさ
れたら嫌かも :-)
私、本職の programmer じゃないのであんまり厳しい目で見ない
でやって下さいまし。
＃ どうせ私の source は「grep static *.h」して色々出てくる
＃し。勿論どれもそれなりに理由はあるんですが教えてはあげませ
＃ん ;-p
--
しらい たかし
Junn Ohta
ka...@pop12.odn.ne.jpさんは書きました。
> いずれにせよ，ある言語を使いこなせるようにするためには，言語仕様（文
> 法など）は後回しにして，「どういう場合にどういうコードを使うか，そし
> てそれは何故か※」という実例をなるべくたくさん覚えさせる，事から始め
> るのがいい（＆それしか無い）のではないかと感じています．
これは同感ですね。だからソースコードレビュー、とい
うか大学の輪講みたいなものを頻繁にやってコードを読
ませるわけです。
オープンソースの良質なコードでもよいですけど、それ
より自分たちの目の前にいる先輩たちが書いたコードの
ほうが臨場感(というかせっぱつまっ感じ:-)があって効
果が高いようですね。
> とは言え，ある言語を使いこなせるようになるのは（私自身の経験からも）
> 大変時間がかかる事ですし，個人差も大きいので，個別の会社で対応してい
> るのではもう無理なのではないかと思います．
終身雇用が成立していたころはそれでもよかったと思う
のですけどね。まあ現在だってOJTでやるべきことはた
くさんあるのだから、その一環で教育するのがまったく
無理だとは私には思えません。それはそれとして、
> ちょっと極端かも知れません
> が，義務教育のうちから「きちんとしたコンピュータ教育※」をしないとダ
> メなのではないでしょうか．
やれるものならやってほしい。けど教育する側の人間が
いないでしょう。仕事が減ってクチが余ってきている可
能性はあるけど、品質の悪いほうから教育に回すのもど
うかと...。:-)
OKAMURA Kikuo
>> お言葉を返しますが，現実には良くある話なんですよ．．．
>> ＃国レベルでのプログラマの育成を真面目に考えないといけないのか？
>
>というと、加藤さんは田部さんが挙げられたような低レ
>ベルのプログラマーもけっこういるとおっしゃるのかな。
>
>私は田部さんの話を聞いてもぜんぜん実感がわかなかっ
>たのだけど、ああいう例ってのはやはりそれなりに実在
>しているってことですかね...。
田部さんが提起した質問と全然関係ないのですが，今回の銀行系のトラブルを
見ると，太田さんの意見より加藤さんの「国レベルでのプログラマの育成」が
必要な気がします．
--
岡村
gf4k...@asahi-net.or.jp
Hideki Kato
In article <a9jn3o$jjk$1...@nsvn01.zaq.ne.jp>, Takashi SHIRAI wrote:
> しらいです。
<cut>
>>＃国レベルでのプログラマの育成を真面目に考えないといけないのか？
>
> コンピュータ技術の発展と共に過ごしてきた世代ってもう新しく
>は現れてきませんよね。そういう時代を経ていないと、hacker タ
>イプの資質は顕現しにくいんじゃないかと思っています。
今の時代，メモリーの制限や CPU 性能の制限は緩くなっていますから，
コーディングテクニックが優れているという意味でのハッカーの必要性はあ
まりないと思います．
＃組込みシステム分野はこの限りではありません．
＃＃↑は私に経験が無いので触れないだけで，重要性／危険性は高いし，こ
＃＃ちらの方がプログラマ不足の問題はより切実だと認識しています．
それより，
各種の応用分野を理解でき，
アルゴリズムと計算量の理論を身に付けており，
広い視野を持ち，
想像力が豊富で，
指導力のある
リーダー（こちらは比較的少数）
と，
仕事を計画的に進められ，
自分の能力を知っており，
ハードウェアの知識があり，
信頼性の高いソフトウェアを，
協同作業で作れる
プログラマが（大量に）
必要になっているのではないでしょうか．
また，デバッグもコーディングに優るとも劣らない重要な分野だと思います
が，これには推理探偵と同様の資質が必要だと思われ，経験上，ほとんどの
人に想像力が不足しているように思われます．こちらの能力を向上させる方
法については，まだこれといって有効なものを思いつきません (^^;;)．
> だって生まれた時から身の回りに既に完成された PC 環境が溢れ
>かえっているんですもの。
>
>＃ しかも大抵は Windows．．．。
これらはプログラマの育成にはさほど障害にならないと思います．
＃ MS-BASIC で育っているよりはなんぼかマシ (^^;;)．
＃「コンピュータは絶対正しい」という迷信を無くす役に立ってたり．．．
Junn Ohta
shi...@nintendo.co.jpさんは書きました。
> ネタとしては構わないと思いますけどそれでも程度問題でしょう。
> あれだけ連発されると「そろそろ気づけよ」って思えてしまいます
> から。
なるほど。私は自分から新しいトピックを起こしたりし
ない人間なので、田部さんみたいな人が出てこないと何
も書く気が起きないんですよね。だからそういう人に甘
い傾向があるのかも。
> これね、実は売り口上の前振りなんじゃないかとずっと穿ってる
> んです。
そんなのどうせみんなお見通しなんだからべつにいいじ
ゃないですか。:-)
> 単なる口下手で済ませていいのか疑問です。口下手というより、
> 直面する問題へのアプローチとか、話の持っていき方とか、文章の
> 表現とか、そんな辺りが技術系の切口ではないような印象を受けま
> す。
> どちらかと言うと、自己啓発セミナー系と言うか、霊感商法系と
> 言うか、ガマの油売り系と言うか。少なくとも純粋な技術論を語る
> 語り口ではないように見えますね。
これは私の印象と違うかな。ガマの油売りにしては下手
すぎます。どちらかというと「勤めてた万年筆工場が火
事で焼けちゃって倒産。給料がわりにくれたのが焼け跡
から拾ってきたこの泥だらけの万年筆...」のほうが近
いかな。まあ技術屋のにわか大道商売ってとこですか。
いずれにしても私からみるかぎり無害です。技術論だと
思って付き合ってよいのではないですかね。
> open source っていいですよねー、って、そういう目的で公開し
> てる訳じゃあないので、みんなで寄ってたかって赤ペンチェックさ
> れたら嫌かも :-)
> 私、本職の programmer じゃないのであんまり厳しい目で見ない
> でやって下さいまし。
「むくむふって何ですか?」ですもんね。:-)
冗談はともかく、しらいさんならご自分の書いたソース
コードの品質が他人からどう評価されるかについて客観
的に想像できるでしょう? その評価と実際に評価されて
みた結果が一致していればいいわけです。いいかげんだ
けど必要十分に動くと思って書いたコードが「いいかげ
んだけど必要十分には動くね」と評価されたのならそれ
はそれでOK。
Junn Ohta
gf4k...@asahi-net.or.jpさんは書きました。
> 田部さんが提起した質問と全然関係ないのですが，今回の銀行系のトラブルを
> 見ると，太田さんの意見より加藤さんの「国レベルでのプログラマの育成」が
> 必要な気がします．
みずほのシステムは知らないのですが、プログラマーの
レベルが高ければ解決していたような問題ではないと思
うのですけどね...。
Hideki Kato
In article <a9k77d$pav$1...@ns.src.ricoh.co.jp>, Junn Ohta wrote:
>fj.comp.lang.cの記事<3cbd9cad$0$27615$44c9...@news3.asahi-net.or.jp>で
> gf4k...@asahi-net.or.jpさんは書きました。
>> 田部さんが提起した質問と全然関係ないのですが，今回の銀行系のトラブルを
>> 見ると，太田さんの意見より加藤さんの「国レベルでのプログラマの育成」が
>> 必要な気がします．
>
>みずほのシステムは知らないのですが、プログラマーの
>レベルが高ければ解決していたような問題ではないと思
>うのですけどね...。
この件に関しては，実は前の記事の最後に一度書いたのですが，最終的に削
除しました．理由は太田さんと同じで，これは経営陣（と SE）の問題だと
判断したからです．しかし，コンピュータのトラブルが社会に与える影響の
大きさを顕にした，という点ではプログラマもこれを他人事（ひとごと）だ
と無視してしまってはいけないと思います．
また，一般の人は（SE とプログラマの区別なんてできませんから）コン
ピュータに関わる人間全体の問題と考えるのは当然で，我々もそれを真摯に
受け止めなければならないと思います．
＃例えば，自動車のトラブルで，それはエンジンだ，いや車体の設計の責任
＃だと言うのと同じ？ ＃＃経営者の責任は別？
NAKAMOTO Tetsuya
Message-ID: <3cbd8...@binarykiller.newsgroups.com>
> また，デバッグもコーディングに優るとも劣らない重要な分野だと思います
> が，これには推理探偵と同様の資質が必要だと思われ，経験上，ほとんどの
> 人に想像力が不足しているように思われます．こちらの能力を向上させる方
> 法については，まだこれといって有効なものを思いつきません (^^;;)．
デバッグ能力が重要だというのも、その能力を向上させる有効な
方法が思いつかないというのも、どちらも激しく同感です。
詰め将棋の問題集みたいなのがあればお手軽なんですけどねー。
# 高度なバグ問題を作るバグ作家の出現を希望。
--
中本徹也 (NAKAMOTO Tetsuya)
Self-employed programmer @ HACHIOUJI City, TOKYO.
tets...@heart.ne.jp
Junn Ohta
ka...@pop12.odn.ne.jpさんは書きました。
> しかし，コンピュータのトラブルが社会に与える影響の
> 大きさを顕にした，という点ではプログラマもこれを他人事（ひとごと）だ
> と無視してしまってはいけないと思います．
他人事だと無視するつもりはないです。というか、いま
どきそんなnaiveなことをおっしゃられても...。:-)
プロジェクト管理では一般に、許容される最悪の事態な
どさまざまな制約の中で効率の期待値を最大に保つこと
が重要ですよね。みずほの件はその「最悪の事態」とい
うファクターがきわめて大きかったものの、経営側がそ
れを見通せなかったのが問題なのでしょう。
> また，一般の人は（SE とプログラマの区別なんてできませんから）コン
> ピュータに関わる人間全体の問題と考えるのは当然で，我々もそれを真摯に
> 受け止めなければならないと思います．
とはいうものの、世間では今回の問題を「コンピュータ
に関わる人間全体の問題」と考えていますかね? 私はそ
れについては大いに疑問。
Hideki Kato
In article <a9keul$s1f$1...@ns.src.ricoh.co.jp>, Junn Ohta wrote:
>fj.comp.lang.cの記事<3cbd93f5$1...@binarykiller.newsgroups.com>で
> ka...@pop12.odn.ne.jpさんは書きました。
>> しかし，コンピュータのトラブルが社会に与える影響の
>> 大きさを顕にした，という点ではプログラマもこれを他人事（ひとごと）だ
>> と無視してしまってはいけないと思います．
>
>他人事だと無視するつもりはないです。というか、いま
>どきそんなnaiveなことをおっしゃられても...。:-)
あ，これは太田さんの事を書いたつもりはありません．ここの読者全員を対
象にしたメッセージです．
ただ，これが naive という意味が分かりません．:-) まで付いているので
益々分からない．．．
>プロジェクト管理では一般に、許容される最悪の事態な
>どさまざまな制約の中で効率の期待値を最大に保つこと
>が重要ですよね。みずほの件はその「最悪の事態」とい
>うファクターがきわめて大きかったものの、経営側がそ
>れを見通せなかったのが問題なのでしょう。
その点の判断が甘かったというのには同意しますが，そう単純に経営陣だけ
の責任とは思いません．
＃最終的な責任は当然プロジェクトの指揮者にあります．
まず，SE レベルで負荷の見積もりが甘かった．尤も，今回のシステムは規
模として国内では初めてと言っていいものだったと思います．また，その構
成もちょっと普通は考えられない形ですから，経験を最大の武器にしている
SE にはかなりきつい注文ではあります．
しかし，SE であれば，この状況に対して，安全率と言うか，それなりの危
険性を予測する事は可能だったと思います．これがどのレベルで握り潰され
たのかが（今回のトラブルでは）一番の問題だと思います．一番上が握り潰
したのであれば，これはどうしようもありませんが，もし技術系のスタッフ
の途中だったとしたら，これはやはり（政治的な問題ではなく）技術面でも
反省すべき点はあったと考えるべきでしょう．
ま，これだけの規模プロジェクトですから，安全装置は複数個有ったはず
（もしそうして無かったとしたら論外）で，それらが全て悪い方に働いたか
らこんなことになったのでしょうから，その全てに責任があると考えます．
分かり易く言えば，上の判断が誤っていると思ったら，技術者はあらゆる手
段を使ってそれを正さなければならない，って事です．
＃これだけシステムが複雑化して部外者に不透明になっている以上，技術者
＃がもっと判断＆主張＆行動しないといけない，そうでないと又似たような
＃事が起きるぞ，と言いたいのです．
＃＃これって naive？ (^^;)
>> また，一般の人は（SE とプログラマの区別なんてできませんから）コン
>> ピュータに関わる人間全体の問題と考えるのは当然で，我々もそれを真摯に
>> 受け止めなければならないと思います．
>
>とはいうものの、世間では今回の問題を「コンピュータ
>に関わる人間全体の問題」と考えていますかね? 私はそ
>れについては大いに疑問。
言葉が足りなかったようですが，これは今回の事例に関するものではなく，
「経営者（あるいは SE）の責任だからプログラマには無関係だ」という主
張は世間様 (^^;;) には通用しません，と言いたかっただけです．
＃今回の事例に関しては経営者の責任ということになると思います．が，
＃UFJ 銀行の ATM ダウン等，最近この手の事例が増えてますから．．．
Shigehiko SASAKI
> >プロジェクト管理では一般に、許容される最悪の事態な
> >どさまざまな制約の中で効率の期待値を最大に保つこと
> >が重要ですよね。みずほの件はその「最悪の事態」とい
> >うファクターがきわめて大きかったものの、経営側がそ
> >れを見通せなかったのが問題なのでしょう。
>
> その点の判断が甘かったというのには同意しますが，そう単純に経営陣だけ
> の責任とは思いません．
外野から勝手な想像だけしててもしょうがない話でありますが、
私は今回の障害は100%経営陣の責任であって、技術屋はかなり
健闘した方だと思ってます。
まず、みずほ銀行の合併は事実上ペイオフ解禁に耐えられない銀行の
救済合併であること。これは、みずほ銀行はそもそも去年4月に合併予定
だったのがペイオフ解禁の1年延期が決まったとたん合併も1年延期になった
ことが傍証にあげられます。
そして、経営陣の予想に反し2002年4月のペイオフ解禁が延期されないことが
確実になったのが去年の年末(小泉首相が宣言)とかなり遅い時期であったこと。
もし延期になったならば確実に合併も延期したであろうということ。
これは、日経などで報道されているシステム統合作業が年末から急に
始まっている印象を受けることを傍証に挙げます。
つまり、経営陣がペイオフ解禁の時期を見誤っていたこと。
そして2002年4月に強行された場合のリスクを軽く見ていたことが
最大の原因でしょう。
どうやっても絶対間に合わないスケジュールでシステムを作れといわれた
SEがすることは、たとえシステムが動かなくても技術屋側の責任ではないと
合意をとることです。今回は、広い範囲で免責合意がとられていると想像して
ます。それゆえスケープゴートとして技術屋の名が挙がってこないのでしょう。
> 言葉が足りなかったようですが，これは今回の事例に関するものではなく，
> 「経営者（あるいは SE）の責任だからプログラマには無関係だ」という主
> 張は世間様 (^^;;) には通用しません，と言いたかっただけです．
世間様というサイレントマジョリティみたいなものの見方はよくわかり
ませんが、私個人は顧客に対する責任は最終的にすべて経営陣にあると
思ってます。プログラマは経営陣に対して役務履行の義務があるだけで、
顧客に対してはせいぜい倫理上の責任がある程度だと考えております。
今回のケースでは倫理上の責任すらないんではないかなぁ?
以上、個人的な勝手な想像でした。
でかいの企画 佐々木茂彦
ssa...@dekaino.net
tabe
鶴田さん、こんにちは、田部です。
"Shin-ichi TSURUTA" <s...@emit.jp> wrote in message
> > > "tabe" <ta...@mug.biglobe.ne.jp> wrote:
> > > > 現象：
> > > > char cs[1024] ;
> > > > if(cs[0] == '\0') {
> > > > }
> > > > と、記述すべきところを
> > > どういう理由で「べき」なのかを書かないと、
> > 「文字列が空ならば」の表現は、
> > 慣用表現を使用すべきと言う意味です。
>
> 早速付帯条件がつきましたね。
？？？
>これ(cs)が文字列であり、
１．スレッドのタイトルで「文字列」と書いてていますけど？
２．プレインｃｈａｒの配列なので、
省略時解釈は単なる文字列になると思いますが？
３．変数名が短いですが、char string の短縮で、
大体類推できると、思いますが？
４．'\0'はそもそも文字列にしか使わないのでは？
>>かつ'\0'で空とし、
かつ？ ＆＆？
鶴田さんは、
「もし、空の文字列ならば」は
どの様に記述されるのですか？
>それを比較するものであることがようやく判りました。
ようやく判るんですか？
Ｋ＆Ｒ２の最初の最初、３６ページあたりに出てくる
初歩の初歩である、記述にそんなに説明がいるんですか？
> しかし、まだ不十分です。
まだ不充分なの？
> 扱う文字コードの種類が不明だし、
空の文字列を判定するのに、
EUC,ASCII,SJIS,etcは関係ないと思いますが？
> char cs[1024];
> は、ローカルなのかグローバルなのかも不明。ローカルでこのプロ
> グラムどおりの流れだと、csは初期化されていなく、直後にifが来
> ること(読み出しを行うこと)自体が問題になる。途中の何らかの処
> 理が省かれていると思われるが、そう言ったことを含めて、読み手
> に対する情報提供が不十分であり、日常会話ならともかく、NetNews
> で議論するには余りにもお粗末であると言わざるを得ないです。
「文字列が空ならば」の表現一つのために、
抜粋では駄目で
完璧にデッバグして、
動作環境を明示せよって事ですか？
> > > 少なくとも私は、暗黙のキャストよりは、明示的に記述する方が良
> > > いと思っています。なので、キャストがあること自体は問題は無い
> > > と思います。
> > キャストは無い方が良いと思います。
> > 使わなければ、使わないほど良いです。
> それを言うのなら、プログラムコード自体が無い方が良いです。
> 少なければ少ないほど「良い」です。
はい。
プログラムコードは少なければ少ないほど「良い」です。
> キャストが必要な場合を暗示しているのがわかりませんか？
キャストが必要な場合がある事は認識しています。
が、
鶴田さんの場合は
char を使用しないで、
BYTE を使用しているとの事なので、
typedef unsigned char BYTE ;
ＢＹＴＥ str[] = "abc" ;
strcmp(str,"abc) ;
と記述している事と思います。
そうすると、コンパイラが文句を言うので、
strcmp(char *)str,"abc) ;
と、キャストするはめになりますが、
これは、「キャストが必要な場合」でしょうか？
> カーニハンの「警告が出て参考になる」と言うのも、言語仕様を考
> える上で「参考」になるという意味にも聞こるぐらいで、言語の設
> 計者と利用者を同列に扱うのは不適切であると思います。
これは、「プログラミング作法」と言う本のなかで、
カーニハンが、
プログラマに向かって
複数のコンパイラで試してみよう
と説いて所で出てくる説明なんですが不適切ですか？。
> もちろんケアレスミス等を未然に防ぐため、警告やツールの分析結
> 果を利用するのは良いことだと思います。しかし、それは従うべき
> という意味ではありません。
従う、従わないは、プログラマが判断すべきと
私も考えます。
――――――――――――――――――――――――
以上
見て、勝手使って http://rec.ncos.co.jp
red brick
>> 扱う文字コードの種類が不明だし、
>
> 空の文字列を判定するのに、
> EUC,ASCII,SJIS,etcは関係ないと思いますが？
UNICODE だったら誤動作するかも。
--
赤煉瓦
Shin-ichi TSURUTA
> １．スレッドのタイトルで「文字列」と書いてていますけど？
書いてあるから何だと言うのでしょう？話題としては文字列を扱い
たいのはわかりますが、どの時点で「文字列」なるものが出現して
いるのか不明です。
> ２．プレインｃｈａｒの配列なので、
> 省略時解釈は単なる文字列になると思いますが？
なりません。char型1024個の配列以上の意味を持ちません。
> ３．変数名が短いですが、char string の短縮で、
> 大体類推できると、思いますが？
そういう類推は危険です。「csをASCIIZ文字列として扱う」等の説
明が不十分です。
> ４．'\0'はそもそも文字列にしか使わないのでは？
いいえ。単なる「文字」にも使います。
> Ｋ＆Ｒ２の最初の最初、３６ページあたりに出てくる
> 初歩の初歩である、記述にそんなに説明がいるんですか？
十分な説明がされている本と、唐突に問題を突きつけている貴方の
記事を同列に扱わないで下さい。
> 「文字列が空ならば」の表現一つのために、
> 抜粋では駄目で
抜粋してそのままでは駄目です。
> 完璧にデッバグして、
> 動作環境を明示せよって事ですか？
いいえ、十分な説明をつければよいです。
> > キャストが必要な場合を暗示しているのがわかりませんか？
>
> キャストが必要な場合がある事は認識しています。
> が、
> 鶴田さんの場合は
> char を使用しないで、
> BYTE を使用しているとの事なので、
> typedef unsigned char BYTE ;
> ＢＹＴＥ str[] = "abc" ;
> strcmp(str,"abc) ;
> と記述している事と思います。
> そうすると、コンパイラが文句を言うので、
> strcmp(char *)str,"abc) ;
> と、キャストするはめになりますが、
> これは、「キャストが必要な場合」でしょうか？
まず、人に読ませる文章というものを考え、出直してきてください。
Junn Ohta
してあります。
fj.comp.lang.cの記事<3cbdb525$1...@binarykiller.newsgroups.com>で
ka...@pop12.odn.ne.jpさんは書きました。
> あ，これは太田さんの事を書いたつもりはありません．ここの読者全員を対
> 象にしたメッセージです．
そうですか。それは失礼しました。
> ただ，これが naive という意味が分かりません．:-) まで付いているので
> 益々分からない．．．
「コンピュータのトラブルが社会に与える影響の大きさ」
なんてものはとっくの昔からアラワなんであって、そん
なの今さら鬼の首を取ったように騒ぐようなことじゃな
いでしょ? ということです。
> まず，SE レベルで負荷の見積もりが甘かった．尤も，今回のシステムは規
> 模として国内では初めてと言っていいものだったと思います．また，その構
> 成もちょっと普通は考えられない形ですから，経験を最大の武器にしている
> SE にはかなりきつい注文ではあります．
見積もりが甘かったというのはどうかな。あの手のシス
テムは処理可能なトランザクション量とか許容される最
大応答時間とか、あるいは安全マージンなど、かなりき
ちんと数値化されているものだと思います。負荷や作業
量を見積もって上に報告する立場の人間がそうそう簡単
に予測をミスすようなものではないですね。
したがって、
> しかし，SE であれば，この状況に対して，安全率と言うか，それなりの危
> 険性を予測する事は可能だったと思います．これがどのレベルで握り潰され
> たのかが（今回のトラブルでは）一番の問題だと思います．一番上が握り潰
> したのであれば，これはどうしようもありませんが，もし技術系のスタッフ
> の途中だったとしたら，これはやはり（政治的な問題ではなく）技術面でも
> 反省すべき点はあったと考えるべきでしょう．
技術系スタッフのレベルで予測を誤ったのではないかと
疑うのはやや無理筋でしょう。そういう可能性がないと
はいわないけど要因としては小さいと。
> ま，これだけの規模プロジェクトですから，安全装置は複数個有ったはず
> （もしそうして無かったとしたら論外）で，それらが全て悪い方に働いたか
> らこんなことになったのでしょうから，その全てに責任があると考えます．
> 分かり易く言えば，上の判断が誤っていると思ったら，技術者はあらゆる手
> 段を使ってそれを正さなければならない，って事です．
経営レベルでは安全装置なんてそうそう作れるものでは
ないと思います。それに技術屋レベルでスケジュールが
無理だと思えば当然のように上を説得しようと試みてい
るでしょう。それくらいのことはふつうの技術屋ならみ
んなやっていることだと思うけど...。
> ＃これだけシステムが複雑化して部外者に不透明になっている以上，技術者
> ＃がもっと判断＆主張＆行動しないといけない，そうでないと又似たような
> ＃事が起きるぞ，と言いたいのです．
> ＃＃これって naive？ (^^;)
そりゃnaiveだよね。:-)
技術者は現在でもじゅうぶん「判断&主張&行動」してい
ると思いますし、この業界では「いろいろしがらみがあ
って泣き寝入り」という後ろ向きの対応はよその業界よ
り少ないのではないかと思ってます。それでも「又似た
ような事」は何度でも起きているわけですね。
# 日経コンピュータの連載「危機からの脱出」のネタが
# 尽きないのもそれがいちばんの理由、と。:-)
> 言葉が足りなかったようですが，これは今回の事例に関するものではなく，
> 「経営者（あるいは SE）の責任だからプログラマには無関係だ」という主
> 張は世間様 (^^;;) には通用しません，と言いたかっただけです．
「開発部隊は必死に頑張ったけど経営側からの圧力でこ
うなっちゃったんだな」とすなおに想像できる程度には
最近の世間様はスレてるだろう、と私は思います。
Junn Ohta
fj.comp.lang.cの記事<3cbd8...@binarykiller.newsgroups.com>で
ka...@pop12.odn.ne.jpさんは書きました。
> また，デバッグもコーディングに優るとも劣らない重要な分野だと思います
> が，これには推理探偵と同様の資質が必要だと思われ，経験上，ほとんどの
> 人に想像力が不足しているように思われます．こちらの能力を向上させる方
> 法については，まだこれといって有効なものを思いつきません (^^;;)．
デバッグを行うには、プログラム実行中のある時点で計
算機内部で何が行われているかを見通す能力が重要だと
思ってます。もっと具体的にいえば、計算機内部を時間
を断面に切り取ったとき、アプリケーション、ライブラ
リー、OS内部などさまざまなレベルでそれぞれどんなデ
ータがどういう状態にあるべきかを認識する能力、です
かね。
そういう能力を高めるには、たとえばライブラリーやシ
ステムコールが内部で何をしているかについて学んだり、
それらに誤ったパラメターを与えたとき何が起きるかに
ついての知識も習得する必要があると思います。このあ
たりはべつに特殊な才能を必要としないので、勉強する
気さえあれば誰でもできることですね。
あとはそれらを組み立てて、低いレベルで何か不具合が
起きたときにそれが表面にはどういう結果として浮かび
上がってくるのか、どういうバグとして見えてくるのか
を想像するチカラが必要。これには才能も関係するかも
しれませんが、私自身の印象としてはシステムをすみず
みまで理解しているかどうかが鍵であって、才能は二の
次ではないかと思ってます。
いずれにしても、デバッグそのものに特化した能力なん
てものはなくて、自分の開発しているシステム全体に関
する知識と理解が深まれば、デバッグ能力も自然に高く
なるだろうということです。
システムによってはデバッグの定石のようなものもない
とは言わないけど、そういう表面的で姑息なテクニック
を学んでもデバッグ全般につながるスキルアップにはな
らないでしょうね。
デバッグに王道なし。
Takashi SHIRAI
In article <a9kbof$pfp$1...@nwjp2.odn.ne.jp>,
NAKAMOTO Tetsuya <tets...@heart.ne.jp> wrote:
>> また，デバッグもコーディングに優るとも劣らない重要な分野だと思います
>> が，これには推理探偵と同様の資質が必要だと思われ，経験上，ほとんどの
>> 人に想像力が不足しているように思われます．こちらの能力を向上させる方
>> 法については，まだこれといって有効なものを思いつきません (^^;;)．
>
>デバッグ能力が重要だというのも、その能力を向上させる有効な
>方法が思いつかないというのも、どちらも激しく同感です。
最初に確認なんですが、ここで「デバッグ」と呼んでいるのはバ
グを見つけることよりも、むしろその原因を見極めて修正すること
にある訳ですよね？
＃ いや、うちらの業界ではバグ探しをする人達を「デバッグ部隊」
＃と呼ぶもので :-)
>詰め将棋の問題集みたいなのがあればお手軽なんですけどねー。
巷に数多ある open source が体の良い問題集になっていると思
いますが如何でしょう？
残念ながら、世の中にバグの全くないソフトなんてまず存在しな
い訳で、バグの見本市会場になっていると思います。そういう状況
にあって、source が公開されていればそれを自分で修正すること
も可能なんです。
バグを見つけた時にそのソフトに対してどう対処するか、この辺
りがデバッグ能力に到達するための一つの資質になっていると思い
ます。
勿論、作者宛にバグ報告するだけという対処でも一ユーザの姿勢
としては十分なんですが、programmer の場合、ここで programmer
として技量を試されているとも見なせますよね。
ある程度流れが読めれば、原因が buffer overflow にあるとか、
もしくは初期化ミスだとか、そういう推測が出来ますし、そこから
更に一歩進めれば source の該当箇所だって当たりがつけられます。
単なる報告に終らずそういう対処もあり得る訳です。
最終的には bug fix patch を自分で作れるところまで辿り着け
れば良いのですが、そこに至るまでの段階的な stage も用意され
ていると思いますよ。
また、この過程では他人の source から学ぶべきことは多々あり
ますし、参考になる以外に反面教師になることもあります。結構至
れり尽せりの問題集だとは思いません？
># 高度なバグ問題を作るバグ作家の出現を希望。
MS に一杯いそうな気がするけど、残念ながらその問題集は非公
開なんだよねー ;-p
--
しらい たかし
Takashi SHIRAI
In article <a9l1j1$4a5fi$1...@ID-138684.news.dfncis.de>,
red brick <f...@qc4.so-net.ne.jp> wrote:
>> 空の文字列を判定するのに、
>> EUC,ASCII,SJIS,etcは関係ないと思いますが？
>
> UNICODE だったら誤動作するかも。
それは多分多くの人が一瞬思いつくことだと思うんですが、UCS2
ならそもそも strcmp() で比較すべきではないし、UTF-8 ならばそ
れで誤動作するのは MS の実装くらいなものです。
で、仮にそういう buggy な実装があったとしても memcmp() で
比較しないと "\0" の { 0, 0 } という配列の全要素を比較出来ま
せんから、結局 UNICODE 云々というのはこの際関係ないと思いま
す。
でもここではそんなことを鶴田さんは指摘した訳ではないと思い
ますよ。そもそも ASCIZ である前提すらどこにも書かれていない
訳で。
そういう「暗黙の前提」を本気で前提にしてしまうような姿勢は
技術者としては頂けませんよね。
＃ 重箱の隅ばかりつついてるのが優秀な技術者だとは言いません
＃けど。
--
しらい たかし
Takashi SHIRAI
In article <a9k69t$p5j$1...@ns.src.ricoh.co.jp>,
Junn Ohta <oh...@src.ricoh.co.jp> wrote:
>> ネタとしては構わないと思いますけどそれでも程度問題でしょう。
>> あれだけ連発されると「そろそろ気づけよ」って思えてしまいます
>> から。
>
>なるほど。私は自分から新しいトピックを起こしたりし
>ない人間なので、田部さんみたいな人が出てこないと何
>も書く気が起きないんですよね。だからそういう人に甘
>い傾向があるのかも。
あ、誤解されているようなんで訂正させて頂きますが、私は別に
そういう人や投稿を排除しようとは思ってませんよ。「気づけよ」
とは思いますが、それで気づかなかったとしても後は放っとくだけ
です。
今回の件は、「私のどこが悪い？」と聞いてきたので答えただけ
のことで、その回答には「だからどうしろ」という意図はありませ
ん。思い当たるところがあれば直せばいいし、そう思わなければ相
変わらず変わらぬ人生を過ごせばいいし。
でもまぁ、言ってあげるくらいはしますよ。私だって。
＃ 「社会の窓が開いてますよ」ってくらいの話かな。確かに暗に
＃閉めなさいとは言ってるんだけど、「これが私のファッションだ」
＃と返されたら「ああそうですか」以上のことは言えませんよね。
>いずれにしても私からみるかぎり無害です。技術論だと
>思って付き合ってよいのではないですかね。
私も害があるとは思ってません。ここの読者もそう無能な人ばか
りじゃないし、妙な影響を受けたりもしないと思います。
>> open source っていいですよねー、って、そういう目的で公開し
>> てる訳じゃあないので、みんなで寄ってたかって赤ペンチェックさ
>> れたら嫌かも :-)
>> 私、本職の programmer じゃないのであんまり厳しい目で見ない
>> でやって下さいまし。
>
>「むくむふって何ですか?」ですもんね。:-)
は？そんな command は POSIX にも規定されていませんが？ :-)
＃ imake なら、とも思ったけどこっちも無いみたい。
>冗談はともかく、しらいさんならご自分の書いたソース
>コードの品質が他人からどう評価されるかについて客観
>的に想像できるでしょう? その評価と実際に評価されて
>みた結果が一致していればいいわけです。いいかげんだ
>けど必要十分に動くと思って書いたコードが「いいかげ
>んだけど必要十分には動くね」と評価されたのならそれ
>はそれでOK。
私も昔は品質より動くものをまず作ることを優先させていたんで
すが、Linux kernel とか Samba とかいう実例を見てからは、徐々
に品質重視に傾きかけてますよ。
--
しらい たかし
Junn Ohta
shi...@nintendo.co.jpさんは書きました。
> 今回の件は、「私のどこが悪い？」と聞いてきたので答えただけ
> のことで、その回答には「だからどうしろ」という意図はありませ
> ん。思い当たるところがあれば直せばいいし、そう思わなければ相
> 変わらず変わらぬ人生を過ごせばいいし。
まあそういうところですね。
私は人間観察が好きなので、変わった人をみるとちょっ
と追っていきたくなります。対話もするし考えかたに介
入もするけど、その人固有の持ち味はいじらない程度に
とどめたい。ロンブローゾではないので分類して遊ぶこ
ともしない。:-)
> 私も昔は品質より動くものをまず作ることを優先させていたんで
> すが、Linux kernel とか Samba とかいう実例を見てからは、徐々
> に品質重視に傾きかけてますよ。
品質って、私にとってはいろいろな切り口のあることば
なんです。バグがあるとかないとかはそのうちのごく一
部ですね。
私にとってもっと重要なのは、設計とコードの両方が美
しくて統一感のあること。統一感というのはそのプログ
ラム自体で完結しているものではなく、周囲の世界との
インターフェースのとりかたも含めてですね。もっとも、
その種の品質を得るには設計やコードを書く段階になっ
て努力してもだめで、ふだんから自分の見識や技術を磨
いておくしかない。よいものを広く深く見ておくのはと
てもよいこと。
あと自分の性格も出るかな。私自身は考えかたがわりと
近視眼的なので、私の書いたコードもそうなっちゃいま
す。あとから見ると気にいらないことが多いけど、だか
らって書きなおしてももっとよくなるわけじゃないんで
すよね。
ソースコードを読むのって音楽を聴くのに似てるな。よ
いソースコードは心地よいリズムがあって、読んでいて
安らかな気持ちになる。Gosling Emacsは好きでした。
NAKAMOTO Tetsuya
Message-ID: <a9s567$b96$1...@nsvn01.zaq.ne.jp>
> 最初に確認なんですが、ここで「デバッグ」と呼んでいるのはバ
> グを見つけることよりも、むしろその原因を見極めて修正すること
> にある訳ですよね？
そうです。テストをする人たちじゃないです。
テスト手法は大学とかでも体系立てて教えてくれますよね。
> ＃ いや、うちらの業界ではバグ探しをする人達を「デバッグ部隊」
> ＃と呼ぶもので :-)
おお、私のとこはテスト部隊とか呼んでいました。
# "de + bug"なので、バグ修正の方がデバッグ部隊の本来の任務
# ではないかと。
> 巷に数多ある open source が体の良い問題集になっていると思
> いますが如何でしょう？
うーん、それは学生とか新人の訓練には不向きじゃないかなぁ。
あらかじめ不具合が判明していてその解答も分かっている問題集
があれば、安心してヒヨコさんにも渡せられるかなと。
そもそも、巷の open sourceを読んで理解できるような人は、も
はや周囲の人間が手をかけてやらにゃいかんようなレベルではな
かったりする。(^_^;
> MS に一杯いそうな気がするけど、残念ながらその問題集は非公
> 開なんだよねー ;-p
えっへっへ、Windows CE 3.0 の sourceなら公開されていますよ。
# Microsoft Passportに登録しないといけないのがちょっと面倒
# くさいですど、もちろん無料で down load できます。
http://www.microsoft.com/windows/embedded/ce/tools/source/default.asp
Hideki Kato
In article <a9kbof$pfp$1...@nwjp2.odn.ne.jp>, NAKAMOTO Tetsuya wrote:
>加藤さん wrote...
>Message-ID: <3cbd8...@binarykiller.newsgroups.com>
>> また，デバッグもコーディングに優るとも劣らない重要な分野だと思います
>> が，これには推理探偵と同様の資質が必要だと思われ，経験上，ほとんどの
>> 人に想像力が不足しているように思われます．こちらの能力を向上させる方
>> 法については，まだこれといって有効なものを思いつきません (^^;;)．
>
>デバッグ能力が重要だというのも、その能力を向上させる有効な
>方法が思いつかないというのも、どちらも激しく同感です。
>詰め将棋の問題集みたいなのがあればお手軽なんですけどねー。
これは面白いかもしれません．正解と点数／評価が付いたポケットブックで
すね．色々なレベルの物を用意するのも比較的容易だし．
＃Ｃ初段とか．．．（半々．
もっと膨らませれば，TOEIC みたいに，適正試験や資格試験にも使えるかも
しれないし，そうなれば真面目にやるだろうし．．．
># 高度なバグ問題を作るバグ作家の出現を希望。
んで夭逝する．．．（爆
Narita Takaoki
<a9s6nj$bqo$1...@nsvn01.zaq.ne.jp>の記事において
shi...@nintendo.co.jpさんは書きました。
> ＃ 「社会の窓が開いてますよ」ってくらいの話かな。確かに暗に
> ＃閉めなさいとは言ってるんだけど、「これが私のファッションだ」
> ＃と返されたら「ああそうですか」以上のことは言えませんよね。
「閉めなさい」と言ったら、「ファッショだ」と言われたり。(^^;
--
成田 隆興 ＠ エー・アイ・ソフト株式会社ソリューシュン開発部
E-mail tak...@aisoft.co.jp
『一秒間で決断し、短い理由を添えよ。』
Sugihara Yoshimi
> > ＃閉めなさいとは言ってるんだけど、「これが私のファッションだ」
> > ＃と返されたら「ああそうですか」以上のことは言えませんよね。
>
> 「閉めなさい」と言ったら、「ファッショだ」と言われたり。(^^;
どうせ脱ぐとき開けるんだから
に1票
Takashi SHIRAI
In article <a9sm3d$a20$1...@nwjp2.odn.ne.jp>,
NAKAMOTO Tetsuya <tets...@heart.ne.jp> wrote:
>> ＃ いや、うちらの業界ではバグ探しをする人達を「デバッグ部隊」
>> ＃と呼ぶもので :-)
>
>おお、私のとこはテスト部隊とか呼んでいました。
># "de + bug"なので、バグ修正の方がデバッグ部隊の本来の任務
># ではないかと。
勿論原義から言えばそうなので「:-)」付な訳ですが、業界固有
の慣用なんてものは得てしてそんなに論理的なものではないもので
して。
そもそも、本当に debug のみを生業とするような人達がいるな
んてのは、よほど大きな会社だけなんじゃないでしょうかね？普通
は開発者自身で debug しません？
>> 巷に数多ある open source が体の良い問題集になっていると思
>> いますが如何でしょう？
>
>うーん、それは学生とか新人の訓練には不向きじゃないかなぁ。
>あらかじめ不具合が判明していてその解答も分かっている問題集
>があれば、安心してヒヨコさんにも渡せられるかなと。
本当の素人ならば市販の C の教科書で十分でしょう。ここで必
要とされているのはその次のステップなんだと思いましたが。言語
仕様をマスターした後での実例集といったところでしょうか。
実際、C そのものをひと通り学ぶだけなら一カ月もあれば十分で
すよね？どうせ個々の関数仕様なんかは man page 見ながら実装す
るんですから、必ず憶えなくてはならない事柄なんてたかが知れて
るでしょう。
そのレベルの熟達度でも patch work は可能ですよね。実際、私
も C を憶えたての頃は「むくむふって何？」なんて言ってるド素
人でしたが、その頃から patch work はやってましたよ。
むしろ、一から組むよりは間違い探しの方が楽かも知れませんよ
ね。
>そもそも、巷の open sourceを読んで理解できるような人は、も
>はや周囲の人間が手をかけてやらにゃいかんようなレベルではな
>かったりする。(^_^;
そんなに難しい software ばかりじゃないと思います。かと言っ
て、理解し易い software なら bug なんて存在しないかと言うと
必ずしもそうとは言えない訳で。
そもそも最近は PC-UNIX の binary 配布が盛んで、自分で一か
ら compile する人が減っちゃったんじゃないでしょうかね？自分
で compile しようとすると、可搬性が甘くて大概どこかで compile
error を起こしていたものです。
机上の空論とは違って、修正した source を compile すれば実
行 module が生成される訳で、その挙動を見れば debug 出来てい
るかどうかの最低限の判断は出来ますよね。
勿論、それが最適解であるかどうかの保証はなくて、実は全く別
の bug を仕込んでしまっていたりする場合もあるでしょうけど、
その過程で得るものが何も無いとは思いません。
--
しらい たかし
saitoh akinori
Takashi SHIRAI wrote:
> しらいです。
> そもそも、本当に debug のみを生業とするような人達がいるな
> んてのは、よほど大きな会社だけなんじゃないでしょうかね？普通
> は開発者自身で debug しません？
聞いた話では、外注の書くコードの質が悪く、任せておいたら
デバッグが遅いので、元請け側の技術者がデバッグしている。人手が足
りないので、それでも外注を切れない。
ということがあるそうな。
本当？
Kazuo Fox Dohzono
Hideki Kato <ka...@pop12.odn.ne.jp> writes:
> いずれにせよ，ある言語を使いこなせるようにするためには，言語仕様（文
> 法など）は後回しにして，「どういう場合にどういうコードを使うか，そし
> てそれは何故か※」という実例をなるべくたくさん覚えさせる，事から始め
> るのがいい（＆それしか無い）のではないかと感じています．
> ※これが大事．
> ＃（実用的な）英語を教えるのと同じです．
その後の話になると思いますが, ある本から引用します.
技術家の仕事もおなじことで, ある意味では芸術だ. 一つの技術的な問題を
解くにも, それぞれの流儀と方法がある. 技術家は, 絵描きと同じように,
その流儀の選びかたで, はっきりと署名 (「署名」に傍点) するのだ.
さて, この本は誰のなんという本でしょう :-)
rot: 奩墫堋垪墫堋圄丼癜唏圄�丿でした :-)
--
Kazuo Fox Dohzono / doh...@hf.rim.or.jp