それって、後から変更した人が、 st がコード内で既に別の意味で使われていることに気付いていなかったってことだよね。
その状況を改善するのに、略語を避けるのは多少有効かもしれないけれど、本質的な解決方法は「保守するコードは書き換える前にちゃんと読む」って以外ないんじゃなかろうか。略語を避けても「こっちの行で status と呼んでいるものとこっちの行で status と呼んでいるものは全然意味が違う」というような同種の現象は起こりうるわけで。
べつに static 等の英単語を st と略すのが良いとは思わないけど、なんか略語が悪の根源みたいに言われると、それは違うんじゃね、と思った。
VIM だと C-n/p で補完が利用できますが、あれは元々 Visual Basic などの IDE (C++ Builder なんかも真似して載せてましたね) などから来ているもので、Visual Studio 系では Ctrl+Space などで意識的に発動させることも可能になってますね。(カスタマイズ可能)
また、今時の IDE ではクラス図、ワークフローデザイナー、フォームデザイナーなどのような GUI 系ベースの機能も少なくありませんし、こちらについてはマウスを使った方が圧倒的に早いと思います。
Visual Studio のエディター固有面で言うと、コード編集中にマウスで右クリックして何かしたい場合、まず基本的にメニューからも操作が可能ですから、マウスで操作するのは慣れが足りないか、そっちの方が早い場合くらいじゃないでしょうか。
さすがに Visual Studio 系を 21 年も使ってないでしょうし、慣れが違いますよね。
開発環境が優秀なので (スコア:5, 興味深い)
30文字ぐらいは全然きになりませんな
変に省略されて意味わからないよりは全然マシ
1行78文字ポリシーを辞めたほうがいいんじゃないですかね
今時固定幅画面でもないでしょうし
Re:開発環境が優秀なので (スコア:5, 興味深い)
名前を省略させないことを優先させて1行78文字ポリシーを捨てたクチです。
しばらくは両立させようとしていましたが、「変数名1->メンバ名 = 変数名2->メソッド（引数1, 引数2);」としただけで78文字を超えたのを見て、78文字ルールは守り切れないと悟りました。
同一関数内でstという省略がstaticとstatisticとstatusの3種類を表している(*)のを見て頭を抱えた経験もあり、ローカル変数なども極力省略は控えるようにしたり、それを布教したりしています。
(*)それぞれ別人が異なる時期にメンテした結果そうなったらしい。
ただ、際限なく長くしても見辛いので、78文字に代わる新たな目安をどうするかに悩んでいます。
今は気分次第で適当に。
巧妙に潜伏したバグは心霊現象と区別が付かない。
Re:開発環境が優秀なので (スコア:3, 興味深い)
自分は最近は 120文字の118文字折り返し(縦は45行)でやっています。
1024x768 なモニタで Teraterm 利用時に 11pt 表示でも 1画面内に収まるというのが理由です。
ノートでのソースの編集は最小限しかしないけど、俯瞰時に折り返しが発生して欲しくないので、
デスクトップよりはノートの現状の制限に合わせています。
Re:開発環境が優秀なので (スコア:2)
それって、後から変更した人が、 st がコード内で既に別の意味で使われていることに気付いていなかったってことだよね。
その状況を改善するのに、略語を避けるのは多少有効かもしれないけれど、本質的な解決方法は「保守するコードは書き換える前にちゃんと読む」って以外ないんじゃなかろうか。略語を避けても「こっちの行で status と呼んでいるものとこっちの行で status と呼んでいるものは全然意味が違う」というような同種の現象は起こりうるわけで。
べつに static 等の英単語を st と略すのが良いとは思わないけど、なんか略語が悪の根源みたいに言われると、それは違うんじゃね、と思った。
Re:開発環境が優秀なので (スコア:1)
> べつに static 等の英単語を st と略すのが良いとは思わないけど、
> なんか略語が悪の根源みたいに言われると、それは違うんじゃね、と思った。
貴方が「良いとは思わない」事からも、略語は悪いと言えるんじゃない？
無論、「悪の根源」じゃないよ。根源は人間でしょ。
貴方の考えによれば「コードを読まずにメンテする人間」。
悪の根源たる「コードを読まずにメンテする人間」が生み出す悪の象徴が略語なんだろ。
変数名の長さと一行の長さは一致するとは限らない (スコア:1)
内部構造と命名規則の不整合の方がもっと大きな問題じゃ無いかな？
ま、stだけじゃ何か分からんってのは同意するが、「なんでここにstが出るんだ？」って異様さがすぐに分かる状況じゃないと、その時点でなんか間違ってる気がする。
正しい変数名に、正しい属性を付ければ、無駄に長くしなくても、混同は結構回避できると思うんだが。
あと、明らかな誤用には必ずコンパイルエラーが出る様に型設定するとかの対策も必要かな？
まあ、妥協は必要だけど、1行78文字ポリシーを原則として、長すぎる場合は「何か間違ってないか？」と考える方が良いかも。
省略して無くても、一行が長いって事は情報量が多いって事で、詰め込め過ぎてる可能性が高いかと。
-- Buy It When You Found It --
Re:開発環境が優秀なので (スコア:5, 参考になる)
EclipseやVisual Studioなんかだと、キャメルケースで補完できますからね。
GetApplicationConfigurationString→SACS
SaveAllChangeSetToDatabase→SACSTD
見たいな感じで。
意外と知らない人もいるみたいですが、タイピングのリズムもいいし、好きな機能です。
Re: (スコア:0)
これは知らなんだ！
大文字で打ったらそうなるんですか？
Re:開発環境が優秀なので (スコア:3, 参考になる)
> 大文字で打ったらそうなるんですか？
Eclipseではキャメルケースマッチングとか言われてる機能です。
単語の区切りの先頭文字から補完してくれます。
[N]→[P]→[E]→[Ctrl]+[Space]
↓
NullPointerException
エディタだけでなく、型検索のダイアログとかでも使えるので便利です。
Visual Studioでは確か2010でEclipseからパクってきてます。
Re:開発環境が優秀なので (スコア:3, 興味深い)
Re:開発環境が優秀なので (スコア:2)
Re: (スコア:0)
>その代わり行数が増えるのを極端に嫌う
どこからそんなことを読み取ったんですか…？
Re: (スコア:0)
それとも1万行くらい普通って環境なのかな？
80カラム制限を疑うほうが先 (スコア:1)
きわめて同感。
APIが出てくるところはそもそも多いとは言えないし、関数名短くするためにどのように省略するかとか規則を決めたりとかのほうがイライラするんじゃないかと思う。
いまどき80カラムである必然性は少ない様に思う。C++とかだとAPI関係なく80なんてきつすぎだと思う。
結局のところ自分が慣れたやり方が一番で、違うものと接すると自己防衛が働いて排斥したくなるってことじゃないのかな。
Re:開発環境が優秀なので (スコア:1)
1行78文字にこだわる理由もないけど、変数名とか識別子が長いのが多量にあると、演算子とか記号の類が埋もれがちで目立たなくなるので好きではない。
シンタックスハイライトとかで、昔よりは長くても分かり易いのだけど、何事も程々がよいかなと思う。
というか、長さは重要度に応じていればいいかなと。
＃とか言いながらさっき面倒くさくて1文字変数多用してきた。サンプルコードだけどサンプルコードなのに。
Re: (スコア:0)
GetApplicationConfigurationString（33文字）位は気にならないです。
これ以上長くなると今度は読むのが苦しくなるのでこの位にしてますが。
Re: (スコア:0)
長さは別として、その関数名は気に入らん
Re: (スコア:0)
viに慣れて21年の身としては，統合開発環境のエディタの編集機能の使いにくさに困っている．
編集中にマウスに手を伸ばすって，作業時間の増大以上にやる気も一緒にそがれるし，
行単位の編集力の弱さ，正規表現を手軽に使えない弱さ，マーク，ヤンク，ペーストの基本機能の弱さ.....
デバッガ，名前の補完機能，引数の型チェックなど，便利で優秀と思える点は多いけど，
ホント，ガラパゴスな進化をさせてしまったＭＳを恨むよ．
Re:開発環境が優秀なので (スコア:2)
統合開発環境というのをほとんど使わないのは同じくなんですが、天下のMS様がショートカットキーを用意していないとは思えないんですが…ないんですかね…
(78文字制限は今時時代遅れだとは思うけど。Xでも80文字幅でわざわざtty開いたりしてないし)
Re:開発環境が優秀なので (スコア:1)
VisualStudioならかなりの部分をカスタマイズできるよ。
emacs風なら結構簡単にできたと思う。
最近使ってないけど、C-x C-fとか2段階はできたはず。
C-x r cみたいなのはどうだったかな。俺は窓使いの憂鬱と組み合わせてやってた様な気がする。
Re:開発環境が優秀なので (スコア:1)
そもそも標準でemacsキーバインドのせっていができます(2008まで)
2010でもキー設定ファイルが開発ブログで配布されていたかと。
eclipseのemacsバインドなんかよりよほどできがいいです。
Re:開発環境が優秀なので (スコア:1)
vi はともかく、カスタマイズできるから、emacs と変らない、という話をたまに聴くのだけれど、カスタマイズの度合いが違うので、個人的にはやはり差は大きい。
単にキーアサインの問題じゃなくて、自分で多少凝った自動化する、といったことが出来ない。「使い込む」といった感覚が、統合環境ではあまり味わえない気がしています。
Re: (スコア:0)
VSマクロの存在を知らない？
Re:開発環境が優秀なので (スコア:1)
VS マクロって、環境の挙動を変更できるほど強力なのでしょうか？
例えばある機能が呼び出されたときにフックするとか、メニューになにかを追加するとか。
MS環境のカスタマイズ（オフトピ） (スコア:0)
ちょっとオフトピ気味なんだけど、
MS-IMEをカスタマイズしてると困ることって、変更が設定ファイルとして出力できないことなんだよね。
せっかく苦労してカスタマイズしたのに、PCを乗り換えたりOS（やアプリ）を再インストールするたびに、
全部設定を一から入れ直しってのは苦痛だった。
＃ひょっとして、最新のMS-IMEだと改善されてたりする？たとえばクラウドに保存して同期できるとか。
＃だとしたら嬉しいんだけど、MSだしあまり期待してない。
VisualStudioだとその辺りはどうなってるんだろう。
Re:MS環境のカスタマイズ（オフトピ） (スコア:2)
VSは知らないですがMS-IMEなら、私はレジストリの設定をコピーして
あちこちの端末で共有してますよ。
HKEY_CURRENT_USER\Software\Microsoft\IMEJP\10.0\ 以下に
設定とか全部入っていたと思います。(10.0の部分はMS-IMEのバージョンによって異なります)
素人厳禁なレジストリの直接操作ですから方法は敢えて書きませんが、ここの住人なら不用ですよね？
Re: (スコア:0)
今も移動プロファイルを利用していればある程度は可能な時もありますが
設定のローミングはSkyDriveを簡単に使えるようになるWindows8からが本番ですかね。
VisualStudioに関しては少なくとも手元の2010、次期VSの11は可能です。
いちいちカスタマイズしてられるかレベルだし？
Re:開発環境が優秀なので (スコア:2)
Re:開発環境が優秀なので (スコア:2)
Vimプラグインで解決です。
私はVimプラグインとHHKのお陰でコーディングが3倍速くなり，プログラミングを楽しんでいます。
# 個人の感想です。 :-p
Re:開発環境が優秀なので (スコア:2)
Re:開発環境が優秀なので (スコア:1)
おいおい……。
ちゃんと使ってたら、Visual Studio編集中にマウスを操作しなきゃならないことなんてありゃしませんがな。
（Xcodeだと、マウスorタッチパッドなしじゃにっちもさっちも行かないことはありますが）
自分がまともに使いこなせていないのを棚に上げて、そりゃないですぜ。
# Visual Studioの問題点は、むしろバージョン違いによる操作方法の差異。
# そういう意味でも、「ガラパゴスな進化（笑）」は的外れ。VS1.0→VS2010には連続性がないから。
Re:開発環境が優秀なので (スコア:1)
マウス操作は不要だけど、ホームポジションから手を離さないとダメだとかじゃね？
たとえばカーソルキーが必用というだけで、面倒だよね。
Re:開発環境が優秀なので (スコア:2)
c% (メソッド呼び出し(対応する括弧まで)を削除して変更) とか dap (メソッド定義(空行で挟まれたブロック)を削除) みたいなごく基本的な操作のために10ストロークも打鍵しなきゃいけないエディタでは、開発なんてやってられないわけですよ！
Re:開発環境が優秀なので (スコア:1)
どっちかというとあなたの方がガラパゴスな進化をしているんじゃないですかね。
開発環境が整備され誰でも簡単に開発者になれる現在ではキーボードに最適化した開発者の方がガラパゴスですね。
Re: (スコア:0)
総体では退化しているということだな。
Re: (スコア:0)
それをいうなら「キーボード無しで開発できるもんならやってみやがれ」と。
＃それから「おまえガラパゴス言いたいだけちゃうんか」。
VisualなんとかってIDEにしても、IDE自体は全然ビジュアルでもなんでもない罠。
Re: (スコア:0)
Visual Studio で vim を外部ツールに登録してキーカスタマイズしたら
ワンストロークで今見ているファイルを vim で開くとかできますよ。
Re: (スコア:0)
そんな、プログラムなんてわき目も振らずに一気に書き上げるもんでもないので、
マウスに手を伸ばしたり、ホームポジションから手を離すのくらいなんとも思わんがな。
Re: (スコア:0)
コーヒー飲みたくて手を伸ばすのは構わないけど、
たかがカーソル移動のために手を伸ばすのとは、
面倒さの度合いが全然違う。
カーソルキーやマウスに手を伸ばすのと同じくらいの頻度でコーヒーを飲む人なら、構わないかも知れないけど。
Re:開発環境が優秀なので (スコア:1)
VIM だと C-n/p で補完が利用できますが、あれは元々 Visual Basic などの IDE (C++ Builder なんかも真似して載せてましたね) などから来ているもので、Visual Studio 系では Ctrl+Space などで意識的に発動させることも可能になってますね。(カスタマイズ可能)
また、今時の IDE ではクラス図、ワークフローデザイナー、フォームデザイナーなどのような GUI 系ベースの機能も少なくありませんし、こちらについてはマウスを使った方が圧倒的に早いと思います。
Visual Studio のエディター固有面で言うと、コード編集中にマウスで右クリックして何かしたい場合、まず基本的にメニューからも操作が可能ですから、マウスで操作するのは慣れが足りないか、そっちの方が早い場合くらいじゃないでしょうか。
さすがに Visual Studio 系を 21 年も使ってないでしょうし、慣れが違いますよね。
検索や置換では単純パターン、正規表現、ワイルドカードの条件などもかなり昔から利用できますが、具体的にはどの辺が弱いと思いますか?
# vi 系自体がガラパゴスだろっていう話はとりあえず置いときます。
Re: (スコア:0, おもしろおかしい)
なんでもガラパゴスって言えばいいってもんじゃないですよ
Re: (スコア:0)
それくらいVimでもできるのでは？
たとえば、CやC++の補完ではclang_completeプラグインが有名なようで、使ってみるとなかなか面白いです。素晴らしい出来と言うにはまだまだですが、Visual StudioなどそこらのIDEにも負けないと思います（というより、C++が補完機能の類に優しくない言語だから、どっちもどっちの出来という感じ）。
Re: (スコア:0)
Re:開発環境が優秀なので (スコア:1)
VisVimは個人的にあまり使い勝手が良くなかったので、
ViEmu http://www.viemu.com/ [viemu.com]
使ってます。有料($99)ですけど。
Re: (スコア:0)
Java屋に長いやつが多い
Re:開発環境が優秀なので (スコア:1)
Javaのコーディング規約に"変数名等の各単語は省略するな"ってのがあった気がする
Re: (スコア:0)
そうそう、Javaは"変数名略すな"な文化だよね(略してわけわからなくなるよりましだかららしい)。
だからMSはそれを取り入れた(ぱくった)だけだよね
Re: (スコア:0)
標準APIが省略しない方式なのでそれにあわせるべきですよね。
誰が作ったかによっていろんな形式が混在してたらコードが読みにくくなりますから。
省略するしないの問題じゃなくて統一性の問題。
Javaなら省略しないのが最も統一できるということになります。
# toStr()とかイヤだ
Re:開発環境が優秀なので (スコア:2)
しかし…何でもかんでもつなげるのは疲れるわけで
public String convertToStringByHogeAndFugaAndFooAndBarAndFizzAndBuzzAndKouAndOtsuAndHei(Object hoge, Object fuga, Object foo, Object bar, Object fizz, Object buzz, Object kou, Object otsu, Object hei)
...
}
みたいなコードに出くわした時には、ほんとどうしようかと思いました…。
せめて標準にそって、引数の名前だけは省略してくれと。
そもそも、引数が多すぎという問題はダイブあるのですが…しかし、それにしても…。
Re: (スコア:0)
横に2つ並べたいから、うちでは80桁だな。
インデント深すぎない限り、80桁で問題ないよ。