Objective - C 의 우아 한 이름

이 글 은 다음 에 전 재 됩 니 다:http://blog.xcodev.com/archives/objective-c-naming/
비고: 명명 규범 은 Effective Objective - C 2.0 이라는 책 도 참고 할 수 있 습 니 다.
There are only two hard things in Computer Science: cache > invalidation and naming things. 컴퓨터 과학 에 서 는 두 가지 어 려 운 일이 있 습 니 다. > 캐 시 실효 와 이름 -Phil Karlton
컴퓨터 언어 는 사람과 컴퓨터 간 의 통신 의 매개체 이다.좋 은 코드 는 사람 이 컴퓨터 에 말 하 는 것 처럼 자 연 스 럽 고 우아 해 야 한다.이름 을 짓 는 것 은 보기 에는 매우 간단 한 일이 지만, 흔히 간단 한 일 일수 록 잘 하기 어렵다. 그렇지 않 으 면 대사 들 도 이름 을 컴퓨터 계 의 어 려 운 문제 로 보지 않 을 것 이다.어떻게 Objective - C 라 는 컴퓨터 언어 를 우아 한 방식 으로 말 하 는 지, 아니면 엔지니어 가 그것 에 대한 이해 의 깊이 를 비교적 시험 하 는 것 입 니까?애플 의 SDK 에는 대량의 API 가 있 는데, 우 리 는 이러한 API 에서 이름 을 가 진 예술 을 체험 할 수 있다.
줄 임 말 감소

줄 임 말 은 URL

과 같은 일반적인 전문 용어 에 만 사 용 됩 니 다.

Ctr, Msg

와 같은 이름 의 줄 임 말 을 만 들 수 없습니다.

이름 이 길 어 질 지 언 정 이해 하기 어렵 지 않다.

다른 사람의 코드 를 볼 때 각종 줄 임 말 을 몰라 서 그런 가?짧 은 이름 이 좋 긴 하지만 줄 임 말 을 남용 해 가 독성 을 잃 어 서 는 안 된다.
프로 세 스 화

동작 이 일어나 기 전에 Will

발생 후 Did

사용 여 부 를 묻는다. 해 야 한다

모든 처 리 는 일정한 과정 이 있 습 니 다. 이 처 리 는 알림 과 반전 이 발생 할 수 있 습 니 다. 좋 은 이름 은 현재 과정 에서 의 절 차 를 명 확 히 해 야 합 니 다.이 알림 과 리 셋 이름 을 지 을 때 는 발생 전후 두 가지 버 전 을 제공 하 는 것 이 좋 습 니 다. 발생 하기 전에 리 셋 을 확인 하려 면 이 리 셋 이름 을 사용 하고 BOOL 값 을 되 돌려 주 십시오.
이름 공간
각종 전역 작용 범위 의 함수, 상수, 클래스, 매 거, 구조 등 명칭 은 반드시 명칭 접 두 사 를 붙 여야 한다.Objective - C 에는 C + + 와 같은 이름 공간 개념 도 없고 자바 패키지 이름 개념 도 없 으 며, 프로젝트 코드 가 증가 함 에 따라 이름 충돌 이 불가피 하기 때문에 전역 적 역할 범위 의 이름 이 유일 해 야 합 니 다.비교적 고전적 인 방법 은 이름 접 두 사 를 붙 이 는 것 이다.대부분의 사람들 은 이름 접 두 사 는 클래스 앞 에 대문자 몇 개 를 붙 이 는 것 이 라 고 생각 하지만 사실은 그렇지 않다.

유형 (클래스, 매 거, 구조) 이름 을 짓 기 전에 관련 모듈 접 두 사 를 추가 해 야 합 니 다.UIViewNSStringCGRect

상수 이름 은 관련 유형 이름 접 두 사 를 추가 해 야 합 니 다.UIApplicationDidFinishLaunchingNotificationCGRectZero

함수 이름 은 관련 유형 이름 접 두 사 를 추가 해 야 합 니 다.CGRectMakeCGPointMake

매 거 진 형식 이름 은 관련 유형 접 두 사 를 추가 하고 매 거 진 값 이름 은 매 거 진 형식 접 두 사 를 추가 해 야 합 니 다.

typedef NS_ENUM(NSInteger, UIViewAnimationTransition) {  
      UIViewAnimationTransitionNone,
      UIViewAnimationTransitionFlipFromLeft,
      UIViewAnimationTransitionFlipFromRight,
      UIViewAnimationTransitionCurlUp,
      UIViewAnimationTransitionCurlDown,
};

