スラッシュドット・ジャパン

このお題を見て、てっきりFortranの桁揃えのことかと。メインフレームメーカーは7桁目に縦線の入ったコーディング用紙を供給していましたね。フローチャートのテンプレートも供給していた。当時は富士通を使っていたので、FACOMってロゴ入りだった。

FACOMのFortranのテキストにFortranの歌も載っていたな。おおブレネリの替え歌。
ヤーッフォーッフォートランランランてやつ。

「もうやらなくてもいい昔のコーディング規約」かと。

でも、「コーディング規約⊂コーディングテクニック」の様な気もします。
それなりの合理性が有るノウハウや、バグの作り込みの原因を分析結果を元に、決められたのが、コーディング規約な訳で……ま、「規約」なるモノの常として、大概の場合、決められた、その時から、形骸化が始まる訳ですが。

それと変更した日付と変更した人の名前を残すってのがありましたねー。
2004年ごろの話ですけどね！
#CVSやSubversionが今ほど普及していなかった頃の話
#多分今も普及してないだろうけど、あの部署

>直接教育担当ではないので、口出ししないように言われている

その身分制度(の過剰さ)も、かなりおおきな害悪なので、どうにかする努力をしたほうがいいです。

問題指摘なんてのは「社内で一番最初に気づいた奴が言う(という権利が有る)」ことにするのが一番です。
それを採用するかどうかはまた別としても、まず言う権利くらい全員に与えないと、なにしに「会社」に大勢が雁首揃えてるのか判りません。

>フローチャート

無数にある実装(/設計)上必要なもののうちのごくごく一部でしかないですね。
たまたま一本の長い流れが発生したときにそれを記述しやすいというだけなので、フローチャート自体がデザパタとかと同様に「特定の状況では有効、別の状況では逆効果」というものでしかないです。
そういう状況になったときには「そういやフローチャートなんてものもあったな」と押入れから引っ張り出せばいいものであって、常に机に置いておくほどのもんじゃないです。

そして、他の人がいってるように並列処理も書けないし、OOPを引き合いに出すまでもなく状態変化やマルチ状態も書けない。つまり「コンテキスト」を記述する能力が無いんですよねフローチャートには。バグは処理そのものよりも処理と絡むコンテキスト(の誤用)に宿ることが多いので、それが見えにくいフローチャートはあんまり役立たないことが多いなあ。つまり本当に数少ない特定の場面でしか有効ではなく、大抵は邪魔。

フローなんぞより、データ構造のほうが余程大事ですし、データ構造を基準に見れば全体が判る「ように設計」すればますますバグりにくくなります。自社を倒産させたくないならば狙うべきはそっちですね。

AppleSoft BASICは識別子の最初の二文字までしか有効でなかったので、気づかずに変数を書き換えてデバッグに苦労した思い出が蘇りました。

アセンブラが買えなかった子供の頃にはPeek/Pokeでハンドアセンブルとかやったなー（遠い目）

自分は、スコープの長い変数には必ずdescriptiveな名前を与えるというルールで書いています。つまり、ループ変数でもループ自体が十分長ければ i ではなく意味のある名前を与えるということです。スコープが短く、一画面で見通せるくらいの長さならば i でもOKということにしてます。

私かもしれません。すみません。
ちなみに、模範解答はどうなりますか?

どうせ、iの代わりにindexとかを使うのだろうから、iで十分。

＞malloc/freeの処理コストの方が高くなったりしないのかな？
＞と。「だいたい、こんくらいとっといてぇー」というようなプログラミングスタイルは無いのだろうか、と思う。

チマチマ何回かに分けて取るより一回にまとめて取った方が相対的に安くなる
ので、「だいたい、このくらい」でまとめて取ってから、それをアプリ内部で
チマチマ切り刻んで使うというテクニックは昔からあったと思います。

そしてJVMなんかだと、それを自動でやってくれるので、Javaな人にとっては
これも「もうやらなくていい昔のコーディングテクニック」の一つですね。

