変数や関数の名前を英語で書くやつって何なの？？？ (42ﾚｽ)
上下前次1-新
1(2): 仕様書無しさん [] 2022/12/21(水)21:47
日本人なら日本語で書いた方が明らかにわかりやすい
俺はいつも日本語で書いてる
https://i.imgur.com/eZ7oN0j.png
2(1): 仕様書無しさん [sage] 2022/12/21(水)21:50
プログラミング言語なでしこはもっと普及するべきだわ
3(2): 仕様書無しさん [sage] 2022/12/21(水)21:55
>>1
ガイジｗ
4: 仕様書無しさん [sage] 2022/12/21(水)22:38
>>3
？
5: 仕様書無しさん [] 2022/12/21(水)22:55
て、ててて天才じゃーーー
6: 仕様書無しさん [] 2022/12/21(水)22:55
>>3
可哀想だろ頑張ったんだから褒めてやらないと
7: 仕様書無しさん [] 2022/12/22(木)09:37
>>1
わろたwこれは酷いwww
8: 仕様書無しさん [sage] 2022/12/22(木)10:44
using 文字列 = string
とかまでやってないからアウトｗ
9: 仕様書無しさん [sage] 2022/12/22(木)12:03
俺も日本語で書くわ
なんなら逆さ言葉で書くわ
読めるだろ
日本人なら
10: 仕様書無しさん [sage] 2022/12/22(木)12:31
もっと短い単語ないかと同義語辞書ひいちゃうのあるあるだとおもいます
11: 仕様書無しさん [sage] 2022/12/22(木)13:19
>>2
なでしこは最強ですわ！
12: 仕様書無しさん [sage] 2022/12/22(木)22:19
字が潰れて読めねーよ
13: 仕様書無しさん [sage] 2022/12/22(木)22:23
ワイ同僚みんな外人さんなので
日本語はちょっと
14: 仕様書無しさん [sage] 2022/12/26(月)19:13
ローマ字表記ありにしてる
その方が意味が正しく通じる（社内では）
15: 仕様書無しさん [] 2022/12/29(木)23:28
変数名だけどさ
他人に見せないんだから略語でもいいよね
area listはalとか
name listはnlとか
扱う人がわかればいいだろ
きっちり書こうとして無駄に長い変数名とか返って見にくくないですか？
16: 仕様書無しさん [sage] 2022/12/30(金)00:03
大概はちゃんと書いた方がいい場合が多いと思うけどスコープ狭いローカルなら問題ない時もあるしセンスなので一年寝かしてから自分で見直してみ？
17: 仕様書無しさん [sage] 2022/12/30(金)22:48
省略は読みにくいので略さずちゃんとキャメルケースで書いて欲しい
18: 仕様書無しさん [sage] 2022/12/30(金)22:48
省略は読みにくいので略さずちゃんとキャメルケースで書いて欲しい
19: 17-18 [sage] 2022/12/30(金)22:49
ごめん、書き込むボタン連打して連投してしまった
20: 仕様書無しさん [sage] 2022/12/31(土)00:26
AKBとかHKTとか慣れれば通じるだろ？
社内だけで運用するなら社内ルールで略語使えば良いと思う
21: 仕様書無しさん [sage] 2022/12/31(土)01:15
略語使うときはちゃんとプロジェクトの規約に書くようにしてるからウチは大丈夫
と入ってもmsg_〇〇_〇〇程度だけど
22: 仕様書無しさん [sage] 2022/12/31(土)06:10
4単語以上の変数名は見にくいよな
23(1): 仕様書無しさん [sage] 2022/12/31(土)08:35
名前が長くなるということは色々やっているということで設計を見直すと良い場合が多い
あとgetEmployeesByCompanyId(int id) とかはgetEmployees(int companyId)とか場合によっては public Employee get(in companyId)で済むような時もあるし
まあ言語にもよるけど名前が短ければ読みやすいというよりは名前が長くなる理由を潰して行った方がうまく行っている
24: 仕様書無しさん [sage] 2022/12/31(土)09:43
人や会社が多数絡むと被らないようにラクダのコブ増やすでしょ
25: 仕様書無しさん [sage] 2022/12/31(土)10:38
その辺は例えばEmployeeサービスとFinanceサービスでgetが被っても問題ないわけで
List<Employee> employees = employeeService.getEmployees(companyId)
のようにしとけば被らない
被るからラクダのコブが増えるというのはたとえばこの例ならEmployeeServiceに大量の人間が絡んでグッチャグチャになってるからでもっとコンポーネントごとに分けるべきではないだろうか
26: 仕様書無しさん [sage] 2022/12/31(土)10:39
アクセスコントロール的にもパッケージを分けて一つの場所に関わる人は少数のわかってる人にしないとスパゲッティーになるのでは？
27: 仕様書無しさん [sage] 2022/12/31(土)10:42
もちろん俺もユニットテストとか再利用しない場合は関数名を自然言語のように長く書く時もあるし状況次第だけど
28: 仕様書無しさん [sage] 2022/12/31(土)10:43
apiの取得名称やコンスタンスの定数みたいなパブリックなやつは長くなりがち
プライベートなもので4文字以上は逆に見づらい
29: 仕様書無しさん [sage] 2022/12/31(土)10:48
上でも書いたけどスコープ狭いなら名前は短くても問題ないしなんなら数学的な関数ならXみたいなので良い時もある
まあ繰り返しになるけど自分のコード一切みないで1年寝かして見直してみた時に自分でわかればそれでいいんじゃないかな
経験的には状況とか書いてる言語とかによるけどなるべく初見の人がみてわかるような言葉で書いた方が1年後の俺もほぼ初見になってるので自分にもわかりやすいし
それで長くなるなら設計が良く無い事が多かったかな
30: 仕様書無しさん [sage] 2022/12/31(土)21:57
識別子を長くすると
自然にコメントみたいな効果を発揮するから
長い方がいいと思うけどなあ
入力は最初の一回が大変なだけで
二回目からは補完してくれるから
そんなに大変じゃないし
31(1): 仕様書無しさん [sage] 2023/01/01(日)00:39
getOrImportCompany(int companyId)くらいは書くね
テストだとtestGetAndPostOrganizationOnboardingQuestionsAndAnswersContractorType()
くらいまでやるけど本体の方でこんなになってたらSOLIDのSが出来てない
32: 仕様書無しさん [sage] 2023/01/03(火)18:52
iTronのAPIは関数の命名が糞過ぎたっけ
33: 仕様書無しさん [sage] 2023/01/06(金)15:39
>>31
クソ長い
34: 仕様書無しさん [sage] 2023/01/06(金)16:56
テストの方ならクソ長いけど実際海外のテストエンジニア界隈ではよくあるやつ
再利用しないのでコメントで書いても関数の名前にしても同じ
本体のgetOrImportCompanyがクソ長いならCで秀丸ってわけじゃないじゃんみたいな
最近の高級言語でまともなIDEで書いてればタイプアヘッドで欲しいの出てくるしそうじゃなくてもプログラマならこれくらいサラサラ打てるし
短く省略してコメント書いても呼ばれる先ではわからないわけだからgoicとか略すより生産性が少なくとも俺の場合は全然高いのでそうしてる
35: 仕様書無しさん [] 2023/01/10(火)14:07
長すぎるのは略語でいいだろ
どうせ社内の限られた人しか見ないんだし
36: 仕様書無しさん [sage] 2023/02/15(水)00:23
クリスマスなのに俺にあったかいのは便座だけ
37: 仕様書無しさん [sage] 2023/09/29(金)21:11
世の中ね、顔かお金かなのよ
38: 仕様書無しさん [sage] 2023/11/29(水)04:38
寒色インコっぽい悩みでちょっと微笑ましい・・・
変数名mekoにしとけｗ
39: 仕様書無しさん [] 2024/03/29(金)13:43
やっぱ若手は平野しか浸透しない。
40: 仕様書無しさん [sage] 2024/03/29(金)13:59
>>23
最後の鳴き声だよ
41: 仕様書無しさん [sage] 2024/03/29(金)15:10
そういえば
俺も悪だっての
42: 仕様書無しさん [] 2024/03/29(金)16:00
波恋
黙って🐶
マジで過密日程やからな
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.297s*