「変数」を含む日記 RSS

はてなキーワード: 変数とは

2017-04-25

http://anond.hatelabo.jp/20170425115251

おれは俺もそう思う。

変数の中に何入れても成り立つからこそ言ってるのにって。

2017-04-24

隣の席の人が怖い

新しいプロジェクトで隣の席になった人の独り言が怖い。

プログラミングブツブツ言うのは全く気にならないんだけど、時折「死ねよこのコード書いたやつ」とか言い出す。

挙句には変数名をfuckにしたり引数にfuckを渡したりコマンドラインにfuckって書いたりしている。

変数のfuckは気付いたら普通になってるけどこんなにイライラしながら仕事してハゲないんだろうか?

2017-04-22

http://anond.hatelabo.jp/20170421230333

基本英語(つーか半角英数)のプログラムの中で

変数名とか関数名とかを全角の日本語統一すると、

全角文字アイキャッチになって、可読性が上がって良さそう。

漢字カナ交じりの日本語ってすごく速読に向いてるよね。

英語の本を流し読みしたいときに、すごくそう思う。

変態言語として、全角で書くと変数名として解釈されるとか、

そういう仕様言語があってもいいと思う。

http://anond.hatelabo.jp/20170421230333

増田変数名・関数名・カラム名について語り合いたいし、語り合っているので

ひまわりなど日本語で書けるプログラム言語はある」とドヤってるブクマカ勢は反省して

http://anond.hatelabo.jp/20170421230333

今、仕事をしてるシステムは、DBテーブルカラム漢字になっていてすごくわかりやすい。

SQLとか、

SELECT 
  商品名, 
  商品略称, 
  仕入値, 
  売価 
FROM 
  商品マスタ 
WHERE 
  仕入日 >= '2017-04-01' 

みたいな感じ。

DBからとってきた値をいれる変数も同じように日本語にしたらめちゃくちゃよくなりそうだけど、残念ながら既存ソースがそうなってないから俺もソースのほうはローマ字で書いてる。

http://anond.hatelabo.jp/20170421230333

判る。俺もたまに、日本語でいいんじゃね、って思うよ。

日本語にしたいのは、業務固有の用語だね。各人がバラバラに英訳されて、何だこれ?ってならなくて済むからね。

対応表を作りゃいいのかも知れないけど、作ったり参照したりメンテする手間を考えるとさぁ。

で、俺も考えるだけで実際には日本語変数名なんて使わないんだが、使わない理由は、みんなやってないから、だね。

誰かが勇気を持って踏み出してくれりゃいいのに。

テストコード日本語使ってる実感だと…

テストコードシナリオ名とか振る舞い名は日本語で書いてる。

プログラム部分とテスト部分がはっきり区別できるし、テストコードがそのまま要件定義になって便利。

ただ、他の変数とかメソッド名は、英語の方が良さげな気がする。

日本語で書いたテストコードを読んでる実感からすると、文章的に読むのはいいけど、構造把握するのにはめんどくさそうな印象。


http://anond.hatelabo.jp/20170421230333

C++/Perl/Rubyゴミ

分かったのは言語の多機能さというのは、一点水準さえ満たしていれば、それ以上足しても生産性寄与しないという事

自分しか使わない、最初書くときに限れば書きやすいと思うこともあるが、それ以上に保守性を落とす

ライブラリを利用したり他人コードを読む機会の方が多い昨今マイナス要素でしかない

perlスローガンだかに "There's More Than One Way To Do It." というのがあるらしいが、読む側からするとたまったもんじゃない

演算子オーバーロードされてるかも?モンキーパッチされてないかな?等々あれこれ想定しなきゃいけないのが苦痛しかない

スラムダンク流川が沢北を抜いたのも

パス選択肢を見せた事で沢北が集中できなくなってしまたか

それほど選択肢が多いということはストレスになる

Rubyゴミ

DSL(笑)が良いと思ってるのは最初だけで、最終的に負債しかならない糞コード

統計機械学習系のライブラリが皆無で先細りのイメージしかいかRailsと一緒に心中ください

Perlゴミ

リスト評価スカラー評価とか意味わかんねーくくりもtie変数アイディアは糞中の糞

Perl6にいたってはわけわかんねー演算子オンパレードで悪いところをさらに悪くした感じ

C++ゴミ

