見本誌いただきました。いつもありがとうございます。
id:amachang、かくたにさん、高橋さんの連載も始まり、ますますすごいことに。
特集1は構成管理。重要だ。いいところついてきた。(ところで今号の表紙、特集1のフォントはメイリオだ。)何気に面白いと思ったのは特別企画。うーん、エンタープライジー。あと一般記事にマジカ！。こっそりカメラスキープレス。
.NET連載では予告どおりAJAX話です。ポトペタでできるのはやっぱすごいですよ。
次号予告！いよいよIronRubyがベールを脱ぐ!!IronRubyの目的は!?Silverlightにつきぬけろ！→[マタ]
昨日書いた記事について、「サヌールがやらねば俺がやる」的な感じで（うそです。調子乗ってすんまっせん）おおざっぱに訳してみた。
(追記)マーティン・ファウラーの Bliki の日本語訳が更新された。訳文のおかしなところが直ったし、ハイパーリンクも追加されているのでそっちを参照のこと。
（更新：反応リンク集を末尾に追加）
RailsConf2007ではJRubyに大興奮だった。この小さなチームは瀕死のプロジェクトを引き受け、JVM上のRubyプラットフォームの一級実装に見えるように変えた。多くの賞賛を得たのは当然だ。
JRubyについてはまさにそんな感じとして、スポットライトはもう一つの共通マネージコード・ランタイム上に動く。.NETだ。Rubyについてのマイクロソフトの意図は今のところすごく不透明だ。彼らはSilverlightのスクリプティング言語としてRubyを発表した――でも未解決の問題が多く残っている。これってRuby言語をフル実装するのか、それともRuby++みたいなもの――Rubyサブセットの拡張――なのか？
JRubyの目的には、異なっているが相補的なものが2つある。1つはJVM用の強力なスクリプト言語であり、Javaアプリケーションに動的言語を織り込むことができる。2番目の目的はJVM上のRubyプラットホームの実装であり、Rubyアプリケーション、特にRuby on Railsアプリケーションを、MRI(Matz's Ruby Interpreter、現在のC版ランタイム)で動くのと同じようにJVM上で動かすことができる。
マイクロソフトの"Iron Ruby"に対する大きな疑問は、どのくらい互換性をもつことになるか？だ。CLR上にフル実装されるのか？私が受信した電波によれば、John Lam(Iron Rubyの中の人)は完全互換実装にするつもりらしい。でもこれは今の状況だとかなり困難なことかもしれない。もうじきThoughtWorkの中の人になるOla Bini(JRubyのコミッタ)は、MRIのソースコードを見ずにRubyランタイムを実装する方法を知るのはほぼ不可能だと推測している――しかしMicrosoftは、従業員がOSSのソースコードを見るだけでなくダウンロードすることにもおもいっきり制限をかけている。オープンソースコミュニティでは、多くのコミュニケーションがソースコードを通して行われる――このため、オープンソースコミュニティとの共同作業が非常に難しくなっている。
これに暗雲を投げかけているのはもちろん、マイクロソフトとオープンソース界との歴史的な難しい関係だ。過去においては、マイクロソフトはオープンソースコミュニティを中傷し脅す努力をしていた。近年、もろもろは改善されたけれど、マイクロソフトの奥の意図については本当に謎だ。特許による脅しを、マイクロソフトはオープンソースが死ぬまで戦おうとしていることの証明だと見ている人が多い。
他の多くの技術会社とは違い、マイクロソフトはオープンソース界と共存する方法を発見するのに苦労している。マイクロソフトにとっては難しいことなのだ――SunやAppleやIBMとは違い、彼らは圧倒的にソフトウェア会社だから。LinuxやGNUやOpen Officeのようなオープンソースプロジェクトは、マイクロソフトの重要事業ともろに競合する。しかし私は、オープンソースに宣戦布告し、それを根絶しにしようすることが、長期的に現実的な解決案だと感じたことはない。オープンソースは定着している。問題はどのように対応するべきかということだ。
Rubyでは、マイクロソフトの立ち位置は明白なデスマッチとは違う。Rubyはマイクロソフト製品群の中心的な収益発生源とは競合しない。それ以上に、Rubyコミュニティはマイクロソフトと協力したいと本当に願っている。私がRailsConfで話した人たちの大部分は、マイクロソフトがRubyを全面的に支援するのをとても見たがっていた――そして、どうすればそれを実現させるような提案を持ち込むことができるかについての創造的な意見がたくさん出回っていた。コミュニティで聞いた意見は圧倒的に、「Rubyは邪悪なマイクロソフトを倒す」ではなく「どうすれば問題を解決してマイクロソフトのRubyを得ることができるのだろうか」だった。
Chris Sellsが指摘したように、「マイクロソフトは何を狙っているのか」という疑問を考慮しないといけない。理由は２つほど思いつく。１つめは、データセンター内での.NETやWindowsの役割だ。もしマイクロソフトがRubyプラットフォームをサポートしなければ、Ruby on Railsが成功したときにサーバーファームにおいて.NET(およびWindows)から人々が去ってしまうリスクを冒すことになる。
もう１つの理由は人だ。マイクロソフトは公式に認めたくないだろうが、アルファギークがマイクロソフトプラットフォームから去りつつあるというのが本当に懸念されている。マイクロソフトのビジョンは指揮管理組織における死の軍隊だという意見が増えている。優秀なエンタープライズ開発者に可能性を与えるツールや、アジャイル開発プロセスに対するあからさまな支障がたびたび見られる。
数年前、レドモンドの（ちょっとした）つては、技術リーダーたちがWindowsプラットフォームから実際に離れていっているのを見ていると言っていた。最近この兆候は増加しているようだ。私のブログロールの「お人よし部分」を読んで、長い間マイクロソフトのサポーターだった人たちの間に実際に幻滅があるという感じを受けた。アジャイル指向の開発者たちはマイクロソフトツールの方向性に不満を持っている。アジャイルプロセスにはほとんど触れず、ウォーターフォールアプローチにかなり傾いているマイクロソフトのカンファレンス。ツールは、役割の分離が厳密なため、アジャイラーたちが好むぼんやりとした境界を積極的に阻止している。
Tim BrayはRailsConfで、技術についての鍵となる決定はプログラミングコミュニティによってなされると主張した。部分的に同意する。余計で重いソフトがIT界に多すぎる理由は、ITの購買は、ソフトウェア開発の現実との大きな接点をなくした人々によってゴルフコース上で決定されるのが普通だからだ。短期的にはゴルフコースでの決定が支配するかもしれないが、時間が過ぎれば、Timの主張が正しいと思う。だからアルファギークを失っても今年や来年には影響しないかもしれないが、時間とともに容赦なくマイクロソフトに危害をもたらすだろう。
実はマイクロソフトにとってはすでに「来年」が過ぎている。私たちは、マイクロソフトなプロジェクトの顧客、特にアメリカの顧客から、関心が目だって減少していくのを見た。オーストラリアでは、.NETは顧客の地盤をまったく得られなかった。このデータから何を受け取ればいいのかはよく分からない。私たちは統計学的に有効なサンプルになるほど大きくはない。でもそうは言っても、私たちの顧客は「アルファITショップ」だと考えているから、部分的には役に立つデータ点だ。
たぶんもっと重要なのはThoughtWorksの中の話だ。.NETが登場したときは多くの関心が注がれた。たくさんの人がJavaプラットフォームに強力な競争相手が現れたことを歓迎し、.NETのプロジェクトに参画したがった。しかし去年あたりは.NETからの大転換があった。レドモンドから出てくるものには本当に面白いものもあるという事実にもかかわらずだ。Mike TwoはWindows Workflowツールにすごく熱心だし、私はLINQや他の言語進化にとても感心した。でもマイクロソフト技術の全体図にはあくびが出る。これが重要なのは、Tim O'Reillyが信じるように、アルファギークたちは他の人たちが数年間やるであろうことを指し示すからだ。そして決定的な点は、マイクロソフトに対する態度が憎悪（多くのギークで一般的な態度）ではなく退屈であるということだ。これが、Paul Grahamが「マイクロソフトは死んだ、もはや危険ではないから」と言ったことの意味だ。
オープンソースに対する態度こそがこの問題の大部分だ。Javaが現れたとき、そのポートフォリオには大きな隙間があったし、さらに悪いことにはAPIにはひどい標準ツールがあった(Entity Beansのビジョンが思い浮かぶ)。これらの隙間やひどいアイディアはオープンソースコミュニティが修正した。Antがビルドツールを与え、EJBはSpringとHibernateで置き換えられた。.NETにもギャップはあって、再びオープンソースコミュニティがギャップを埋めるために力を注いだ。ところがマイクロソフトはこういう努力に協力することを拒否している。むしろ台無しにしようと努力しているかのようだ。特にうんざりしたのはNUnitに対するマイクロソフトの反応だ――優れたXUnitテストツールであり、その設計要素がOOPSLAでAnders Hejlsbergに称賛されたが、マイクロソフトは競合ライブラリを出荷してきただけでなく、故意に非互換にしてきた。これは、人々がプラットフォームに対して時間をつぎこむことを奨励するような反応ではない。
公平に言えば、この大失敗は2年も前のことだ。Jim HuguninとJohn Lamを雇うといった行動は、あの印象に対抗するのに一役買った。Chris Sells、Don Box、Jim Newkirkといった技術者はマイクロソフトがより開かれた環境になる努力をしている。しかし、大きな組織はどれも同じだが、マイクロソフトは矛盾する勢力であふれており、どれが勝利するのかは私たちには分からない。
同僚のJohn Kordybackは、全ての中心では、Rubyは「もう一つの.NET言語」ではなく、ソフトウェア開発のコミュニティと態度の全てなんだと気づきつつあるんだと指摘した。Rubyとは、オープンソース、アジャイル思考法、軽量ソリューションが価値としてとても深く浸透したコミュニティなのだ。彼が言うには、レドモンドでの共通の疑問は、「『なぜこの考えが重要なのか？』じゃなくて『なぜこの言語が重要なのか？』って聞かれるんだよ」とのことだ。
だから、私がRubyとマイクロソフトに見ているものはチャンスだ。Rubyコミュニティは、マイクロソフトとともに働きたがっているようだ。このことが、レドモンドがオープンソースとともに働くという問題にどう対処するべきか知ることと、将来の協同作業のための模範となる努力のための機会を提供する。完全なRubyプラットフォームの.NETでの一級実装は、この共同作業のすばらしい成果となるだろう。もっといい結果はたぶん、マイクロソフトがオープンとアジャイルを対象にしたコミュニティとどうやって共同作業するかという例をこの作業が示すことだろう――プログラマーと顧客にとってさらに役に立つ姿勢が、マイクロソフト界の中でさらに広がっていくような、そんな跳躍台となりえる例に。
これについてかなりの反応があった(全リストはTechnoratiにある)。特に読むべきなのは次の人たちからの反応だ: Sam Gentile, Cory Foy, Luke Melia, Jeremy Miller, Rockford Lhotka, John Lam, Evan Hoff, Karl Seguin, Ola Bini, Miro Adamy, Charles Nutter, Peter Laudati, Nick Malik
ファウラー氏のblikiに"RubyMicrosoft"という記事が。
Indeed it's already past next year for Microsoft.
とか、
And the crucial point is that the attitude to Microsoft isn't hatred (a common attitude amongst many geeks) but boredom. This is what Paul Graham means when he says that Microsoft is dead because it's no longer dangerous.
あたりは感じるなあ。MS技術話はブログ界の大きな話題にならない。びっくりするほどユートピアだ。つかMSワールド＝ディストピア、ってことか。
The attitude to open-source is a large part of this problem.
うんうん。nUnitもそうだけど、monoに対する態度とか、Ms-LPLとかもそうだし。僕は「待て、あわてるな。これはMSの罠だ」みたいなことは思っていないんだけど、歩み寄るのはどうしてこんなに難しいのか、とは思っている。気を持たせながらつれないそぶり、とか書くと何かちがうな。MSが変わろうとしているのは感じるんだけど。
But like any large organization, Microsoft is full of contradictory forces and we don't know which ones will prevail.
このあたりはMSの欠点でもあるけど強みでもある。手広く投資するし、大々的にアナウンスするけど、儲からないことの予算は大幅カット、みたいな。ビジネスとはそういうものだとも言えるが、そういうところで、ベイパーウェアとかバージョン3からとか突っ込まれる。
So what I see for Ruby and Microsoft is an opportunity.
愛だろ、愛。そこに愛はあるのかい？愛がなーい！
愛とはコミットし続ける覚悟ってことで、MSの覚悟を見たい(そしてまだ見れていない)んだよ。とか言いつつ、MS技術をメシのたねにしているいち開発者ももっとコミットする覚悟がいるなあと思いながら、駄文〆。
まあ、職場つながりの飲み会なのは間違いないんだが、今日は8割が技術に関した話だった。
書ける話、書きにくい話、いろいろあった。僕が書きやすい話を２つほど選んでみると。
煙草ネット＝喫煙室コミュニケーションのこと。ユニシスは全館禁煙になり、煙草を吸う人は屋外の喫煙所に向かう。これが、さらに締め付けが厳しくなるという噂もあったりする。俺は禁煙して煙草フリーな生活なんだけど、煙草ネットのよさは知っている。
「ルートの無限入れ子クイズ」に答えてみる。
ルートが無限に入れ子になっているけど、落ち着いてみれば、無限積だと分かる。だから下の1行目が書けたら、もう解けたようなもの。
2行目の指数のところは、等比数列の和になっている。
……になっているかどうかはわからない。でもまあきっとこういうことなんだろう。
いろいろ追記。
個人的には、前者は手続き型、後者は関数型なイメージ。なぜなら、前者はforループ(等比数列の和ってあたりが特に)、後者は再帰だから。
後者についてはこんなこともぼんやり思った。
「31日間ReSharper一周」の20日目にようこそ。
Alt+Enterについては、エラーを修正する方法を2、3種類話した。でもそれは表面をひっかいただけだ。いろんなものが修正できる――全部とは言わないが、かなりのことはできる。それに対象はエラーだけじゃない。結構な種類の警告(灰色)も修正できる。
だから今日は、もう少し例を挙げよう。網羅的ってわけではないけど。
コード中のReSharper警告(灰色のコードまたは青波線)の上でAlt+Enterを押すと、応急処置の中のひとつに警告を非表示にするものがある。例えば、「『未使用のprivateメンバー』の警告を表示しない」のように。忠告しておくけど、このコマンドはやめておけ。
一度試してみたんだ。「ここだけ特別にOKとする印として、コメントとか#pragmaみたいなものを追加する」って意味だと思ったから。違った。結局「この条件は二度と、決して、金輪際チェックしない」ってことだった。それにアンドゥもできない。もう一度オンにする正しい設定を見つけるには、ReSharper Optionsをくまなく探さないといけない。
幸い、このコマンド自体を停止させることができる(意図しないで選択してしまい、設定解除をしに行くのと同じページにある)。ReSharper Options > Highlightingに移動して、「『警告を表示しない』のアクションを表示する」のチェックを外そう。
コードをVS 2003からVS 2005にアップグレードしようとしていて、ジェネリクスを使い始めているとしよう。そして、ユーティリティメソッドがIListではなくIList<foo>を返すようにリファクタリングする。でもそのせいで、それを呼び出している全ての箇所が壊れた。
これはメソッドの戻り値をIListに割り当てている呼び出し元の一例だ。この例では、「'errors'の型を'IList<Exception>'に変更」を選びたいだろう。それに、他の呼び出し元でも同じ事ができる。同じ戻り値の型を何度も何度もタイピングし直すのを打ち破る。
テンプレートメソッドを取り入れている最中ならば、あるクラスに抽象メソッドがあるけれども、クラス自体をまだabstractでマークしていないということがあるかもしれない。
この例では、abstractキーワードへカーソル移動して、Alt+Enterを押し、「'クラス名'を抽象クラスにする」を選べばいい。もちろん、クラス宣言までスクロールしてそこでabstractと入力するのには大してタイピングはいらない。ただ、この機能のいい所は、今作業しているコードの上に波線が表示されるので、ファイルの上部にスクロールする必要がないということだ。
ReSharperでは、宣言されたけど使われていない変数を修正することができるが、大して面白いことはない。一方通行の変数――読まれるけど書かれない、またはその逆――の方が少しは面白い。ということで下の例が、宣言内で割り当てられたけど一度も読み取られていない変数だ。
「(複数の)割り当て」と書いてあるけど、実際そうする。宣言部にある割り当てだったとしても削除されるし、他のどこにあったとしても割り当ては削除される。一度も読み取られないフィールドがあるなら特に顕著だ。ReSharperはどんなメソッド中のどんな割り当てでも削除する。不要になったコードをちぎり捨てるときにとても重宝する機能だろう。
1点だけ気をつけてほしい。もし割り当てに副作用があったなら、その副作用もなくなってしまうだろう。上の例で言えば、値がリストボックスに追加されなくなってしまう。
これはすごいよ。「(複数の)コンストラクタでフィールドを初期化する」を選ぶだけで完了だ。ReSharperは、新しい引数を自動的にコンストラクタに追加して、割り当てコードを生成する。
変なのは、読み取り／書き込みプロパティを作成する応急処置がないことだ。応急処置で見かけたと思ったんだけど、どう見てもここには無い。
そうなんだ。ReSharperで未使用のパラメータを削除すると、自動的に呼び出し元も全部修正してコードがコンパイルできる状態を維持してくれる。
時には、余計に灰色コードが増えることもある。特に、7層のコード世界を垂直に掘り下げるようなオブジェクトがあったんだけど、リファクタリングしたのでいらなくなってしまったときなんかに。下の層で削除すると、その上の層でパラメータが灰色になってしまう。
でもそんなのはそうそう見ることはないだろう。ReSharperは、privateメソッドの中でパラメータを灰色に変えるだけのようだから。もちろんばかげている。最低でもprivateメソッド内と同程度には、publicメソッド内で使われていないパラメータのことを気にするだろうからね。
エラーや警告を修正するためにAlt+Enterができることの味見ってだけなんだけどね。カラーバーが縞模様になっているなら、F12(次のエラーへ移動)とAlt+Enterを押し続けてみるといい。コードをきれいにするためにReSharperが何をやってくれるのかがよくわかるよ。
「31日間ReSharper一周」の19日目にようこそ。
Visual Studio 2003と2005にはどちらもインターフェースの実装を支援する機能があった。VS2003の機能はかなり気難しかった。VS2005はだいぶよかった。ReSharperはさらによい。見てみよう。
新しいクラスを作成してクラス宣言に: IFoo を追加すると、現在のコードは(インターフェースを満たすメソッドがクラスにないために)コンパイルできないので赤波線が出る。カーソルを波線つきコードに持ってくると赤い電球が表示され、Alt+Enterを押すと「メンバーを実装」という応急処置が表示される。
同じことは、あるクラスが非抽象クラスなのに親クラスが抽象メソッドを持っているときにも起こる。ただこの場合には第2の応急処置がある。「○○クラスの抽象クラス化」だ。一目瞭然だから無視するよ。
注意してほしいのは、子孫クラスがすでにabstractでマークされているなら、未実装の抽象メソッドがあっても赤波線が出ないことだ。エラーではないからだ。だから応急処置は表示されない。ReSharperにはそれらを自動的にオーバーライドする方法もあるが、今のところ木曜日(22日目)にネタにする予定だ。
ウィザードの最初のページではどのメンバーを実装したいかを選ぶ。デフォルトではすべてが選択されている。どれか1つでもチェックをはずすのは馬鹿なことだ。未実装のままのインタフェースメンバーや抽象メンバーが残ってしまい、コードはコンパイルできないままだろうから。
リストの上、右上にあるツールバーボタンに注目して欲しい。こいつらでリスト表示を切り換えられる。ツリー表示ではすべてがインターフェースでグルーピングされる。平らなリスト表示ではアルファベット順にソートされる。この設定は、ウィザードでの表示方法にしか影響しない。 どんな順序に並んでいようがReSharperはメンバーを生成する。
下には3つの選択肢がある。「ドキュメントコメントのコピー」、「明示的なインターフェース実装」、そして「インターフェース実装をリージョンで囲む」だ。これらはどう見ても自明です。本当にありがとうございました。それに僕はこいつらをいまだに使ったことがないから、これ以上取り上げることはない。2ページ目に行こう。
2ページ目はReSharper版の方がVisual Studio版よりずっとすごいところだ。プロパティのどれか、あるいは全部に裏づけフィールドを自動作成できるからだ。(ReSharper Optionsで設定した命名規約に沿った)フィールドを追加し、プロパティのゲッターとセッターでそれを読み書きする。メソッドには、一覧でチェックしなかったプロパティと同様、NotImplementedExceptionを投げる代替コードが置かれる。
一覧の全てのフィールドにチェックを入れるには、Ctrl+Aを押してSpaceを押す。
最後にFinishをクリックすればコードが生成される。
注：2ページ目にある「アルファベット順にソート」のチェックボックスは、1ページ目のツールバーボタンと同じ設定だ。「アルファベット順にソート」にチェックすれば、ソートされた平らなリストで表示されるが、チェックをはずせばツリーで表示される。要はこれは、両方のページのためのただ1つのオプション(一方を変えれば他方も変わる)だ。でも、なんだかよく分からない理由で、2つのページでは異なる表示になっている。
さて、「メンバーを実装」はこんな感じだ。単純だけど役に立つ。唯一足りないと思うオプションは、裏づけフィールドのどれか、あるいは全てに初期値を設定するためのコンストラクタを追加することだ。これを自動化する方法もある(22日目に予定してもいる)けど、ウィザードに追加のページがあったならもっとよかったのに。とはいえ、すべてをいっぺんに実装しながら、裏づけフィールドを作成もするという機能は、かなりすてきだ。
Mono meeting 2007-06-27 Moonlight Specialが気になっている。が、今行っても口ポカーンで聞いてるだけになりそうで気が引けている。
DLRとは言わないまでも(これが一番楽しそうなんだけど)、WPFやXAMLについては仕込んでおかないとダメだなあ。
「31日間ReSharper一周」の18日目にようこそ。
昨日は赤い電球のことと、それを使ってChange Allを実行する方法について話した。今日は、赤い電球のメニューにあるいくつかの応急処置について話そう。前に書いたとおり、赤い電球があるときには、Alt+Enterを押せばメニューがドロップダウン表示される。
未定義の(赤い)シンボルがあれば、ReSharperはシンボルを定義するための選択肢を表示する。どの選択肢が表示されるかは賢く決まる。
これらも全部賢いんだけど、Change Allのように無気味なくらい賢いってわけじゃない。
| 以下を入力して…… | 「局所変数の作成」をすると |
|---|---|
| if (a) | bool a; |
| ArrayList.Adapter(b) | IList b; |
| c.PixelOffsetMode = PixelOffsetMode.Half; | object c; |
「局所変数の作成」が「Change All」と同じくらい賢いなら、上の3行目では単なるプレーンなobjectではなく、Graphics c;が生成されているだろう。(違いの理由はこんなところじゃないかと思う。Change Allでは既存のシンボルのどれが使用法に合致するかを知らなければならない。だから、見ないといけない変数とプロパティはたぶん2～3ダースだ。「局所変数の作成」の場合は出発点がフィルタリングされているという利点がないから、同じことをするには.Net Frameworkの何十万ものクラスをすべて見なければならないし、それはかなり遅い。でももしそうだったならとてもすごかっただろうに。追記: サポートが同意した。機能要請は追加されており、ReSharperの次のバージョンに入ると言ってた！)
ReSharperがAlt+Enterメニューを作成しているとき、シンボルがどう使われているのかは見ていない。でも一度選択肢を選んだ後からは見る。
もしこんな風にシンボルを1箇所で使うだけならば、
ReSharper は、変数をそのものずばりの型で、この場合はBitmapとして宣言するだけだ。(でもカーソルは、一時的なコードテンプレートを伴って、新しく宣言された変数の所にくる。だから、別の型がよければそこに入力できる。)
でも、もしこんな風に基底型を期待する場所でもシンボルを使っているなら(DrawImageは第一引数にBitmapの親である型(Image)を期待する)、
それなら、「局所変数の作成」ではどの型を使いたいかという選択肢が表示され、デフォルトは基底型になる。
プロパティを作成するとき、ReSharperは再び一時的なコードテンプレートを作る。最初は戻り値の型から始まり、受け入れるか変えるかすることができる。そしてTabを入力すると、ゲッター/セッターコードをどのように生成するかの選択肢が表示される。
メソッドを作成するためにAlt+Enterを使うと、一時的なコードテンプレートで戻り値の型、引数の型、引数名が指定できる。大して驚くようなことはない。
でもすごいのは、ReSharperの変数名提案が始まることだ。もし呼び出し元が変数かプロパティを渡しているなら、ReSharperは同じ変数名を引数名のデフォルトに使う。さらに、型名に基づいた通常の提案も行われる。
Tabキーを押して複数の名前が提案された引数に移動すると、補完用ドロップダウンボックスが表示される。もちろん、一覧にない名前を入力することもいつでもできる。
接頭辞(例えば、"first")を入力してからCtrl+Spaceを押して残りの名前を提案させることだってできる。(残念なことに、これは呼び出し元の変数名で補完できず、型名に基づいて提案することしかできない。たとえば、上記のコードでfirstと入力してCtrl+Spaceを押すと、firstIntは提案されるが、firstCountはされない。)
これらのコマンドのどれかを使うと、ReSharperは新しい宣言の中にカーソルを入れ、そして一時的なコードテンプレートを使って型やコードを変更できる。しかし、それが終わったときは、元いたところに戻る方法を分かっていないといけない。
ReSharperには「最後に編集した場所に移動」というコマンドがあって、Ctrl+Shift+Backspaceでアクセスできる。これで出発地点に戻ることができるようだ……少なくとも時々は。最初に押したときは何も動作しないだろうけど、ツイていれば2回目にはかつて赤かったシンボルに戻れるだろう。(でも、その後何か他のものをAlt+Enterで補完して、また戻ろうとすると、期待する動作はしないだろう。)
これらの機能は、ReSharper Optionsにおける「命名規約」ページにちゃんと従うほど賢くはない。フィールドは_から始まるという半標準を指定すれば、すでに_ から始まっているシンボルには局所変数を作成する選択肢は出ないことが期待されるし、さらに、_のないシンボルには「フィールドの作成」オプションは表示されず、フィールドを作成するときに_を加えないことが期待される。ReSharperは、これらのどれもやらない。「フィールドの作成」と「局所変数の作成」はどちらも命名規約設定に全く気づいていない。(僕はこれを機能要求に入れておいた。)
