영어 못하는 개발자

영어 못하는 개발자

외국어가 외계어 같이 느껴져서
문서를 한글로 번역하여 저장하는 블로그

프런트 엔드의 명명 규칙

업데이트: Link

프런트 엔드의 명명 규칙

There are only two hard things in Computer Science: Cache invalidation and naming things.
컴퓨터 과학에는 캐시 무효화와 이름 지정이라는 두 가지 어려운 일이 있습니다.
— Phil Karlton

명명 규칙은 아마도 보편적으로 동의할 수 있는 가장 어려운 것입니다. 모든 사람이 따라야 할 좋은 규칙이 있지만 모든 사람을 만족시키는 규칙은 없을 것입니다. 모든 개발자는 자신의 개인적인 취향에 가깝게 만드는 것을 선호하며 때때로 외부인에게 어떤 규칙도 따르지 않는다는 인상을 주는 혼란을 야기합니다. 이것은 불일치가 분명합니다. 따라서 항상 팀에 더 적합한 것을 따르는 것이 좋습니다.

좋은 이름 패턴을 채택하면 모든 사람이 컨텍스트를 빠르게 이해하고 검색 속도가 빨라지며 예측 가능성이 높아집니다. 다른 언어/프레임워크는 다른 종류의 규칙을 따르거나 권장할 수 있으며 대부분의 경우 밀접하게 따르는 것이 좋습니다. 여기에서 우리는 어떤 것을 선택해야 하는지에 따라 채택하기 쉬운 것으로 판명된 몇 가지 일반적인 패턴에 대해 논의할 것입니다.

  • 쉽게 읽기 : 우리는 코드를 읽고 이해하는데 매우 많은 시간을 할애하고 있기 때문에 쉽게 읽히고 이해할 수 있어야 합니다.
  • 더 빠른 입력 : 코드를 더 쉽게 입력하고 실수로 인한 오타 오류를 방지하도록 노력해야 합니다.
  • OS 간 문제 방지 : 대부분의 운영 체제에는 유사한 파일/폴더 명명 규칙이 있지만 때로는 다릅니다. 예를 들어 Windows는 대소문자를 구분하지만 Linux는 그렇지 않습니다. GIT는 Windows 및 Mac의 대문자 및 소문자 파일 이름으로 인해 이름을 확인하는 데 문제가 발생하는 경우가 있습니다.
  • 컨텍스트 식별 용이 : 파일/폴더 이름, 변수/메서드/클래스 이름은 목적과 컨텍스트를 나타내야 합니다.
  • 대부분의 라이브러리/프레임워크 따라하기 : 원활하고 쉽게 팀의 모든 사람을 설득할 수 있습니다.

각 사용 유형에 대한 예제 섹션으로 이동하기 전에 이 기사에서 빠른 조회를 위해 각 케이스 유형의 이름을 입력하겠습니다.

  • camelCase: 소문자로 시작하고 대문자로 시작하는 모든 후속 단어
  • PascalCase: 모든 단어는 대문자로 시작
  • snake_case: 밑줄로 구분된 단어
  • kebab-case: 하이픈으로 구분된 단어

명명 규칙에 대한 단일 선택 사항은 없으며 모두에 대한 하나의 규칙도 없습니다. 사용법, 출처, 문맥에 따라 규칙이 변경되고 예외도 있습니다. 이러한 규칙과 변형을 하나씩 살펴보겠습니다. 나는 또한 가능한 한 당신이 가질 수 있는 1차 선택과 2차 선택을 할 것입니다.

파일 및 폴더 이름 지정

파일 및 폴더 이름을 선택할 때 가장 중요하게 고려해야 할 사항은 운영 체제 종속성입니다. 따라서 밑줄(“_“)과 하이픈(“-“) 이외의 특수 문자를 선택하지 않는 것이 좋습니다.

폴더 이름 지정

위에서 언급한 다른 종류를 기반으로 하는 선택 사항을 확인해 보겠습니다.

  1. oldArchive
  2. old_archive
  3. OLD_ARCHIVE
  4. old-archive
  5. OldArchive

최선의 선택은 모든 소문자 와 하이픈 을 선택하는 것 입니다.

예: old-archive, login-section

파일 이름 지정

camelCase & PascalCase