テンプレートマクロboostも何もかもダメ意味不明

オーバーロードされまくりコードなんてどっから読んでいいかわかんねーよ

こんな意味不明なことを覚えていられるほど人生長くない

結局PythonとかGo言語現実的な解で黒魔術のある言語なんて意味ない要らない使わない

2017-04-21

プログラム日本語で書けばいい気がするけど(追記した)

定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。

実践はしていない)

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

日本語でいいと思う理由は主に2つ

○画面に表示する時

フレームワーク言語にもよるけど表示するとき英語名前から日本語名前に変換して表示って手間があるものがある。

最近見かけた例だと.NETプロパティ属性に表示名書いて表示するときに取り出していた。

最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける

英語がわけわからん

まず自分英語化するとき

いい単語が出てこないとか、しょっちゅう

慣れが必要だし慣れてもなんかコレジャナイ感とかで苦戦する。

次に他の人の英語化したのを見る時。

その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもchildsみたいな謎の語があったり。

そこそこできる人同士でも、「私はニュアンス的にこっちの単語」「僕はこの単語のほうがいいと思う」とかある。

相手の書いたところがわかりづらいのはもちろんだけど、プログラム的に同じ意味なのにクラス関数によって呼び方違うと辛い。

かといって全員に日本語英語対応を先に渡しておいて統一しようというのは大変すぎる。

日本語だと仕様の時点で日本語で書いてるからまぁおかしなことにはそうならないはず)

そういうわけで日本語で書けば色々解決するのにって思う。

----

次にデメリット

軽く調べた感じ主にこの2つな感じ。

IME」「英語圏のものへの対応

IME

半角全角を打つのってめんどい

と思うけど、実際チャットやこういう文章書いてて英語が出るときに割りと頻繁に押してる。

ほぼ無意識でやってて意外と苦じゃない。

短いとF10変換で半角にすることもあるけど、キーボードタイプカウンタとか入れてみると半角全角キーはけっこう上位にいた。


それに、なんだかんだコメント日本語で書くことが多くて、他の人と作るのならこまめにコメント書いてる。

そうなると全角半角の切り替えは普段からあるもので、あんまり気にするほどじゃない気がした。

最近じゃIDEエディタの補完が優秀だし、日本語にするにしても「最初はjから始める」とかルール入れておけば「j」って打ってあとはスコープにあるいくつかの候補から選ぶだけで全角にしなくていいかもしれない。


英語圏への対応

githubで公開したりとかライブラリ再利用してもらうとき日本語じゃ使ってもらえない。ってことみたい。


私が日本語にすればいいじゃないって思ってるのは、ビジネスロジックというかそのアプリケーション固有名詞みたいなところ。

「足し算」って関数名は 「add」 でいいと思うし、配列のそれぞれは element とか item とかそういう一般的英単語でいいと思う。

具体例がいいづらいけど、業務システムで表示する金額名前とか、日本語独特なものとか、一般的単語じゃなさそうなの。

こういうのを日本語にしたいってわけなので、ライブラリ的な共通なところは英語で良いかgithubで公開する範囲英語のものでいいと思う。


ただ、最近はやってるマストドンとか、ライブラリ的なものじゃなくアプリケーション自体githubで公開する場合はできない気がする。

でも、海外対象にしてるものだと日本語特有なせいでわかりづらい英語になる苦労とか少なそうだしそういうのだと英語いいんじゃないかな。


----

長くなったけど、まとめると、


業務システム固有名詞とか日本語特有ものとか無理に英語化してよくわからないことになってり、見づらくなるくらいなら日本語使えばいいんじゃないかな

ということ。

まあ思ってる割には実践してないので、やってる人がいたら良かった・悪かったとか聞きたいなと思ったのが書いた理由



追記


帰ってきたらすごいブクマついてた。

色々意見あってとりあえず感謝

絶対自分でやってから言えよ」みたいな意見来るだろうと思って今日の空き時間日本語行ける言語調べたり軽く日本語使ってコード書いてみたので、そのあたりと目についたコメに答えてみる。



まず、思いの外日本プログラミング言語上げてる人がいたので、うまく伝わってなかったぽい。

具体例上げずにサッと書いたらからかな。

あと自分もわりとするけどタイトルだけ見て中身見ずにコメントしてた人もいるだろうなー。

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

