プログラミングのうまい下手は

プログラミングのうまい下手は、
どんな言語を使うかではなく、
１アイデア
２操作性
３アルゴリズム
だと思いますが実際のところどうでしょう。

集中力が全て。物事に偏執する粘着質の精神的パワー。

煩悩に負けない忍耐力

＞どんな言語を使うかではなく、
「ＶＢ好き」に言われてもナァ…

>1
>３アルゴリズム
そのアルゴリズムを詰めていくと言語の選択も
重要になってくるんだよね。

１の言うのはプログラムの、というより設計のうまい下手のような気が‥
プログラムのうまい下手というのは、言語やＯＳや開発環境を含めた
使いこなしのことではないだろうか？

「分析」だともうな。地味な答えだけど、アイディアにしろアルゴリズムに
しろ、新しいものを生み出すのには、分析あるのみ、と。
知らないアルゴリズムなら調べればいいけど、どにもないアルゴリズムは
自分で生み出すしかないし。

僕は
「メンテナンスのしやすいコードを書けるかどうか」
だと思うなあ。

ゲイツいわく、
「よいプログラマになるものは、最初の２、３年でよいプログラマになる」
つまり才能。
具体的にはたぶん、バランス感覚とか。あと、物事の裏に回りこむ
能力みたいなもの。正面突破するパワーは鍛えられるけど、こういう
ものは鍛えられない。

>9
なかなかよいことをいう。。さすがに苦労してますな。
ちなみにゲイツがどこで述べたのだろうか

>>1
それって、いいプログラムとは何かで、
プログラミングが上手い下手じゃないんじゃない？
ついでに言うとプログラムを見てプログラミングが上手いかどうかなんてわからん。

たぶんVBが否定されっぱなしで悲しいいんだろうけど、
VB製のアプリはWIN標準のインターフェイスを知らないのがほとんど、
MFCを覚えればいろいろ解かると思う。

>7
分析、だけじゃなくて整理し、構成し、そして
応用ができるようになるんだと思う。

アイディア・センス・技術はその結果後から付いて来る
ものかもね。プログラム以外の予備知識も重要だなー。

#「VBではせっかくのアイデアが活かせない」っての、あると思うよ。

>1
良いプログラムの基準が解らないなぁ。
パフォーマンス？
コストパフォーマンス？
メンテのしやすさ？
自己満足？

> VB製のアプリはWIN標準のインターフェイスを知らないのがほとんど

ＶＢでできないことなんかそうはないよ。
ＶＢが悪いんじゃない。ＶＢでそういうアプリを作るやつが悪いのだ。

＃ＶＢ製でなくてもひどいのあるけどな‥

あぁぁ、いつもの展開に…

>15
そうやって会話して、みんな厨房を卒業するんだから
大人はおとなしく見守ってﾔﾚ

ところで、プラグラマとコーダーを別に考えるとすると、
やっぱり、細かい設計はプログラミングに入るんでしょうか？

でしょうかといわれれば、そうでしょう。

プログラミングのうまい下手か・・・
バグの発生率と関係がありそうな。
汚いけどバグフリーなコードと
綺麗だけどばぐだらけなコードとか・・・
うーん、眠たくなってきた。

>>19
現場の状況によっても変わるよね。
俺は後者だとは思うけど。

プログラミングのうまい下手は
プログラミングがうまい人にしか理解できないと思います．

もし本当にバグが"無い”のなら、前者だと思うんよね。
でも、これって、バグが未発見であったり、症状として現れないだけで"無い"わけじゃない。
そうすると、汚いコードだと、いざバグを発見した時点で、原因追及が難しかったり、
バグをつぶせなかったり、最悪無関係な処理をよりおかしくしてしまったりし兼ねないよね。

保守性のよいきれいなプログラムが上手なプログラムなんだろうな。
しかし、それでバグだらけだと、うーん、デバッグが足りないんだろうなぁ。