여기에는 많은 변형이 있습니다. oops를 따르는 다른 언어에서 온 사람들은 javascript 파일에 대해 camelCase 및 PascalCase를 사용하는 것을 선호합니다. 이것은 camelCase와 PascalCase의 경우에 클래스와 메소드를 작성한다는 원칙에서 비롯됩니다. 파이썬 배경을 가진 사람들은 밑줄로 구분된 단어를 따릅니다. 솔직히 파일 이름을 클래스 이름과 정확히 같은 방식으로 작성할 필요는 없지만 검색에는 확실히 도움이 됩니다. HTML 및 CSS 파일도 때때로 동일한 규칙을 따릅니다. HTML 파일의 경우 이 트릭은 SEO 친화적인 URL을 실제 HTML 파일/프레그먼트/서버 측 템플릿에 매핑하여 기본 파일 시스템을 숨기는 데 도움이 됩니다.

// Pascal case
Login.js,
LoginModule.js,
Login.html

// Camel case
login.js
loginModule.js
login.html
loginPage.html

이것은 좋은 선택 중 하나이지만 여전히 크로스 OS 문제의 위험이 있습니다. 이것은 클래스 기반 프로그래밍에 너무 많은 관심이 있는 경우에 적합합니다.

kebab-case

하이픈이 붙은 이름은 많은 좋은 라이브러리에서 채택됩니다. 이것은 폴더 이름과 일치하며 가장 쓰기 쉽습니다.

login.js
login-module.js
mobile-products.html
mobile-products.css

모든 유형의 파일에 하이픈 구조를 사용하는 이점은 입력의 일관성을 높이고 OS 간 문제가 없습니다.

버전 관리, 변형 또는 하위 라이브러리를 사용하는 동안 이름은 점 .으로 결합되어야 합니다. 그리고 SASS 부분 파일의 경우 기본 규칙은 밑줄을 앞에 추가하는 것입니다.

login.v3.0.0.js 
login.min.js
coursel.jquery.js
_color-variables.scss // exception for sass partial files

일반적으로 파일 이름은 다음 패턴을 따를 수 있습니다.

<name-of-the-file>.<name-space/parent-library>.<variations>.<version>.<extension>

두 경우 모두 약간의 변형과 예외가 있습니다. 두 스타일 모두 똑같이 좋지만, 저는 일관성을 위해 케밥 스타일을 선호하고 제안합니다. 그런데 요즘 뉴에이지 개발자들의 사랑을 받고 있는 믹스백 스타일의 세 번째 스타일이 있습니다. 리액트 및 앵귤러 커뮤니티에서 주로 채택하고 컨텍스트 스타일을 채택합니다. 그러나 어떤 파일 이름을 사용하든 항상 폴더 이름에 대해 모두 소문자를 사용하여 케밥을 사용하는 것이 좋습니다. 새 프로젝트로 시작하는 경우 팀을 위해 이것을 고려해야 할 것입니다.

다음은 일반적인 파일/폴더 이름 지정 방법입니다.

config
    - app-config.json /* 이 파일들은 외부 헬퍼 파일들이며 카멜케이스를 따르지 않습니다. */
    - build-config.js
    - project-aliases.js 
    - unit-testing
        jest.config.json
src
    - components
        - main-navigation
            - MainNavigation.js // React class/ react functional component
            - MainNavigation.style.js // css in js 
            - MainNavigation.css // if using regular css or css modules
            - MainNavigation.spec.js // test cases, it may have .spec or .test 
            - index.js // 긴 경로 입력을 피하기 위해 MainNavigation을 내보내는 파일
    - assets
        - images
            - application-logo.svg // assets to follow lower case kebab convention 
        - fonts 
            - custom-font.ttf
    - utils
        - browser-utils
            - getNavigatorDetails.js // utilities or any other such javascript to be named by default export 
            - scrollTo.js
        - ApplicationCache.js // class utils - so starts with capital case.
    - views
        - index.js // view templates in case there are no html files
        - applicationDashboard.js // follow camel case as per the module name inside.
    - templates
        - index.html
        - application-dashboard.html // html files to be named kebab style
.editorconfig // configurations like eslint, editorconfig, prettier to follow hidden file style - all lowercase and no space
README.md // special treatment to readme doc to easily differentiate
package.json
package-lock.json

자바스크립트 변수 이름 지정

변수

