종로5가역 2번출구, 큰 길 안쪽에 위치한 '남해 굴국밥'.

각굴은 너무 큰 경우가 있지만 굴국밥에 들어가는 굴은 적당해서 좋습니다.

 

굴의 양은 흡족할 정도로 많지 않아 아쉽긴 했지만 맛은 좋네요.

메뉴에 홍어도 있다는 걸 보고서 다음 날에도 방문했습니다.

 

위 사진은 홍어전. 혼자 먹기엔 많은 양이라 3점 남겼습니다.

오랜만에 입 안이 다 벗겨졌네요. 혓바닥까지 벗겨지는 경험은 처음이었습니다. 😂😂😂😂😂

🍖🍖🍖🍖 (4/5점)

 

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

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

5. 데이터형 규정

5. 2 고정 크기 정수

규정

  1. 정수형의 크기가 중요하다면 고정 길이 데이터형을 char, short, int, long, 또는 long long형 대신 사용해야 한다. 부호 없는 또는 부호 있는 고정 길이 정수형은 아래 표와 같다.
Integer Width Signed Type Unsigned Type
8 bits int8_t uint8_t
16 bits int16_t uint16_t
32 bits int32_t uint32_t
64 bits int64_t uint64_t
  1. 키워드인 short, long은 사용할 수 없다.
  2. 키워드인 char의 사용은 문자열에 관한 선언 및 연산으로 제한되어야 한다.

이유

C90 표준에서는 의도적으로 char, short, int, long 그리고 long long 형에 대해 고정되지 않은 크기를 허용함으로써 코드 이식성에 문제를 야기했습니다. C99 표준에서도 이 문제를 해결하지 않았지만, 위 테이블에서 보듯 stdint.h 헤더 파일에 정의된 정수형을 공개했습니다.

 

이식 가능한 고정 크기 정수형에 대한 또 다른 참조 문서:

barrgroup.com/embedded-systems/how-to/c-fixed-width-integers-c99

C99 표준과 호환되지 않는 컴파일러의 경우 typedef를 이용해 고정크기 데이터형을 정의하는 것이 허용됩니다. 필요하다면 컴파일시 확인하는 과정이 꼭 필요합니다.

시행

빌드시 매번 자동화된 도구를 이용해 short, long 키워드에 대한 체크를 해야 합니다. 코드 검토시 또 다른 규정 준수에 대해 검토해야 합니다.

 

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

[ECCS] 고정 크기 정수  (0) 2020.10.18
[ECCS] 데이터형 명명 관례  (0) 2020.10.17
[ECCS] 파일 템플릿  (0) 2020.10.17
[ECCS] 소스 파일  (0) 2020.10.17
[ECCS] 헤더 파일  (0) 2020.10.10
[ECCS] 모듈 명명 관례  (0) 2020.10.10

5. 데이터형 규정

5. 1 명명 관례

규정

  1. 구조체(structure), 유니언(union) 및 열거(enumeration)를 포함한 모든 새로운 데이터형의 이름은 소문자와 단어 내부의 밑줄로만 구성되어야 하며 ‘_t‘로 끝나야 한다.
  2. 모든 새로운 구조체, 유니언형 및 열거형은 typedef 통해 명명되어야 한다.
  3. 모든 public 데이터형의 이름은 모듈 이름과 밑줄을 앞에 붙여야 한다.

예시

typedef struct
{
  uint16_t count;
  uint16_t max_count;
  uint16_t _unused;
  uint16_t control;
  
} timer_reg_t;

이유

데이터형 이름과 변수 이름은 종종 유사합니다. 예를 들어, 주변장치에서 타이머 제어 레지스터 세트가 'timer_reg' 이름을 호출합니다. 레지스터 레이아웃을 정의하는 구조체 정의를 구분하기 위해서는 'timer_reg_t'와 같이 고유한 이름으로 새로운 유형을 만든는 것이 중요합니다. 필요한 경우 이같은 유형을 사용하여 'timer_reg_shadow'같은 타이머 레지스터의 복사본을 만들 수 있습니다.