バグの多い少ないは、その実装がどれぐらい枯れているか
のほうに大きく依存してそうなので反対。
へたくそでもいつも同じ事しか書かなくてバグが出ない人もいる。
（ある意味自分を知ってて有能とも言える）

全く新規な（といっても今時もう無いかも）ロジックを
書いてもらって比較したいね。
もしくは、仕様変更にたいする耐性かな。
メンテしてるときに書き換えるところが少ないほど
「うまいなあ」と思う。

保守性と性能のバランスが取れているものがうまい。
要は品質高いソースを短時間で作れる人がうまい。

あと、汚いコードを、なぜかいとも簡単に保守出来る人はえらい。

脳味噌のスタック領域が相当広いんだろう。

俺レジスタも少なくてちょっと前のことも真剣に思い出さないと
だめなんだよね．．．

俺も最近、Ｚ８０レベルにまで落ちてるような気が、

１アイデア ・・・大きくなると要Exe分割、Win32APIコール一苦労、インストーラ死ＶＢ
２操作性・・・画面を何枚か開くとメモリエラー、インタープリタ&ActiveX劇遅ＶＢ
３アルゴリズム・・・ポインタも派生も出来ない、エラー処理古いＶＢ

チームプレイでプログラミングするには、もちろん、

・みんなが見やすい
・保守性がある

コードを書く、ということは、大事だと思います。

しかし、私、プログラミング能力という意味では、

いきなりエディタに向かって書き始め、どんどんコードが巨大になっても、
ちっとも破綻しない。

という人が、才能のある人(凡人が「方法」を勉強しても辿り着けない境地に居る人)
ではないかと思います。こうゆうひと、たまに居るよね。

>29
実は、時々ひそかに大幅に書き直してたりして。(これは凡人?)

> 23
へたくそでもいつも同じ事しか書かなくてバグが出ない人もいる。
（ある意味自分を知ってて有能とも言える）

おお、枯れてない方法は絶対に使わない、という、揺るぎ無い意志!!
私は、これを実践できる人こそプロだ、と思っとります。

やったことないことはやらない、という考えの人を馬鹿にしているのではなく、
本気でそう思っています。

23氏の発言は、私の良心に、深く深く響くお言葉でごさいます。

私は、お客様のための大切なプロジェクトなのに、いつも実験君になってしまい、バグを出してしまいます。

これでは、プロではありませんね(プロとかゆう以前に性質の問題ですね)。

でも、この癖は絶対に直らないと思います。

鬱だ氏のう...

>・みんなが見やすい
>・保守性がある

これって言語に依存だよね。例えば、アセンブラやＶＢでは×。

>へたくそでもいつも同じ事しか書かなくてバグが出ない人もいる。

やっぱ、クラスにしといて差分コーディングするしかないね。派生が出来ないＶＢは×。

で、基底クラスに大規模な変更があったときに、さあ大変。

>34
基底クラスの変更で上に影響があるような変更だとしたら、
誰かがお馬鹿をやってるはずってことじゃないですか？

インタフェイスの変更しないですむようにそのクラスを作って
ないってことでしょ？いや、現実には難しいのかな？

>現実には難しいのかな
そうなんよ…なんでかね…

>>33
派生ができるVB7だったらOKなんか?
http://www.microsoft.com/japan/developer/vstudio/nextgen/technology/language.asp

>37
VBは、派生云々以前に環境汚すの何とかして欲しい｡

>>38
それは言えてる。
一度インストールすると、元の環境に戻すにはOSごと再インストール
するしかないもんな。

>38
それってVBじゃなくてMS全般に言えることじゃ、、、

VBで作られたカスみたいなソフトでさえその破壊力を備えてる。

何を以ってそう言ってるのかよくわからないんだけど、
ランタイムのSP違いとかそんなのはユーザ側の問題だと思うよ。

うまい下手見分けるなんて簡単だよ
それは英語。
英語も出来ないやつの書いたプログラムなんて
見る気もしませんって感じ。
変数、関数名のスペル間違いの多い奴は間違いなくヘボ。