위 와 같은 몇 가 지 를 하면 이름 이 충돌 하지 않 을 정도 로 할 수 있다.
매개 변수 알림
방법 이름 을 지 을 때 매개 변수 앞 에 매개 변수의 이름 알림 을 추가 해 야 합 니 다.

- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil
- (void)performSegueWithIdentifier:(NSString *)identifier sender:(id)sender

대상 이름
수식 이 있 는 대상 에 게 이름 을 붙 일 때 는 형식 을 먼저 지정 하 는 것 이 아니 라 수식 + 형식 을 사용 해 야 합 니 다.많은 사람들 이 대상 의 유형 을 대상 의 이름 앞 에 놓 고 대상 이 어떤 유형 인지 표시 하 는 것 을 좋아한다. 이것 은 Objective - C 언어의 특징 에 부합 되 지 않 고 다른 의 미 를 일 으 키 기 쉽다. 예 를 들 어 UILabel 대상:

titleLabel //     label， UIlabel  
labelTitle //label   ？     NSString？

confirmButton //    
buttonConfirm //      ，           。

방법 이름 맞 춤 법
대부분의 방법 은 아래 두 가지 로 나 눌 수 있 는데, 이 두 가 지 는 종종 남용 된다.그것들 은:
뭐 공부 해요?
'무엇 을 원 하 는가' 는 어떤 대상 을 얻 으 려 면 명 사 를 방법의 시작 으로 해 야 한 다 는 것 을 나타 낸다.'무엇 을 하 느 냐' 는 어떤 조작 을 집행 하 는 것 을 나타 내 고 동 사 를 방법 으로 시작 해 야 한다.아래 의 이 명명 방식 을 보십시오.

- (XXItem *)itemNamed:(NSString *)name //Good.     
- (XXItem *)findItemWithName:(NSString *)name //       ，         。

findItemWithName 이 이름 은 대상 을 되 돌려 주지 않 고 작업 을 표시 합 니 다. 예 를 들 어 설정 류 의 내부 구성원 에 사용 할 수 있 습 니 다. 예 를 들 어:- (void)findItemWithName:(NSString *)name{ ... self.foundItem = xxx; ... }
get
'무엇 을 원 하 느 냐' 는 종종 get 으로 시작 하 는 방법 이 라 고 함부로 명명 된다.먼저 get 은 동사 이기 때문에 '무엇 을 하 느 냐' 거나 '무엇 을 하 느 냐' 고 말한다.그러면 get 방법 은 대상 을 되 돌려 주 는 데 사용 되 지 않 지만 매개 변수 에서 되 돌려 주 는 데 사용 할 수 있 습 니 다.

- (XXItem *)getItemAtIndex:(NSUInteger)index //Bad!!       
- (XXItem *)itemAtIndex:(NSUInteger)index //Good,     
- (void)getItem:(XXItem **)outItem atIndex:(NSUInteger)index //      ，      。

인지 성
호출 할 때 호출 자 는 호출 방법 에서 첫 번 째 매개 변수 에 호출 자 를 추가 할 수 있다 는 것 을 알 아야 합 니 다.

- (BOOL)application:(UIApplication *)application willFinishLaunchingWithOptions:(NSDictionary *)launchOptions
- (void)buttonTapped:(UIButton*)sender

상수
전역 상수 에서 매크로 정 의 를 사용 할 수 없습니다. 매크로 로 정 의 된 알림, 키워드 등 을 자주 볼 수 있 습 니 다.사실 이렇게 하 는 것 은 매우 위험 합 니 다. 매크로 는 다시 정 의 될 수 있 고 서로 다른 파일 을 인용 하면 매크로 가 다 를 수 있 기 때문에 가능 한 한 const 를 사용 하여 상수 를 정의 합 니 다.
약간의 사고.
명명 의 좋 고 나 쁨 은 개발 에서 도 그다지 중시 하지 않 는 다. 왜냐하면 나 쁜 명명 도 프로그램 논리 에 영향 을 주지 않 기 때문이다.그러나 좋 지 않 은 이름 이 큰 프로젝트 에서 가 져 온 스텔스 유지 비용 은 상당히 높다. 이런 것들 은 프로젝트 를 시작 할 때 눈치 채 기 어 려 울 수도 있 고 나중에 앞 뒤 가 이어지는 유지 보수 곤경 에 빠 질 수도 있다.우 리 는 종종 프로젝트 논리의 복잡성 을 매우 중시 하지만 '간단 하 다' 는 이름 을 잘 지 을 수 없다.사실 간단 한 것 도 못 하면 아무리 복잡 한 것 을 만들어 도 쓰레기 다.