프로그래밍 700

상태머신을 통해 점프 애니메이션을 적용해보자. ABP에 들어가서 AnimGraph를 수정하자. 상태머신 내부로 들어가면 위와같은 창에서 에니메이션을 수정할 수 있게 되는데, 애니메이션을 드래그해서 블럭을 만들고,블럭의 외부에 드래그해서 위와같이 연결한다. 위의 좌우 교차된 화살표는 IF문이다. 어떠한 조건에 해당되면 화살표 방향으로 애니메이션을 전환해준다. 점프에 사용될 데이터는 InAir인지 아닌지 확인하는 bool타입 변수를 사용한다. Bool타입 변수 제작 위와같이 현재 담당된 Player에 대해 InAir를 가져올 수 있다. 만약, 떨어지고 있다면, 현재 객채가 공중에 있다는 의미 임으로, InAir를 True로 전환하고, 아니라면 False로 변환해준다. 해당 Valid는 블루프린트가 업데이트 ..

3.5 스타일이 있는 언어의 활용 C++언어는 잘못 활용하면 도저히 사람이 알아볼 수 없는 해괴한 코드를 만들 수 있다. i++ + ++i; 위 코드는 어떤식으로 동작하는지 C++표준에 정해져 있지 않다. i++가 변수 i를 이용하면서, 그 값을 증가시키는 부가 효과가 있기 때문이다. 표준에서는 문장 실행 중에 결과값(i + 1) 리턴과 함께 변수 자체의 값 증가까지 완료해야 하는지 정하고 있지 않다. 변수 자체의 값 증가는 문장의 끝인 ; 이후에 반영되어도 된다. 이때문에 ++i에서 어떤 i값이 사용될지 알 수 없다. 따라서 이 코드의 결과는 어떤 컴파일러를 사용하느냐에 따라 달라진다. a[i] = i++; 이 코드도 마찬가지 이유에서 결과가 어떻게 될지 알 수 없다. 이러한 코드의 사용은 피해야 한다..

3.4.2 네이밍 컨벤션 이름을 정하는 데 많은 시간이나 상상력이 꼭 필요한 것은 아니다. 일반적인 경우에 쉽게 적용할 수 있는 표준적인 네이밍 방법이 있으면 편리하다. 3.4.2.1 카운터 프로그래밍을 시작할 때 많은 코드에서 i를 반복문의 카운터 변수로 활용하는것 을 보았을 것이다. 습관적으로 변수 i와 j를 각각 바깥 루프와 안쪽 루프의 카운터 변수로 사용할 수 있다. 하지만 중첩된 루프에서는 i와 j의 형상이 비슷함으로 변수를 혼동하기 쉽다. 그럼으로, 좀더 명확한 이름을 사용하고 루프 변수에 i와 j를 쓰는게 별로 좋지 않을 수 있다. 3.4.2.2 접두사 많은 프로그래머가 변수명을 정할 때 변수의 타입이나 사용법을 암시하는 접두사를 붙인다. 그런데 마찬가지라 많은 수의 프로그래머가 유지보수 문..

3.4 네이밍 컴파일러는 몇 가지 네이밍 원칙을 가지고 있다. 이름이 숫자로 시작할 수는 없다. 밑줄이 두개로 된 이름이나(예:my__name) 밑줄로 시작하는 이름(예:_Name)도 사용해서는 안된다. 이런 이름들은 컴파일러가 자체적으로 사용하거나 표준 라이브러리 에서 사용하기 위해 예약되어있다. 이런 경우를 제외하면 이름은 순전히 나 자신과 내가 작성한 모듈을 이용할 동료 프로그래머를 돕기 위해 존재한다. 이러한 재경에 비추어 보았을 때 아무런 의미가 없거나 엉뚱한 오해를 불러일으키는 이름을 사용하는 경우가 너무나 많다는 데 안타까움을 금할 수 없다. 3.4.1 좋은 이름의 선택 변수, 메서드, 함수, 클래스는 그것의 목적을 정확히 설명해줄 수 있는 이름을 가지는 것이 가장 좋다. 부가적으로 타입이나..

3.3 코드 분할 코드 분할(decomposition)은 큰 덩어리의 코드를 작은 덩어리로 쪼개는 것이다. 함수 하나하나가수백라인씩 되고, 블록이 몇 중으로 겹쳐진 코드는 코드를 봐야하는 사람을 낭패스럽게 한다. 이상적으로는 함수 하나가 한가지 작업만 해야 한다. 복잡도를 심각하게 높이는 다른 부가 작업은 별도의 함수로 분리되어야 한다. 예를들어, 누군가 이 함수가 하는일이 물었을 때, 먼저 A를 하고, B를 한 후 C면 D를 하고, 아니면 D를 한다 라고 답했다면, A, B, C, D를 별도의 메서드로 분리해야하는 것이 바람직 하낟. 코드 분할은 이론적으로 잘 정립된 개념은 아니다. 어떤 프로그래머는 종이로 출력했을 때 함수 크기가 한쪽 이내여야 한다고 주장할 수도 있다. 또 다른 경험 법칙은 코드의 ..

3.2.2 주석 작성 스타일 어느 조직이든, 그 조직만의 주석 작성 방식이 있을 수 있다. 어떤 환경에서는 코드에 대한 공통적인 문서 표준으로서 특정 스타일의 주석을 강제하기도 한다. 어떤곳 에서는 주석의 스타일과 양을 전적으로 프로그래머 재량에 맡긴다. 3.2.2.1 모든 라인마다 주석 달기 충분한 문서화를 위해 소스 코드의 모든 라인마다 주석을 달 수도 있다. 모든 라인마다 주석을 달게 되면, 아무런 이유 없이 작성되는 코드를 피할 수 있다. 하지만, 대규모 프로젝트에 적용하기에는 무리가 있고, 코드가 지저분해지는 문제가 발생한다. int result;// 결과를 저장하기 위해 int 변수 선언 result = doodad.getResult(); // doodad의 결과 얻기 if ( result %..