これが、などしこやひまわりや、BF系のmisaやら北斗のあれやらうにゃーとか色々な「構文など最初から日本語を前提とした言語」ではないってこと言ってた。


---

日本語かえる言語

最近の主要な言語ならだいたい Unicode 対応でしょと思って環境があった言語を試した結果はこうだった。

JavaScript/Python/PHP/Scala/Kotlin/C#/Go/Swift

これらは日本語変数作れた。


rust と Lua は無理だった。

rust は確か前に、変数名が ascii 文字だけなことに日本以外のどこかの国からUnicode対応にしてって多くの要望あったみたいな記事があったし将来的に対応するんじゃないかなって思ってる。

実際に今どんな状態かは知らない。

その記事コメントとかでみたけど、日本語以外は割りと自国言葉を使ってたりするっぽいね

(正確なデータはないか信憑性はあるとはいえないけど)

VBA を上げてる人がいたけど、私はそこまでのはみたことない。(幸せ者っぽいな)

稀にエクセルマクロいじるときに使い方ググってて出て来る、解説してるページで関数名が日本語なのをたまに見るくらい。

パット見なんか気持ち悪い感はあるけど、読んだときのわかりやすさはけっこう大きい。

---

○使ってみて

大規模案件に使ってみてこその問題もあるだろうけど、簡単スクリプト程度のを日本語にしてみて気づいたこと。

割といける。

全角半角キーPHP の $ より楽。

PHP言語変数は全部$からはじめないといけない欠陥言語

まあ変数のみのgrepのしやすさや予約語キーワード変数名に使えるからメリットもある。

だが、$って打ちづらい。

Shift+4ってすごいつらい。

に比べて全角半角キーってちょい遠いけどそこまで苦痛じゃない。

ふだんから多用してるキーなわけだし。

ただPHP日本語の組み合わせは相性悪い。

$は半角でその後に日本語から手間が多すぎる。


それ以外の言語だと、IMEのおかげでかなり楽。

GoogleIMEだけど、多少のタイプミスは補完で修正してくれるし、予測変換が優秀だし。

IDEいから補完機能のない軽いエディタで書くようなときなら、IMEのおかげで英語変数名で書くより速度は早いと思う。

---

少し前に知人から言われた日本語デメリットを思い出したのでそれも触れとく。

仕様変更言葉変わったとき日本語だと全部書き換えないといけないよ。英語だと別にそのままでいいし。」

英語からない人が、英語言葉とみなさずただの記号として考えてるから、っていうような発言

仕様変わって変数名まで変えるのは面倒なのはわかるけど、あとからコード読む人が英語で見て意味不明になる。

英語日本語対応コメントに書いたとしても、全然意味の違う英語があるのは混乱でしかない。

こういう考えの人がいたら本当にやめてほしい。


---

あとは気になったコメントについて書いてく。


表記ゆれとか方言とか言い回しなどについては、全部日本語にするとあるだろうけど、私が想定してるのは直感的に英語にならないような固有名詞とか。


DBの項目名日本語っていうのは私の思ってるのと近い。

年金の例も○○年金というのがいろいろあって、全部英語だと嫌になってくるしよくわかる。

こういうのを日本語にしたい。

なので年金額を取得する関数で「年金額を取得する」「年金額を取得」「年金額を取り出す」とかの表記を迷うんじゃなくて「get年金額」でいいと思う。

こういう単語だけだと表記はそれなりに揃うと思う。

特にDBにある項目だと仕様とかで先に言葉が決まってることが多いだろうし。

---

見た目について。


見た目が残念とか見づらいというのは同意

ただそれ以上に読んだときのわかりやすさが大きいと思う。

見た目が悪いというのも全部英語っていう前提があるからで1ヶ月も日本語コード見ればなれるんじゃない?って思う。


---


へとヘ

これはありそうな問題

ただ、IDEを使う前提なら未使用変数エラーとか、選択したときに色が変わってないとか、割と気づけると思う。

lとIとかアルファベットでもあるけど、IDEや高機能エディタ使うと困ることはほぼなくなった。


---

ローマ字

私が日本語にしたいような固有名詞ローマ字化してるプロジェクトにであったことはある。

やすい語は見やすいけど、見づらい語は圧倒的に見づらい。


