プログラミング言語なでしこはもっと普及するべきだわ
using 文字列 = string
とかまでやってないからアウトｗ
俺も日本語で書くわ
なんなら逆さ言葉で書くわ
読めるだろ
日本人なら
もっと短い単語ないかと同義語辞書ひいちゃうのあるあるだとおもいます
ローマ字表記ありにしてる
その方が意味が正しく通じる（社内では）
変数名だけどさ
他人に見せないんだから略語でもいいよね
area listはalとか
name listはnlとか
扱う人がわかればいいだろ
きっちり書こうとして無駄に長い変数名とか返って見にくくないですか？
大概はちゃんと書いた方がいい場合が多いと思うけどスコープ狭いローカルなら問題ない時もあるしセンスなので一年寝かしてから自分で見直してみ？
省略は読みにくいので略さずちゃんとキャメルケースで書いて欲しい
省略は読みにくいので略さずちゃんとキャメルケースで書いて欲しい
AKBとかHKTとか慣れれば通じるだろ？
社内だけで運用するなら社内ルールで略語使えば良いと思う
略語使うときはちゃんとプロジェクトの規約に書くようにしてるからウチは大丈夫
と入ってもmsg_〇〇_〇〇程度だけど
名前が長くなるということは色々やっているということで設計を見直すと良い場合が多い
あとgetEmployeesByCompanyId(int id) とかはgetEmployees(int companyId)とか場合によっては public Employee get(in companyId)で済むような時もあるし
まあ言語にもよるけど名前が短ければ読みやすいというよりは名前が長くなる理由を潰して行った方がうまく行っている
人や会社が多数絡むと被らないようにラクダのコブ増やすでしょ
その辺は例えばEmployeeサービスとFinanceサービスでgetが被っても問題ないわけで
List<Employee> employees = employeeService.getEmployees(companyId)
のようにしとけば被らない
被るからラクダのコブが増えるというのはたとえばこの例ならEmployeeServiceに大量の人間が絡んでグッチャグチャになってるからでもっとコンポーネントごとに分けるべきではないだろうか
アクセスコントロール的にもパッケージを分けて一つの場所に関わる人は少数のわかってる人にしないとスパゲッティーになるのでは？
もちろん俺もユニットテストとか再利用しない場合は関数名を自然言語のように長く書く時もあるし状況次第だけど
apiの取得名称やコンスタンスの定数みたいなパブリックなやつは長くなりがち
プライベートなもので4文字以上は逆に見づらい
上でも書いたけどスコープ狭いなら名前は短くても問題ないしなんなら数学的な関数ならXみたいなので良い時もある
まあ繰り返しになるけど自分のコード一切みないで1年寝かして見直してみた時に自分でわかればそれでいいんじゃないかな
経験的には状況とか書いてる言語とかによるけどなるべく初見の人がみてわかるような言葉で書いた方が1年後の俺もほぼ初見になってるので自分にもわかりやすいし
それで長くなるなら設計が良く無い事が多かったかな
識別子を長くすると
自然にコメントみたいな効果を発揮するから
長い方がいいと思うけどなあ
入力は最初の一回が大変なだけで
二回目からは補完してくれるから
そんなに大変じゃないし
getOrImportCompany(int companyId)くらいは書くね
テストだとtestGetAndPostOrganizationOnboardingQuestionsAndAnswersContractorType()
くらいまでやるけど本体の方でこんなになってたらSOLIDのSが出来てない
テストの方ならクソ長いけど実際海外のテストエンジニア界隈ではよくあるやつ
再利用しないのでコメントで書いても関数の名前にしても同じ
本体のgetOrImportCompanyがクソ長いならCで秀丸ってわけじゃないじゃんみたいな
最近の高級言語でまともなIDEで書いてればタイプアヘッドで欲しいの出てくるしそうじゃなくてもプログラマならこれくらいサラサラ打てるし
短く省略してコメント書いても呼ばれる先ではわからないわけだからgoicとか略すより生産性が少なくとも俺の場合は全然高いのでそうしてる
長すぎるのは略語でいいだろ
どうせ社内の限られた人しか見ないんだし
寒色インコっぽい悩みでちょっと微笑ましい・・・
変数名mekoにしとけｗ
ブックマークへ