アカウント名:
パスワード:
昔のコンパイラには識別子の長さについて制限のやたらきついものがあったので、無理やり短縮した名前にせざるを得なくなって自分でも何が何やらわけのわからない名前になってしまうことがありました。まぁアセンブラのニーモニックだってそのアーキテクチャに精通してない人にはたとえ規則性があったとしてもなんじゃこりゃ~なわけで、まぁあんな感じです。MASMだって識別子は確か31文字くらいに制限されていた時代があったはず。もっと古いアセンブラのラベルなんて8文字に制限されているものもあったり。
というわけで、「無理やり短縮した識別子」は「もうやらなくていい昔のコーディングテクニック」です。
でもバランスが必要だと思います。若い人の関数名は、年寄りから見ると長いというか、冗長な場合が多いですね(関数名にすべてを語らせようとせずにちゃんとコメント書いてね)。簡潔にそれでいて本質をついた命名ができるといいかと思います。そういう気がないと、クソ長い関数名が大量発生する困ったコーディング規則を平気で仕込むリーダになっちゃいますので最初が肝心です。
関数の中身を書く場合には短い関数名でもいいのでしょうが、実際にその関数を使ってロジックを組む場合は冗長な位の関数名の方が組みやすいしメンテやバグ潰しもしやすい。
一つのロジックを見直すときに呼び出す関数自体のソースコードやコメント・ドキュメントを毎度毎度見ないといけないのは、煩雑な分見落としミスの温床になりやすい。どっちかというと関数同士の引数の順序や法則性での統一性の維持に労力を割いた方が余程メンテを考えることになる。
関数内部のドキュメントの充実以前の問題です。ロジックの記述ミスや手順ミスを見つけるデバッグ側の立場からすると短い関数名でアレコレやっちゃう人は逆に困るんですが。
# つまりはメンテやる側がソースコードにアクセスする時の工数増やさないで欲しい。って事。# 呼び出し先の関数については一回コメント読んだら後は関数内部のロジックの妥当性を見る必要が出るまで# 一切見ないで済む位を目標にすべき。# 余計な工数自体がメンテやバグ潰しの時のチョンボを誘発する大要因になる。
関数の命名規則として変な略語や日本語記述とか頭に機能種別をつけたり。というのは一人二人でやって作りきりで後にコード引き継がせる必要がないときにはいいのでしょうが引き継ぎとか考えるとParanoidなハンガリアン規則などでロジック自体の可読性を高める程度がちょうどいい場合も少なくないですよ。
# しかし、そういうプロジェクトに限って関数名16文字以内とか頭にアレコレつけろだつけないだと# と言う所ばかりに拘ったコーディングを要求してくる_| ̄|○汎用機とか十五年前のアセンブラかと_| ̄|○## それよりも引数の統一性と中身の可読性の方が問題だろうと。
> 冗長な位の関数名の方が組みやすいしメンテやバグ潰しもしやすい。という話の論拠や具体例が探しづらいような気がします。
> 関数自体のソースコードやコメント・ドキュメントを毎度毎度見ないといけないのは、煩雑使う関数自体が簡単に参照できない場合は確かにそうかもしれません。でもその場合はすでに関数名について選択の余地がない場合では?
> 短い関数名でアレコレやっちゃう人は逆に困るんですが。たしかに限度というものがありますよね。
> ソースコードにアクセスする時の工数増やさないで欲しい。そんなにソースが参照しにくい開発環境って何ですか?とても興味があります。
コーディングする人が20人以上いるプロジェクトでバグ潰しやっていたときのこと(Linuxカーネルが使われるようなリッチになる前の組み込み家電)。バグ出しの実際の作業をやってる人たちと一緒に動いていましたが、仕様書どおりではない使われ方をしたときのバグというのも考えてランニングテストする訳ですが、現象が出てすぐだとコード書いた側でもわからないバグがそこそこ出るわけです。何でそういうバグが出てしまったのか再現するのも一苦労と言うのが普通にありました。
で、そういう場合はデバッグ用のトラップを組み込んでビルドし直してどこに直接の原因があるか絞り込んで行くのですが(そもそもJTAGとかICEとかつなげられる所でだけデバッグしていたのでもないし)、コンポーネント単位で見た場合に簡略な関数名の組み合わせでコンポーネントを組む人(たち)の程、内部ロジックの直感的な可読性も下がっていく傾向がありましたよ。
つまりは、この手の異常現象を追っかける時にはあるコンポーネントの中では何をやろうとしてるのか?と言うのを迅速に読み取る必要が出てくるのですよ。一行一行逐一読まないと何をやろうとしてるのかわからないコードよりも斜め読みで何をやってるのか、とりあえずのあたりを付けられる方が、原因にたどり着くための絞り込み自体は圧倒的に速くできます。もう少し言うならば、外部監査を見越して設計時の設計書と実際の中身のずれを可視化出来るように組みつづけるのを心がけるというのは簡単なようで非常に難しいという事です。下手に複雑にしたり独りよがりになったりすると、すぐに外の人は読む気なくしますので。そういう所に決まって深刻なバグが仕込まれていたりもする<自戒を込めて
> 関数自体のソースコードやコメント・ドキュメントを毎度毎度見ないといけないのは、煩雑使う関数自体が簡単に参照できない場合は確かにそうかもしれません。でもその場合はすでに関数名について選択の余地がない場合では?昔みたいに関数呼び出しの段数制限が厳しかったりマクロの個数が限定される場合ならまだしも、今時のコーディングだとターゲット機のリソースがよっぽどシビアでない限りは非常に単純な構造のロジックをマトリーショカのように入れ子にして重ね合わせることで大概の物が出来る筈ですよね?ソースコードやコメント・ドキュメントをデバッグの度に毎回見ないといけないというのは内部構造の面でも煩雑窮まりない場合が多い気がしますけど。> ソースコードにアクセスする時の工数増やさないで欲しい。そんなにソースが参照しにくい開発環境って何ですか?とても興味があります。+
昔みたいに関数呼び出しの段数制限が厳しかったりマクロの個数が限定される場合ならまだしも、今時のコーディングだとターゲット機のリソースがよっぽどシビアでない限りは非常に単純な構造のロジックをマトリーショカのように入れ子にして重ね合わせることで大概の物が出来る筈ですよね?ソースコードやコメント・ドキュメントをデバッグの度に毎回見ないといけないというのは内部構造の面でも煩雑窮まりない場合が多い気がしますけど。
> ソースコードにアクセスする時の工数増やさないで欲しい。そんなにソースが参照しにくい開発環境って何ですか?とても興味があります。+
関数の頭の数行を記憶しておけばその関数の概略を覚えられるかどうかというのはデバッグ時の工数に関わってきますよ。特にテスト工程と並行して(第三者が)行うデバッグ工程の場合。ソースコード自体が参照しにくいのではなく、そのソースコードが何をやろうとしているかを参照しにくい作りにされてるコードはメンテナンスやバグ潰しが厳しいよね。と言う話ですが…そういうのは作ってる側個人個人の手癖的な差異というか物のとらえ方の違いを吸収して同じ土俵にのっけてデバッグする場合にもやりやすいかしにくいかの勝負を決めますから。
ご説明ありがとうございます。多分、「冗長」という言葉の捕らえ方が違うんですね。関数の性質を記述することは、それがたとえ叙述的だろうと別に冗長だとは思いません。例えば、・その関数が、どのモジュールに属するかとか・その関数は、どのRevから登場したかとか(開発のコードネームが入ってたり)・その関数のテスト方法は、どこのグループに属するとか・その関数は、どこのチームが書いたとか・その関数の重要度は、どのレベルだとかそういう情報をうだうだと関数名に仕込めという命名規則をつくっちゃう人が実際いるんです。しかも本人はそれが有用だと信じて疑わない。文句言う奴はタイピングが遅いのでブーたれてるだけだ、とか本気で思ってる。で、くそ長い関数名ができて、しかもそれぞれの文節がどういう意味なのかはソースとは関係ない(開発環境も与り知らない)ドキュメントのどこかに書いてあると。関数名は簡潔であるべき、という基本的な考えがあれば、たぶんそんなことにはならないと思うんですけどね。
1例で。SafeHandleZeroOrMinusOneIsInvalidクラス [microsoft.com]abstractクラスなので、継承されることが前提。なのでここまで叙述的なクラス名でも邪魔にならないし、使い方を間違えることもまずないはず。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
わかりやすい(無理やり短縮されていない)識別子 (スコア:3, 参考になる)
昔のコンパイラには識別子の長さについて制限のやたらきついものがあったので、無理やり短縮した名前にせざるを得なくなって自分でも何が何やらわけのわからない名前になってしまうことがありました。まぁアセンブラのニーモニックだってそのアーキテクチャに精通してない人にはたとえ規則性があったとしてもなんじゃこりゃ~なわけで、まぁあんな感じです。MASMだって識別子は確か31文字くらいに制限されていた時代があったはず。もっと古いアセンブラのラベルなんて8文字に制限されているものもあったり。
というわけで、「無理やり短縮した識別子」は「もうやらなくていい昔のコーディングテクニック」です。
屍体メモ [windy.cx]
Re: (スコア:0)
gdgd、wktk
みたいな変数名付ける馬鹿がいまだにいるよね。
Re: (スコア:1)
でもバランスが必要だと思います。
若い人の関数名は、年寄りから見ると長いというか、冗長な場合が多いですね(関数名にすべてを語らせようとせずにちゃんとコメント書いてね)。
簡潔にそれでいて本質をついた命名ができるといいかと思います。
そういう気がないと、クソ長い関数名が大量発生する困ったコーディング規則を平気で仕込むリーダになっちゃいますので最初が肝心です。
冗長でいいのでは?と言うか冗長でないと後工程が困る(Re:わかりやすい (スコア:3, すばらしい洞察)
関数の中身を書く場合には短い関数名でもいいのでしょうが、実際にその関数を使ってロジックを組む場合は冗長な位の関数名の方が組みやすいしメンテやバグ潰しもしやすい。
一つのロジックを見直すときに呼び出す関数自体のソースコードやコメント・ドキュメントを毎度毎度見ないといけないのは、煩雑な分見落としミスの温床になりやすい。
どっちかというと関数同士の引数の順序や法則性での統一性の維持に労力を割いた方が余程メンテを考えることになる。
関数内部のドキュメントの充実以前の問題です。ロジックの記述ミスや手順ミスを見つけるデバッグ側の立場からすると短い関数名でアレコレやっちゃう人は逆に困るんですが。
# つまりはメンテやる側がソースコードにアクセスする時の工数増やさないで欲しい。って事。
# 呼び出し先の関数については一回コメント読んだら後は関数内部のロジックの妥当性を見る必要が出るまで
# 一切見ないで済む位を目標にすべき。
# 余計な工数自体がメンテやバグ潰しの時のチョンボを誘発する大要因になる。
関数の命名規則として変な略語や日本語記述とか頭に機能種別をつけたり。というのは一人二人でやって作りきりで後にコード引き継がせる必要がないときにはいいのでしょうが引き継ぎとか考えるとParanoidなハンガリアン規則などでロジック自体の可読性を高める程度がちょうどいい場合も少なくないですよ。
# しかし、そういうプロジェクトに限って関数名16文字以内とか頭にアレコレつけろだつけないだと
# と言う所ばかりに拘ったコーディングを要求してくる_| ̄|○汎用機とか十五年前のアセンブラかと_| ̄|○
## それよりも引数の統一性と中身の可読性の方が問題だろうと。
Re:冗長でいいのでは?と言うか冗長でないと後工程が困る(Re:わかりやすい (スコア:1)
> 冗長な位の関数名の方が組みやすいしメンテやバグ潰しもしやすい。
という話の論拠や具体例が探しづらいような気がします。
> 関数自体のソースコードやコメント・ドキュメントを毎度毎度見ないといけないのは、煩雑
使う関数自体が簡単に参照できない場合は確かにそうかもしれません。でもその場合はすでに関数名について選択の余地がない場合では?
> 短い関数名でアレコレやっちゃう人は逆に困るんですが。
たしかに限度というものがありますよね。
> ソースコードにアクセスする時の工数増やさないで欲しい。
そんなにソースが参照しにくい開発環境って何ですか?とても興味があります。
Re:冗長でいいのでは?と言うか冗長でないと後工程が困る(Re:わかりやすい (スコア:1)
コーディングする人が20人以上いるプロジェクトでバグ潰しやっていたときのこと(Linuxカーネルが使われるようなリッチになる前の組み込み家電)。
バグ出しの実際の作業をやってる人たちと一緒に動いていましたが、仕様書どおりではない使われ方をしたときのバグというのも考えてランニングテストする訳ですが、現象が出てすぐだとコード書いた側でもわからないバグがそこそこ出るわけです。何でそういうバグが出てしまったのか再現するのも一苦労と言うのが普通にありました。
で、そういう場合はデバッグ用のトラップを組み込んでビルドし直してどこに直接の原因があるか絞り込んで行くのですが(そもそもJTAGとかICEとかつなげられる所でだけデバッグしていたのでもないし)、コンポーネント単位で見た場合に簡略な関数名の組み合わせでコンポーネントを組む人(たち)の程、内部ロジックの直感的な可読性も下がっていく傾向がありましたよ。
つまりは、この手の異常現象を追っかける時にはあるコンポーネントの中では何をやろうとしてるのか?と言うのを迅速に読み取る必要が出てくるのですよ。一行一行逐一読まないと何をやろうとしてるのかわからないコードよりも斜め読みで何をやってるのか、とりあえずのあたりを付けられる方が、原因にたどり着くための絞り込み自体は圧倒的に速くできます。
もう少し言うならば、外部監査を見越して設計時の設計書と実際の中身のずれを可視化出来るように組みつづけるのを心がけるというのは簡単なようで非常に難しいという事です。
下手に複雑にしたり独りよがりになったりすると、すぐに外の人は読む気なくしますので。そういう所に決まって深刻なバグが仕込まれていたりもする<自戒を込めて
関数の頭の数行を記憶しておけばその関数の概略を覚えられるかどうかというのはデバッグ時の工数に関わってきますよ。特にテスト工程と並行して(第三者が)行うデバッグ工程の場合。
ソースコード自体が参照しにくいのではなく、そのソースコードが何をやろうとしているかを参照しにくい作りにされてるコードはメンテナンスやバグ潰しが厳しいよね。と言う話ですが…そういうのは作ってる側個人個人の手癖的な差異というか物のとらえ方の違いを吸収して同じ土俵にのっけてデバッグする場合にもやりやすいかしにくいかの勝負を決めますから。
Re:冗長でいいのでは?と言うか冗長でないと後工程が困る(Re:わかりやすい (スコア:1)
ご説明ありがとうございます。
多分、「冗長」という言葉の捕らえ方が違うんですね。関数の性質を記述することは、それがたとえ叙述的だろうと別に冗長だとは思いません。
例えば、
・その関数が、どのモジュールに属するかとか
・その関数は、どのRevから登場したかとか(開発のコードネームが入ってたり)
・その関数のテスト方法は、どこのグループに属するとか
・その関数は、どこのチームが書いたとか
・その関数の重要度は、どのレベルだとか
そういう情報をうだうだと関数名に仕込めという命名規則をつくっちゃう人が実際いるんです。しかも本人はそれが有用だと信じて疑わない。文句言う奴はタイピングが遅いのでブーたれてるだけだ、とか本気で思ってる。
で、くそ長い関数名ができて、しかもそれぞれの文節がどういう意味なのかはソースとは関係ない(開発環境も与り知らない)ドキュメントのどこかに書いてあると。
関数名は簡潔であるべき、という基本的な考えがあれば、たぶんそんなことにはならないと思うんですけどね。
Re:冗長でいいのでは?と言うか冗長でないと後工程が困る(Re:わかりやすい (スコア:1)
1例で。SafeHandleZeroOrMinusOneIsInvalidクラス [microsoft.com]
abstractクラスなので、継承されることが前提。なのでここまで叙述的なクラス名でも邪魔にならないし、使い方を間違えることもまずないはず。