それにローマ字のほうが「ん」でnは1つか2つかや、ヘボンorローマ?という日本語より表記が揃わない問題ある。

特にローマ字場合自分キーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。

---

ラバゴス化・日本が遅れる

海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。

そういうのは対象外

今回いいたいのは、元から日本しか対応してないような業務システムなど。

そういったところの固有名詞日本語になったからって、困ることはないはず。

もともとガラバゴスなわけだし。

日本しか使われないもの海外向けにするにしてもフルスクラッチで作り直すことになるようなもの

こういうのは日本語化いいんじゃないかと思う。

---

テスト

テストだと日本語が使ってる人多いのかな?ブコメスタートップだし。

とりあえずはテストから使い始めてみようと思う。


---


長くなったけど参考になる意見もいろいろあって助かった。

2017-04-17

シンプレックス法

シンプレックス法か?

方程式の解を求める方法を手計算でやるところを

説明してくれるサイトって貴重だね。

変数を少し動かすたびに表を逐一書き換えないといけないか

あれは大変。でも人生に一度はやっておくべきかもね。

どうせ既存アルゴリズムに突っ込むことになるけど

ブラックボックスであるよりかは

ま☆し

2017-04-15

http://anond.hatelabo.jp/20170415170545

動的型の言語流行ったのは、Webプログラミングの隆盛のおかげだろ。

大昔にテキスト処理のawkがあって、その発展版みたいなPerlが現れて、タイミングよくWebプログラミングの波がきて需要が拡大。

でもPerlは、awkの発展版だから、数値も文字列も全部文字列っていう設計思想

変数に型がない以前に、値に型がない。

で、そのPerlの影響を受けたRubyPHPがはやってしまって、動的型の言語の隆盛の時代に。

間違った世界線に入ってしまった。

 

一連のスクリプト言語の特徴は表記が簡略だってことだけど、これは型が動的か静的かというのは関係ない。

でも動的型派は、それが動的型の特徴だと思い込んで「動的型サイコー」みたいに言い出した。

10年くらい前にはハテナでも「Javaで書いたら50行のこの処理が、Rubyで書いたらたったの10行。Javaだせえ!」みたいなブログ流行った。

 

でも、静的型の言語も、今では記述の簡略化が進んで動的型のスクリプト系の言語メリットは薄れてる。

いまさら動的型でやるメリットはない。

2017-04-11

http://anond.hatelabo.jp/20170411164112

数学では暗黙の了解があって、

未知の変数はだいたい x だし、 xの次は y だし、

整数を数える時は n や m

係数は a , b ,c ,α、β、γ

関数は Φやf

このあたりをまとめていた本があったと思うけど、題名わすれたわ。

2017-04-06

http://anond.hatelabo.jp/20170406092042

元増田です。ありがとうございます

教えてくれた事はなんとなくわかった気がします。

ただ読んでイメージしている限りでは下に引用したあたりのことは

ある程度以上の規模のソースコードにならないと便利さが実感しにくいものなんですね。


まとまりのある複数変数メソッドを1つのクラスカプセル化できること。

ただねぇ、開発規模が大きくなると、関数名の重複を避けた命名が面倒になったり、

連想配列だと好きな場所勝手変数増やされたりして、メンテナンス性が悪くなるのね。

からクラスを使うようになりました。

まとまりのあるデータメソッドがあって、まとめておかないとヤバそうなときだけクラスにすればいい。

http://anond.hatelabo.jp/20170406081854

現役ペチパーだけど、元々PHPHTMLスクリプトを埋め込むところから始まった変態言語なので、

普通に関数を作って組み合わせてしまえば大半は事足りるのも当然なんだけども。

実務で使うと便利だなと思うのは、まとまりのある複数変数メソッドを1つのクラスカプセル化できること。

例えば、ユーザ情報管理するときに、「ユーザ情報」というクラスを作って、

その中に publicな変数として、名前フリガナ郵便番号、住所、電話番号、会員ID階級職業性別

を放り込んでおく。

同時に、ユーザ情報の処理に関連する処理の関数を public なメソッドとして、定義する。

ユーザ情報をタブ区切りで得るメソッド getTABDATA()

フォーム入力からユーザ情報にセットする setFromForm()

ユーザ情報が正しく入ってるか評価する Validate()

こうしておけば、

