堕天使の煉獄
2015-10
30
06:45:32
英語わからん
なんだかんだで他の人も結構いい加減だったりするので、いまさら完全な正解なんてないんでしょうけど。プログラムの関数名の付け方にはいつまで経っても悩みがつきない。
特に「boolを返す」系。とりあえず馬鹿の一つ覚え的に「is」+○○とかに統一しちゃえばいいのか。
でもその場合よく例で上がるのがexists()とかcontains()とか。
三人称単数とか意味がわかんないんですけど、このへんのやつはisをつけると英語的にはおかしな表現となるので、つけるべきではないそうな。
しかし、単純に英語的に正しいかどうかなんてクソ食らえ、可読性をとるぜってポリシーならば、べつにisをつけちゃってisExist()でもいいんじゃね? という考えもある。isがついてりゃboolが返ってくるんでしょ? というのが一目瞭然なので、確かに理はあるとおもふし。
他にはisEnable()はisEnabled()のほうがいいのか。
セットする時はsetEnable()のが自然な気がするのだけど、統一性を考えるとsetEnabled()にした方が良いのかとか。
setEnabled()てなんか、「有効化された」をセットするっていう変な語になる感じがして気持ちが悪いんだけども。
enable系だと、個人的には
void setEnable(bool flag);
bool enabled();
が良いかなとおもっているのだけども。
でもこれだと記述ミスしやすいんですよね。dつけ忘れorつけない方につけちゃったとか。
そんなささいなことで悩むぐらいならやはり
void setEnabled(bool flag);
bool isEnabled();
とした方が、英語として云々はおいといてわかりやすい&たいぽし難いってのでは正解なのかなと言う気も。
なにげにstlでも、「空か?」というメソッドはempty()になってて、isEmpty()ではなかったりして。
過去の他のライブラリとかではisEmpty()が使われてるのをよく見たのだけどもstlではis無しかとおもうと、bool返しにはisをとりあえずつけとけというのは、もう時代遅れな感じなのかなという気もしないでもない。
単語の意味を考えればempty()なら空かそうでないかの二択、つまりはbool値が返ってくるなんてのは自明ですし。
そういうところで
bool enabled();
is無しの方が良いのではないか。という気もするし。
void setEnable(bool flag);
bool enable();
むしろdもとっちゃってこれでもいいような。
英語的にどうかとかおいといて、とりあえず見ただけで何をしてるか、何が返るのかは自明だし、表記も統一してるのでtypoの危険も少ない。
うーん。
このへんのは、コーディング規約とおんなじで一度決めたらすべてのソースコードで統一させるべきものだったりするので、後でやっぱ変えようとか気軽にできなかったりして。
enableとか汎用的なものは特に。
どういうルールで統一すべきかですんごく悩む。
こういうところで英語力のなさが浮き彫りになるな……。
英語わからん。
特に「boolを返す」系。とりあえず馬鹿の一つ覚え的に「is」+○○とかに統一しちゃえばいいのか。
でもその場合よく例で上がるのがexists()とかcontains()とか。
三人称単数とか意味がわかんないんですけど、このへんのやつはisをつけると英語的にはおかしな表現となるので、つけるべきではないそうな。
しかし、単純に英語的に正しいかどうかなんてクソ食らえ、可読性をとるぜってポリシーならば、べつにisをつけちゃってisExist()でもいいんじゃね? という考えもある。isがついてりゃboolが返ってくるんでしょ? というのが一目瞭然なので、確かに理はあるとおもふし。
他にはisEnable()はisEnabled()のほうがいいのか。
セットする時はsetEnable()のが自然な気がするのだけど、統一性を考えるとsetEnabled()にした方が良いのかとか。
setEnabled()てなんか、「有効化された」をセットするっていう変な語になる感じがして気持ちが悪いんだけども。
enable系だと、個人的には
void setEnable(bool flag);
bool enabled();
が良いかなとおもっているのだけども。
でもこれだと記述ミスしやすいんですよね。dつけ忘れorつけない方につけちゃったとか。
そんなささいなことで悩むぐらいならやはり
void setEnabled(bool flag);
bool isEnabled();
とした方が、英語として云々はおいといてわかりやすい&たいぽし難いってのでは正解なのかなと言う気も。
なにげにstlでも、「空か?」というメソッドはempty()になってて、isEmpty()ではなかったりして。
過去の他のライブラリとかではisEmpty()が使われてるのをよく見たのだけどもstlではis無しかとおもうと、bool返しにはisをとりあえずつけとけというのは、もう時代遅れな感じなのかなという気もしないでもない。
単語の意味を考えればempty()なら空かそうでないかの二択、つまりはbool値が返ってくるなんてのは自明ですし。
そういうところで
bool enabled();
is無しの方が良いのではないか。という気もするし。
void setEnable(bool flag);
bool enable();
むしろdもとっちゃってこれでもいいような。
英語的にどうかとかおいといて、とりあえず見ただけで何をしてるか、何が返るのかは自明だし、表記も統一してるのでtypoの危険も少ない。
うーん。
このへんのは、コーディング規約とおんなじで一度決めたらすべてのソースコードで統一させるべきものだったりするので、後でやっぱ変えようとか気軽にできなかったりして。
enableとか汎用的なものは特に。
どういうルールで統一すべきかですんごく悩む。
こういうところで英語力のなさが浮き彫りになるな……。
英語わからん。
コメント:2件
Re.あかしゃち
2015-11-02(Mon) 23:31:16
7年前のサイトをそのまま使ってたらセキュリティホール突かれてアレやソレなタグ埋め込まれて鯖側でもうダメって隔離されたお。
ふぁっきん!
DBに日記は残ってるんでこれどうにかできんかなと途方にくれるですよ。
ふぁっきん!
DBに日記は残ってるんでこれどうにかできんかなと途方にくれるですよ。
Re.織田霧
2015-11-03(Tue) 07:47:29
ここ数日見えなかったから、レンタル鯖の代金払い忘れか
ついに閉鎖したのかとおもてたよ。
なんか表示も重いしレスも書けないしだったので、新しいのに変える良い機会では。
DBのバックアップとリストアはいろいろ面倒そうだけど……。
ついに閉鎖したのかとおもてたよ。
なんか表示も重いしレスも書けないしだったので、新しいのに変える良い機会では。
DBのバックアップとリストアはいろいろ面倒そうだけど……。
Sun
Mon
Tue
Wed
Thu
Fri
Sat
01
■
■
これなんてスネーク?
02
03
04
05
■
■
あついさむい
06
07
08
09
10
■
■
また値上がりしてないか?
11
12
[体育の日]
13
14
15
■
■
テロっていうか罰ゲームだろ
16
■
■
そろそろ毛布だすか
17
■
■
共産主義者の夢
18
■
■
そういう流れなのね
19
■
■
二等兵ぇ……
20
■
■
またあとでね~
21
22
■
■
うざいアレ
23
24
25
■
■
冬支度開始
26
■
■
さむっ
27
28
29
30
■
■
英語わからん
31
total:2076239 t:147 y:119
■記事タイトル■
■年度別リスト■
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