개발자가 가장 높은 수준의 자유를 얻는다고 생각하는 변수 이름은 오해입니다. 현실은 충분히 좋은 것으로 밝혀진 옵션이 가장 적다는 것입니다. 파이썬 배경을 가진 사람들은 단어 구분 기호로 밑줄을 선호하고, 액션 스크립트 세계에서 온 사람들은 개인 변수에 밑줄을 추가하는 것을 선호합니다.

이러한 규칙이 가능하지만 가장 선호되고 동의된 규칙은 일반 변수 및 메서드에 대해 camelCase를 따르는 것입니다. 항상 약어를 사용하지 않는 것이 좋습니다.

tip 약어와 두문자어를 사용하지 마십시오. 이러한 경우의 예가 아래에 나와 있습니다.

var counter = 0;
var selectedIndex = 0; 
let humidityFactor = 45;
function getIndex() { /*....*/ } 
const getIndex = () => {} 
const getHttpHeader = () => {} 

// getter, setter in classes
const getClientId = () => {}
const setClientId = () => {}

약어의 경우 camelCase를 따릅니다.

변수 이름이 명확하면 좋습니다. 다음은 “별로 좋지 않은” 및 “좋은” 이름의 예입니다.

var a = 0; // not so good
var basePrice = 0 // good
function index() {} // not so good
function getIndexOfStateSelection () {} // good

상수

ES6에 const 키워드가 도입되면서 한 번 선언되면 변경되지 않는 것을 잘 알 수 있습니다. 이를 위해 밑줄로 구분된 대문자를 사용하여 시각적으로 표시하는 가장 일반적이고 가장 좋은 방법입니다.

tip const 는 function 이름과 함께 사용할 때 이 규칙을 따르지 않습니다.

// example of constant variable
const TOTAL_STATES = 50; 
const GENERIC_ERROR_MSG = "Oops! Something went wrong"

이벤트

이벤트 이름은 일종의 상수이므로 상수와 동일한 패턴을 따라야 합니다. 다음은 샘플 예입니다.

// example of events
let customEvents = {
    ANIMATION_START: "animation-start",
    ANIMATION_END: "animation-end"    
}

자바스크립트 클래스 이름 지정

클래스 이름은 파스칼 대소문자를 따라야 합니다.

class BrowserUtils {
  static freeze() {
       // some code here.
    }
}

React functional components

React functional components는 클래스 키워드를 사용하지 않지만 여전히 일종의 클래스로 간주되고 사용자 지정 구성 요소이므로 클래스 명명 규칙을 따라야 합니다.

const SecondaryHeader = ( props ) => {
   return (
        <>
            <h2 className="SecondaryHeader">{props.label}</h2>
        <>
   )
}

CSS 클래스 및 변수 이름 지정

우리가 CSS를 작성하는 방식은 최근에 많은 변화를 겪었습니다. 하나의 CSS 파일을 JS 작성 방식으로 CSS에 작성하는 간단한 방법부터 시작하여 모든 곳에서 클래스 및 변수 사용 방법이 이후 기술에 따라 변경되었습니다. 클래스와 변수의 이름 지정에 영향을 미치는 세 가지 주요 단계를 보았습니다.

일반 CSS 및 SCSS/SASS/LESS와 같은 전처리기 사용 : 개발자는 기본 하이픈(케밥 케이스) 클래스 이름과 변수를 사용했습니다. SASS/LESS 함수/변수는 javascript 메소드 이름을 따릅니다.

BEM/SMACCS/ITCSS/DRY 및 유사 개념의 진화 : 대규모 CSS, CSS 조각 및 개발 팀을 처리하는 데는 많은 일관성과 패턴이 필요했습니다. BEM은 여전히 가장 많이 채택된 패턴으로 간주됩니다. BEM에 대해 자세히 알아보려면 여기를 클릭하십시오.

CSS 모듈 / CSS in JS : 이것은 CSS 우선순위 및 이름 충돌 문제를 해결했습니다. 이렇게 하면 클래스 이름에 추가 세부 정보가 추가되어 항상 고유합니다. CSS 모듈은 여전히 BEM 또는 기타 유사한 패턴을 따를 수 있지만 JS의 CSS는 자바스크립트 방식에 너무 빠져 있으므로 대부분의 경우 camelCase를 따릅니다.

클래스 작성에 대해 자세히 알아보기 전에 id에 대해 알아보겠습니다. 스타일 지정을 위해 id를 피하고 대신 클래스를 사용하는 것이 항상 권장됩니다. 여전히 id를 사용하여 스타일을 선언해야 하는 경우 camelCase로 작성하는 것을 선호합니다. PascalCase를 사용하는 개발자도 조금 있지만 상대적으로 드뭅니다.

