アカウント名:
パスワード:
昔のコンパイラには識別子の長さについて制限のやたらきついものがあったので、無理やり短縮した名前にせざるを得なくなって自分でも何が何やらわけのわからない名前になってしまうことがありました。まぁアセンブラのニーモニックだってそのアーキテクチャに精通してない人にはたとえ規則性があったとしてもなんじゃこりゃ~なわけで、まぁあんな感じです。MASMだって識別子は確か31文字くらいに制限されていた時代があったはず。もっと古いアセンブラのラベルなんて8文字に制限されているものもあったり。
というわけで、「無理やり短縮した識別子」は「もうやらなくていい昔のコーディングテクニック」です。
でもバランスが必要だと思います。若い人の関数名は、年寄りから見ると長いというか、冗長な場合が多いですね(関数名にすべてを語らせようとせずにちゃんとコメント書いてね)。簡潔にそれでいて本質をついた命名ができるといいかと思います。そういう気がないと、クソ長い関数名が大量発生する困ったコーディング規則を平気で仕込むリーダになっちゃいますので最初が肝心です。
関数の中身を書く場合には短い関数名でもいいのでしょうが、実際にその関数を使ってロジックを組む場合は冗長な位の関数名の方が組みやすいしメンテやバグ潰しもしやすい。
一つのロジックを見直すときに呼び出す関数自体のソースコードやコメント・ドキュメントを毎度毎度見ないといけないのは、煩雑な分見落としミスの温床になりやすい。どっちかというと関数同士の引数の順序や法則性での統一性の維持に労力を割いた方が余程メンテを考えることになる。
関数内部のドキュメントの充実以前の問題です。ロジックの記述ミスや手順ミスを見つけるデバッグ側の立場からすると短い関数
> 冗長な位の関数名の方が組みやすいしメンテやバグ潰しもしやすい。という話の論拠や具体例が探しづらいような気がします。
> 関数自体のソースコードやコメント・ドキュメントを毎度毎度見ないといけないのは、煩雑使う関数自体が簡単に参照できない場合は確かにそうかもしれません。でもその場合はすでに関数名について選択の余地がない場合では?
> 短い関数名でアレコレやっちゃう人は逆に困るんですが。たしかに限度というものがありますよね。
> ソースコードにアクセスする時の工数増やさないで欲しい。そんなにソースが参照しにくい開発環境って何ですか?とても興味があります。
1例で。SafeHandleZeroOrMinusOneIsInvalidクラス [microsoft.com]abstractクラスなので、継承されることが前提。なのでここまで叙述的なクラス名でも邪魔にならないし、使い方を間違えることもまずないはず。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
わかりやすい(無理やり短縮されていない)識別子 (スコア:3, 参考になる)
昔のコンパイラには識別子の長さについて制限のやたらきついものがあったので、無理やり短縮した名前にせざるを得なくなって自分でも何が何やらわけのわからない名前になってしまうことがありました。まぁアセンブラのニーモニックだってそのアーキテクチャに精通してない人にはたとえ規則性があったとしてもなんじゃこりゃ~なわけで、まぁあんな感じです。MASMだって識別子は確か31文字くらいに制限されていた時代があったはず。もっと古いアセンブラのラベルなんて8文字に制限されているものもあったり。
というわけで、「無理やり短縮した識別子」は「もうやらなくていい昔のコーディングテクニック」です。
屍体メモ [windy.cx]
Re: (スコア:0)
gdgd、wktk
みたいな変数名付ける馬鹿がいまだにいるよね。
Re: (スコア:1)
でもバランスが必要だと思います。
若い人の関数名は、年寄りから見ると長いというか、冗長な場合が多いですね(関数名にすべてを語らせようとせずにちゃんとコメント書いてね)。
簡潔にそれでいて本質をついた命名ができるといいかと思います。
そういう気がないと、クソ長い関数名が大量発生する困ったコーディング規則を平気で仕込むリーダになっちゃいますので最初が肝心です。
冗長でいいのでは?と言うか冗長でないと後工程が困る(Re:わかりやすい (スコア:3, すばらしい洞察)
関数の中身を書く場合には短い関数名でもいいのでしょうが、実際にその関数を使ってロジックを組む場合は冗長な位の関数名の方が組みやすいしメンテやバグ潰しもしやすい。
一つのロジックを見直すときに呼び出す関数自体のソースコードやコメント・ドキュメントを毎度毎度見ないといけないのは、煩雑な分見落としミスの温床になりやすい。
どっちかというと関数同士の引数の順序や法則性での統一性の維持に労力を割いた方が余程メンテを考えることになる。
関数内部のドキュメントの充実以前の問題です。ロジックの記述ミスや手順ミスを見つけるデバッグ側の立場からすると短い関数
Re: (スコア:1)
> 冗長な位の関数名の方が組みやすいしメンテやバグ潰しもしやすい。
という話の論拠や具体例が探しづらいような気がします。
> 関数自体のソースコードやコメント・ドキュメントを毎度毎度見ないといけないのは、煩雑
使う関数自体が簡単に参照できない場合は確かにそうかもしれません。でもその場合はすでに関数名について選択の余地がない場合では?
> 短い関数名でアレコレやっちゃう人は逆に困るんですが。
たしかに限度というものがありますよね。
> ソースコードにアクセスする時の工数増やさないで欲しい。
そんなにソースが参照しにくい開発環境って何ですか?とても興味があります。
Re:冗長でいいのでは?と言うか冗長でないと後工程が困る(Re:わかりやすい (スコア:1)
1例で。SafeHandleZeroOrMinusOneIsInvalidクラス [microsoft.com]
abstractクラスなので、継承されることが前提。なのでここまで叙述的なクラス名でも邪魔にならないし、使い方を間違えることもまずないはず。