[Process] 코딩 컨벤션 정하자!

[SoinDosa]

내가 생각했을 때 분리해야 하는 건...
네이밍규칙, 괄호 들여쓰기 정도면 될 것 같음

Common 규칙

• 불필요한 using은 전부 삭제
• 조건문이나 반복문 짧다고 바로 붙여쓰지 말기
  • 예시)

  if (true) Console.log("true!");
  // Fuck
  
  if (true)
      Console.log("true!");
  // Good

  • 사실 한 줄짜리여도 괄호로 분리해야 가독성이 좋다라는 말이 있긴 한데 투머치지 않을까 싶음
• 수식과 수학 연산자(+, -, *, / 등...)은 모두 띄어쓰기
• 행바꿈 두 줄 이상 하지 않기

네임스페이스

• namespace NHD.[directory path]
  이건 저번 회의때 정했으니까 알것이구

네이밍

• 클래스 : 파스칼 표기법(첫 글자는 대문자, 이후는 카멜표기법과 같음)
• 메서드 : 파스칼 표기법
• 클래스 프로퍼티 변수 : 카멜 표기법(첫 글자가 소문자)
  • 현재 우리 프로젝트는 프로퍼티 변수와 메서드 변수를 딱히 구분짓는 네이밍을 하지 않는데 회사에서는 언더바를 앞에 붙여서 구분했음. 이거 싹다 바꾸려면 코스트 클텐데 그냥 냅둘까? 고민 중
• 메서드 변수 : 카멜 표기법
• 상수 : 대문자 스네이크 표기법(언더바로 구분하는거)
• 외부 데이터(JSON으로 불러오는 값처럼) : 소문자 스네이크 표기법

읽어보고 수정하고 싶거나 이거 현실적으로 힘들 것 같다! 싶으면 댓글 달아주셈

[HUSK-321]

맛있네요 이대로 하면 좋을거 같습니다. 고정해두죠

[SoinDosa]

맛있네요 이대로 하면 좋을거 같습니다. 고정해두죠

클래스 프로퍼티 변수같은 경우에는 어떡할까, 냅둘까? 아니면 언더바같은 기호 붙여서 구분할까?

[HUSK-321]

맛있네요 이대로 하면 좋을거 같습니다. 고정해두죠

클래스 프로퍼티 변수같은 경우에는 어떡할까, 냅둘까? 아니면 언더바같은 기호 붙여서 구분할까?

아무래도 파라미터랑 겹치는 경우가 있으니 언더바 추가 어떨까?

[SoinDosa]

오케 그럼 비주얼스튜디오 기능써서 프로퍼티 변수에는 다 언더바 추가해둘게 ㄱㅊ?

[HUSK-321]

오케이 비주얼 믿고 있겠삼

[SoinDosa]

ㅇㅋㅇㅋ 이거하면서 씬도 좀 분리하려는데 어케하면될까

[HUSK-321]

ㅇㅋㅇㅋ 이거하면서 씬도 좀 분리하려는데 어케하면될까

내가 가지고 있는 씬은 dev_husk가 개잘 집합 느낌이고 나머지는 서버용 씬인데 기획ㅌ 아트 씬은 건드리지 않고 추가만 하면 될듯? 일단 내씬에서 지울건 없음

[SoinDosa]

ㅇㅋㅇㅋ 일단 프로퍼티변수에 언더바 다 붙이고 커밋한 다음 씬분리해보곘음

[HUSK-321]

ㅇㅋㅇㅋ 일단 프로퍼티변수에 언더바 다 붙이고 커밋한 다음 씬분리해보곘음

여기서 씬 분리란 어떤 뜻인가요

[SoinDosa]

씬분리는 폴더분리를 하겠단 의미입니다

그리고 코딩 규칙은 찾아보니 C#에 통용되는 규칙들이 꽤나 많아서
https://learn.microsoft.com/ko-kr/dotnet/csharp/fundamentals/coding-style/coding-conventions
https://gall.dcinside.com/mgallery/board/view/?id=game_dev&no=78528
등 좀더 알아보고 수정할때 말해주겠음

[HUSK-321]

씬분리는 폴더분리를 하겠단 의미입니다

그리고 코딩 규칙은 찾아보니 C#에 통용되는 규칙들이 꽤나 많아서 https://learn.microsoft.com/ko-kr/dotnet/csharp/fundamentals/coding-style/coding-conventions https://gall.dcinside.com/mgallery/board/view/?id=game_dev&no=78528 등 좀더 알아보고 수정할때 말해주겠음

인터페이스 I 붙이는거 같은건 완전 필수라고 생각하긴 함. 폴더 분리는 일단 확인했고 이후에 다 되면 여기로 코멘트 날리면 될듯.

너 정리 다 끝나는 대로 핑 시스템 맞춰서 개발 들어갈 예정

[SoinDosa]

현재 작업내용

• 모든 클래스 필드 변수에 _ 추가
  • 내가 프로퍼티 변수라고 잘못 말함. 클래스가 가지고 있는 변수는 필드 변수가 맞는 표현임