#mainHeader {
 padding: 50px;
}

그럼 클래스와 변수를 하나씩 살펴보도록 하겠습니다.

CSS 변수

tip CSS 변수는 비교적 새로운 것이며 작성 당시 브라우저 제한 사항이 거의 없을 수 있습니다.

CSS 변수는 camelCase의 경우나 kebab-case의 경우 또는 BEM 패턴을 따를 수 있습니다. 팀이 따라가는 것에 따라 그들 중 하나를 선택하십시오. 아래 코드는 주로 SASS, LESS용입니다.

:root {
    --primary-color: #000;
    --brand-name-primary-color: #00f
}

간단한 CSS의 경우 하이픈 연결이 가장 선호되며 거의 모든 라이브러리에서 채택됩니다.

SASS/LESS 방식의 CSS

/* sass/less hyphenated */
$primary-color: #000;
$brand-name-primary-color: #00F;

/* camel case */
$primaryColor : #000;
$blueThemePrimaryColor: #000;

/* BEM way */
$accent-color: #ff0;
$accent-color--primary: #000;
$theme-name__accent-color--primary: #00F;

/* modified BEM - hybrid of camel casing along with BEM separators */
$accentColor: #ff0;
$accentColor-primary: #000;
$themeName_accentColor-primary: #00F

작은 프로젝트에는 간단한 하이픈 연결 구조를 선호하고 대규모 분산 프로젝트에는 보통 BEM을 선호합니다.

CSS 클래스

변수와 달리 CSS 클래스 이름은 전처리기 사용을 기반으로 하는 패턴을 따라야 합니다. 일반 CSS 및 SASS/LESS 작성 방법의 경우 전역 재사용 가능한 클래스와 개별 구성 요소에 대해 유틸리티 우선 접근 방식을 채택할 것을 제안하며 하위 BEM이 최상의 규칙입니다. 우리는 컴포넌트 지향 아키텍처 경향이 있기에, 나는 절대 SMACSS의 열렬한 팬이 되거나 component(c-header), layout(l-left-container), utility(u-center-align), typography(t-body-copy) 등에 prefix를 추가하지 않습니다.

Mixins / Functions / Placeholders

믹스인 및 함수의 경우 클래스 및 변수와 유사한 패턴을 따를 수도 있습니다.

// example of function
@function calculate-rem($size) {
  $rem-size: $size / 14px;
  @return #{$rem-size}rem;
}
.application-bar {
  @extend .app-bar;
  @extend %flex-layout;
  background-color: red;
}

동시에 자바스크립트의 메소드와 매우 유사하기 때문에 유사한 처리를 하는 것이 합리적입니다.

// example of function
@function calculateRem($size) {
  $remSize: $size / 14px;
  @return #{$remSize}rem;
}

@mixin mobileOnly {
  @media (max-width: 599px) { @content; }
}

.applicationBar {
  @extend .appBar;
  @extend %flexLayout;
  background-color: red;
}

HTML의 명명 규칙

HTML은 관대합니다. 대문자와 소문자 모두 쓸 수 있지만, 타이핑이 쉽기 때문에 모든 요소와 속성에 소문자를 사용하는 것이 좋습니다.

<P>Example of uppercase : avoid writing like this</P>
<p>Example of lowercase : this is the best</p>

결론

html, css 및 javascript 규칙을 알아 봤습니다. 다만 올바른 규칙을 선택하는 것보다 일관성을 유지하는 것이 더 중요하기 때문에 팀에 더 좋은 것을 선택하시면 됩니다.

댓글남기기

참고

Java 8 Streams 소개

2023-03-27 Link

Introduction to Java 8 Streams 원문: Introduction to Java 8 Streams 1. Overview 이 글에서는 Java 8에 추가된 새로운 기능 중 주요 기능 중 하나인 스트림에 대해 간략히 살펴보겠습니다. 스트림에 대해 설명하고 간...

Spring REST API + OAuth2 + Angular

2023-02-23 Link

방금 새로운 Learn Spring Security 강좌를 발표했는데, 여기에는 Spring Security 5의 새로운 OAuth2 스택에 초점을 맞춘 전체 자료가 포함되어 있습니다.