기억해둘 플러터(Flutter) 코드 작성 규칙

프로그래밍 언어마다 공식적으로 권장하는 코딩 컨벤션이 조금씩 다릅니다. 특정 언어에서 다른 언어로 마이그레이션 할 때는 새로운 언어의 코딩 컨벤션에 맞게 코딩 스타일을 적용해주는 게 좋습니다. Java Script는 Java Script답게, Python은 Python답게, 플러터는 플러터답게 코딩하는 방식을 의미합니다. 그렇다면 플러터다운 코딩 방식은 어떤 걸까요? Dart에서 제공하는 Linter rules에서 주요 사항 몇 가지를 살펴보겠습니다.

패키지 임포트할 때 상대 경로 대신 절대 경로 쓰기 (always_use_package_imports)

Good	Bad
import 'package:firebase_auth/firebase_auth.dart';  import 'package:insta_clone/create_page.dart'; import 'package:insta_clone/model/page.dart';	import 'package:firebase_auth/firebase_auth.dart';  import 'create_page.dart'; import '../model/page.dart';

파일 임포트 시에 상대 경로보다는 해당 파일이 속한 패키지의 전체 경로를 써서 import 하길 권장합니다. 

제품 모드에서 print문 쓰지 않기 (avoid_print)

프로덕션 (혹은 상용 혹은 운영) 환경에서 자주 호출되는 API에 print문을 넣었다가 문제가 생기는 경우가 종종 있습니다. 퍼포먼스를 느리게 만드는 주범이죠. 플러터에서도 프로덕션 환경에서 print 문을 쓰지 않길 권고하고 있습니다. 보통 프로덕션 환경에서는 로거를 통해 로그 수준을 제어하기 때문에 print문은 개발 환경에서만 쓰는 게 좋겠죠. 이 때는 kDebugMode인지를 체크하도록 권장하고 있습니다.

TODO에 Github 이름 남기기 (flutter_style_todos)

// TODO(username): message.
// TODO(username): message, https://URL-to-issue

코드를 작성하다가 나중에 해야 할 일을 남길 때 코멘트로 TODO를 남기곤 합니다. 플러터에서는 이 TODO 코멘트에 문제를 이해하고 있는 사람의 Github 사용자 이름을 남기길 권장하고 있습니다. 이렇게 관리한다면 아무래도 협업할 때 히스토리를 파악하기 더 쉬워지겠죠?

항상 리턴 타입 선언하기 (always_declare_return_types)

Good	Bad
void main() { }  _Foo _bar() => _Foo(); class _Foo { int _foo() => 42; } typedef predicate = bool Function(Object o);	main() { } _bar() => _Foo(); class _Foo { _foo() => 42; }

리턴 타입을 명시적으로 적어주지 않으면 복잡한 함수의 경우 어떤 값이 리턴되는지 확인하기 어려울 때가 있습니다. 이 값을 제대로 모른 상태에서 함수를 가져다 쓰다 보면 예상하지 못했던 버그들이 나올 수도 있겠죠. 플러터에서는 이런 상황을 방지하기 위해 리턴 타입을 선언하도록 권장하고 있습니다. 플러터뿐만 아니라 리턴값을 명시적으로 선언하지 않아도 되는 파이썬 등과 같은 언어에서도 적용하면 좋을 규칙입니다.

 

더 읽어보기 👉

https://dart.dev/guides/language/effective-dart/style

https://dart.dev/tools/linter-rules