アカウント名:
パスワード:
>>世にも悪名高い、コードを修正したらコメントアウトして元のコードを残せというルールだった。
こんな現場でやりました。せっせとコメントに直しているうちに、自分がCVSの動作を手でやっていることに気づきました。
数ヶ月前に入ったメンテのプロジェクトで、手動CVSが嫌になったのでVSSの導入を提案したら却下されました。きっとVSSを知らなかった上司は、自分の10年間が否定されるようで嫌だったのでしょう。
#いやね、デフォルト値のON/OFFを切り替えるのに以前の状態に戻すのは駄目なので、ONにするコード、OFFにするコードが10個くらいコメントアウトされているのを見て、小一時間問い詰め(ry#さらには同じプログラムを弄らない様に声を掛け合うルールが導入されたり。どんだけ非効率がすきなんだよ。
VSSを提案されたら自分でも却下だなぁ。あれ、ライセンスがものすごく高い。svnを提案してみては。
>>いらないとこは後日削除すればいい。
それが徹底されないから問題なんでしょう。
ないんじゃないかな。
コメント削除して、テストとデバッグを一からやり直す工数を考えると、決して安い作業ではない。それにリファクタリングはおろか、テスト工程さえも「コスト削減」の名の下に削られるご時世で、「(ソースコードの)クリーンナップ」なんて『無駄な時間』はそうそう与えられないと思う。
その都度削除しておけば、本来は要らない作業だしね。
「バージョン管理システムにコミットする時は、完璧に仕上げてからコミットしてください」的な意識を持つ管理者と一緒に仕事をしたことがある。
まだまだ開発中のプログラムなのに、インデントが一文字違うだの、この部分がタブとスペースが混在してるだの、ネチネチネチネチネチネチネチネチ。あげくにコミットする前は(常に)全部チェックしてからコミットしろだとか。
どうもバージョン管理システムのことを、完成品を保管するための金庫室か何かと勘違いしているような意識のズレを感じた。
おや?と思って「インデント コミット」で ぐぐってみたけど、「そのプロジェクトのコーディングスタイル規約に合致する程度にはしてからコミットする」ほうが多数派っぽい感じ。
「入力するときのインデントなんてどうでもいいんだ。最後にツールで整形したらいいんだから」 なんて嘯いているプログラマはヘボ。ってのは20世紀(CVSどころかSCCSが現役だった)の常識でしたが、21世紀ではどうなんでしょうねぇ。
内容に関わるコーディング規約はともかく、インデント程度だったら、pre-commit hook でフォーマッタを通せばいいだけでは?
「落胆その1」その二行で済む話のために延々会議「落胆その2」上司「フォーマッタって何。俺が知らないから使用禁止」
>私は「インデントなどスタイルは、出来た(コンパイルが通った)あとで直すものではなく、最初からそう書くもの」と教育された。日本のSIerに?それをまず疑うべし。
それと、こういうものをぐぐる時は英語にしたほうがいいよ。日本のSIer的開発手法は現代の秘境ガラパゴス。いや生きる化石でシーラカンスかな?
>Googleではcommit前レビュー必須だと誰かが書いてたよ。それとこれとは全然話が別でしょ。
いくらGoogleでも、まだリリース予定もたってないver0.5くらいのコードで、アルゴリズムやクラス設計の話もせずに、「スペース一個入ってない」部分をネチネチネチネチ言ったりしないんじゃないかな。
馬鹿な人ほど、本質を見ずに重箱の隅『だけ』をつつくんだよ。
それでもちゃんとしたプログラマーは習慣になってるんでインデントに空白とタブが混在してるなんてことはないと思う。
8tab 2indentな世界だと普通。#8tab 8indentはきついよな。
>「スペース一個入ってない」部分を> ネチネチネチネチ言ったりしないんじゃないかな。Google Coding規約を公式取りしまるツールはあっても整形ツールはない。さすがにEmacsスタイルはあるが。
Googleを辞める理由によると、
「あの官僚主義と「コーディングの規則・規制の神々」の権威主義は熟練開発者を骨抜きにする致命傷だけども、大学出たばかりの青二才にはあれで丁度いいのかもね。」とのことです。
そうそう。タグ付けじゃ納得しないんですよね・・・まあ、こちらが上手く納得のいく説明をできないのも問題なんですけど。
_yyyymmdd等の日付フォルダでも管理したがるひとも多い。一見で分かりやすいのはわかるけど、n日以降の変更分のみを抽出なんて、バージョン管理システムの得意とするところじゃないですかねぇ。
TortoiseSVNは素晴らしいと思いますが、もう少しだけ使い勝手がよくなればいいなぁとは思います。
# ログメッセージからn日~の変更分を抽出しようとした時、リビジョンAとリビジョンBを1行ずつ選択して比較後に選択ファイルのリスト保存で抽出できるけど# ログメッセージで複数行選択したときの、リストから直接エクスポートできると説得しやすいとおもう。# タグもいまいち理解してもらえてないし。一般的なtrunk/branches/tags構成だけど、その上位からチェックアウトしちゃうよ・・・
まだまだ開発中のプログラムなのに、
開発中だからこそ、インデントを揃えることが大事なんじゃないの?
コードでそれをやるのはまだマシです。
私が以前いた職場 (の、とあるプロジェクト) では、プログラムを直接コードを書かずに PAD [geocities.jp] で書いて、そこからコードを自動生成する、ということをやってました。
そして「変更したら必ず変更前の部分をコメントとして残しておく」を PAD についてやらされてたのです。
PAD は、箱状の記号の中に処理内容を書きますが、その処理が逐次実行なのか反復なのか分岐なのかは、箱の形状で区別します。
処理をコメントアウトするには、それらの箱をコメントを表す箱に変更するしかありませんが、当然のことながら、コメントの箱には、それがコメントアウトされる前な
自分だったら、コメントアウトすべき処理をまとめて偽条件の反復ブロックに入れたりしそうです。#1.条件が定数の分岐を最適化する処理系前提#2.しかしそうであっても 上司が理解してくれず「とにかく却下」される可能性あり# (おかしなことしてないで真面目にコメントにしろ、とか)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
手動CVS (スコア:3, おもしろおかしい)
>>世にも悪名高い、コードを修正したらコメントアウトして元のコードを残せというルールだった。
こんな現場でやりました。
せっせとコメントに直しているうちに、自分がCVSの動作を手でやっていることに気づきました。
Re: (スコア:0)
数ヶ月前に入ったメンテのプロジェクトで、手動CVSが嫌になったのでVSSの導入を提案したら却下されました。
きっとVSSを知らなかった上司は、自分の10年間が否定されるようで嫌だったのでしょう。
#いやね、デフォルト値のON/OFFを切り替えるのに以前の状態に戻すのは駄目なので、ONにするコード、OFFにするコードが10個くらいコメントアウトされているのを見て、小一時間問い詰め(ry
#さらには同じプログラムを弄らない様に声を掛け合うルールが導入されたり。どんだけ非効率がすきなんだよ。
Re: (スコア:0)
VSSを提案されたら自分でも却下だなぁ。あれ、ライセンスがものすごく高い。
svnを提案してみては。
Re: (スコア:0)
緊急修正の場合はこちらの方が便利。 いらないとこは後日削除すればいい。
Re:手動CVS (スコア:2, すばらしい洞察)
>>いらないとこは後日削除すればいい。
それが徹底されないから問題なんでしょう。
Re: (スコア:0)
Re:手動CVS (スコア:1)
ないんじゃないかな。
コメント削除して、テストとデバッグを一からやり直す工数を考えると、決して安い作業ではない。
それにリファクタリングはおろか、テスト工程さえも「コスト削減」の名の下に削られるご時世で、
「(ソースコードの)クリーンナップ」なんて『無駄な時間』はそうそう与えられないと思う。
その都度削除しておけば、本来は要らない作業だしね。
金庫室的バージョン管理 (スコア:0)
「バージョン管理システムにコミットする時は、完璧に仕上げてからコミットしてください」
的な意識を持つ管理者と一緒に仕事をしたことがある。
まだまだ開発中のプログラムなのに、
インデントが一文字違うだの、
この部分がタブとスペースが混在してるだの、
ネチネチネチネチネチネチネチネチ。
あげくにコミットする前は(常に)全部チェックしてからコミットしろだとか。
どうもバージョン管理システムのことを、完成品を保管するための
金庫室か何かと勘違いしているような意識のズレを感じた。
Re: (スコア:0)
おや?と思って「インデント コミット」で ぐぐってみたけど、「そのプロジェクトのコーディングスタイル規約に合致する程度にはしてからコミットする」ほうが多数派っぽい感じ。
「入力するときのインデントなんてどうでもいいんだ。最後にツールで整形したらいいんだから」 なんて嘯いているプログラマはヘボ。ってのは20世紀(CVSどころかSCCSが現役だった)の常識でしたが、21世紀ではどうなんでしょうねぇ。
Re:金庫室的バージョン管理 (スコア:1)
内容に関わるコーディング規約はともかく、
インデント程度だったら、pre-commit hook でフォーマッタを通せばいいだけでは?
Re:金庫室的バージョン管理 (スコア:4, おもしろおかしい)
「落胆その1」
その二行で済む話のために延々会議
「落胆その2」
上司「フォーマッタって何。俺が知らないから使用禁止」
Re: (スコア:0)
>私は「インデントなどスタイルは、出来た(コンパイルが通った)あとで直すものではなく、最初からそう書くもの」と教育された。
日本のSIerに?
それをまず疑うべし。
それと、こういうものをぐぐる時は英語にしたほうがいいよ。
日本のSIer的開発手法は現代の秘境ガラパゴス。
いや生きる化石でシーラカンスかな?
Re: (スコア:0)
うるさ過ぎ。そうでないなら・・・
勘違いでもないんじゃない。
Googleではcommit前レビュー必須だと誰かが書いてたよ。
> インデントが一文字違うだの、
> この部分がタブとスペースが混在してるだの、
> ネチネチネチネチネチネチネチネチ。
> あげくにコミットする前は(常に)全部チェックしてからコミットしろだとか。
インデントとタブまで指摘されるのはいい加減な仕事が多くて
信頼されてないんじゃない。あるいは
Re: (スコア:0)
>Googleではcommit前レビュー必須だと誰かが書いてたよ。
それとこれとは全然話が別でしょ。
いくらGoogleでも、まだリリース予定もたってないver0.5くらいのコードで、
アルゴリズムやクラス設計の話もせずに、「スペース一個入ってない」部分を
ネチネチネチネチ言ったりしないんじゃないかな。
馬鹿な人ほど、本質を見ずに重箱の隅『だけ』をつつくんだよ。
Re: (スコア:0)
1) 実質一人でやってるプロジェクト。他の人が見ない、依存しない、引き継がない
2) 一から作り直すの前提のアルゴリズム検証用テストコードで規模が大きくないもの
3) 数十行のやっつけスクリプト
それでもちゃんとしたプログラマーは習慣になってるんでインデントに空白とタブが混在してるなんてことはないと思う。
アルゴリズムやクラス設計はまた次元の違う話なんで置いとくとして、インデント気にしないのは重箱の隅だけど
プログラマーにとって大事な「細かい所にまで目が届く」と言う資質に欠けてないかって不安も感じる。
ただプログラミングはジャンルが幅広いんで自分の世界の常識が他の常識とは違ってるかもしれん。
Re: (スコア:0)
8tab 2indentな世界だと普通。
#8tab 8indentはきついよな。
Re: (スコア:0)
これが一番起き易いのは、きっとネットからのコピペ。
違うかな?
Re: (スコア:0)
>「スペース一個入ってない」部分を
> ネチネチネチネチ言ったりしないんじゃないかな。
Google Coding規約を公式取りしまるツールはあっても整形ツールはない。
さすがにEmacsスタイルはあるが。
Googleを辞める理由によると、
「あの官僚主義と「コーディングの規則・規制の神々」の権威主義は熟練開発者を骨抜きにする致命傷だけども、大学出たばかりの青二才にはあれで丁度いいのかもね。」
とのことです。
Re: (スコア:0)
そうそう。タグ付けじゃ納得しないんですよね・・・
まあ、こちらが上手く納得のいく説明をできないのも問題なんですけど。
_yyyymmdd等の日付フォルダでも管理したがるひとも多い。
一見で分かりやすいのはわかるけど、n日以降の変更分のみを抽出なんて、バージョン管理システムの得意とするところじゃないですかねぇ。
TortoiseSVNは素晴らしいと思いますが、もう少しだけ使い勝手がよくなればいいなぁとは思います。
# ログメッセージからn日~の変更分を抽出しようとした時、リビジョンAとリビジョンBを1行ずつ選択して比較後に選択ファイルのリスト保存で抽出できるけど
# ログメッセージで複数行選択したときの、リストから直接エクスポートできると説得しやすいとおもう。
# タグもいまいち理解してもらえてないし。一般的なtrunk/branches/tags構成だけど、その上位からチェックアウトしちゃうよ・・・
Re: (スコア:0)
開発中だからこそ、インデントを揃えることが大事なんじゃないの?
PADでそれをやった (スコア:0)
コードでそれをやるのはまだマシです。
私が以前いた職場 (の、とあるプロジェクト) では、プログラムを直接コードを書かずに PAD [geocities.jp] で書いて、
そこからコードを自動生成する、ということをやってました。
そして「変更したら必ず変更前の部分をコメントとして残しておく」を PAD についてやらされてたのです。
PAD は、箱状の記号の中に処理内容を書きますが、その処理が逐次実行なのか反復なのか分岐なのかは、
箱の形状で区別します。
処理をコメントアウトするには、それらの箱をコメントを表す箱に変更するしかありませんが、当然の
ことながら、コメントの箱には、それがコメントアウトされる前な
Re:PADでそれをやった (スコア:2)
自分だったら、コメントアウトすべき処理をまとめて偽条件の反復ブロックに入れたりしそうです。
#1.条件が定数の分岐を最適化する処理系前提
#2.しかしそうであっても 上司が理解してくれず「とにかく却下」される可能性あり
# (おかしなことしてないで真面目にコメントにしろ、とか)