アカウント名:
パスワード:
仕事で使ったハードウェアに付いてた、ドライバのソースに、
//どうしよう
って書いてありました。そのどうしようの理由はどこにも書かれてないし。
困り果てた hirata は//まったく同感やね!と付け加えておきましたとさ。
ソースコードにツッコミいれたのは、生まれて初めてやったね……
//同志要
ええ、仲間が欲しくって...
# 赤の他人なので nick
ほぼ同じ状況ですね. しかも驚くべきことにこれが1年半前に完全に新規作成されたソースだってこと. 私は10何年ソフトウェアを扱っていて, 初めて絶望という物を味わいました. 現在せめてもの望みは私がこれにかかわったという一切の痕跡を消し去ることです.
完全新規に書き直した方が今後の累積テスト工数を考えれば良いのは確実なんですが, それ以前に本番開始1年以上たっているのに要求仕様が明文化されていないので何をかいわんやなんですが.
取り敢えず indent してみます。
それで綺麗にならないようなコードは救う労力よりも書き直した方がきっと早いのでステ。
indent が使えない環境では、ちょっと危険ですが cb を使ったりとか。 最近だと astyle [sourceforge.net] なんてのもあるようで。
解析すればいいのだからソースはいらん、 なんて人もいましたが。。。
# ふぅ。しばらく ELF の hack は御免被りたし。
ぼくは Lisp をやらないのですが、 Lisper は、C のソースも Lisp みたいな括弧のレイアウトで書こうとする 誘惑と常に戦っているのでしょうか?
ぼくは、年に数度、ごくたまに Emacs の設定ファイルをいじるとき、括弧のレイアウトを C ライクに書こうとする誘惑に負けてしまいます。
# でも、仕事でプログラムを書く人にとって、汚いソースというのは 切実な問題なんだろうなあ。
もしかして変数が全て大域変数だったりするのでしょうか? 実は15年程前にCOBOLプログラマの書いたコードの変数が全て大域変数で, 関数のパラメータが全く有りませんでした.
実は15年程前にCOBOLプログラマの書いたコードの変数が全て大域変数で, 関数のパラメータが全く有りませんでした.
# そしてこのコードが年始にはカットオーバー。 # さぁ、大丈夫かな？
#ifdef 言い訳 違う、ウチじゃないんだ。 コード書いた会社が逃げただけなんだ...。 #endif
構造化というものが存在しないんです。
私の狭い世間の範囲内において、COBOL プログラマよりは FORTRAN (や、PL/I) プログラマの方が真っ当な C のコードを書く確率が高いんですが。
# 元物理屋なんでそう思うだけかも。 # 量産型 COBOL 屋さんのコードはよう読まん...
いつものくせで、つい7カラムめから書き始めたり、それもインデントはFORTRANの美学に反するからと、全てのステートメントがビシっと7カラムにそろっていたり、小文字の変数名は何か気持ち悪いから、大文字しか使わなかったり、1行を72カラムまでしか使わなかったり、入力設計にも思わず80桁のカードを意識したり…
indent とかスタイルの問題やネーミングについては、読んでれば慣れるのでまだ良いのですが、根本設計に問題がある場合は困りますね。明らかに選択したアルゴリズムの効率が悪いとか、プログラム構造に問題があるとか。
ケースバイケースで書き換えることもあるけど、このときは呪いの言葉を「吐き」ながらです。;-)
かつて、人間が速度優先最適化をかけることができた時代が ありました。人が最適化したソースはたいてい、大学のレポートに 出せば提出点しかつかないようなきちゃないソースになったものです。 社会人に成り立ての頃、ソースの最適化に燃えていたことが あって、ポインタのヌルチェック(0をヌルにしていた)に ; 以下M68Kのアセンブリ言語 move.l a0,d0 ; d0.lに0が代入されるとゼロフラグがたつ bne ?NotNull ?Null: ヌルの処理 ?NotNull: ヌルでないときの処理 と書いて、cmpa.l #0,a0より10クロック減ったといって 喜んでいた恥ずかしい記憶があります。 ええ、オチがありましたとも。そのモジュールではd0の 退避をワード長でしか行っていなくて、外のモジュールがb31~b16が 保存されていることを前提に動いていたものだから…
タブ数はプロジェクトに参加している人が妥協出来る範囲であれば、さっさとコーディング規約にでも入れちゃって、宗教戦争は避けるのが吉です。
ちなみに私は「4tab 原理主義者」なので、私の関ったプロジェクトに関する限り「全員が妥協出来る範囲」は 4tab でしかありえません。(爆)現在はプロジェクトリーダーの立場なので、一応プロジェクトメンバーには 4tab を推奨してます。守らなくてもペナルティーとかはありませんし、やるつもりもありませんが。(^_^;
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
なんでやねん (スコア:5, おもしろおかしい)
仕事で使ったハードウェアに付いてた、ドライバのソースに、
//どうしよう
って書いてありました。そのどうしようの理由はどこにも書かれてないし。
困り果てた hirata は//まったく同感やね!と付け加えておきましたとさ。
ソースコードにツッコミいれたのは、生まれて初めてやったね……
Re:なんでやねん (スコア:1)
ええ、仲間が欲しくって...
# 赤の他人なので nick
Re:なんでやねん (スコア:1)
「/どっとしよう」はちょと違うか
＃ソースの二度付けはいけません(何か違う
本当かい♪本当かい♪
Re:なんでやねん (スコア:1, おもしろおかしい)
n = next;
// 念のため
n = next;
はあ、そうですか…。
Re:なんでやねん (スコア:2, すばらしい洞察)
使ったら済む問題じゃないでしょうか？
参考図書 (スコア:2, 参考になる)
Re:参考図書 (スコア:1)
はてな日記 [hatena.ne.jp]継続ちう
コンパイルしたら‥ (スコア:2, おもしろおかしい)
kero
gaimの中のHACKINGより (スコア:2, 参考になる)
Coding styles are like ***holes,
everyone has one and no one likes anyone elses.
(by warmenhoven)
(コーディングスタイルは＊＊＊の穴みたいなもの、
だれもが一つ持っていて だれも他人のは好きじゃない
――拙訳)
1000! (スコア:2, おもしろおかしい)
￣￣￣￣￣∨￣￣￣ (´´
∧∧ ） (´⌒(´
⊂（゜Д゜⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
￣￣ (´⌒(´⌒;;
ズザーーーーーッ
2000! (スコア:2, おもしろおかしい)
￣￣￣￣￣∨￣￣￣ (´´
∧∧ ） (´⌒(´
⊂（゜Д゜⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
￣￣ (´⌒(´⌒;;
ズザーーーーーッ
吐きます (スコア:1)
共通部品化されてないくどいソースを見ると発狂しそうになります
ちゃぶ台を投げたくなります。
まあ、そんなことは出来ないから、
それらの怒りをやる気に変換して作業します。
Re:吐きます (スコア:1)
Re:吐きます (スコア:1)
吐きそうだが...
Re:吐きます (スコア:1)
仕事だと… (スコア:1)
あんまりサイズが大きくなければ、「書き直したほうが早い！」としちゃうこともあるけど、
何人月かかかりそうなのはそうも行かなくてね…
そういう場合に出来ることは、「吐く」ことぐらいだよなあ…
Re:仕事だと… (スコア:1)
んで、修正する際も、見栄えや構造を優先するのではなく、その場での修正行数や、試験項目の少ない修正を選ばされるから、その調子で１０年もメンテされたソースは大変さぁ…
＃修正履歴もすべてコメントで残すから、もとの倍以上のソースサイズなんてザラだし。
＃書き直した方が早く（速く）ても、書き直したソースにより発生する試験の工数まで考えると無理な場合がほとんど。
お陰で、ソース読解用のマクロや、脳内インデントが洗練されました。
ま、そもそも、自分もそんな綺麗なソース書かないけど。
＃８０×２５文字にどれだけの機能を盛り込むか？とかが得意な人間だったので。
こんな事がありますた (スコア:2, おもしろおかしい)
unsigned char x;
...
if(x0){
...
漏れ「あの、ヘンなコードがあるんですが」
上司「あぁ、動いてるモノだから直さないでね」
漏れ「...( ﾟДﾟ)ﾎﾟｶｰﾝ」
Re:こんな事がありますた (スコア:1)
日曜プログラムにはunsigned char に数を入れて使いますよ。
#つっこみどころ、違いますね。
(unsigned char) < 0
( ﾟДﾟ)ﾆｮｶﾞｰﾝ
#使い方にもよりますが、よく動いてますね。
Re:仕事だと… (スコア:1)
ほぼ同じ状況ですね. しかも驚くべきことにこれが1年半前に完全に新規作成されたソースだってこと. 私は10何年ソフトウェアを扱っていて, 初めて絶望という物を味わいました. 現在せめてもの望みは私がこれにかかわったという一切の痕跡を消し去ることです.
完全新規に書き直した方が今後の累積テスト工数を考えれば良いのは確実なんですが, それ以前に本番開始1年以上たっているのに要求仕様が明文化されていないので何をかいわんやなんですが.
"反省"します (スコア:1)
…最初より読みにくいような気がするのは、あくまで気のせいなのであって…
++ ftsh ++
indent (スコア:1)
取り敢えず indent してみます。
それで綺麗にならないようなコードは救う労力よりも書き直した方がきっと早いのでステ。
indent が使えない環境では、ちょっと危険ですが cb を使ったりとか。 最近だと astyle [sourceforge.net] なんてのもあるようで。
Re:indent (スコア:2, 参考になる)
構文解析してツリー構造にした上でソースを生成するのでやりたい放題(^^;
コメントも構文の一部として定義しているので、無茶な書き方をしてない限り生成後も残るようになってました。
まぁ、しょうがない (スコア:1)
// Give me chocolates!
気にするも何も・・・・ (スコア:1)
『今日の屈辱に耐え明日の為に生きるのが男だ』
宇宙戦艦 ヤマト 艦長 沖田十三氏談
2006/06/23 JPN 1 - 4 BRA
Re:一般的には汚いソースでも… (スコア:1)
>
> c=cosf(thi); s=sinf(thi);
> mtx[0][0]=c; mtx[0][1]=0.0f; mtx[0][2]=-s; mtx[0][3]=0.0f;
> mtx[1][0]=0.0f; mtx[1][1]=1.0f; mtx[1][2]=0.0f; mtx[1][3]=0.0f;
> mtx[2][0]=s; mtx[2][1]=0.0f; mtx[2][2]=c; mtx[2][3]=0.0f;
> mtx[3][0]=0.0f; mtx[3][1]=0.0f; mtx[3][2]=0.0f; mtx[3][3]=1.0f;
>
> …なんて書き方を平気でやりますけど、一般的にはこーゆー書き方はタブーなんですよね。
> でも、こんなの１行１文でなんて書いてられませんがな。
こんなのは、
float mtx[4][4] = {};
c=cosf(thi);
s=sinf(thi);
mtx[0][0] = c;
mtx[0][2] = -s;
mtx[1][1] = 1.0f;
mtx[2][0] = s;
mtx[2][2] = c;
mtx[3][3] = 1.0f;
という感じにすべきなんでは。
初期化でないなら、一行まとめて突っ込む関数を作ったほうがいいような気がするな。
汚かろうとなんだろうと (スコア:1)
あはははははははは・・・ハァ。
Re:解析するからソースはいらん (スコア:1)
# ふぅ。しばらく ELF の hack は御免被りたし。
Lisp みたいな C、C みたいな Lisp (スコア:1)
ぼくは Lisp をやらないのですが、 Lisper は、C のソースも Lisp みたいな括弧のレイアウトで書こうとする 誘惑と常に戦っているのでしょうか?
ぼくは、年に数度、ごくたまに Emacs の設定ファイルをいじるとき、括弧のレイアウトを C ライクに書こうとする誘惑に負けてしまいます。
# でも、仕事でプログラムを書く人にとって、汚いソースというのは 切実な問題なんだろうなあ。
Re:Lisp みたいな C、C みたいな Lisp (スコア:1)
TeXだけどPythonみたいなコード
若しくは
PythonだけどTeXみたいなコード
のどっちかが該当したりするのだろうか...いずれもキツイ気がしますが。
> 汚いソースというのは 切実な問題なんだろうなあ。
汚いといっても、いろいろありますが、shやPerlの$1みたいに数値に意味があるならともかく、命名規則hoge1 hoge2とか後に数字つけられると混乱の元ですね。少しでも意味を匂わせるくらいの名前くらいにして欲しい...tmpでもいいし(w)
私がC書くときは、構造体があってそれをどう料理するか、できるかを書いてワンセットします。外に晒したくない関数はstaticでおさえつけて、いかにもJavaとかPythonのなりそこないみたいになります。
Re:Lisp みたいな C、C みたいな Lisp (スコア:1)
>
>若しくは
>
> PythonだけどTeXみたいなコード
それはひどい…(;_;)
PerlだけどCみたいなコード、は書いたことありますが
上みたいな痛いのは書いたことないですよぅ。
# TeXだけどPythonみたいなコード、は書きたいけど書けない…
Re:Lisp みたいな C、C みたいな Lisp (スコア:1)
>>
>>若しくは
>>
>> PythonだけどTeXみたいなコード
>
>それはひどい…(;_;)
あは、悪い冗談でしたがお気に召さなかったようで(^^;
Pythonはエディタの縛りがないとやりにくいっすよね。
Re:Lisp みたいな C、C みたいな Lisp (スコア:1)
いえいえ :-)
> Pythonはエディタの縛りがないとやりにくいっすよね。
まあ今ごろ言語支援機能のないエディタで開発することもないですし、
読むことに重点を置いているPythonの仕様は個人的に結構好きです。
文法にインデントが含まれてるのが生理的に嫌！ってひとがいるのは知ってますけど…(^^;;;
汚く「も」書ける、と自称している言語で書かれた
どうしようもなく汚いソースを見てると胸がムカムカと…(ひひ
Re:Fotran みたいな C。 (スコア:1)
もしかして変数が全て大域変数だったりするのでしょうか? 実は15年程前にCOBOLプログラマの書いたコードの変数が全て大域変数で, 関数のパラメータが全く有りませんでした.
COBOL みたいな C (Re:Fotran みたいな C。) (スコア:1)
# そしてこのコードが年始にはカットオーバー。
# さぁ、大丈夫かな？
#ifdef 言い訳
違う、ウチじゃないんだ。 コード書いた会社が逃げただけなんだ...。
#endif
Fotran みたいな? COBOL (スコア:1)
未だいるのか、こんなん流派は?
Re:Fotran みたいな C。 (スコア:1)
私の狭い世間の範囲内において、COBOL プログラマよりは FORTRAN (や、PL/I) プログラマの方が真っ当な C のコードを書く確率が高いんですが。
# 元物理屋なんでそう思うだけかも。
# 量産型 COBOL 屋さんのコードはよう読まん...
Re:Fotran みたいな C。 (スコア:1)
いつものくせで、つい7カラムめから書き始めたり、それもインデントはFORTRANの美学に反するからと、全てのステートメントがビシっと7カラムにそろっていたり、小文字の変数名は何か気持ち悪いから、大文字しか使わなかったり、1行を72カラムまでしか使わなかったり、入力設計にも思わず80桁のカードを意識したり…
Re:○○みたいなＣ (スコア:1)
開発MLを煽る (スコア:1)
Re:開発MLを煽る (スコア:2, おもしろおかしい)
とかポストして上げることです(w
なお、初心者は(・∀・) カエレ!!的返信に
初心者扱いしないでください!
と逆切れするとなお吉。
ただしやりすぎると、開発者を怒らせて
開発をとめてしまうというしまうという諸刃の剣。
====危険なのでよい子は真似しないでください====
by rti.
選択肢 (スコア:1)
＃むむむ、寒くなってきたなぁ
本当かい♪本当かい♪
HTMLの場合… (スコア:1)
見なかったこと(気にしない)に(^^; (スコア:1)
仕事で改造しなければならなかったのは
まず大量にバグが出ますね(^^;
今やってるのも比較的綺麗だけどバグが沢山(^^;
その前のもバグが沢山(^^;
人のプログラムを見るのは嫌いです(^^;
困るのはさ (スコア:1)
そういうのに遭遇すると10倍ぐらい領域を増やしたくなるよ。
(´д｀;)
Re:見なかったこと(気にしない)に(^^; (スコア:1)
indent とかスタイルの問題やネーミングについては、読んでれば慣れるのでまだ良いのですが、根本設計に問題がある場合は困りますね。明らかに選択したアルゴリズムの効率が悪いとか、プログラム構造に問題があるとか。
ケースバイケースで書き換えることもあるけど、このときは呪いの言葉を「吐き」ながらです。;-)
の
気にしない (スコア:1)
#自分で書くほうが汚い、というよりもむしろ書けないことのほうが多い……けどID
若気の至り (スコア:1)
かつて、人間が速度優先最適化をかけることができた時代が
ありました。人が最適化したソースはたいてい、大学のレポートに
出せば提出点しかつかないようなきちゃないソースになったものです。
社会人に成り立ての頃、ソースの最適化に燃えていたことが
あって、ポインタのヌルチェック(0をヌルにしていた)に
; 以下M68Kのアセンブリ言語
move.l a0,d0 ; d0.lに0が代入されるとゼロフラグがたつ
bne ?NotNull
?Null:
ヌルの処理
?NotNull:
ヌルでないときの処理
と書いて、cmpa.l #0,a0より10クロック減ったといって
喜んでいた恥ずかしい記憶があります。
ええ、オチがありましたとも。そのモジュールではd0の
退避をワード長でしか行っていなくて、外のモジュールがb31~b16が
保存されていることを前提に動いていたものだから…
Re:Tab (スコア:2)
１列に８０文字とか、その辺の数字でなんとかしようとすると、
インデント幅も縮めたいなーとか思っちゃいます。
Ｊａｖａだと、名前が長くなりがちだし。
とりあえず、全部タブでやっちゃってあとはエディタの設定で
見たいように見るのがよいかと。
#行によってタブとスペースが入り乱れているのは論外
##スコアの +1 ボーナスを使ってみました。
Re:Tab (スコア:2, 参考になる)
タブ数はプロジェクトに参加している人が妥協出来る範囲であれば、さっさとコーディング規約にでも入れちゃって、宗教戦争は避けるのが吉です。
ちなみに私は「4tab 原理主義者」なので、私の関ったプロジェクトに関する限り「全員が妥協出来る範囲」は 4tab でしかありえません。(爆)現在はプロジェクトリーダーの立場なので、一応プロジェクトメンバーには 4tab を推奨してます。守らなくてもペナルティーとかはありませんし、やるつもりもありませんが。(^_^;
vyama 「バグ取れワンワン」