ユーザ情報を何かの関数に渡す時は、インスタンス変数1つ渡せば済む。

ユーザ情報に関する処理は、ユーザ情報クラス定義部を観れば済む。

という2大メリットが得られる。



そんなのPHPなら連想配列変数はまとめられるし、

メソッドだってつのファイル関数並べてインクルードすれば同じメリットが得られるやん?

…と私も思ってた。ただねぇ、開発規模が大きくなると、関数名の重複を避けた命名が面倒になったり、

連想配列だと好きな場所勝手変数増やされたりして、メンテナンス性が悪くなるのね。

からクラスを使うようになりました。




あとは、例えばメールを送るという1つの大きな処理に関連して複数関数定義する場合に、

その関数をまとめてメール送信クラスとしてしまうのはあるかな

実例

http://web-terminal.blogspot.jp/2014/04/php-file-mail-pear.html

PHPエクセル出力できるPHPExcelもクラスになっているから使いやすそう。

http://qiita.com/suin/items/7a8d0979b7675d6fd05b

PHPからPDF出すのもクラスになっていてありがたかった。

http://cmf.ohtanz.com/blog/archives/2463


結論としては、

まとまりのあるデータメソッドがあって、まとめておかないとヤバそうなときだけクラスにすればいい。

2017-03-28

私が死んだら代わりはいない

なんとかならないこともないだろうが、結構大変な事になるに違いない。

というのは、完全に内製の、パソコン上でスタンドアロンとして動作しているシステムがある。

これは私が独自に作ったもので、VisualBasic for Application(Excel)って奴だ。

 

ある業務を別の人から引き継いだんだが、そいつは大して引き継ぎ資料も残さずにさっさと辞めてしまったもんだから、私はかなり大変な事になった。

彼はパソコンといえばExcelくらいしか使えず、プログラムなんか全く書けない人だった。

でも、やたらと毎日一人忙しく仕事しているので社内的評価もそこそこ高い人だったのだが、引き継いだ私は彼の仕事振りに唖然とする羽目になった。

どう考えても、私から見るに自分勝手に金にもならないのに仕事を増やしていただけ、としか思えない。

詳しい事は書ききれないので、ざっくり言うと、「なんでそこまでこの業務を複雑にしたんだ?」って感じ。

しかし、今更その業務簡素にする事は最早無理な状況。

そこで考えあぐねて、業務自体簡素にする事は出来なくとも、業務を処理するシステムを組むことにより仕事を減らそうと決めた。

IT系会社では全くないし、社内にもそんな人材はいない上に個人の考えで外注業者に依頼するわけにもいかいから、独力でVBAを学び、業務を進めつつ四苦八苦してシステムを完成させた。

出来上がったものは、使う分には誰でも簡単に使う事が出来る様になっているので、実際私自身がメンテナンス以外では使う事もなくなり、もっぱら部下にやらせている。

効率が上ったなんてもんじゃない、前任者はその業務に掛かりっきりだったが、私は普通に他の業務をいくつか抱えても特に大きな問題もないほどである

 

だが、劇的に効率上げて実質的コスト削減までしたのに、会社は私のことをまるで評価しないどころか、前任者より仕事をしてないという目で見てくるので正直頭に来てて退職を考えている。

で、そのシステム個人的に作ったものしかいから、仕様書なんてあるはずもなく、勝手に触られても困るのでソースコードを弄られないようにパスワードロックを掛けてある。

さらに、ある時期以降そのシステム更新しないで使うとその業務に支障を来たす為、内部的にタイマーセットしてその日以降は使えないようにもしてある。

それがあと二ヵ月後。 

 

うそう、そのシステムに載せれば問題はないと、調子に乗って前任者より業務さらに複雑にしてしまったんだけど。

どうなっても俺は知らん、ぞと。

 

追記:

id:mazmot

業務改善? 簡素しろという意味なら難しすぎて無理。例えるならば今更Core i7を8086に出来るわけがないって感じっすかねw

id:aukusoe

使えなくするのは嫌がらせではなく、業務仕様がその時期に変わる事が予定されてるからです。誤って使わないようにとの配慮ですよ。

id:houyhnhm

これも同様、嫌がらせではなくて、業務上理由からそうしているだけです。パスワード開示請求があれば即座に応じますよ。金貰ったらメンテナンスも考えなくもありません。