시행

각 빌드 전, 자동화 도구를 사용해 새 소스나 수정된 소스 코드를 검색하여 키워드 struct, union 또는 enum이 typedef 문이나 익명의 선언 내에서만 사용되는지 확인해야 합니다. 코드 검토시 새로운 형(type)에 대한 명명 규정을 시행해야 합니다.

 

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

[ECCS] 고정 크기 정수  (0) 2020.10.18
[ECCS] 데이터형 명명 관례  (0) 2020.10.17
[ECCS] 파일 템플릿  (0) 2020.10.17
[ECCS] 소스 파일  (0) 2020.10.17
[ECCS] 헤더 파일  (0) 2020.10.10
[ECCS] 모듈 명명 관례  (0) 2020.10.10

4. 모듈 규정

4. 4 파일 템플릿

규정

  1. 헤더 및 소스 파일에 대한 템플릿은 프로젝트 수준에서 유지 관리되어야 한다.

이유

새 파일을 작성할 때 템플릿을 이용하면 첫머리 코멘트 블록의 일관성이 보장되고, 저작권 고지 사항을 확실히 할 수 있습니다.

시행

파일 형식의 일관성은 코드 검토시 시행되어야 합니다.

 

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

[ECCS] 고정 크기 정수  (0) 2020.10.18
[ECCS] 데이터형 명명 관례  (0) 2020.10.17
[ECCS] 파일 템플릿  (0) 2020.10.17
[ECCS] 소스 파일  (0) 2020.10.17
[ECCS] 헤더 파일  (0) 2020.10.10
[ECCS] 모듈 명명 관례  (0) 2020.10.10

4. 모듈 규정

4. 3 소스 파일

