Effective Dart | Style 편

요즘 대학 동기와 사이드 프로젝트로 Dart & Flutter 를 이용하여 앱을 만들고 있다. 원래 내가 앱을 만들 때 쓰는 언어는 React Native 인데 동기의 추천으로 Dart 를 이용하기로 하였다. 나중에 이 앱을 만들 때 겪었던 삽질, 이해한 부분들을 올릴 것이다.

🤨 Effective Dart?

앱을 개발하면서 PR 을 보내면 동기가 Dart 공식 홈페이지의 효율적으로 코드 짜는 법을 보내주면서 PR 을 request changes 할 때가 있다. 이런 부분이 너무 좋은 게 코드를 짜면서 효율적으로 짜고 싶었는데 맨날 나의 귀차니즘으로 넘길 때가 있었기 때문이다. 그래서 이번 기회에 공식 홈페이지에 있는 글을 공부하여 여기에 남기기로 하였다. 이번 편은 코드의 전반적인 Style 편이다.

A surprisingly important part of good code is good style. Consistent naming, ordering, and formatting helps code that is the same look the same. It takes advantage of the powerful pattern-matching hardware most of us have in our ocular systems. If we use a consistent style across the entire Dart ecosystem, it makes it easier for all of us to learn from and contribute to each others’ code.

일관적인 코드 스타일이 도움이 된다는 내용이다. 세부적으로 알아보자!

✔ DO name types using UpperCamelCase

클래스, 열거 타입, typedef, 타입 매개변수 들은 첫번째 글자를 대문자로 쓰는 UpperCamelCase 를 적용해야 한다.

good

class SliderMenu { ... }
class HttpRequest { ... }
typedef Predicate<T> = bool Function(T value);

또한 메타데이터 어노테이션으로 사용하려고 하는 클래스도 해당한다.

good

class Foo {
  const Foo([Object? arg]);
}

@Foo(anArg)
class A { ... }
@Foo()
class B { ... }

만약 어노테이션 클래스의 생성자가 아무 매개변수도 받지 않는다면 분리된 lowerCamelCase 상수를 적용시키자.

good

const foo = Foo();

@foo
class C { ... }

✔ DO name libraries, packages, directories, and source files using lowercase_with_underscores.

몇몇 파일 시스템들은 파일명에 관해 그렇게 민감하지 않아 많은 프로젝트 파일들이 lowercase 들로 이루어져 있다. Dart 에서는 _ 를 이용하여 읽기 쉽게 구분한다.

good

library peg_parser.source_scanner;

import 'file_system.dart';
import 'slider_menu.dart';

bad

library pegparser.SourceScanner;

import 'file-system.dart';
import 'SliderMenu.dart';

✔ DO name import prefixes using lowercase_with_underscores.

내부 고정 라이브러리들은 lowercase_with_underscores 를 적용하지 않는다.

good

import 'dart:math' as math;
import 'package:angular_components/angular_components'
    as angular_components;
import 'package:js/js.dart' as js;

bad

import 'dart:math' as Math;
import 'package:angular_components/angular_components'
    as angularComponents;
import 'package:js/js.dart' as JS;

✔ DO name other identifiers using lowerCamelCase.

다른 식별자들은 lowerCamelCase 를 적용한다. 클래스 멤버, 상위 선언문, 변수 등은 구분 문자 없이 lowerCamelCase 를 사용한다.

good

var count = 3;

HttpRequest httpRequest;

void align(bool clearItems) {
  // ...
}

✔ PREFER using lowerCamelCase for constant names.

상수 변수(열거형 변수도 포함) 들은 lowerCamelCase 로 쓰는 것을 지향하자.

good

const pi = 3.14;
const defaultTimeout = 1000;
final urlScheme = RegExp('^([a-z]+):');

class Dice {
  static final numberGenerator = Random();
}

bad

const PI = 3.14;
const DefaultTimeout = 1000;
final URL_SCHEME = RegExp('^([a-z]+):');

class Dice {
  static final NUMBER_GENERATOR = Random();
}

🙄 하지만 SCREAMING_CAPS(전부 다 대문자)도 사용해야 될 때도 있다.

• 파일이나 라이브러리 코드를 추가할 때 이미 SCREAMING_CAPS 를 쓰고 있는 경우
• 다트 코드를 만들 때 Java 코드와 병행해야 될 때

✔ DO capitalize acronyms and abbreviations longer than two letters like words.

두 글자보다 긴 acronyms 와 abbreviations 는 대문자로 쓰자. 대문자로 되있는 acronyms 은 읽기 힘들 수도 있고 다중의 인접한 acronyms 은 모호한 이름으로 읽힐 수도 있다. 이러한 점들을 피하기 위해 acronyms 과 abbreviations 들은 평범한 단어와 같이 대문자로 표시한다.

• Exception : 두 글자 acronyms, 예를 들면 IO(input/output) 같은 경우는 모두 대문자로 표시한다. 반면에 두 글자 abbreviations, 예를 들면 ID(identification) 은 여전히 Id 로 표시한다.

good

class HttpConnection {}
class DBIOPort {}
class TVVcr {}
class MrRogers {}

var httpRequest = ...
var uiHandler = ...
Id id;

bad

class HTTPConnection {}
class DbIoPort {}
class TvVcr {}
class MRRogers {}

var hTTPRequest = ...
var uIHandler = ...
ID iD;

✔ PREFER using _, __, etc. for unused callback parameters.

콜백 함수에서 안 쓰는 매개변수를 쓸 때는 _ 을 쓰는게 관용적이다. 만약 안 쓰는 매개변수가 많다면 변수 충돌을 피하기 위해 __, ___ 등을 쓰자.

good

futureOfVoid.then((_) {
  print('Operation complete.');
});

⚠ 주의점!

이 지침은 익명 함수와 지역 함수에 대해서만 적용된다. 이러한 함수들은 일반적으로 사용되지 않은 매개변수가 나타내는 것이 분명한 컨텍스트에서 즉시 사용된다. 반대로 최상위 함수 및 메서드 선언에는 해당 컨텍스트가 없으므로 사용하지 않더라도 각 매개 변수의 용도가 명확하도록 매개 변수의 이름을 지정해야 한다

지금까지 Style 편의 식별자들에 대해 어떻게 코드를 작성해야 할지 배웠다. 다음편에는 주석을 문서화하기 위해 어떻게 작성해야 하는지 포스팅하겠다. 그럼 20000