>>34
話の流れからいくと、基底クラスは枯れてるんじゃないのか？

仮に大幅な変更があったとしても、いっそのこと既に派生したクラスは不問とした上で、
基底クラスから新たなクラスを導出し、その上で新規のクラスはそこから導出するように
するってのはどうよ？
ま、それができない状況なんていくらでもあるだろうけどさ。

＞19

１、>汚いけどバグフリーなコードと
２、>綺麗だけどばぐだらけなコードとか・・・
追加で
３、綺麗でバグの少ないコード。

プログラムの品質の話になるとよくこの両者が比較されるけど、
１は、下手糞が作った完成品で
２は、未完成なプログラムでしょ。
バグだらけで綺麗なコードって事は、まだなんにも出来ていなから
これからデバックして行けば、１になるか３になるか解からないじゃない。
もしプログラマーが、綺麗に書けたけどバグバグしてる。って主張するなら
デバックさせれば良いと思う。あっという間に１になるから。
完成した段階で、綺麗でバグの少ないコードを早く作れるのがプログラミングが
上手いといえるんじゃないかな？
そーゆうプログラムってチューニングもしやすいし。

45を読んでいてい思い当たったのだが、中級者のプログラムを見ていると
Aの部分は非常にうまくかけた。Bの部分はまだきれいにまとまらない
のでもう少し手直しします。というパターンによく出会う。
で、一生懸命Bをいじくり回して四苦八苦しているのだが、この場合えてして
Bの部分がうまくまとまらないのはAに原因があることが多い。
さらにAとBの担当者が別だと別の問題が絡んできて…

日常に埋没している中、ふと全体設計が大事だなっと思うのはこんなとき。

でもさ、きれいにかけたAまで手をつけちゃうと、納期に間に合わなくなるよ。

A＋Bを書き直す手間とBでもがく手間との工数をきっちり見極められるのが
うまいプログラマだと思う。(もちろんA+Bを書き直すのが常に正しいわけではない)

すばらしいコードの実例をみせて。

ん？49は煽ってるのかな？違ったらすまん。

４９＞
そこらの初心者用のプログラミング参考書見れば腐るほど載ってるよ。
プロの腕の見せ所はそれを（宇宙に存在する原子の数）倍ほど複雑なプログラムでも実現してみせるとこでしょう。

ぼくにとってうまいプログラミングってのはインターフェース部分がしっかり作成されていて、オブジェクト単位で独立してるようなコードがかけるということ。
バグが多い少ないなんて議論は不毛。将来バグが多くなるか少なくなっていくかはこの一点によると個が多いと思う今日この頃。

蛇足かもしれないが46は45への反論とかではない。むしろ同じスタンスと思っている。

その名前にしてはまともなことを言う。つっこめないぢゃないか。
もっと名に恥じないことを言うように。

インタフェースがきちんとできてりゃ言うことないよね。
それが難しいんだよね。段階的に詳細なインタフェースを
手間かけずに楽にかつ安全に定義できる、インタフェース言語が
あればいいのに。

世界が平和であればいいのに

>49

int main(int argv＠｀char* argc)
{
/* 旅に出ます。
　　　　ごめんなさい。
　　　　ごめんなさい。
　　　　ごめんなさい。
*/
return 0;
}

＞int argv＠｀char* argc
天然っぽくてステキ（はあと

＞（宇宙に存在する原子の数）倍ほど複雑なプログラム

う〜む。せいぜい、１０〜１００倍と思うんだが。

プログラミングのうまい下手は
特殊なテクニックを使わずに、
短いコードをかけるやつですね。

言語が、OSが なんて言っている連中にかぎって
まともなコードがかけないものですよ

プログラミングのうまい下手は
上手なコードをかけるやつですね。

>58
複雑さの数え方によるんじゃないか。2^(コードのバイト数)とか。

プログラミングのうまい下手は、
さくらんぼの枝を舌で結べるかどうかで分かります。

