Analysis Engine - 3. Coding Conventions

[ansrlm]

목표

• 코딩 컨벤션을 협의합니다.
• directory 구조 및 file naming과 같은 부분을 포함합니다.

참고사항

• 코멘트로 밴치마킹하면 좋을 레포지토리 혹은 제안하고 싶은 코딩 컨벤션에 대해서 공유 부탁드립니다.

[ansrlm]

• 변수 네이밍
  • https://www.oreilly.com/library/view/code-complete-2nd/0735619670/ 11장
  • https://wikidocs.net/32376
• myDataList vs myData
• Dart의 코딩 컨벤션
  • https://points.tistory.com/80

[anpaul0615]

file naming 관련 참고했었던 자료 공유드립니다.
주로 nestjs 를 사용하다보니, 성향이 이쪽으로 치우쳐져 있는 점 고려하시고 읽어주시면 좋겠습니다 ㅎㅎ

• https://narhakobyan.github.io/awesome-nest-boilerplate/docs/naming-cheatsheet.html
• https://stackoverflow.com/questions/61666498/file-naming-in-nest-js

[anpaul0615]

여기에 더해서 지난 PR에서 찾은 문기님 코멘트도 덧붙입니다. (개인적으로 매우 좋은 참고가 됐습니다ㅎㅎ)

링크: githru/githru-boot#30 (comment)

1.말씀 주신 부분처럼 파일을 찾는 행위에 도움이 됩니다.

2.대부분의 경우 fila path를 통해서 어떤 파일행위를 할 것인지 유추가 가능합니다. import {time} from "utils/time"
그러나 특정 이유(기능 단위의 파일 관리적 측면을 한다거나,,,)로 인해서 디렉토리가 정확히 분리되어 있지 않은 경우가 발생하거나 디렉토리 내부에서 상대경로로 접근하는 경우는 file path를 통해서 유추하기가 어렵습니다.

이러한 경우를 위해서 filename.desc.ts 와 같은 패턴을 사용하고 있습니다.
사실 이러한 습관(?)은 Angular에서 지향하는 패턴과의 중간 영역에 놓여 있습니다.
Angular는 더 나아가서 기능 단위의 파일 디렉토리를 하기보다는 영역 단위의 파일 디렉토리 구성을 지향하는 것 같습니다. (/utils/ 보다는 /octokits/ 를 선호)

3.파일 테스트 커버리지를 다르게 적용할 수 있습니다. 이부분도 가정이지만, 기능 단위의 디렉토리 구조를 강하게 구성하고 있다면 pattern matching을 잘 사용하면 utils와 services에 대한 테스트 커버리지를 다르게 설정할 수 있습니다. 그러나 테스트파일들의 구성 구조가 레포 전반에 대해서 scatter 정도가 높다면, 중간에 네이밍을 넣는 것으로 **.util.spec.**와 같이 기능 단위에 대한 실행을 가능하게 할 수 있습니다.

FYI
https://v2.angular.io/docs/ts/latest/guide/style-guide.html#!#02-01

[ansrlm]

• 많이 쓰이는 함수성 모듈 레포
  • https://github.com/remarkablemark/html-react-parser
  • https://github.com/socketio/socket.io
• 총평
  • 천차만별(?)인 듯 합니다. (lib 하위에 파일들을 떄려박는 방식이 많네요)
  • annotation만 사용하는 것을 습관으로?
  • 디렉토리 구조는 진행하면서 PR에서 논의하는 방식은 어떨지?

[ooooorobo]

코딩 컨벤션 - https://github.com/airbnb/javascript#the-javascript-style-guide-guide 을 따르고 PR에서 그때그때 논의
디렉토리 구조 - 일단은 src 폴더 하위에 1뎁스로 관리

[blcklamb]

디렉토리 구조가 구체적으로 어떻게 되는지 궁금합니다.

아래와 같이 여러 파일들을 구성해도 괜찮은걸까요?

src - /__test__/
      - parseIndex.ts
      - parseLog.ts
      - parseSpawn.ts
      - ...

아니면 feature 하나당 파일 하나로만 구성되어야 하나요?

src - /__test__/
      - commitList.ts
      - DAG.ts
      - STEM.ts
      - CSM.ts

[anpaul0615]

오 여기서 디스커션이 계속 진행되는줄 몰랐습니다 ㅎㅎㅎ

일단 저희가 회의에서 이야기한 내용은 1depth 에 다 몰아넣자(?) 고 얘기된 것 같은데요.
그리니 다음 미팅때까지는 우선 얘기된대로 진행하셔도 될 것 같습니다.

src/
  parseIndex.ts
  parseLog.ts
  parseSpawn.ts
  ...
  XXX.d.ts
  ...

아마 작업 진행되면서 분명 파일 구분이 필요해지게될테니,
미팅에서 같이 논의하면서 바로 파일정리 해버리면 될것같아요ㅎㅎ

[anpaul0615]

테스트 코드 같은 경우도 동일한 논리로 XXX.spec.ts 형태로 같이 src 안에 위치시켜도 될 것 같아요.
이것도 src/__test__ 로 묶을지, src/ 와 같은 위상으로 test/ 로 구분할지 등등 나중에 같이 얘기해서 정해질 것 같아요~!

[ansrlm]

헉... 이런 말씀들이 있으셨군요.
머지전에 봤으면 토의 후에 반영할 것을 그랬습니다.
현 상황은 @anpaul0615 님 말씀주신 부분처럼 src/*.spec.ts 로 구성되어 있습니다.
변경이 필요하다면 해당 부분은 설정과 빌드 스크립트 변경이 어렵지 않으니 자유롭게 진행하면 좋을 것 같습니다~