それから、OSが仮想記憶をサポートして以降は、mallocは実メモリを確保する
わけではなくOSの管理テーブルに予約するだけなので、ちょっとくらい大きい
領域を予約しても影響はすごく小さくなってるはずです。

malloc/freeはシステムコールなので呼ぶとコンテキストスイッチが発生します。
特にCPUのクロック数よりもL2キャッシュのヒット率とかのほうが性能的影響が
大きいようなメモリレイテンシにシビアなシステム、例えば、
マルチスレッドでサイズの大きいヒープを頻繁に生成／開放しながら
沢山のアクセスを受け付けるサーバーアプリみたいな処理系では、
コンテキストスイッチのオーバヘッドが馬鹿にならないので、
JVMや.Netのようにヒープの大枠確保しておいて、プロセス内部で
cpu user timeでやりくりするメモリ管理があったほうが性能的には有利。
というもんだと理解しとります

紙テープを繋ぐツールが色々とありましたね。でも、こんどは高速のテープリーダにかけると、繋いだところでテープがひっかかってちぎれたりするんですよ。

さん孔タイプライタで打ち込みに集中していたら、テープが引っかかって、横一列に穴が空いていただけっていうトラブルも見かけました。集中していても、たまには脇見をしましょう。

あと、忘れてならないテクニックが、メインフレームのラインプリンタは筐体が大きくて余裕があるので、ものを隠すには最適ってことです。オヤツとか隠しやすい ^-^)

パンチカードの束をうっかり落としてバラバラになっても、すぐ順番に並べられるように、束の側面に斜めの線をマジックで引いておく。

除算も同じシフト演算で置き換えしてましたですよね。ただ、組み込み系のような、いつまで経っても進歩しないアホなコンパイラを使わざるを得ないケースとかですと、未だ現役の知識なのですｗ

それはさておき、

z = x * 8 + 1; と等価のつもりで z = x << 3 + 1; と書いてバグった

私の場合は、演算子の優先順位というのを頭に入れるのが面倒でしたので、四則演算の組み合わせでも括弧をつける癖をつけてました。10年前はアホだの無駄だのひどい扱いを受けていましたが、今は「コーディングの鏡」扱いされるのって、複雑な気分です。

余談ですが、CPUの命令によっては高級言語を意識した命令があって、例に挙げられたような n * { 2,4,8 } + { 0-7 } のような演算を1命令でこなせるモノもあり、コンパイラによってはちゃんと置き換えしてくれるものもありますね。昔はインラインアセンブラ使って人力コンパイルしたりしてました。

＞これがコーディング規約の力なのか？
違います。

コーディング規約こそ、なんの役にも立たない御託そのものだと思います。

そのへんの制限はGecko 2で一気に取っ払われる予定で、たとえば今nsresultを使っていちいち戻り値を判定しているものはC++例外処理に置き換えられたりするようです。
昔はキャスト演算子すら満足にそろっていないコンパイラが多くてマクロで代用していましたが(NS_REINTERPRET_CASTとか)、これはだいぶ前に解禁されてマクロは廃止されました。64ビット整数も同様の理由でサポートしていない環境では構造体にtypedefされる特別な型を使ったりしていたのですが、現在は解禁されています。

その頃とは難しさの「質」が違いますよ。
今のシェーダプログラミングの「難しい」は、ライティングなどのモデルにおける数学や物理の難しさで、
昔のポリゴン描画の「難しい」は、キャッシュフェッチなどのスループット向上の難しさです。

昔のポリゴン描画は数学ではせいぜい外積までしか使わなかったため、そういう意味では敷居が低かったと思います。

昔のBASICの高速化のテクニック(?)として、

