アカウント名:
パスワード:
後からコードを読む人がいるならきれいに書きましょう。
とはいってもソースが長くなるので私は好きではありません
長いのがメンテナンス性や再利用性が悪い傾向があるのは理解しますが、逆にメンテナンス性や再利用性を向上させようとすれば多少は長くなるのは仕方ないと思います。
もちろん、組み込みとかで「短く書かなきゃいけない」ってことがあるのは分かってますが、それは「分かりやすく」「正しい」プログラムが出来た後の最適化のフェーズだと思ってます。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
新しいUI の採用 (スコア:2, おもしろおかしい)
Re:新しいUI の採用 (スコア:2, 参考になる)
しかも、IE7 共々、メニューバーがノイズのように扱われだしている点が気になります。メニューバーって、ツールバーやコンテキストメニューと比べて、ずっと安定しているから、実は地味に電話サポートやメールサポートなどで活躍してるんですよね。
サポートや教育にかかるコストを想像するとオソロシイ..。
Re:新しいUI の採用 (スコア:2, 参考になる)
メニューってのは、（少なくともそのウィンドウの）すべての機
能にアクセスできる唯一の手段で、ツールバーやポップアップメ
ニューは、頻繁に使われる機能へのショートカットでしかないは
ずなんですがね。
一時期、ユーザーサポートに身をおいたことがあるのですが、た
しかにメニューをもとに操作を説明する方が、相手もわかりやす
く感じているようです。ツールバーやポップアップメニューは
非表示になっている場合があるので、そこで面倒くさくなります。
個人的に不思議なのが、ツールボタンのクリックイベントに本処
理を書いて、メニューのクリックイベントはその処理を呼び出す
…というように実装するプログラマがいることです。
まぁ、どのように実装しようとバグさえなければ問題はないんで
すが、そういう方って、無駄にツールボタンを追加していく傾向
があるようです。これもメインメニューが操作の基本という基本
がないためでしょうか。
＃愚痴ってすいません。
Re:新しいUI の採用 (スコア:0)
>メニューのクリックイベントはその処理を呼び出す
>…というように実装する
違うよね。
メニューのクリックイベントに本処理を書くんだよね！
＃さあ、正解を以下に書いてくれ！
Re:新しいUI の採用 (スコア:0)
が正解では。
とはいってもソースが長くなるので私は好きではありませんが。
後からコードを読む人がいるならきれいに書きましょう。
それがデスマーチの短縮につながるのです。
--
void office2007LikeMenuItem_新規作成_Click(Object o,EventArgs e)
{
NewDocument();
}
みたいに。
#学生だけどプログラミングで徹夜経験があるのでID
Re:新しいUI の採用 (スコア:1)
長いのがメンテナンス性や再利用性が悪い傾向があるのは理解しますが、逆にメンテナンス性や再利用性を向上させようとすれば多少は長くなるのは仕方ないと思います。
もちろん、組み込みとかで「短く書かなきゃいけない」ってことがあるのは分かってますが、それは「分かりやすく」「正しい」プログラムが出来た後の最適化のフェーズだと思ってます。
vyama 「バグ取れワンワン」
Re:新しいUI の採用 (スコア:0)
長いソースになると開発中の手間も倍増しますし（スクロールの回数ですら侮れません）、見通しが悪くなります。
なので私は短いソースこそ美しく高度だと思い、また長いソースが嫌いです。
要は「長さ」と「理想的なモデル」の問題は「可読性」と「再利用性」との問題といえます。
同様にして基本的に前サンプルのような関数呼び出しだけの関数はソースを読みにくくします。
しかしながら、イベントハンドラの場合、イベントの種類によって引数の型が異なるため、別のところに本体処理を書くという方法がよいと思うわけです。
最後に、あのサンプルソースはネタです。
マジレスだと思った人はよく見てみましょう。
・OfficeLikeMenuItemは架空のクラスであり私の別の投稿 [srad.jp]に掛かっている。
・「--」の下に書かれている
・<ECODE>を使用していない