>特殊なテクニックを使わずに、
>短いコードをかけるやつですね。

だから、派生が出来ないＶＢは×。

但し、将来出来るは×ね。ＶＢの場合、機能が増えるたびに環境破壊が深刻になる。
毎度→ ttp://www5.airnet.ne.jp/init/vb/level1/level1001.html

>だから、派生が出来ないＶＢは×。

喧嘩を売られたのかな？（笑）

派生が使えないとまともなプログラムが組めないのなら
プログラマーを辞めた方がいいんじゃない？
って 思うぐらいのレスですね

プログラムの上手いやつはそんなものを使わなくても
上手いコードを書くものですよ。

＞57
ごめん本当に天然だった。
こんな僕は上手いプログラマーになれるでしょうか?

>プログラムの上手いやつはそんなものを使わなくても上手いコードを書くものですよ。

派生を否定する方がプログラマ辞めるべきだ。

>派生を否定する方がプログラマ辞めるべきだ。

別に否定したつもりはないんですけど
ただ 使えない環境ってのも存在するんですよ
使えないから プログラムできませんでは、
駄目だと思うのですが、どうでしょうか？
そのなかでも ベストのコードを書ける人は
いるって言いたかったのです。

ＶＢ自体はオブジェクトの寄せ集めに見える・・・・

文章は論理的に正しいが、内容が正しくない。
開発環境が無いなら、それさえも作るのがシステム開発。
それを知らないならプログラマ辞めるべき。
後、Cですらオブジェクト指向言語になって、実用化されて相当経つ。

>70
本末顛倒じゃないか？
なんで「オブジェクト指向言語」にするかとゆーと
保守性とか開発コストを下げるためでしょ
Ｃで足りてる実装に、無理してＣ＋＋にする必要はない

と思うぞ

>Ｃで足りてる実装に、無理してＣ＋＋にする必要はない

足りてないから言語が開発されている。
例えば、SUNが「C++の簡易インタープリタ言語 for 組み込みシステム」として開発したのがJava。
（現在のJavaは嫌い）
現状に甘んじてしまうのは、「腐った言語ユーザ」に多い。（根拠は無い。経験則）

>開発環境が無いなら、それさえも作るのがシステム開発。
>それを知らないならプログラマ辞めるべき。

う〜ん プログラムを上手に書くかってのが
お題だったのに、なんで こんな方向に行くのだろうか？
俺の方が頭おかしいのかな？
悩んできます （笑）
別に否定したわけでもないのに 否定したかのように受け止められて
う〜ん

スレッド題読んでみて。全てが解決します。あなたのお題なら、あなたがスレ建ててね。

>>72
いや、足りてると思ったらC使っていればよいだけで、
足りない人がC++を使えばよい、て話じゃないのか？>>71
そんなに無下に否定しなくても。

あと「開発コスト」というの政治的問題も絡んでしまうので
開発効率としておくのが良いかと存じます。

>1
ゲームとか研究的な所以外は、アイデアはほとんどいらない。
ソフト開発は本人達が思ってるほど「クリエイティブ」では無かったりする。
実は。

何か、誰も聞いてない質問に答えているようだぞ。

ＶＢはもちろんだが、ＢＣＢでもその現象は起きてるぞ。（ＶＢほどではないが）

ソフト開発に「アイデア」が必要な場面はいくらでも有るっしょ。
それに、いまどきソフト開発が「クリエイティブ」だって思ってる
やつって、そんなにいるのか？

アイデアなんて不安定なものに頼ってるのはへたくそだけ。

アイデアを不安定だなどと逝っているのは、力技に頼るだけのヘボ。

アイデアってなによ。

１理解力
２行動力
３センス

＜アイデア
力技より多少マシな考え。

アメリカの某プログラム系のコンテストのお話し。
発見的な手法（アイデア）に頼ったプログラム大半は、
力技のプログラムにかないませんでしたとさ。
おしまい。

