-
- いいね！0
M.K
@ryutorion
#UEOsaka 読みやすい処理は驚かせてこない ja.wikipedia.org/wiki/驚き最小の原則 Safariからだとリンクがちゃんと貼れない?
2024-04-28 12:42:35
暇人（ゲームプログラマー）
@hima_zinn
ある人が『プログラマーは名前をつけるのがメインの仕事』って言ってたの思い出した。 いい名前をつけられる人はプログラム書くのキレイ。 #UEOsaka
2024-04-28 12:43:56
おかず
@pafuhana1213
処理や変数の役割が他人から見て明確なことが大事 名前が初期値のままだったり、抽象的すぎたり（プレイヤーマネージャーとかも含まれる。Somethingクラス #UEOsaka
2024-04-28 12:46:33
Indie-us Games
@IndieusGames
本日の開催の『Unreal Engine Meetup in Osaka Vol.02』のハッシュタグは #UEOsaka です！みなさまぜひ感想や知見をポストしてください！ ※一部の講演は写真撮影・SNSでの公開は禁止しております。
2024-04-28 12:47:00
M.K
@ryutorion
#UEOsaka 名前で驚かせるので見かけるのは Getってついているのに中でデータ生成してたりしてしょっちゅう呼び出すと重いやつとか コードレビューでもちょくちょく指摘するやつ
2024-04-28 12:47:24
おかず
@pafuhana1213
使用者を驚かせないこと。 名前で示していること以外の処理をしない Get関数内で色々処理しちゃってるとかも含まれるやつだ！ #UEOsaka
2024-04-28 12:48:38
おかず
@pafuhana1213
なぜこのような処理を書いたのかが分かるようにすること めちゃわかる…数ヶ月後の自分は他人だから、これ書いておかないと実装の意図が分からなくて書き換えたりして同じバグを踏んだりする… #UEOsaka
2024-04-28 12:50:34
M.K
@ryutorion
#UEOsaka 処理を実装した意図がわかるようにしておくと，削除する時とかにも消してOKか分かる 最近だとArchitecture Decision Record (ADR) を導入しようみたいな話もありますね バージョン管理のログも大事な情報なので，適当なコメント残されると実装した意図がわからなかったり
2024-04-28 12:50:36
暇人（ゲームプログラマー）
@hima_zinn
そういや、自分は『処理のコスト』よりも『読みやすさ』のほうが優先度高い書き方してます。 もちろん、ボトルネックになるようなレベルの処理コストだったら処理コストのほうが優先ですが、実際には感じられないレベルの処理コストしか効果がないなら読みやすさ優先でいいと思ってます。 #UEOsaka
2024-04-28 12:53:25
alwei
@aizen76
「ベタ書き」をしない ただしベタ書き全てが悪ではないと思ってる。 実装速度が早いのでケースバイスケースに利用する。 #UEOsaka
2024-04-28 12:54:07
じろち (jirochi.sz)
@jirochi_sz
#UEOsaka 読みやすさってチームでちゃんと共有しないとずれがちよね、、、プルリクごとやってると大変なので、本読む勉強会とかで共有知としないと、、、
2024-04-28 12:54:22
暇人（ゲームプログラマー）
@hima_zinn
ゲームジャムは……最低限は気をつけつつ、実現重視で絵ベタ書きすることは多々ある。それは仕方ないこと。 #UEOsaka
2024-04-28 12:54:50
暇人（ゲームプログラマー）
@hima_zinn
『AとBは一緒でいいですよね？』って何度も確認して実装したのに、最後の最後で『この場合だけ別処理にしたいです』って言われる事、あるある過ぎて……。 #UEOsaka
2024-04-28 12:56:31
おかず
@pafuhana1213
ベタ書きを減らすために、処理が同じ処理をまとめるのが大事。治す手間が減ったりなどのメリット。処理をコピべしたときに関数化できないかを要検討 コピペしたら検討、は指針が明確で非エンジニアにも分かりやすくていいなぁ #UEOsaka
2024-04-28 12:56:40
M.K
@ryutorion
#UEOsaka 重複をまとめよう ただし，意図せず一緒になっているだけのケースもあり，下手にまとめると，他の修正がしにくくなるケースも どっちにしろまとめる前に関係者とは相談が必要よね
2024-04-28 12:57:05