2. 주석 규정

2.1 주석에서 허용하는 형식

규정

  1. C++ 스타일의 단일 행 주석(//으로 시작하는)은 전통적인 C 스타일 주석(/* ... */)의 유용하고 수용 가능한 대안이다.
  2. 주석에는 전처리기 토큰(token)인 /*, //, \ 가 포함되지 않아야 한다.
  3. 아래 두 경우 일시적으로라도 주석을 작성해서는 안 된다.
    1. 코드 블록을 일시적으로 비활성화하려면 전처리기의 조건부 컴파일 기능을 사용한다(예: #if 0 … #endif).
    2. 디버그 출력 정보의 수준을 높이기 위해 특별히 존재하는 모든 라인 또는 코드 블록은 #ifndef NDEBUG … #endif로 둘러싸야 한다.

예시

/* The following code was meant to be part of the build...
...
safety_checker();
...
/* ... but an end of comment character sequence was omitted. */

이유

의도적이든 아니든 중첩된 주석을 사용하면 컴파일 후 실행할 코드에 대해 코드 검토자를 혼돈케할 위험이 있습니다. assert() 매크로를 비활성화하는 것과도 관련이 있기 때문에 네거티브 로직인 NDEBUG의 사용은 의도적인 것입니다. 두 경우 모두 프로그래머는 장황한 코드를 방지하기 위해 행동합니다.

시행

허용되는 주석 형식만 컴파일러 또는 정적 분석에 의해 부분적으로 적용할 수 있습니다. 그러나 사람인 코드 검토자만이 주석 처리된 코드와 설명적인 코드 스니펫을 포함하는 주석 간의 차이를 구별할 수있습니다.

 

'Digital Developer > Embedded C Coding Standard' 카테고리의 다른 글

[ECCS] 공백  (0) 2020.10.04
[ECCS] 주석의 위치와 내용  (0) 2020.10.03
[ECCS] 주석에서 허용하는 형식  (1) 2020.10.02
[ECCS] 자주 사용하는 키워드  (0) 2020.10.01
[ECCS] 피해야할 키워드  (0) 2020.10.01
[ECCS] 캐스트  (0) 2020.10.01
  1. 영화다시보기 2020.10.06 10:30

    포스팅 잘 보고 갑니다...

1. 일반 규정

1.8 자주 사용하는 키워드

규정

  1. 선언한 모듈 외부에서 볼 필요가 없는 모든 함수와 변수는 키워드 static을 사용하여 선언해야 합니다.
  2. 적절한 경우에 키워드 const를 항상 사용해야 합니다. 사용 예는 다음과 같습니다.
    1. 초기화 이후 변하지 않는 변수를 선언할 때
    2. 수정돼서는 안될 참조 호출(call-by-reference) 함수의 매개변수를 정의할 때(예를 들어, char const *param)
    3. 수정돼서는 안될 struct나 union의 항목을 정의할 때(예를 들어, 메모리 사상 입출력 주변장치의 레지스터를 위한 구조체 오버레이에서)
    4. 상수를 생성하는 #define에 대한 대안으로 사용
  3. 적절한 경우 키워드 volatile를 항상 사용해야 합니다. 사용 예는 다음과 같습니다.
    1. 인터럽트 서비스 루틴(ISR)에서 접근 가능한 전역 변수를 선언할 때
    2. 두 개 이상의 스레드에서 접근 가능한 전역 변수를 선언할 때
    3. 메모리 사상 입출력 주변장치 레지스터의 포인터를 선언할 때(예를 들어, timer_t volatile * const p_timer)
    4. 지연 루프에서 사용하는 카운터 변수를 선언할 때

예시

typedef struct
{
  uint16_t count;
  uint16_t max_count;
  uint16_t const _unused;       // read-only register
  uint16_t control;
} timer_reg_t;

timer_reg_t volatile * const p_timer = (timer_reg_t *) HW_TIMER_ADDR;

이유

C의 static 키워드는 여러 의미가 있습니다. 모듈 레벨에서, static으로 선언된 전역 변수 및 함수는 외부로부터 보호됩니다. static 키워드를 많이 사용하면 모듈간의 간섭을 줄일 수 있습니다.

const나 volatile 키워드는 더욱 중요합니다. const를 최대한 많이 사용하면 읽기 전용인 데이터에 의도하지 않은 쓰기로부터 컴파일러 수준에서 시행하는 보호를 받을 수 있습니다. volatile 키워드를 적절히 사용하면 변수 또는 레지스터에 대한 읽기 또는 쓰기를 삭제하는 컴파일러 최적화를 방지하여 찾기 어려운 버그를 모두 제거할 수 있습니다.

시행

이 규정은 코드 검토시 시행해야 합니다.

'Digital Developer > Embedded C Coding Standard' 카테고리의 다른 글

[ECCS] 주석의 위치와 내용  (0) 2020.10.03
[ECCS] 주석에서 허용하는 형식  (1) 2020.10.02
[ECCS] 자주 사용하는 키워드  (0) 2020.10.01
[ECCS] 피해야할 키워드  (0) 2020.10.01
[ECCS] 캐스트  (0) 2020.10.01
[ECCS] 괄호  (0) 2020.10.01

 

동결건조된 블록으로, 내용물은 된장, 우거지, 홍고추, 다시마, 멸치엑기스 등이다.

12g 블록에 끓는 물 200ml 붓고 30초 저으면 끝.

그리고 밥 말아서 김치만 있으면 한 끼 끝이다.

찾아보니 12g짜리 24개가 들어있는 큰 박스가 있고

8g짜리 5개가 들어있는 작은 사이즈가 있다.

난 12g짜리만 먹어 봤는데 강추한다.

끼니는 쉽게 때울 때 만족도가 급상승한다.

' > 먹을것' 카테고리의 다른 글

남해 굴국밥  (0) 2020.10.24
샘표 시골식 된장국  (0) 2020.10.01
보닐라 감자칩  (0) 2020.09.30
인생에일  (0) 2020.09.22
리스토란테 냉동피자  (0) 2020.09.11
농심 김치 큰사발  (0) 2020.08.16

1. 일반 규정

1.7 피해야할 키워드

규정

  1. 키워드 auto는 사용할 수 없습니다.
  2. 키워드 register는 사용할 수 없습니다.
  3. 키워드 goto는 사용하지 않는 것이 좋습니다. goto를  사용할 경우 동일한 블록내에서 이후에 선언된 레이블로만 점프합니다.
  4. 키워드 continue는 사용하지 않는 것이 좋습니다.

이유

키워드 auto는 C 언어의 불필요한 과거 기능입니다. 키워드 register는 프로그래머가 컴파일러보다 더 똑똑하다고 가정하고 있습니다. 현대 프로그래밍 관행에서 이러한 키워드를 사용해야 하는 설득력있는 이유는 없습니다.

키워드 goto와 continue는 C 언어에서 계속 사용되지만, 사용하면 코드가 엉망진창이 되는 경우가 많습니다. 특히, 구조적 프로그램의 일상적인 흐름제어에 반하는 점프문인 goto의 사용은 문제가 있습니다. 코드를 단순화 하고 명확히 하는 경우에는 예외적 상황을 처리하기 위한 goto문을 가끔 사용하는 것은 허용됩니다.

시행

새 소스 코드 또는 수정된 소스 코드에서 금지된 키워드는 빌드시 자동화된 도구를 통해 감지해서 보고되어야 합니다. goto나 continue의 사용이 허용되는 범위 내에서, 코드 검토자는 유지보수성과 가독성을 개선하기 위한 대체 코드 구조를 조사해야 합니다.

 

'Digital Developer > Embedded C Coding Standard' 카테고리의 다른 글

[ECCS] 주석에서 허용하는 형식  (1) 2020.10.02
[ECCS] 자주 사용하는 키워드  (0) 2020.10.01
[ECCS] 피해야할 키워드  (0) 2020.10.01
[ECCS] 캐스트  (0) 2020.10.01
[ECCS] 괄호  (0) 2020.10.01
[ECCS] 중괄호  (0) 2020.09.30

1. 일반 규정

1.6 캐스트

규정

  1. 캐스트를 사용하는 코드에서 가능한 값의 범위에 걸쳐 적절한 동작을 보장하는 방법을 설명하는 주석을 달아야 합니다.

예시

int
abs (int arg)
{
  return ((arg < 0) ? -arg : arg);
}
...
  uint16_t sample = adc_read(ADC_CHANNEL_1);
  result = abs((int) sample);        // WARNING: 32-bit int assumed.

이유

캐스트는 위험합니다. 위의 예제에서 부호없는 16비트 "sample" 변수는 부호가 있는 16비트 정수보다 큰 양의 값을 가질 수 있습니다. 이 경우 절대값도 부정확하게 됩니다. 따라서 int 형이 ISO C 표준에서의 16비트라면 오버플로우가 발생할 수 있습니다.

시행

이 규정은 코드 검토시 시행되어야 합니다.

'Digital Developer > Embedded C Coding Standard' 카테고리의 다른 글

[ECCS] 자주 사용하는 키워드  (0) 2020.10.01
[ECCS] 피해야할 키워드  (0) 2020.10.01
[ECCS] 캐스트  (0) 2020.10.01
[ECCS] 괄호  (0) 2020.10.01
[ECCS] 중괄호  (0) 2020.09.30
[ECCS] 코드 길이  (0) 2020.09.30

1. 일반 규정

1.5 일반 약어

규정

  1. 약어와 두문자어는 공학계에서 그 의미가 광범위하고 일관되게 이해되지 않는 한 일반적으로 피해야 합니다.
  2. 프로젝트별 약어 및 두문자어 표는 버전 관리 문서에 표시되어야 합니다.

예시

Abbreviation Meaning
adc analog to digial converter
avg average
b_ Boolean
buf buffer
cfg configuration
curr current (item in a list)
dac digital to analog converter
ee EEPROM
err error
g_ global
gpio general purpose IO pins
h_ handle (to)
init initialize
io input / ouput
isr interrupt serivce routine
lcd liquid crystal display
led light emitting diode
max maximum
mbox mailbox
mgr manager
min minimum
msec millisecond
msg message
next next (item in a list)
nsec nanosecond
num number (of)
p_ pointer (to)
pp_ pointer to a pointer (to)
prev previous (item in a list)
prio priority
pwm pulse width modulation
q queue
reg register
rx receive
sem semaphore
str string (null terminated)
sync synchronize
temp temperature
tmp temporary
tx transmit
usec microsecond

이유

프로그래머는 암호같은 약어와 두문자어를 코드에 너무 쉽게 사용합니다(심지어 이력서에까지도!). 프로그래머가 ZYZGXL의 의미를 안다고 해서 이후에 유지보수나 포팅 담당자가 이 암호같은 이름을 이해할 수 있는 것은 아닙니다.

시행

이 규정은 코드 검토시 시행되어야 합니다.

1. 일반 규정

1.4 괄호

규정

  1. 유지관리자에게는 명확해 보이지 않을 수 있으므로, C 언어 자체의 우선 순위 규칙에 의존하지 말고, 실행 순서를 분명히 하기위해 괄호를 사용해야 한다. (또는 길이가 긴 실행문은 몇 줄에 나눠 코딩한다.)
  2. 단일 식별자 또는 상수가 아닌 한, 논리 연산자 AND(&&)  OR(||)의 피연산자에는 괄호를 사용해야 한다.

예시

if ((depth_in_cm > 0) && (depth_in_cm < MAX_DEPTH))
{
  depth_in_ft = convert_depth_to_ft(depth_in_cm);
}

이유

C 언어의 구문에는 많은 연산자가 있습니다. 어떤 연산자를 먼저 계산해야 하는지 결정하는 우선 순위 규칙은 12개 이상의 우선 순위 레벨이 있을 정도로 복잡하며 모든 프로그래머에게 명확한 것은 아닙니다. 확실하지 않을 때는 컴파일러가 계산하기 원하는 방식을 명시적으로 표시하는 것이 좋습니다.

시행

이 규정은 코드 검토시 시행됩니다.

'Digital Developer > Embedded C Coding Standard' 카테고리의 다른 글

[ECCS] 피해야할 키워드  (0) 2020.10.01
[ECCS] 캐스트  (0) 2020.10.01
[ECCS] 괄호  (0) 2020.10.01
[ECCS] 중괄호  (0) 2020.09.30
[ECCS] 코드 길이  (0) 2020.09.30
[ECCS] C 언어 버전  (0) 2020.09.30

1. 일반 규정

1.3 중괄호

규정

  1. 중괄호는 항상 if, else, switch, while, do, for 다음에 나오는 코드 블록(복합문)을 둘러싸야 합니다. 이들 키워드 다음의 단문이나 빈 문장도 중괄호로 둘러싸야 합니다.
  2. 왼쪽 중괄호({)는 시작 키워드 아래줄에 사용해야 한다. 오른쪽 중괄호(})는 파일 뒷부분, 왼쪽 중괄호와 동일한 위치에 표시하여야 한다.

예시

{
  if (depth_in_ft > 10) dive_stage = DIVE_DEEP;   // This is legal...
  else if (depth_in_ft > 0)
    dive_stage = DIVE_SHALLOW;                    // ... as is this.
  else
  {                             // But using braces is always safer.
    dive_stage = DIVE_SURFACE;
  }
  ...
}

이유

중괄호로 둘러싸이지 않은 빈문장과 단일문이 있는 경우 상당한 위험이 있습니다. 이 같은 구문은 근처 코드가 변경되거 주석을 달 때 버그가 발생하는 경우가 많습니다. 이러한 위험은 중괄호를 일관되게 사용함으로써 피할 수 있습니다. 다음 줄에 왼쪽 중괄호의 위치를 지정하면 해당 오른쪽 중괄호를 육안으로 쉽게 알아볼 수 있습니다.

시행

if, else, switch, while, do, for 다음에 왼쪽 중괄호가 나타나도록 빌드시 자동화된 도구로 강제되어야 합니다. 중괄호의 정렬을 강제하기 위해 동일한 도구나 다른 도구(code beautifier 같은)를 사용해야 합니다.

 

'Digital Developer > Embedded C Coding Standard' 카테고리의 다른 글

[ECCS] 캐스트  (0) 2020.10.01
[ECCS] 괄호  (0) 2020.10.01
[ECCS] 중괄호  (0) 2020.09.30
[ECCS] 코드 길이  (0) 2020.09.30
[ECCS] C 언어 버전  (0) 2020.09.30
[ECCS] Embedded C Coding Standard  (0) 2020.09.20

1. 일반 규정

1.2 코드 길이

규정

  1. 프로그램에서 코드 한 줄의 길이는 최대 80자를 넘어서는 안된다.

추론

수시로 동료끼리의 리뷰 및 기타 코드 검사를 수행하게 되는데, 인쇄된 페이지에서 수행합니다. 이러한 인쇄물을 사용하려면 주의를 산만하게 하는 줄바꿈 뿐 아니라 누락된 문자(즉, 오른쪽 여백을 넘어서는 글자)가 없어야 합니다. 코드 길이 규칙을 준수하면 화면상에서도 나란하게 코드 차이점을 쉽게 구별할 수 있습니다.

시행

이 규칙에 대한 위반은 빌드 중 자동화된 스캔을 통해 감지될 수 있습니다.

 

'Digital Developer > Embedded C Coding Standard' 카테고리의 다른 글

[ECCS] 캐스트  (0) 2020.10.01
[ECCS] 괄호  (0) 2020.10.01
[ECCS] 중괄호  (0) 2020.09.30
[ECCS] 코드 길이  (0) 2020.09.30
[ECCS] C 언어 버전  (0) 2020.09.30
[ECCS] Embedded C Coding Standard  (0) 2020.09.20

거인족이 존재했었딴 말인가...

'끄적끄적' 카테고리의 다른 글

生과 死에서의 역할  (0) 2020.10.09
거인들  (0) 2020.09.30
비 맞으며 산책  (0) 2020.07.27
우리집 바둑이 ❛열매❜  (0) 2020.07.16
첫째 딸이 벌써  (0) 2020.07.08
부동산 정책에 대한 단상  (0) 2020.07.07

+ Recent posts