追記2:

まぁ、私がいなくとも何とかならんこともないだろう、という事は冒頭に書いたとおりです。

もうちょっと考察してから書くべきでしたが、多分私の言いたい事は会社が駄目駄目ってことなんじゃないかなと思います

一応、簡単に引継ぎ時にあまりに大変な事は上司にも報告したんです。会議でも言った。

ところが、ほぼ無視あいつに出来たんだからお前にも出来るだろーって感じで放ったらかしにされたというのが偽らざる実感。

でも業務は放ってはおけないので、愚痴っててもどうにもならない。

どうしようもないから、プログラム書いて効率化って方向に進めざるを得なかった、というか判断になったわけです。

こうした細かい話も散々報告したのに全然聞いてないんですよ、上司連中はさ。

ちゃんと聞いてたら、後々になっても私が関与できなくなっても、最低限どうにかして仕様書に落とすとか、あるいは外注してもっとマシなシステムにするような方向で考えるとか、いくらでも検討できた筈です。

それが、トラバレスでも書いたけど「あいつの方が仕事してたよな」って噂流されたんですよ?

「私が死んでも代わりはいる」って増田記事にひっかけて増田に書いたわけですが、実際私自身は私が辞めても業務は滞りなく進んで欲しいと思ってます、というかそうあるべきだと思います

まー、辞めますけどね。もちろん世の中、努力が報われない事も多いですけど、でも馬鹿馬鹿しくてやってられないです。

 

追記3:

Excel VBAパスワード解除は簡単です。それは知ってますし、そんなのググれば一発で出てきます

何遍でも言いますが、パスワードかけたのは不用意に知らない人が触ってシステムおかしくならないように、との意図であって私がやめた後に使えなくする意図などありません。

ただし、会社から指示されない限り、パスワードについて話すつもりもありません。

ですが、もしパスワードを解除してソースを見たら、コメントだらけのソースが読めるようにはしてあります

これは、私が初心者から自分で書いててもよくわからないことが多かったのであくまでもそんなバカ自分のために書いたものなのですけど、変数名前付に至るまで出来る限り意味理解やすものにしてあるつもりです。

何千、何万行もあるような大層なものでもないのでそんなに理解は難しくはないと思います

独学なので色々と変なことはしてると思いますけどね。

2017-03-25

そばをつくった日記(打ってません)

嫁が出張から帰ってきた。

おみやげ信州そばと野沢菜漬けを買ってきた。よし、今日はこのそばで昨日のリベンジマッチといこうじゃないか

冷蔵庫には昨日食べられなかったつゆがそのまま残ってる。これを温めて麺を入れればすぐにできる。

しかし昨日作ったつゆだと2人では少したりなさそうだな。足して2人分にするか、ざる蕎麦で食べるか……。うーん、ここはざるで食べたいな。うん、半分はざるにしよう。とすればねぎ海苔か。まずここからとりかかろう。

しかしせっかくのリベンジだ。ここは天ぷらも揚げたいところ。

冷蔵庫にはなす、舞茸。おっ、昨日解凍した鶏肉も余ってる。鶏天もいい。天ぷら粉は……少ないな。足りるか微妙なところだ。

なす、舞茸、鶏肉を切って、天ぷら粉につける。油もいつもより少し多め。まずは時間のかかる鶏天からだ。

同時進行でそばを茹でるための湯も沸かす。水は多めに。今日はダパァを防ぐために大きめのザルでいこう。

野沢菜も切っておくか。ん?意外と消費期限が短いな。この量だと食べきるのが大変だ。野沢菜天ぷら……そうか、その手があったか野沢菜天ぷら、これがうまいんだよなぁ。勝利確信

そうと決まれ時間がないぞ、急がねば。野沢菜天ぷらサイズに切り、汁気はできるだけ切って、と。

ん、湯も湧いたか。そばを入れるか。忙しくなるぞ。

なすと舞茸を揚げる。左手でそばが固まらないように混ぜつつ、右手天ぷらを揚げる。

おっと、昨日の残りのつゆも電子レンジに入れて温めておこう。

よし、天ぷらもいい感じだ。なすと舞茸はもういいな。しか天ぷら粉が足りなさそうだな、作るか。薄力粉片栗粉、卵……む、卵がない。なんてことだ、ここへ来て……。嫁に買いに行かせるか…?

