반응형
switch문과 함께 고려해야 할 것 : lookup table, state machine, if-else
switch문
case : null이 아닌 모든 case에는 break;를 사용해야 함.
모든 switch문에는 반드시 default:가 있어야 함.
연산 결과가 boolean이면 if then else문 사용
루프제어
for 횟수를 알 때, while 횟수를 모를때
for문 안에서 loop제어 금지!
루프 내부에서 실수변수 X
루프 내부에서 break; continue; 사용 자제.
함수 코딩
recursive 호출 사용금지 - 사용할 경우 자세히!
모든 함수에 대해 prototype선언
모든 함수는 가능하면 return 값을 가지도록 코딩. return은 가능하면 한 곳으로!!
모든 함수의 리턴값을 확인할 것!
API 매뉴얼을 꼭 볼 것!
연산
괄호는 많이 사용하는 것이 좋음
&&, ||는 식이 컴파일러에 따라 실행 혹은 skip
if((a=b)) <= 조건문에서 일부러 assignment할때 이렇게 괄호 사용
>>, << : data type이 합당한지 확인
연산식에서 sizeof() 사용금지
for loop 이외에서 comma 연산 사용 금지
명백히 boolean이 아닐경우 value==0으로 사용.
malloc()의 사용
관리가 어렵다.
overhead 실행시간이 크다.
alloca : 함수 안에서만 사용할 때.
대안 : pointer, static memory
테스트시 모든 메모리 사용을 반드시 monitor
malloc의 리턴값을 반드시 확인 : 총 메모리 사용량을 검사함.
하드웨어와 연관되면 매뉴얼을 자세히 일어야 함.
- 테스트가 가능한 하드웨어 설계를 하도록 요구
기타
unreachable은 없앰.
괄호는 사용
if - else if 마지막에는 else 사용
================
프로그램 디자인을 잘해야 함. : 분업을 위해
설명이 없는 magic 상수가 많이 발견된다.
소프트웨어 발전 방향
소프트웨어 모듈의 재사용이 중요
Platform 기반 S/W 개발, Documentation, Testability
Coding Standard
주기적인 소스 reading
깨끗한 코드를 짠 사람에게 보상 체계
안전하고 멋진코드
에러가 없고 테스트할 수 있고 포팅이 잘되고 따라하고 쉽고
코딩의 자세
시나리오 -> 전체적인 그림(아키텍쳐)
구현 전에 문서를 만들자.
최소한의 설계, API 문서를 만들자.
적어도 만들면서 문서를 쓰자.
반드시 코드를 읽자!
문제를 드러내자.
모든 문제를 분석해야 한다. => 끝까지 쫒아가서 오류를 해결.
3개의 답 : 효율이 낮은 해결책, 최적의 답, 중간에 있는 답.
=> 최적화는 뒤로 미룸. (db는 최적화가 중요, 그래서 돈을 많이 번다.)
Profile 후 가장 오래걸린 하나만 최적화 하자.
읽기 쉽게 쓰자.
warning은 버그로 돌아온다!
코딩의 생산성을 생각하자.
컴파일러는 스마트하다. 의심하지 말자.
컴파일러 매뉴얼을 읽자
자제의 미덕
루프를 짧게 사용하자
global 변수를 자제하자.
global변수를 사용하더라도 포인터를 넘기자.
테스트
모든 모듈을 별도 시험하자
설계대로 시험하자
테스트는 non-interactive하게 하자.
(돌려놓고 집에 갈 수 있게)
코드는 "우리"의 재산!
소스를 인쇄해서 읽는다! => 건들지 말것.
=> 따로 코멘트를 적음. Inspection Defect List 만듬.
시간당 100~200라인 읽을 수 있음.
Source Inspection의 효과
- 품질 1000% 증가, 14% 생산성 증가
- 테스트 전에 82% 오류가 검사됨.
- 시간당 4.4개의 오류를 발견함.
Source Inspection 장려책
- 테스트 시간에서 뺀다.
- 소스 리딩(over pizza) day를 만듬.
- 읽은 소스만 release한다.
- 각 모듈마다 맨 뒤에 Inspection History comment로 쓴다.
반응형