• Action에는 _추가 안함, 보니까 파스칼, 카멜 표기법 혼용된거 많음
  • (결정 해야됨)Action 네이밍
  • 카멜(소문자 시작) 표기법? 파스칼(대문자 시작) 표기법?
  • 인터넷에 선호되는 컨벤션을 찾아보니 보통 파스칼표기법 쓰는 듯 함
  • https://github.com/ktaranov/naming-convention/blob/master/C%23%20Coding%20Standards%20and%20Naming%20Conventions.md

[SoinDosa]

추가) 함수 매개변수에 _ 있는거 다 지웠음

[HUSK-321]

현재 작업내용

• 모든 클래스 필드 변수에 _ 추가

  • 내가 프로퍼티 변수라고 잘못 말함. 클래스가 가지고 있는 변수는 필드 변수가 맞는 표현임

• Action에는 _추가 안함, 보니까 파스칼, 카멜 표기법 혼용된거 많음

  • (결정 해야됨)Action 네이밍
  • 카멜(소문자 시작) 표기법? 파스칼(대문자 시작) 표기법?
  • 인터넷에 선호되는 컨벤션을 찾아보니 보통 파스칼표기법 쓰는 듯 함
  • https://github.com/ktaranov/naming-convention/blob/master/C%23%20Coding%20Standards%20and%20Naming%20Conventions.md

그러면 클래스 변수는 전부 _ 붙이는걸로 이해하고
이벤트, 델리게이트 같은 경우 일단 델리게이트는 타입을 선언하는거니 클래스 선언과 동일하게 가져간다고 보고 이벤트도 이에 따라서 파스칼 표기법으로 가고 끝에 event 붙이는걸로?

[SoinDosa]

오케이 그렇게 하겠음 씬분리는 좀더 개발된 후에 나중에 하는게 맞는게 같아서 커밋하면 말할테니 그때 포크합시다

[HUSK-321]

오케이 그렇게 하겠음 씬분리는 좀더 개발된 후에 나중에 하는게 맞는게 같아서 커밋하면 말할테니 그때 포크합시다

오케이, 확인완료. 고생 많았구만

[SoinDosa]

비상사태, 변수 네이밍 바꾸니까 인스펙터에 오브젝트 할당된거 다 떨어져나감
존나 오래걸릴것같은데 이거
아직 커밋은 안해놔서 원상복구시키긴했는데 멘탈나가네

[HUSK-321]

비상사태, 변수 네이밍 바꾸니까 인스펙터에 오브젝트 할당된거 다 떨어져나감 존나 오래걸릴것같은데 이거 아직 커밋은 안해놔서 원상복구시키긴했는데 멘탈나가네

아 이건 좀 큰데. 최근 서버 연동하면서 find로 할당하던거 바뀐게 많아서 더 타격 클거 같은데.
일단 변수는 하나하나 이후에 바꾸는거로 하는게 어떨까. 코드 리팩토링 하면서 천천히.

그리고 추가로 알아낸건데 Gitify라는거 사용하면 깃허브 알림 받을 수 있는듯? 그래서 일단 링크 남겨둠

Gitify

[SoinDosa]

변수 네이밍은 포크하고 개발하면서 각자 바꿔나가는 식으로 합시다... 그래야할 듯
https://blog.naver.com/PostView.naver?blogId=dlakek&logNo=220836589009 이 방법 써서 하면 되긴하는데 시간이 오래 소요되서 오늘 하루에 끝내는 걸로 잡을 순 없을 듯

[HUSK-321]

변수 네이밍은 포크하고 개발하면서 각자 바꿔나가는 식으로 합시다... 그래야할 듯 https://blog.naver.com/PostView.naver?blogId=dlakek&logNo=220836589009 이 방법 써서 하면 되긴하는데 시간이 오래 소요되서 오늘 하루에 끝내는 걸로 잡을 순 없을 듯

일단 수작업은 아니니깐 만족하는걸로 하고 그러면 추가 작업은 없는건가?

[SoinDosa]

yes 이제 포크하고 개별작업합시다

[HUSK-321]

고생했구만 그럼 이번 이슈는 일단 닫아두는걸로?

[HUSK-321]

아 추가 질문이라면 fork 많이 안써봐서 그런데 기능 하나당 fork 해서 개발하고 다음 개발떄 다시 fork 하는건가?

[SoinDosa]

ㄴㄴㄴ 포크한거 그냥 냅두고 기능 개발할 때마다 여기에 Pull request 하면 됨
그리고 내가 신규 기능 개발해서 Pull request해서 업데이트 되면 너꺼 레포지토리에서 fetch 최신화 시켜주면 내거 반영 돼

[HUSK-321]

ㄴㄴㄴ 포크한거 그냥 냅두고 기능 개발할 때마다 여기에 Pull request 하면 됨 그리고 내가 신규 기능 개발해서 Pull request해서 업데이트 되면 너꺼 레포지토리에서 fetch 최신화 시켜주면 내거 반영 돼

오카이 완벽 이해 완료