いや、慌てるな。卵はマヨネーズでも代用できる。昔クックパッドで見た。焦るな俺、まだ対応できる。分量をスマホ検索だ。

遅い、なんだ、Wi-Fiが切れている。クソッ、LTE通信制限にかかってるんだよ肝心なときに何やってんだWi-Fiは!!

まずい、そばをゆでているんだった。そんなことに気を取られている場合ではない。

よし、見ていなかったがゆで加減はちょうどいいぞ。あぶないあぶない。ダパァには細心の注意を払って、と。よし。少し流水で洗おう。

天ぷら粉、スマホが使えないので感に頼るしかない。現代人はテクノロジーに頼りすぎだ。薄力粉片栗粉マヨネーズ、水、たったの4変数だ。

慎重かつ大胆に、そして素早く……よし!いい感じだ。野沢菜なすの残りを油に投下。アチッ!めっちゃ跳ねる!熱い!

いったん油の前から離れて避難だ。その間にそばの水を切って、温めたつゆに入れる。うーん、少し冷めてしまったな。もう一度電子レンジで軽く温めるか。よし、残りはざるに盛り付けてざる蕎麦だ。

お、いいぞ、天ぷらもちょうどよく揚がってる。これも盛り付けて完成だ!

………。

やりきった……!昨日のリベンジ、見事に達成。そば、天ぷら、うますぎる。野沢菜天ぷらホント最高。長野県民はこれもっと打ち出していくべきだ。

嫁氏もご満悦だったよ。排水口につまったうどんを見るまでは、ね。

2017-03-20

http://anond.hatelabo.jp/20170320001230

自分html,pdf,csv等々は拡張子変数名でみかけるので小文字を使いがち

文章中のWWWが草生やしているようにみえて、それがWorld Wide Webの略であることに数秒を要した。

WEBと打ったのはCapsLockキーがそうさせたのではと推測した。普段まりCapsLockキー使わないからね。

http://anond.hatelabo.jp/20170320001230

htmlpdfって変数名とかでよくあるけど

web固有名詞constっぽいかWEBと書くのが俺的に正しい。

はい固有名詞ならWWW使った方がもっと正しいのだが俺の中で発音できなかったのでWEBとした。

という言い訳を思いついたが実のところどうしてそう書いたのかよくわからない。

2017-02-26

httphttp://anond.hatelabo.jp/20170226153940anond.hatelabo.jp/20170226153940

言語仕様上、マルチバイト文字変数名に利用できる場合でも、変数名は半角英数字を使う。

グローバル変数はなるべく使わない。

・1関数に100行以上書かない。

主に、PHP使ってる。

2017-02-25

http://anond.hatelabo.jp/20170224152614

プログラミングで省略語、って、仕様の話なのかコメントの話なのか、省略されすぎていてよくわからない。

関数名や変数名の話じゃないよね。

http://anond.hatelabo.jp/20170224152614

プログラミングで省略語、って、仕様の話なのかコメントの話なのか、省略されすぎていてよくわからない。

関数名や変数名の話じゃないよね。

2017-02-14

http://anond.hatelabo.jp/20170214114736

人間脳みそが信用できるのは一度に扱う変数がせいぜい4〜7個の時だけじゃハゲ

と言うてやれ。

ジャバスクの話で思ったんだけどさあ

サンプルコード変数名とかにクリとリスを必ず含めてく文化JS界に求められてると思うんだよね。

アリスとボブみたいに。

2017-02-01

http://anond.hatelabo.jp/20170201160608

システムハンガリアンはIDEの発達や型推論で廃れた。変数ポインタを当てるだけで型がわかる。

アプリケーションハンガリアンは、自分もメンバ変数btn~にしたり~Buttonにしたり迷ってたりしてたが、プロパティとして公開するときはハンガリアンにするわけにはいかないので、結局ハンガリアンをやめた。プロパティとメンバ変数機械的対応が取れてたほうが便利。"_プロパティ名"とかにしてしまう。

型よりもその変数意味のほうが重要だという考え方がハンガリアンが廃れた大もとの原因だろう。最近IDE中間一致で補完するのが主流なので、Buttonと打てばボタン一覧が出てくる。

ログイン ユーザー登録
ようこそ ゲスト さん