アカウント名:
パスワード:
昔のコンパイラには識別子の長さについて制限のやたらきついものがあったので、無理やり短縮した名前にせざるを得なくなって自分でも何が何やらわけのわからない名前になってしまうことがありました。まぁアセンブラのニーモニックだってそのアーキテクチャに精通してない人にはたとえ規則性があったとしてもなんじゃこりゃ~なわけで、まぁあんな感じです。MASMだって識別子は確か31文字くらいに制限されていた時代があったはず。もっと古いアセンブラのラベルなんて8文字に制限されているものもあったり。
というわけで、「無理やり短縮した識別子」は「もうやらなくていい昔のコーディングテクニック」です。
AppleSoft BASICは識別子の最初の二文字までしか有効でなかったので、気づかずに変数を書き換えてデバッグに苦労した思い出が蘇りました。
アセンブラが買えなかった子供の頃にはPeek/Pokeでハンドアセンブルとかやったなー(遠い目)
>昔のコンパイラには識別子の長さについて制限のやたらきついものがあったので、無理やり短縮した名前にせざるを得なくなって
mallocやstrcmpなんかは6文字制限の名残ですかね。
それぞれmemory allocateや string compareとかではなかったかと思われる。
FORTH [rubyist.net]というのも.
コンパイラというか、リンカの制限だね。それもまあFORTRANコンパイラの制限の名残なんだけど。(36ビットワードに1文字6ビットで、6文字までが1ワードに入る)http://srad.jp/comments.pl?sid=282950&cid=820917 [srad.jp]
処理系側の制約がもう無いし、あんまり好ましくないのは理解してるんですが、短縮した識別子のほうが頭に入りやすくて打ちやすいのでつい…。
# おつむのアップデートに失敗しました
ライブラリなどのサンプルの使い方を示す意味のないプログラムに、foo とか bar とか hoge とか、、、今でも相変わらず使うなぁ。
でもバランスが必要だと思います。若い人の関数名は、年寄りから見ると長いというか、冗長な場合が多いですね(関数名にすべてを語らせようとせずにちゃんとコメント書いてね)。簡潔にそれでいて本質をついた命名ができるといいかと思います。そういう気がないと、クソ長い関数名が大量発生する困ったコーディング規則を平気で仕込むリーダになっちゃいますので最初が肝心です。
関数の中身を書く場合には短い関数名でもいいのでしょうが、実際にその関数を使ってロジックを組む場合は冗長な位の関数名の方が組みやすいしメンテやバグ潰しもしやすい。
一つのロジックを見直すときに呼び出す関数自体のソースコードやコメント・ドキュメントを毎度毎度見ないといけないのは、煩雑な分見落としミスの温床になりやすい。どっちかというと関数同士の引数の順序や法則性での統一性の維持に労力を割いた方が余程メンテを考えることになる。
関数内部のドキュメントの充実以前の問題です。ロジックの記述ミスや手順ミスを見つけるデバッグ側の立場からすると短い関数名でアレコレやっちゃう人は逆に困るんですが。
# つまりはメンテやる側がソースコードにアクセスする時の工数増やさないで欲しい。って事。# 呼び出し先の関数については一回コメント読んだら後は関数内部のロジックの妥当性を見る必要が出るまで# 一切見ないで済む位を目標にすべき。# 余計な工数自体がメンテやバグ潰しの時のチョンボを誘発する大要因になる。
関数の命名規則として変な略語や日本語記述とか頭に機能種別をつけたり。というのは一人二人でやって作りきりで後にコード引き継がせる必要がないときにはいいのでしょうが引き継ぎとか考えるとParanoidなハンガリアン規則などでロジック自体の可読性を高める程度がちょうどいい場合も少なくないですよ。
# しかし、そういうプロジェクトに限って関数名16文字以内とか頭にアレコレつけろだつけないだと# と言う所ばかりに拘ったコーディングを要求してくる_| ̄|○汎用機とか十五年前のアセンブラかと_| ̄|○## それよりも引数の統一性と中身の可読性の方が問題だろうと。
> 冗長な位の関数名の方が組みやすいしメンテやバグ潰しもしやすい。という話の論拠や具体例が探しづらいような気がします。
> 関数自体のソースコードやコメント・ドキュメントを毎度毎度見ないといけないのは、煩雑使う関数自体が簡単に参照できない場合は確かにそうかもしれません。でもその場合はすでに関数名について選択の余地がない場合では?
> 短い関数名でアレコレやっちゃう人は逆に困るんですが。たしかに限度というものがありますよね。
> ソースコードにアクセスする時の工数増やさないで欲しい。そんなにソースが参照しにくい開発環境って何ですか?とても興味があります。
コーディングする人が20人以上いるプロジェクトでバグ潰しやっていたときのこと(Linuxカーネルが使われるようなリッチになる前の組み込み家電)。バグ出しの実際の作業をやってる人たちと一緒に動いていましたが、仕様書どおりではない使われ方をしたときのバグというのも考えてランニングテストする訳ですが、現象が出てすぐだとコード書いた側でもわからないバグがそこそこ出るわけです。何でそういうバグが出てしまったのか再現するのも一苦労と言うのが普通にありました。
で、そういう場合はデバッグ用のトラップを組み込んでビルドし直してどこに直接の原因があるか絞り込んで行くのですが(そもそもJTAGとかICEとかつなげられる所でだけデバッグしていたのでもないし)、コンポーネント単位で見た場合に簡略な関数名の組み合わせでコンポーネントを組む人(たち)の程、内部ロジックの直感的な可読性も下がっていく傾向がありましたよ。
つまりは、この手の異常現象を追っかける時にはあるコンポーネントの中では何をやろうとしてるのか?と言うのを迅速に読み取る必要が出てくるのですよ。一行一行逐一読まないと何をやろうとしてるのかわからないコードよりも斜め読みで何をやってるのか、とりあえずのあたりを付けられる方が、原因にたどり着くための絞り込み自体は圧倒的に速くできます。もう少し言うならば、外部監査を見越して設計時の設計書と実際の中身のずれを可視化出来るように組みつづけるのを心がけるというのは簡単なようで非常に難しいという事です。下手に複雑にしたり独りよがりになったりすると、すぐに外の人は読む気なくしますので。そういう所に決まって深刻なバグが仕込まれていたりもする<自戒を込めて
> 関数自体のソースコードやコメント・ドキュメントを毎度毎度見ないといけないのは、煩雑使う関数自体が簡単に参照できない場合は確かにそうかもしれません。でもその場合はすでに関数名について選択の余地がない場合では?昔みたいに関数呼び出しの段数制限が厳しかったりマクロの個数が限定される場合ならまだしも、今時のコーディングだとターゲット機のリソースがよっぽどシビアでない限りは非常に単純な構造のロジックをマトリーショカのように入れ子にして重ね合わせることで大概の物が出来る筈ですよね?ソースコードやコメント・ドキュメントをデバッグの度に毎回見ないといけないというのは内部構造の面でも煩雑窮まりない場合が多い気がしますけど。> ソースコードにアクセスする時の工数増やさないで欲しい。そんなにソースが参照しにくい開発環境って何ですか?とても興味があります。+
昔みたいに関数呼び出しの段数制限が厳しかったりマクロの個数が限定される場合ならまだしも、今時のコーディングだとターゲット機のリソースがよっぽどシビアでない限りは非常に単純な構造のロジックをマトリーショカのように入れ子にして重ね合わせることで大概の物が出来る筈ですよね?ソースコードやコメント・ドキュメントをデバッグの度に毎回見ないといけないというのは内部構造の面でも煩雑窮まりない場合が多い気がしますけど。
> ソースコードにアクセスする時の工数増やさないで欲しい。そんなにソースが参照しにくい開発環境って何ですか?とても興味があります。+
関数の頭の数行を記憶しておけばその関数の概略を覚えられるかどうかというのはデバッグ時の工数に関わってきますよ。特にテスト工程と並行して(第三者が)行うデバッグ工程の場合。ソースコード自体が参照しにくいのではなく、そのソースコードが何をやろうとしているかを参照しにくい作りにされてるコードはメンテナンスやバグ潰しが厳しいよね。と言う話ですが…そういうのは作ってる側個人個人の手癖的な差異というか物のとらえ方の違いを吸収して同じ土俵にのっけてデバッグする場合にもやりやすいかしにくいかの勝負を決めますから。
ご説明ありがとうございます。多分、「冗長」という言葉の捕らえ方が違うんですね。関数の性質を記述することは、それがたとえ叙述的だろうと別に冗長だとは思いません。例えば、・その関数が、どのモジュールに属するかとか・その関数は、どのRevから登場したかとか(開発のコードネームが入ってたり)・その関数のテスト方法は、どこのグループに属するとか・その関数は、どこのチームが書いたとか・その関数の重要度は、どのレベルだとかそういう情報をうだうだと関数名に仕込めという命名規則をつくっちゃう人が実際いるんです。しかも本人はそれが有用だと信じて疑わない。文句言う奴はタイピングが遅いのでブーたれてるだけだ、とか本気で思ってる。で、くそ長い関数名ができて、しかもそれぞれの文節がどういう意味なのかはソースとは関係ない(開発環境も与り知らない)ドキュメントのどこかに書いてあると。関数名は簡潔であるべき、という基本的な考えがあれば、たぶんそんなことにはならないと思うんですけどね。
1例で。SafeHandleZeroOrMinusOneIsInvalidクラス [microsoft.com]abstractクラスなので、継承されることが前提。なのでここまで叙述的なクラス名でも邪魔にならないし、使い方を間違えることもまずないはず。
たぶんそれと関連しますが、私は「識別子にゃ日本語を」と思っています。英語やローマ字に直そうとするとどうにも冗長で長ったらしくなりがちなので。しかも誤訳したりするし。
とくにいわゆる「業務」ソフトだと(国内企業の)業務用語をわざわざ英訳したりするのが地獄です。定訳がある語ならまだいいですがその会社の独自語なんてお手上げです。更には既知のはずの語でもその会社ならではの変な(なぜか世間とは違う)用法が有って、どう訳せばいいのやら。
訳がブレないように対訳表を管理すればいい、という管理主義は面倒なだけです。それならそのままの日本語を使うほうがよほどマシ。
むろんこれには実装言語やDBMSも日本語をきっちりサポートしてくれることが前提となりますが…。
どうせ、iの代わりにindexとかを使うのだろうから、iで十分。
>私が興味があるのはプログラムそのものであって、識別子ではないのです。
そんなあなたには
つ[内部イテレータ]
をお勧めします。ループカウンタ変数なんてなものに煩わされる度合いが激減しますよ。
#いわゆるループカウンタは外部イテレータです。最も原始的ですが。
それはそうと、「プログラムそのもの」ってなんですか?そこに既に存在してしまっている変数を無視していいなら、関数だって無視していいことになる。他の色々なものも無視していいことになる。…すると一体何が残るんでしょうか?
> それはそうと、「プログラムそのもの」ってなんですか?
なんというかその、プログラムそのものとしか言いようのないものです。アルゴリズムとかデータフローとか一切合切。名前は他の名前に変えてしまってもプログラムの実行には影響がありませんので、こういうものは不純物として排除するなり目立たなくするかしたい。
内部イテレータもよいツールですが、究極的にはコンビネータ論理 [e.tir.jp]のようなものをイメージしています。(もちろんこれはやり過ぎです)
何か問題でも?
それ自体に大した意味があるわけではない変数に大仰しい名前を付けると却って可読性が悪くなるような。
「i, j, k といったら整数変数」のような古き良きお約束は、お約束が通じる状況でお約束を守っている分には理解の助けになるので、それ自体は現役のスタイルだと思う。
でも、変数名に意味が無い i とか j とかを文脈無視して使いまわすのは勘弁な!
お約束が通じる状況でお約束を守っている分には
そうそう。ネストされているループの外側がjで、内側がiとかになってなければOKかな。
あと、「もったいないからループ処理のあとでもう1回だけフラグとして使うよ」なんてエコなことをされていなければね。
>「i, j, k といったら整数変数」のような古き良きお約束
同感。なのだけど、グリフ的な問題として、iとjをミスタイプした挙句、ソースを眺めてもなかなか気づかなかった、という経験はしたことありませんか?いい解決案はないですかね。i の次は ii にするとか?
自分は、スコープの長い変数には必ずdescriptiveな名前を与えるというルールで書いています。つまり、ループ変数でもループ自体が十分長ければ i ではなく意味のある名前を与えるということです。スコープが短く、一画面で見通せるくらいの長さならば i でもOKということにしてます。
別の角度からの解決策として、単語を検索したりハイライトしたりするのが得意なエディタ/IDEを使え、ってのもあります。
たとえばvimなら「i」にカーソル合わせて「*」キーを叩けば、「i」が黄色とかにハイライトされます。むろん「j」はされません。「*」で捕捉されるのは単語単位なので「ii」とかもハイライトされません。
ちょくちょく「*」で確認する癖をつけると、変数名取り違えの事故がだいぶ減りました。ていうか殆ど起こさなくなりました。これはかなり劇的な効果があったなあと思っています。
Eclipse(のJava環境)でも、ある単語というか識別子にカーソルを合わせると、同じ識別子が灰色っぽくなりますね。
1. * または # で検索履歴に「\」を拾う。2. / でキーワード検索に入り、Ctrl+P で「\」を呼び出す。3. 後ろの「\>」を消して再検索する。
# ちょっと手順長いですかね?# でも g* ではダメなんですよね?
おっと失敬、化かしてしまいました。
> 1. * または # で検索履歴に「\」を拾う。> 2. / でキーワード検索に入り、Ctrl+P で「\」を呼び出す。
履歴に取り込んで再利用するのは「¥<aVar>¥」です。
ミスタイプは長い名前の方が起きやすいんじゃないか?(コピペonlyの人には関係ない話)
そこまで重要な変数にiとかjと言った名前をつけるのが問題かと。
orz
私かもしれません。すみません。ちなみに、模範解答はどうなりますか?
今は亡き「南町奉行所」というパソコン通信のBBSがありまして・・・その時代からのハンドルです.そういやあのころの人たちは今何やってるんだろうなぁ.スラド民の中にもいるのかも.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
わかりやすい(無理やり短縮されていない)識別子 (スコア:3, 参考になる)
昔のコンパイラには識別子の長さについて制限のやたらきついものがあったので、無理やり短縮した名前にせざるを得なくなって自分でも何が何やらわけのわからない名前になってしまうことがありました。まぁアセンブラのニーモニックだってそのアーキテクチャに精通してない人にはたとえ規則性があったとしてもなんじゃこりゃ~なわけで、まぁあんな感じです。MASMだって識別子は確か31文字くらいに制限されていた時代があったはず。もっと古いアセンブラのラベルなんて8文字に制限されているものもあったり。
というわけで、「無理やり短縮した識別子」は「もうやらなくていい昔のコーディングテクニック」です。
屍体メモ [windy.cx]
Re:わかりやすい(無理やり短縮されていない)識別子 (スコア:2, 興味深い)
AppleSoft BASICは識別子の最初の二文字までしか有効でなかったので、気づかずに変数を書き換えてデバッグに苦労した思い出が蘇りました。
アセンブラが買えなかった子供の頃にはPeek/Pokeでハンドアセンブルとかやったなー(遠い目)
署名スパムがウザい?アカウント作って非表示に設定すればスッキリさ。
Re: (スコア:0)
Re:わかりやすい(無理やり短縮されていない)識別子 (スコア:1, 興味深い)
>昔のコンパイラには識別子の長さについて制限のやたらきついものがあったので、無理やり短縮した名前にせざるを得なくなって
mallocやstrcmpなんかは6文字制限の名残ですかね。
それぞれmemory allocateや string compareとかではなかったかと思われる。
Re:わかりやすい(無理やり短縮されていない)識別子 (スコア:1, おもしろおかしい)
Re:わかりやすい(無理やり短縮されていない)識別子 (スコア:2, 参考になる)
FORTH [rubyist.net]というのも.
Re:わかりやすい(無理やり短縮されていない)識別子 (スコア:1, 参考になる)
コンパイラというか、リンカの制限だね。それもまあFORTRANコンパイラの制限の名残なんだけど。
(36ビットワードに1文字6ビットで、6文字までが1ワードに入る)
http://srad.jp/comments.pl?sid=282950&cid=820917 [srad.jp]
Re:わかりやすい(無理やり短縮されていない)識別子 (スコア:1)
今はメソッド名を見れば分かるので、ほとんどコメントは書かなくなりましたが、今度は名前が長すぎて読むのが面倒という…。
Re:わかりやすい(無理やり短縮されていない)識別子 (スコア:1)
処理系側の制約がもう無いし、あんまり好ましくないのは理解してるんですが、
短縮した識別子のほうが頭に入りやすくて打ちやすいのでつい…。
# おつむのアップデートに失敗しました
Re:わかりやすい(無理やり短縮されていない)識別子 (スコア:1)
ライブラリなどのサンプルの使い方を示す意味のないプログラムに、foo とか bar とか hoge とか、、、今でも相変わらず使うなぁ。
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クラスなので、継承されることが前提。なのでここまで叙述的なクラス名でも邪魔にならないし、使い方を間違えることもまずないはず。
日本人にわかりやすい識別子 (スコア:1, 興味深い)
たぶんそれと関連しますが、私は「識別子にゃ日本語を」と思っています。
英語やローマ字に直そうとするとどうにも冗長で長ったらしくなりがちなので。
しかも誤訳したりするし。
とくにいわゆる「業務」ソフトだと(国内企業の)業務用語をわざわざ英訳したりするのが地獄です。
定訳がある語ならまだいいですがその会社の独自語なんてお手上げです。
更には既知のはずの語でもその会社ならではの変な(なぜか世間とは違う)用法が有って、どう訳せばいいのやら。
訳がブレないように対訳表を管理すればいい、という管理主義は面倒なだけです。
それならそのままの日本語を使うほうがよほどマシ。
むろんこれには実装言語やDBMSも日本語をきっちりサポートしてくれることが前提となりますが…。
Re:わかりやすい(無理やり短縮されていない)識別子 (スコア:1, おもしろおかしい)
変数名は、i,num,hogeとか、
コメントには、//これを消すと動かないからいらないけど消さないこと
とか、もうね・・・
# 親コメと全然関係ない愚痴になってしまった;;
Re: (スコア:0)
Re: (スコア:0)
ループ変数 (スコア:0)
#とか、わざと書いてみる。
Re:ループ変数 (スコア:2, 興味深い)
どうせ、iの代わりにindexとかを使うのだろうから、iで十分。
Re:ループ変数 (スコア:1)
で、FORTRANのI, J, Kも結局は数学由来です。数学者が何を思ってI, J, Kを使うようになったのかは知らないけど。
Re:ループ変数 (スコア:1)
私が興味があるのはプログラムそのものであって、識別子ではないのです。
Re: (スコア:0)
>私が興味があるのはプログラムそのものであって、識別子ではないのです。
そんなあなたには
つ[内部イテレータ]
をお勧めします。
ループカウンタ変数なんてなものに煩わされる度合いが激減しますよ。
#いわゆるループカウンタは外部イテレータです。最も原始的ですが。
それはそうと、「プログラムそのもの」ってなんですか?
そこに既に存在してしまっている変数を無視していいなら、関数だって無視していいことになる。他の色々なものも無視していいことになる。…すると一体何が残るんでしょうか?
Re:ループ変数 (スコア:1)
> それはそうと、「プログラムそのもの」ってなんですか?
なんというかその、プログラムそのものとしか言いようのないものです。アルゴリズムとかデータフローとか一切合切。
名前は他の名前に変えてしまってもプログラムの実行には影響がありませんので、こういうものは不純物として排除するなり目立たなくするかしたい。
内部イテレータもよいツールですが、究極的にはコンビネータ論理 [e.tir.jp]のようなものをイメージしています。
(もちろんこれはやり過ぎです)
Re: (スコア:0)
もたまにいますね。
Re: (スコア:0)
何か問題でも?
Re: (スコア:0)
それ自体に大した意味があるわけではない変数に大仰しい名前を付けると却って可読性が悪くなるような。
「i, j, k といったら整数変数」のような古き良きお約束は、お約束が通じる状況でお約束を守っている分には理解の助けになるので、それ自体は現役のスタイルだと思う。
でも、変数名に意味が無い i とか j とかを文脈無視して使いまわすのは勘弁な!
Re:ループ変数 (スコア:1)
お約束が通じる状況でお約束を守っている分には
そうそう。ネストされているループの外側がjで、内側がiとかになってなければOKかな。
あと、「もったいないからループ処理のあとでもう1回だけフラグとして使うよ」なんてエコなことを
されていなければね。
Re: (スコア:0)
>「i, j, k といったら整数変数」のような古き良きお約束
同感。
なのだけど、グリフ的な問題として、iとjをミスタイプした挙句、ソースを眺めてもなかなか気づかなかった、
という経験はしたことありませんか?
いい解決案はないですかね。i の次は ii にするとか?
Re:ループ変数 (スコア:2)
自分は、スコープの長い変数には必ずdescriptiveな名前を与えるというルールで書いています。つまり、ループ変数でもループ自体が十分長ければ i ではなく意味のある名前を与えるということです。スコープが短く、一画面で見通せるくらいの長さならば i でもOKということにしてます。
Re:ループ変数 (スコア:1, 参考になる)
別の角度からの解決策として、
単語を検索したりハイライトしたりするのが得意なエディタ/IDEを使え、
ってのもあります。
たとえばvimなら「i」にカーソル合わせて「*」キーを叩けば、
「i」が黄色とかにハイライトされます。
むろん「j」はされません。
「*」で捕捉されるのは単語単位なので「ii」とかもハイライトされません。
ちょくちょく「*」で確認する癖をつけると、
変数名取り違えの事故がだいぶ減りました。
ていうか殆ど起こさなくなりました。
これはかなり劇的な効果があったなあと思っています。
Eclipse(のJava環境)でも、ある単語というか識別子にカーソルを合わせると、
同じ識別子が灰色っぽくなりますね。
便乗質問(ループ変数) (スコア:2)
ログ解析の時に便利なんですけど。
Re: (スコア:0)
でもあれ、一画面を超える範囲で使われてる名前のミススペルを探すには使いにくいんですよね。
あと、aVar に対して aVar_variant みたいな名前も柔軟に引っ掛けて欲しいときにちょっと困る。
Re:ループ変数 (スコア:2)
1. * または # で検索履歴に「\」を拾う。
2. / でキーワード検索に入り、Ctrl+P で「\」を呼び出す。
3. 後ろの「\>」を消して再検索する。
# ちょっと手順長いですかね?
# でも g* ではダメなんですよね?
名物に旨いものなし!
Re:ループ変数 (スコア:2)
おっと失敬、化かしてしまいました。
> 1. * または # で検索履歴に「\」を拾う。
> 2. / でキーワード検索に入り、Ctrl+P で「\」を呼び出す。
履歴に取り込んで再利用するのは「¥<aVar>¥」です。
名物に旨いものなし!
Re:ループ変数 (スコア:1)
ミスタイプは長い名前の方が起きやすいんじゃないか?
(コピペonlyの人には関係ない話)
the.ACount
Re: (スコア:0)
Re:ループ変数 (スコア:1)
# ちなみに、私の場合はiteratorでも単順に列挙して順次処理する意味しかない場合はi, j, kを良く使います。
Best regards, でぃーすけ
Re: (スコア:0)
見易さという意味では、長い変数名でなおかつ似たような名前が大量に出てくる状況と件のi,jのようなもののどっちがマシなのやら。
# SoCな組込みCPUのメモリマップドなペリフェラル用レジスタは名前が似ているのが多いから大変だぜい
Re:ループ変数 (スコア:1)
そこまで重要な変数にiとかjと言った名前をつけるのが問題かと。
Re:ループ変数 (スコア:1)
orz
Re:ループ変数 (スコア:1)
何万件もまわすアホみたいな処理のときに…
Re: (スコア:0)
# 公私含め自分だけしか組まないので、わがままOK。
Re: (スコア:0)
Re: (スコア:0)
# 同僚にはバレバレなので AC
Re:ループ変数 (スコア:2)
私かもしれません。すみません。
ちなみに、模範解答はどうなりますか?
パソ通時代からのハンドルで (スコア:1)
今は亡き「南町奉行所」というパソコン通信のBBSがありまして・・・その時代からのハンドルです.
そういやあのころの人たちは今何やってるんだろうなぁ.
スラド民の中にもいるのかも.
屍体メモ [windy.cx]