発見的な手法の内容を押さえて置きたいんだけど、やっぱ、それ以上情報無いんでしょ？

<85
「大半」ってのが微妙だな。
くだらねーアイデアより力技、それより良く練ったアイデア、っていうようにも思えるし、
めったに出ない良いアイデアより、確実に結果を出せる力技、っていうふうにも…

確実に結果を出せる力技>>めったに出ない良いアイデア
>>中途半端な力技
かな？

>>85
某プログラム系？コンテスト？
プログラムっぽい何かが
琵琶湖の上でも飛んだの？

まじでモニタの前でばかうけしちまった
あ〜腹いて〜

>>90
あなたの想像力に乾杯

「囚人のジレンマ」のコンテストの事？

>92
アメリカの昔のチェスプログラムのコンテスト（大会）の話しです。

仕様を最小努力、最短時間で実現できればいい
アイデアがどうしたこうしたなんて学生レベルだぜ？

>>94
その発想が駄コードを膿む。

>>94
算数ドリルやってんの？

>>94
コピー＆ペーストでプログラミングですか？

>>97
もちろん！
プログラミングかどうかについてだけ考え
質についてはここでは言及しない。

最小努力、最短時間で実現するためにアイデアを絞るんじゃねーのかな。

プログラムをプログラムの世界だけで見ちゃいけないと思う
プログラムは現実を抽象化してる訳だから
そういう所の視点とかでセンスが問われるって事はない？

コピペをうまく使える奴が１番。

>101
あんたは今後プログラムするな。
ソースコピペはOOPでは犯罪扱い。

一口に「最小努力」「最短時間」といってもどの程度長期的なスパンで物事を
考えるかで変わってくると思うが。
「汎用性」やら「ポータビリティ」やらを求めるとは、その場限りの話で言えば
余分な工数を必要とする訳で。
例えばそのプログラムが「どの程度使い捨てでいいか」を判断するのも、一つの
「センス」だろう。

＞ソースコピペはOOPでは犯罪扱い。
俺のまわりでOOPとか言ってるやつって、まともな
クラスひとつ書けないやつばかりなんだわ。まあ
利用するのは、上手なんだけど。。。逆に、すば
らしいクラス書け、何でも出来る人は、OOPなんて
気にしてないよ。OOP、OOPってうるさいやつは、
他人の作ったものを利用することには長けているよ
うな気がするけど、一流のやつは見たことないもの。
口だけのやつが多すぎる。。。あんたもそうなの（笑）

OOPはね、オブジェクトを設計して用意する方と　、それを利用する方にひとを分けるの。
分ける率は（2：8）くらいかな。
その、クラス設計してるとか言ってる人のさらに(2:8)は　参考書コピペ型ね。

だから君の言う事も一面正しいと思うよ。　でも残る４％くらいは俺ら下々には
想像出来ないような発想力と行動力を持ってるみたいね。
ただ、人間として一流かどうかは別かもね。それはさらに(2:8)だと思うよ。

という事で、とりあえず尊大なひとは素直に尊敬する所から入る事にしてるけどね
そういう付き合い方の方が楽だからさ。
でも、正直、あたりは少ないけどさ。
まあ平凡な才能者の世渡りの知恵って奴かな

すると、OOやってる人の1000人に8人がきちんと設計ができて人間もできていると。
ちょっと多く見積もりすぎじゃないかな(笑

いつも思うこと。設計書命の馬鹿SEには関数きりだしも
クラスツリー構造の変更も許してもらえないけど｡

同じクラスの別関数からコピペするくらいなら
privateの関数に切り出して共有してくれ｡

機能の似通ったクラスいっぱい作るのなら、インタフェイスだけ
切り出して抽象基底クラス作って、それ継承していとこクラス
にしてくれ。共通の関数は抽象クラスにprotected（クラス外から
よびだすんならpublic）関数と言うことにして移動させといてくれ｡

それで大抵のコピペはなくなるっしょ。