堕天使の煉獄
2014-02
13
06:51:14
だいたい英語の成績は2でした。
またまた小ネタ。
bool型について。
boolean 変数を返すメソッドの命名方法例というので
「is + 形容詞」
「can + 動詞」
「has + 過去分詞」
「三単現(三人称単数現在)動詞」
「三単現動詞 + 名詞」
のいずれかの名称をつかうべき。
というのがわりと定石のようになっている。
過去分詞、三単現、三単現動詞てなんだよ。
さぱりわかんねーw
使用例は上の順でこんな。
isEnabled()
canGet()
hasCanged()
contains()
containsKey()
基本的には、返ってくる値がtrueなのかfalseなのかを
判断できるものにすべき。
というのが第一原則だということだそうな。
なので、
isNotEnabled()
などとやってしまうと、
Enabledでない=trueが返ってくるの?
それともEnabledでないという意味でfalseが返ってくるの?
と、不鮮明になってしまうような表現を避けるべき。
というのがまず大事というのだけども。
isEnabled()
は、isの後ろの通りになっていたらtrueが返ってくる
ということで、tureかfalseどちらが返ってくるのか判りやすいし
意味もわかりやすい。
canGet()
この場合はゲットできたらtrueという感じか。
hasCanged()
んでこれは……
過去分詞以前にhasがさっぱりわからないw
「hasって何?」ときょとんとしてしまうレベルの
英語力しかないおいらにはハードル高いです(ぉ
が、変更出来てたらtureというのは語感でわかる(ぉ
contains()
containsKey()
こっちは、含まれていたらtrueでいいのかな。
んでもcontain自体がぱっと意味が出てこないw
コンテナとか聞くと、ああとかおもうけど。
んで、過去分詞ってなんぞや、と
ググってみると、なんだかもう
読む気のうせる長文が。
三単現とかもそう。
「主語が三人称の単数で、
現在の文のとき、
動詞の後ろに s が付く」
なんか、主体がどうとか、実存がどうとか
そういう哲学っぽい難解な文章だなおい。
おもえば、哲学の還元という手法とほぼ同一のことをしているのだから
(文節をこれ以上分けられない単純なものにまで切り分けてその関係性を考える)
なんだか哲学書を読んでるような気分になるのもうなずける。
学生の自分、英語の成績はいつも赤点をギリで免れるレベルで、
あるとき英語の成績の良い友人に、そのコツを聴いてみた事があったのですが。
「単純に構文とかルールをただ暗記して、機械的に組み合わせるだけじゃん。」
と言われた。
ある意味ではプログラム言語の習得に近い物なのかも知れない。
プログラミングの構文を覚えるのも
英語の文法を覚えるのも、基本的には変らない筈なのだけども。
こうなったら後ろにsがつく。
とか
haveとか~ingは使うところで意味が全然変るとか
それもルールさえ覚えれば良いという理屈なのだけども。
さっぱり覚えられなかったなぁ。
そもそもプログラミングとの大きな違いは
コンパイルして文法が正しいか常にチェックされるということから
正しい用法を反復練習し続けるので、意識して文法を覚える必要名がなく
経験として身についていくから習得が簡単なのだろうか。
さらには、作った物が動くという、インタラクティブ性というのも
大きいのかもしれない。
そう言う意味では、英語の学習は
英語圏に行って、周りが英語しか話して無くて、
英語を使わなければ何も出来ない環境に置くのが
一番習得が速い。
というのもおんなじ事なのでしょうね。
実際、日本の学校教育の英語の成績が良くても
英語ぺらぺらにはならないし。
むしろ学校教育の英語は
実際使われている日常会話てきな英語とはかけ離れていて
英語の教科書とか、英語圏の人が読むと噴飯ものな代物らしいしね。
だいたい「過去分詞」って言葉も言葉の意味も知らなくても
使えるしなぁ。
そういう文節とかの繋がりの意味なんて
言語学者の仕事であって、英語を覚えることとは
方向性が違うんじゃないかと。
そういう形から入って、最終的になんにも身につかないのが
日本の英語教育の実態なんだろうなぁ。
そんなところでプログラムのboolに戻ると
英語がさぱーりな人にありがちなのが、
boolを返す関数名に
とにかく何でも頭に「is」をつける。
というのがあります。
はい、わたしも昔はよくやってましたw
だっていみわかんねーんだもん。
英語のw
contains()
なんて書く状況なら、
isInto()
とか書いてそうw
(containていう単語はまずでてこない)
んまあ、こういうのは判ればいいんですけど
んでもなるべくなら、みんなこうしてるよ。
っていう定石に会わせて書くのが無難だし
人にソースを見せる時とかも、そういう共通の基盤が
可読性の向上に貢献するのでそうするべきなのですが。
英語力の無さが如実にでるよなぁ。
独自の関数名とかに……w
基本、英語に一番関わってる瞬間って、プログラミングを除けば
洋楽(メタル)だからなぁ。
変な単語ばっか覚えてたりするのですよね。
人前で口にするのを憚られる感じのw
んでもまあ、意外と技術系だと
細かいニュアンスまで理解出来なくてもわりとおおざっぱなかんじでも
理解出来てしまうのでアレなのですが。
QTとかほとんど英語の資料しかないのですが
基本的にGUIの開発環境なので
一度もその手のをやったことないときついのかもですが
他の環境で経験があれば、なんとなく初めて見る英単語でも
たぶんアレのことだろうなーとか
全体の文章の意味するところは雰囲気でわかるので
あとは穴あき問題みたいな感じで答えを埋めていける感じになるので。
もっと言えばサンプルにソースコード書いてあれば
それだけで用が足りるし。
んでもなにげに改めて考えてみると、
解説の英文がさっぱり判らないのに
ソースコードを見ればほぼ全部判るというのもなんだか不思議な現象だなぁ。
プログラム自体も英語で書かれているのにね。
んまあ、文法がまるで違う
ルールが別物の英語って感じな物だからでしょうけど。
んでもソースコードをテキストにして
解説の英文を解読していくという、逆の使い方してるのも
なんだか滑稽な感じですねw
なんだかんだで、技術文章系の英語を読むことは
それなりに出来るようにはなってきたのですけども
自分で英文作ったりとか、話したりとかはさっぱり出来ないままですw
なので、関数名とか愉快な英語もどきをいっぱい、
自覚症状無しにつかってるんだろうなーとかおもうと
不安になったりする最近DEATH。
bool型について。
boolean 変数を返すメソッドの命名方法例というので
「is + 形容詞」
「can + 動詞」
「has + 過去分詞」
「三単現(三人称単数現在)動詞」
「三単現動詞 + 名詞」
のいずれかの名称をつかうべき。
というのがわりと定石のようになっている。
過去分詞、三単現、三単現動詞てなんだよ。
さぱりわかんねーw
使用例は上の順でこんな。
isEnabled()
canGet()
hasCanged()
contains()
containsKey()
基本的には、返ってくる値がtrueなのかfalseなのかを
判断できるものにすべき。
というのが第一原則だということだそうな。
なので、
isNotEnabled()
などとやってしまうと、
Enabledでない=trueが返ってくるの?
それともEnabledでないという意味でfalseが返ってくるの?
と、不鮮明になってしまうような表現を避けるべき。
というのがまず大事というのだけども。
isEnabled()
は、isの後ろの通りになっていたらtrueが返ってくる
ということで、tureかfalseどちらが返ってくるのか判りやすいし
意味もわかりやすい。
canGet()
この場合はゲットできたらtrueという感じか。
hasCanged()
んでこれは……
過去分詞以前にhasがさっぱりわからないw
「hasって何?」ときょとんとしてしまうレベルの
英語力しかないおいらにはハードル高いです(ぉ
が、変更出来てたらtureというのは語感でわかる(ぉ
contains()
containsKey()
こっちは、含まれていたらtrueでいいのかな。
んでもcontain自体がぱっと意味が出てこないw
コンテナとか聞くと、ああとかおもうけど。
んで、過去分詞ってなんぞや、と
ググってみると、なんだかもう
読む気のうせる長文が。
三単現とかもそう。
「主語が三人称の単数で、
現在の文のとき、
動詞の後ろに s が付く」
なんか、主体がどうとか、実存がどうとか
そういう哲学っぽい難解な文章だなおい。
おもえば、哲学の還元という手法とほぼ同一のことをしているのだから
(文節をこれ以上分けられない単純なものにまで切り分けてその関係性を考える)
なんだか哲学書を読んでるような気分になるのもうなずける。
学生の自分、英語の成績はいつも赤点をギリで免れるレベルで、
あるとき英語の成績の良い友人に、そのコツを聴いてみた事があったのですが。
「単純に構文とかルールをただ暗記して、機械的に組み合わせるだけじゃん。」
と言われた。
ある意味ではプログラム言語の習得に近い物なのかも知れない。
プログラミングの構文を覚えるのも
英語の文法を覚えるのも、基本的には変らない筈なのだけども。
こうなったら後ろにsがつく。
とか
haveとか~ingは使うところで意味が全然変るとか
それもルールさえ覚えれば良いという理屈なのだけども。
さっぱり覚えられなかったなぁ。
そもそもプログラミングとの大きな違いは
コンパイルして文法が正しいか常にチェックされるということから
正しい用法を反復練習し続けるので、意識して文法を覚える必要名がなく
経験として身についていくから習得が簡単なのだろうか。
さらには、作った物が動くという、インタラクティブ性というのも
大きいのかもしれない。
そう言う意味では、英語の学習は
英語圏に行って、周りが英語しか話して無くて、
英語を使わなければ何も出来ない環境に置くのが
一番習得が速い。
というのもおんなじ事なのでしょうね。
実際、日本の学校教育の英語の成績が良くても
英語ぺらぺらにはならないし。
むしろ学校教育の英語は
実際使われている日常会話てきな英語とはかけ離れていて
英語の教科書とか、英語圏の人が読むと噴飯ものな代物らしいしね。
だいたい「過去分詞」って言葉も言葉の意味も知らなくても
使えるしなぁ。
そういう文節とかの繋がりの意味なんて
言語学者の仕事であって、英語を覚えることとは
方向性が違うんじゃないかと。
そういう形から入って、最終的になんにも身につかないのが
日本の英語教育の実態なんだろうなぁ。
そんなところでプログラムのboolに戻ると
英語がさぱーりな人にありがちなのが、
boolを返す関数名に
とにかく何でも頭に「is」をつける。
というのがあります。
はい、わたしも昔はよくやってましたw
だっていみわかんねーんだもん。
英語のw
contains()
なんて書く状況なら、
isInto()
とか書いてそうw
(containていう単語はまずでてこない)
んまあ、こういうのは判ればいいんですけど
んでもなるべくなら、みんなこうしてるよ。
っていう定石に会わせて書くのが無難だし
人にソースを見せる時とかも、そういう共通の基盤が
可読性の向上に貢献するのでそうするべきなのですが。
英語力の無さが如実にでるよなぁ。
独自の関数名とかに……w
基本、英語に一番関わってる瞬間って、プログラミングを除けば
洋楽(メタル)だからなぁ。
変な単語ばっか覚えてたりするのですよね。
人前で口にするのを憚られる感じのw
んでもまあ、意外と技術系だと
細かいニュアンスまで理解出来なくてもわりとおおざっぱなかんじでも
理解出来てしまうのでアレなのですが。
QTとかほとんど英語の資料しかないのですが
基本的にGUIの開発環境なので
一度もその手のをやったことないときついのかもですが
他の環境で経験があれば、なんとなく初めて見る英単語でも
たぶんアレのことだろうなーとか
全体の文章の意味するところは雰囲気でわかるので
あとは穴あき問題みたいな感じで答えを埋めていける感じになるので。
もっと言えばサンプルにソースコード書いてあれば
それだけで用が足りるし。
んでもなにげに改めて考えてみると、
解説の英文がさっぱり判らないのに
ソースコードを見ればほぼ全部判るというのもなんだか不思議な現象だなぁ。
プログラム自体も英語で書かれているのにね。
んまあ、文法がまるで違う
ルールが別物の英語って感じな物だからでしょうけど。
んでもソースコードをテキストにして
解説の英文を解読していくという、逆の使い方してるのも
なんだか滑稽な感じですねw
なんだかんだで、技術文章系の英語を読むことは
それなりに出来るようにはなってきたのですけども
自分で英文作ったりとか、話したりとかはさっぱり出来ないままですw
なので、関数名とか愉快な英語もどきをいっぱい、
自覚症状無しにつかってるんだろうなーとかおもうと
不安になったりする最近DEATH。
Sun
Mon
Tue
Wed
Thu
Fri
Sat
01
■
■
広告消えたらやっぱ速えー
02
■
■
おあずけばかり
03
04
05
06
07
08
■
■
いろいろ小ネタ
09
10
11
[建国記念の日]
12
13
■
■
だいたい英語の成績は2でした。
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
total:2080728 t:190 y:2908
■記事タイトル■
■年度別リスト■
2024年
2024年12月(0)2024年11月(0)
2024年10月(1)
2024年09月(2)
2024年08月(1)
2024年07月(1)
2024年06月(5)
2024年05月(2)
2024年04月(1)
2024年03月(6)
2024年02月(4)
2024年01月(3)
2023年
2023年12月(3)2023年11月(1)
2023年10月(2)
2023年09月(3)
2023年08月(3)
2023年07月(3)
2023年06月(7)
2023年05月(8)
2023年04月(2)
2023年03月(1)
2023年02月(2)
2023年01月(3)
2022年
2022年12月(4)2022年11月(3)
2022年10月(1)
2022年09月(3)
2022年08月(3)
2022年07月(2)
2022年06月(1)
2022年05月(3)
2022年04月(2)
2022年03月(2)
2022年02月(1)
2022年01月(6)
2021年
2021年12月(8)2021年11月(3)
2021年10月(4)
2021年09月(6)
2021年08月(2)
2021年07月(1)
2021年06月(3)
2021年05月(2)
2021年04月(2)
2021年03月(3)
2021年02月(1)
2021年01月(4)
2020年
2020年12月(3)2020年11月(7)
2020年10月(2)
2020年09月(3)
2020年08月(1)
2020年07月(3)
2020年06月(7)
2020年05月(5)
2020年04月(8)
2020年03月(4)
2020年02月(2)
2020年01月(4)
2019年
2019年12月(1)2019年11月(1)
2019年10月(2)
2019年09月(1)
2019年08月(3)
2019年07月(2)
2019年06月(2)
2019年05月(2)
2019年04月(4)
2019年03月(1)
2019年02月(7)
2019年01月(1)
2018年
2018年12月(1)2018年11月(1)
2018年10月(5)
2018年09月(1)
2018年08月(5)
2018年07月(1)
2018年06月(1)
2018年05月(1)
2018年04月(2)
2018年03月(2)
2018年02月(1)
2018年01月(1)
2017年
2017年12月(2)2017年11月(1)
2017年10月(2)
2017年09月(5)
2017年08月(8)
2017年07月(2)
2017年06月(1)
2017年05月(1)
2017年04月(3)
2017年03月(5)
2017年02月(7)
2017年01月(8)
2016年
2016年12月(7)2016年11月(2)
2016年10月(3)
2016年09月(7)
2016年08月(8)
2016年07月(10)
2016年06月(17)
2016年05月(6)
2016年04月(8)
2016年03月(10)
2016年02月(5)
2016年01月(10)
2015年
2015年12月(7)2015年11月(7)
2015年10月(13)
2015年09月(7)
2015年08月(7)
2015年07月(5)
2015年06月(4)
2015年05月(5)
2015年04月(2)
2015年03月(4)
2015年02月(1)
2015年01月(7)
2014年
2014年12月(12)2014年11月(8)
2014年10月(4)
2014年09月(6)
2014年08月(7)
2014年07月(4)
2014年06月(2)
2014年05月(5)
2014年04月(4)
2014年03月(8)
2014年02月(4)
2014年01月(8)
2013年
2013年12月(15)2013年11月(8)
2013年10月(3)
2013年09月(3)
2013年08月(8)
2013年07月(0)
2013年06月(0)
2013年05月(0)
2013年04月(0)
2013年03月(0)
2013年02月(0)
2013年01月(0)
■レス履歴■
■ファイル抽出■
■ワード検索■
堕天使の煉獄
https://rengoku.sakura.ne.jp
管理人
織田霧さくら(oda-x)
E-mail (■を@に)
oda-x■rengoku.sakura.ne.jp