iDrogba

예제 코드 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 import SwiftUI struct ContentView: View { var body: some View { VStack{ Text("Main Title!") .font(.largeTitle) .foregroundColor(.black) .bold() .padding(.bottom, 20) // 일반 스타일 Text("Sub Title!") .modifier(textSty..

예제 코드 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 import SwiftUI struct Animal: Identifiable{ let id = UUID() let name: String let index: Int } struct ContentView: View { var animalList = [ Animal(name: "dog", index: 3), Animal(name: "dog", index: 1), Animal(name: "do..

4장 주석 - 부정확한 주석은 아예 없는 주석보다 훨씬 더 나쁘다. - 주석을 유지 보수하기란 현실적으로 어렵기에 시간이 지날수록 완전히 그릇될 가능성이 높다. 잘못된 정보를 전달하는 주석이 되는것이다. - 코드만이 자기가 하는 일을 진실되게 말한다. 코드만이 정확한 정보를 제공하는 유일한 출처다. - 그러므로 우리는 간혹 필요한 예외적인 상황을 제외하곤 주석을 줄이도록 노력해야 한다. 주석은 나쁜 코드를 보완하지 못한다. 코드로 의도를 표현하라! - 코드에 주석을 다는 이유?? 코드 품질이 나쁘니까. - 주석 달 시간에 코드를 고쳐! - 많은 경우 주석으로 달려는 설명을 함수로 만들어 표현해도 충분하다. 좋은 주석 - 법적인 주석 - 정보를 제공하는 주석 - 의도를 설명하는 주석 - 의미를 명료하게 밝..

3장 함수 의도를 분명히 표현하는 함수가 목표 * 작게 만들어라! - 함수가 후술할 원칙들을 만족하는 선에서 최대한 작게 만드는게 좋다. - 블록과 들여쓰기 if문/else문/while문에 들어가는 블록은 한줄이어야 한다. 대개 그 한줄에서 함수를 호출한다. 이로써 해당 함수 자체가 작아지고 함수에 중첩 구조가 생길만큼 커지는 것을 방지할 수 있다. 들여쓰기 수준은 1단 혹은 2단을 넘어서면 안 된다. * 한 가지만 해라! - 함수는 한가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. - 한가지 작업만 수행하는 함수 판별법 지정된 함수 이름 아래에서 추상화 수준이 하나인 단계들만 수행하는지? ( 함수는 점점 세부적인 깊이에서 여러번의 작업을 하는 방향으로 분화됨. 여기서 세부..

2장 의미 있는 이름 * 의도가 분명한 이름 - 변수, 함수, 클래스 등의 이름은 존재 이유, 수행 기능, 사용 방법 등의 의도를 알 수 있게 지어야한다. ex) 1 int d; // 경과 시간(단위 : 날짜) cs 의도를 전혀 드러내지 못하는 이름 1 2 3 4 5 6 7 int elapsedTimeInDays; int daysSinceCreation; int daysSinceModification; int fileAgeInDays; cs 의도가 충분히 드러나는 이름 * 그릇된 정보를 피하라 - 코드에 남겨진 잘못된 단서는 코드 의미를 흐린다. - ex) 배열로 구현된 그룹을 accountList로 이름 짓는 경우. 단순히 Accounts로 명명하는게 옳음. - 서로 흡사한 이름은 피한다. - 유사한 ..

* 코드는 요구사항을 상세히 표현하는 수단이다. * 나쁜 코드는 나쁜 코드를 낳는다. 이 악순환이 계속될수록 생산성은 떨어지고 마침내 0에 수렴한다. * 코드의 품질은 프로그래머의 첫번째 책임이다. - 기한과 요구사항에 쫓겨 겨우 돌아가기만 하는 코드를 짜는 것은 결국엔 더 큰 작업부하로 이어진다. * 깨끗한 코드 - 누가 읽더라도 읽기에 편한 코드 (ex.가독성). - 추측이 아닌 사실에 기반하여 반드시 필요한 내용만 담는 코드. - 세세한 사항까지 꼼꼼하게 손이 닿아 있는 코드 (ex.오류 처리). * 이 책에서 다룰 큰 원칙 - 중복 금지 - 한 기능만 수행 - 명확한 표현 - 작게 추상화

Life Cycle정리 아이폰 OS에서 어플리케이션의 상태는 위와 같이 정리된다. Not Running : 말 그대로 어플리케이션이 작동 중이지 않은 상태로 메모리에도 올라가 있지 않다. Foreground : 앱이 메모리 상에 존재하고 화면을 점유하고 있는 상태. -active : 앱이 유저의 화면을 대부분 점유하여 모든 기능이 완전히 제어 가능한 상태. -inactive : 앱이 외부요인(문자, 카톡, 전화 등)으로 인해 일부 기능의 제어권을 잃은 상태. 길지 않음. Background : 앱이 메모리 상에 존재하고 화면을 점유하고 있지 않은 상태. -suspend : 앱이 'Background'에서 아무 동작도 하고 있지 않는 상태. // 메모리가 부족하거나 너무 오랜 시간 아무 작업도 하지 않게 ..

view.isUserInteractionEnabled 기본값은 true이며 false로 설정 시 해당 뷰부터 하위에 있는 stucture들의 iteraction이 차단된다. (활용) collectionview에서 cell의 contentview 하위에 supplementaryview로 설정한 view가 존재할 시, 위 방법을 적용하면 유저가 터치 시 해당 cell내부의 view들의 간섭이 차단된다. 즉, collectionview에 있어 유저의 활동 영역이 cell의 선택, 해제 두개로 간단화된다.