[협업/Git/Jira 기초] #1 컴공 팀 프로젝트가 처음인 분들께... ❤️Code Convention(프론트 한정)
~제가 작성한 노션을 블로그에도 옮긴 내용입니다!~
목차
- Dart Convention
- UpperCamelCase
- lowerCamelCase
- snake_case
- 언더바('-')
- Lint
flutter로 하실 분들 아니면 여기서 Android라던지, ios라던지 키워드를 달리해서 찾아보시면 될 거 같습니다!
1. Dart Convention
🍎 사용이유: 가독성을 높이고, 서로의 코드를 잘 이해하기 위한 가장 기본적인 언어 규칙입니다.
1-1. UpperCamelCase
- class , enunm type, typedef, type parameter 들 일 경우
class HttpRequest { ... }
typedef Predicate<T> = bool Function(T value);
1-2. lowerCamelCase
- 대부분의 변수, 클래스 멤버, 파라미터 등
var count = 3;
HttpRequest httpRequest;
void align(bool clearItems) {
// ...
}
- 상수
const pi = 3.14;
const defaultTimeout = 1000;
final urlScheme = RegExp('^([a-z]+):');
class Dice {
static final numberGenerator = Random();
}
1-3. snake_case
- 라이브러리, 패키지, 디렉토리, 소스파일, prefix를 사용한 import 등
library peg_parser.source_scanner;
import 'file_system.dart';
import 'slider_menu.dart';
import 'package:angular_components/angular_components.dart' as angular_components;
import 'package:js/js.dart' as js;
1-4. 언더바(’_’)
사용하지 않는 callback parameter는 ‘_’로 표시합니다.
사용하지 않는 callback parameter가 여러개일 경우 충돌을 피하기 위해 __, ___ 사용합니다.
또는 private인 것을 명시할 때 변수명 앞에 '_ ‘를 붙이기도 합니다.
futureOfVoid.then((_) {
print('Operation complete.');
});
final _blackColor = const Color(0xFF1F2123);
2. Lint
🍎 사용이유: 린트(lint) 또는 린터(linter)는 소스 코드를 분석하여 위 컨벤션들을 잘 지켰는지, 프로그램에 오류는 없는지를 자동으로 검사해주는 도구입니다. Lint를 설정을 통해 규칙적인 코딩 스타일을 만들 뿐 아니라 , 런타임 에러를 줄일 수 있습니다.
제가 프로젝트 초기 설정 시 린트를 깔아두겠습니다.
터미널에 아래 명령어를 사용해 규칙을 잘 지켰는지 확인하시고, 린트 테스트를 통과할 때까지 수정하시면 됩니다.
어느 부분에서 어떤 문제가 있는지도 함께 알려주기 때문에 수정이 어렵진 않을 겁니다!
flutter analyze
린트 검사를 깃 액션으로도 걸어둘 것이기 때문에 린트를 까먹고 머지했을 경우도 걱정하지 않으셔도 됩니다.
깃 액션이란, 머지 시에 깃 액션으로 걸어둔 테스트를 통과하지 않으면 머지되지 않는 것을 의미합니다.
함께 읽어보시면 좋을 포스트들입니다.
- 린터 룰들 Linter rules
- [Flutter] Linter: Flutter에서 코드의 스타일을 통일하고, 잠재적인 버그를 찾기 위해 Linter를 설정하는 방법에 대해서 알아봅시다.
- [Github Actions] eslint 통과한 PR만 merge 할 수 있게 해보자.
~아래서부터 주저리~
이런 식으로 맨 처음에는
1. 우리가 사용할 툴이 어느 언어를 사용하는지,
2. 그 언어는 어떤 규칙을 가지고 있는지,
3. 이 언어 규칙을 지키기 위해는 어떤 방법이 있는지
에 대해 안내했다.
이건 플러터면 다트 컨벤션, 안드로이드면 코틀린 컨벤션 이런 식으로 검색해서 다른 식으로 변형/응용도 가능하다.
꼭 공식 문서에서 확인하는 게 좋다.
나는 팀원들이 이 문서 내용을 빨리 숙지하는 게 중요해서 영어 원문으로 된 금같은 블로그들을 최대한 제외했는데, 이 부분이 꽤나 아쉽다...
영어 문서 중에 제대로 된 게 진자진자 많거든.
암튼 공식 문서나, 한국어 글 중 설명이 괜찮은 글을 링크로 남겨놔서 추가로 더 공부할 수 있게 했는데...
울 팀원들은 봤으려나 이 링크들,,,?
나중에 물어봐야지,,,
아 그리고 각 큰 타이틀마다 이거를 왜 사용하는지에 대해서도 꼭 덧붙였다.
내가 프론트 리더라는 이유로
"님들 다 필요없고 이게 좋으니까 이거 쓰삼요 ㅇㅇ"하고 "그냥"이라는 이유로 이 규칙들을 지켜달라고 말하고 싶지 않았기 때문에...
글고 혹시나 내가 이런 이유로 이걸 쓰고자함을 알면
"아 그런 거라면 이거도 있는데 혹시 이거는 어때요? 써보셨나요?"라는 피드백을 받을 수 있을 거 같기도 해서,,,ㅇㅇㅇㅇ
또 나도 프론트 처음에는 이런 게 왜 필요한지 몰랐으니까...