규정

  1. 각 소스 파일에는 하나의 entity를 제어하는 적절한 동작만 포함해야 한다. entity의 예로는 캡슐화된 데이터 타입, 활성 객체, 주변장치 드라이버(예: UART), 통신 프로토콜 또는 계층(예: ARP) 등이 있다.
  2. 각 소스 파일에는 다음 섹션의 일부 또는 전부가 열거된 순서대로 구성되어야 한다. 주석 블록, #include문, 데이터 유형, 상수 및 매크로 정의, 정적 데이터 선언, private 함수 프로토타입, public 함수 몸체 그리고 private 함수 몸체.
  3. 각 소스 파일은 컴파일러가 public 함수와 해당 프로토타입이 일치하는지 확실히 할 수 있도록 동일한 이름의 헤더 파일을 포함해야 한다(예: 파일 adc.c에는 #include "adc.h" 문장이 있어야 함).
  4. 파일의 절대 경로는 #include문 내에 사용할 수 없다.
  5. 소스 파일에는 사용하지 않는 include 파일이 없어야 한다.
  6. 소스 파일은 다른 소스 파일을 #include 문에 포함해서는 안 된다.

이유

소스 파일의 목적 및 내부 레이아웃은 그것을 다루는 모든 사람에게 명확해야 합니다. 예를 들어, public 함수는 일반적으로 가장 관심이 많으므로 private 함수보다 먼저 표현됩니다. 중요한 점은 컴파일러 입장에서 모든 함수 선언이 프로토타입과 일치해야 한다는 것입니다.

시행

정적 분석 도구를 사용하여 실제로 사용하지 않는 파일이 포함되어 있는지 확인 가능합니다. 다른 규칙들은 코드 검토중 시행됩니다.

 

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

[ECCS] 데이터형 명명 관례  (0) 2020.10.17
[ECCS] 파일 템플릿  (0) 2020.10.17
[ECCS] 소스 파일  (0) 2020.10.17
[ECCS] 헤더 파일  (0) 2020.10.10
[ECCS] 모듈 명명 관례  (0) 2020.10.10
[ECCS] 출력되지 않는 문자  (0) 2020.10.10

아이패드에서 리디북스로 이북을 읽으며 애플 펜슬 더블탭을 하면 다음장으로 넘어가는 기능이 있네요.

이제사 발견했는데 언제부터 지원했는지 몰겠지만 누워서 볼 때 유용할듯.

 

2006년 출간. 저자는 레이 커즈와일과 테리 그로스만

미래학자인 레이 커즈와일이 공동 저자라 알게되어 읽었다.

먹거리에 대한 조언들, 첨단 현대의학을 소개하며, 광범위한 보충제나 약도 소개한다.

특히 심장병, 암에 대해 자세히 설명하며

뇌, 호르몬, 성 호르몬, 보충제, 운동, 스트레스도 별도의 장을 할애했다.

🍖🍖🍖 (3/5점)

' > ' 카테고리의 다른 글

노화와 질병  (0) 2020.10.10
마광수 <상상놀이>  (0) 2020.10.02
스티브 워즈니악  (0) 2020.09.11
나는 슈뢰딩거의 고양이로소이다  (0) 2020.07.11
인공지능 투자가 퀀트  (0) 2020.07.09
유년기의 끝  (0) 2020.06.19

4. 모듈 규정

4. 2 헤더 파일

규정

  1. 각 소스 파일에 대해 정확하게 하나의 헤더 파일이 있어야 하며, 항상 동일한 루트 이름을 가져야 한다.
  2. 각 헤더 파일은 아래의 예와 같이 다중 include에 대응하기 위한 전처리기를 포함해야 한다.
  3. 헤더 파일에는 (프로토타입 또는 매크로, #define  typdefs를 통해) 다른 모듈과 비교해 엄격하게 알릴 필요가 있는 프로시저, 상수 및 데이터 형식만 표시해야 한다.
    • 헤더 파일에 (extern을 사용한) 어떤 변수도 선언하지 않는 것이 선호되는 관행이다.
    • 어떤 변수에 대한 저장 공간도 헤더 파일에서 할당되어서는 안된다.
  4. public 헤더 파일은 private 헤더 파일을 #include 할 수 없다.

예시

#ifndef ADC_H
#define ADC_H
...
#endif /* ADC_H */

이유

C 언어 표준은 기본적으로 모든 변수와 함수에 전역 범위 접근을 허용합니다. 이러한 단점으로 모듈간의 불필요하며 위험한 연결이 발생합니다. 모듈간 연결을 줄이려면 가능한 많은 프로시저, 상수, 데이터형 그리고 변수를 모듈내에 감춰야 합니다.

인터넷에서 추가글 'What Belongs in a C .h Header File?'을 참조하세요.

What Belongs in a C .h Header File.pdf
0.05MB

시행

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

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

[ECCS] 파일 템플릿  (0) 2020.10.17
[ECCS] 소스 파일  (0) 2020.10.17
[ECCS] 헤더 파일  (0) 2020.10.10
[ECCS] 모듈 명명 관례  (0) 2020.10.10
[ECCS] 출력되지 않는 문자  (0) 2020.10.10
[ECCS] 탭  (0) 2020.10.09

4. 모듈 규정

4. 1 명명 관례

규정

  1. 모든 모듈 이름은 소문자, 숫자 및 밑줄로 구성되어야 합니다. 헤더 및 소스 파일 이름에 공백을 사용하면 안됩니다.
  2. 모든 모듈 이름은 앞 8자에 의해 고유해야 하며 헤더 및 소스 파일 이름에 대해 각각 .h와 .c로 끝나야 합니다.
  3. 모듈의 헤더 파일 이름은 C 또는 C++ 표준 라이브러리의 헤더 파일 이름을 공유해서는 안 됩니다. 예를 들어 모듈의 이름은 “stdio” 또는 “math“로 지정해서는 안됩니다.
  4. main() 함수를 포함하는 모듈은 소스 파일 이름의 일부로 “main”라는 단어를 포함해야 합니다.

예시

/** @file crc.h
*
* @brief Compact CRC library for embedded systems for CRC-CCITT, CRC-16, CRC-32.
*
* @par
* COPYRIGHT NOTICE: (c) 2000, 2018 Michael Barr. This software is placed in the
* public domain and may be used for any purpose. However, this notice must not
* be changed or removed. No warranty is expressed or implied by the publication
* or distribution of this source code.
*/

#ifndef CRC_H
#define CRC_H

// Compile-time selection of the desired CRC algorithm.
//
#if defined(CRC_CCITT)

#define CRC_NAME "CRC-CCITT"
typedef uint16_t crc_t;

#elif defined(CRC_16)

#define CRC_NAME "CRC-16"
typedef uint16_t crc_t;

#elif defined(CRC_32)

#define CRC_NAME "CRC-32"
typedef uint32_t crc_t;

#else

#error "One of CRC_CCITT, CRC_16, or CRC_32 must be #define'd."

#endif

// Public API functions provided by the Compact CRC library.
//
void 	crc_init(void);
crc_t 	crc_slow(uint8_t const * const p_message, int n_bytes);
crc_t 	crc_fast(uint8_t const * const p_message, int n_bytes);

#endif /* CRC_H */

/*** end of file ***/

이유

멀티플랫폼 개발환경(예 : 유닉스와 윈도우)은 예외적인 상황이 아니라 일반적인 것입니다. 모듈 이름에 대소문자를 섞어 사용하는 것은 다른 운영체제 걸쳐 문제를 일으킬 수 있으며, 유사한 이름이지만 대소문자가 다른 파일은 프로그래머로 하여금 혼동을 일으킬 수 있어 오류가 발생하기 쉽습니다.

파일 이름에 'main'을 포함하는 것은 소프트웨어 구성이 여러 개인 프로젝트에서 유용한 것으로 입증되었으며, 코드 관리자에게 도움이 됩니다.

시행

자동화된 도구를 이용하여 모든 파일 이름이 이 규정을 따르고 있는지 확인해야 합니다.

 

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

[ECCS] 소스 파일  (0) 2020.10.17
[ECCS] 헤더 파일  (0) 2020.10.10
[ECCS] 모듈 명명 관례  (0) 2020.10.10
[ECCS] 출력되지 않는 문자  (0) 2020.10.10
[ECCS] 탭  (0) 2020.10.09
[ECCS] 들여쓰기  (0) 2020.10.09

3. 공백 규정

3. 6 출력되지 않는 문자

규정

  1. 가능하면 모든 소스 코드 라인은 'CR'-'LF'(0x0D 0x0A)가 아닌 단일 문자 'LF'(ASCII 0x0A)로만 끝나야 한다.
  2. 소스 코드 파일에서 허용되는 또다른 출력되지 않는 문자는 form feed 문자 'FF'(ASCII 0x0C)뿐이다.

예시

출력되지 않는 문자는 나타낼 수 없습니다.

이유

다중 문자 'CR'-'LF'는 단일 문자 'LF'보다 다중 플랫폼 개발 환경에서 문제를 일으킬 가능성이 높습니다. 이러한 문제중 하나는 유닉스 플랫폼의 다중 라인 전처리기 매크로와 관련있습니다.

시행

에디터 프로그램은 LF를 사용하도록 설정되어야 합니다. 또한 자동화된 도구는 빌드 중에 모든 새 소스코드 또는 수정된 소스코드 파일을 스캔하여 CR-LF 문자를 LF로 변경해야 합니다.

 

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

[ECCS] 헤더 파일  (0) 2020.10.10
[ECCS] 모듈 명명 관례  (0) 2020.10.10
[ECCS] 출력되지 않는 문자  (0) 2020.10.10
[ECCS] 탭  (0) 2020.10.09
[ECCS] 들여쓰기  (0) 2020.10.09
[ECCS] 빈 줄  (0) 2020.10.09

+ Recent posts