・プログラムの最初でDEFINT A-Z
・よく実行されるコードは最初の方においておく (行番号を先頭から線形探索しているから？)
・変数名は短くする
・複数行はマルチステートメント化する
・IF I=29 THEN X=X+1 ELSE IF I=30 THEN X=X-1の代わりにX=X+(I=30)-(I=29)とする。

とかいうのを思い出しました。

それらは実装次第だから、処理系によるね。

例えば、For ～ Next ～は、Fortran時代からよく語られたテクニックだけど、ちゃんと最適化していたら違いはないはずだからね。

普段使いはPythonとJavaとC#ですが、やはりいざって時にC/C++は頼りになる。
なんというか、まぁナイフとロープみたいなもんじゃないでしょうか。
日常生活ではもっと各種用途に便利な機能を備えた道具がたくさんあるけど、
極限の状態でこの道具があったから生き残れた、みたいな。

まぁ懐中電灯ですら金属製だと武器とみなされて軽犯罪法違反で
警察官にしょっ引かれるらしいので、ナイフなんて所持してたら
警察官に何されるかわかったもんじゃないですが。

高木先生の到着が遅れているようですので張ってみます。

> > 悪しき習慣です。CやC++がプログラミングに携わる人のすべての必携の言語
> > として蔓延りかけてしまったことは、世界の情報産業の生産性をいったいど
> > れだけ損失させたか計り知れません。
>
> すべての必携の言語にＣがなり得たのは、それだけ優れた言語だったからでしょう。

いいえ。一部の人が使うのには優れていますが万人が使うべきものではあり
ません。C以外が普及しなかったのは、様々な背景があるのであって、Cが優
れていたからではありません。
[JavaHouse-Brewers:28599] [java-house.jp]

元ストーリーに沿った話だとこんな所が。

> 知りませんでした、それではＣ言語においても、わざわざポインタを駆使した
> プログラムを書く必要はないということですね。

そのとおりです。C言語で
        for (i = 0; i < n; i++) {
                array[i] = ...
        }
というコードを、いまだに、わざわざ
        for (p = &array[0]; p < &array[n]; p++) {
                *p = ...
        }
と書いている人がいるんでしょうかね。だとしたら…誰の責任なんだろう。
[JavaHouse-Brewers:28504 [java-house.jp]

# しかし、もう１０年前の話になるのか。。

オフトピなんですけど、あえてここに。

一応、8086のアクセス空間内にあるということで、コンカレントドライバーを入れた環境下で、裏側のRAMをメッセージ受け渡し領域として使いましたねぇ。
もち、数十バイト程余分が領域は、資源管理に使ったのは、言うまでもありません。

一般的には、グラフィックRAMは、RAMディスクに使われることの方が、多かったみたいですね。＠目的外使用

プログラミングの経験の少ない人は型でなんでも出来ると思いがちなんだけど、例えば
pxA + pxB という式は要注意だが、
(pxA + pxB) / 2 という式は平均を取っているのでたぶん問題なし、
ということを読み取りたいわけ。

ハンガリアンの目的はコードの可読性を高めることにあるので、型とは目的からして違うんだよ。

普通ここまでやらないのはパフォーマンスがどうとか使い勝手がどうとかいう話が絡んでくるからで、アプリケーションハンガリアンなんてもんは所詮妥協の産物ってこった。

おっしゃる通りで、どっちに寄りかかるにせよ、狂信的な原理主義者に現場が振り回されるのだけは勘弁して欲しいものです。

しかしこの辺の議論を読んでいて思ったのですが、最近のトレンドではハンガリアンという代名詞を持ち出すまでもなく、変数や関数に「意味のある名称」をつけること自体、もはや時代遅れとされつつあるのでしょうか? 元々ハンガリアン記法が忌み嫌われていた一番の理由は、処理系の都合に過ぎない (組み込みの) 型という概念の為だけに名前付けが冗長になってしまうことであり、それは名前に対するセマンティクスの重視と、読みやすくメンテナンスしやすいプログラムソースの追求という命題に対する裏返しなのだと思っていたのですが。