Sass 스타일 가이드: 더 나은 CSS 코드를 작성하는 방법에 대한 Sass 자습서

확장성이 좋은 일관되고 읽기 쉬운 CSS를 작성하는 것은 어려운 과정입니다. 특히 스타일 시트가 점점 더 커지고 복잡해지고 유지 관리가 더 어려워질 때. 개발자가 더 나은 CSS를 작성하기 위해 사용할 수 있는 도구 중 하나는 전처리기입니다. 전처리기는 한 유형의 데이터를 가져와 다른 유형의 데이터로 변환하는 프로그램이며, 우리의 경우 CSS 전처리기는 CSS로 컴파일된 전처리 언어입니다. 프론트엔드 개발자들이 추천하고 사용하는 CSS 전처리기가 많이 있지만 이 기사에서는 Sass에 초점을 맞출 것입니다. Sass가 제공해야 하는 것이 무엇인지, 다른 CSS 전처리기보다 Sass가 선호되는 이유, 최상의 방법으로 Sass를 사용하는 방법을 살펴보겠습니다.

Sass란 무엇이며 왜 사용해야 합니까?

Sass가 무엇인지 모르는 분들을 위해 가장 좋은 출발점은 공식 Sass 웹페이지를 방문하는 것입니다. Sass는 Syntactically Awesome StyleSheets의 약자이며 기본 언어에 강력함과 우아함을 더하는 CSS의 확장입니다.

Sass는 강력한 기능이 많이 포함된 CSS 전처리기입니다. 가장 주목할만한 기능은 변수, 확장 및 믹스인입니다.

변수는 색상이나 일반적으로 사용되는 기타 값과 같이 나중에 다시 사용할 수 있는 정보를 저장합니다. Extends는 규칙에 대한 상속을 허용하는 "클래스"를 만드는 데 도움이 됩니다. 믹스인은 "함수"와 같이 생각할 수 있습니다. Sass는 또한 논리문(조건부 및 루프)의 사용, 사용자 정의 함수, Compas와 같은 다른 라이브러리와의 통합 등과 같은 다른 전처리기와 비교하여 몇 가지 놀라운 기능을 가지고 있습니다. 이러한 기능만으로도 귀하와 귀하의 팀이 생산성을 높이고 결국 더 나은 CSS를 작성하는 데 도움이 될 수 있습니다.

CSS 스타일 가이드가 필요한 이유

불행히도 전처리기조차도 모든 것을 수정하고 좋은 CSS 코드를 작성하는 데 도움을 줄 수는 없습니다. 모든 개발자가 직면한 문제는 현재 웹 애플리케이션이 점점 더 커지고 있다는 것입니다. 그렇기 때문에 코드는 확장 가능하고 읽을 수 있어야 하며 스파게티 코드와 사용하지 않는 코드 줄을 피해야 합니다. 언급된 문제를 방지하려면 일상 업무에서 팀에 대한 일종의 표준이 필요합니다. 스파게티 코드란 무엇이며 어떻게 발생합니까? 스파게티 코드는 나쁘고 느리고 반복적이며 읽을 수 없는 코드의 이름입니다. 팀이 정의된 지침이나 표준 없이 큰 응용 프로그램을 작성할 때 각 개발자는 자신에게 필요한 것과 원하는 방식을 작성합니다. 또한 개발자가 많은 버그 수정, 핫픽스 및 패치를 작성할 때 문제를 해결할 코드를 작성하지만 최상의 방법으로 코드를 작성할 시간이 없는 경향이 있습니다. 이러한 상황에서는 응용 프로그램의 어떤 부문에서도 더 이상 사용되지 않는 많은 CSS 행으로 끝나는 것이 매우 일반적입니다. 개발자는 코드를 정리할 시간이 충분하지 않으며 가능한 한 빨리 수정 사항을 게시해야 합니다. 또 다른 되풀이되는 상황은 고장난 것을 빠르게 수정하기 위해 개발자가 !important 를 많이 사용한다는 것입니다. 그 결과 유지 관리하기 어려운 매우 해킹된 코드가 생성되고 예기치 않은 동작이 많이 발생하고 나중에 리팩토링해야 합니다. 이미 언급했듯이 코드가 커질수록 상황은 더욱 악화됩니다.

이 기사의 아이디어는 더 나은 Sass를 작성하기 위한 규칙, 팁 및 모범 사례를 공유하는 것입니다. 이러한 Sass 팁과 모범 사례를 함께 그룹화하면 Sass 스타일 가이드로 사용할 수 있습니다. 이 스타일 가이드는 개발자가 위에서 언급한 상황을 피하는 데 도움이 됩니다. 규칙은 더 쉽게 참조할 수 있도록 논리적 세그먼트로 그룹화되지만 결국에는 규칙을 모두 채택하고 따라야 합니다. 또는 적어도 대부분.

스타일 가이드

이 스타일 가이드의 규칙 및 모범 사례는 많은 팀과 작업한 경험을 바탕으로 채택되었습니다. 그 중 일부는 시행착오를 거쳐 나온 것이고 다른 일부는 BEM과 같은 인기 있는 접근 방식에서 영감을 받은 것입니다. 일부 규칙의 경우 설정 이유와 방법에 대한 구체적인 이유가 없습니다. 때로는 과거의 경험을 유일한 이유로 삼는 것으로 충분합니다. 예를 들어, 코드를 읽을 수 있도록 하려면 모든 개발자가 동일한 방식으로 코드를 작성하는 것이 중요하므로 괄호 사이에 공백을 포함하지 않는 규칙이 있습니다. 괄호 사이에 공백을 포함하는 것이 더 나은지 논쟁할 수 있습니다. 괄호 사이에 공백이 있어야 더 잘 보인다고 생각되면 이 스타일 가이드와 규칙을 취향에 따라 조정하세요. 결국 스타일 가이드의 주요 목표는 규칙을 정의하고 개발 프로세스를 보다 표준적으로 만드는 것입니다.

일반 CSS 규칙

일반 규칙은 항상 따라야 합니다. 코드의 일관성과 가독성을 위해 Sass 코드의 형식을 지정하는 방법에 주로 중점을 둡니다.

• 들여쓰기의 경우 탭 대신 공백을 사용합니다. 가장 좋은 방법은 2개의 공백을 사용하는 것입니다. 이 옵션을 사용하여 자신만의 신성한 전쟁을 실행할 수 있으며 자신만의 규칙을 정의하고 탭이나 공백 또는 가장 적합한 것을 사용할 수 있습니다. 규칙을 정의하고 일관성을 유지하면서 규칙을 따르는 것이 중요합니다.
• 각 문 사이에 빈 줄을 포함합니다. 이것은 코드를 사람이 더 읽기 쉽게 만들고 코드는 사람이 작성합니다. 맞습니까?
• 다음과 같이 한 줄에 하나의 선택기를 사용합니다.

 selector1, selector2 { }

• 괄호 사이에 공백을 포함하지 마십시오.

 selector { @include mixin1($size: 4, $color: red); }

• 작은따옴표를 사용하여 문자열과 URL을 묶습니다.

 selector { font-family: 'Roboto', serif; }

• 다음 앞에 공백 없이 세미콜론으로 모든 규칙을 종료합니다.

 selector { margin: 10px; }

선택자 규칙

다음은 선택자를 다룰 때 사용할 일련의 규칙을 따릅니다.

• ID 선택기를 사용하지 마십시오. ID는 너무 구체적이며 주로 JavaScript 작업에 사용됩니다.
• !important 하지 마십시오. 이 규칙을 사용해야 하는 경우 일반적으로 CSS 규칙에 문제가 있고 CSS가 제대로 구성되지 않았음을 의미합니다. !important 규칙이 많은 CSS는 쉽게 남용될 수 있으며 결국 CSS 코드가 지저분하고 유지 관리하기 어렵습니다.
• 자식 선택기를 사용하지 마십시오. 이 규칙은 ID 규칙과 동일한 추론을 공유합니다. 자식 선택자는 너무 구체적이고 HTML 구조와 밀접하게 연결되어 있습니다.

Sass 규칙을 순서대로 유지

코드에서 일관성을 유지하는 것이 중요합니다. 규칙 중 하나는 규칙의 순서를 지켜야 한다는 것입니다. 이렇게 하면 다른 개발자가 코드를 훨씬 더 잘 이해할 수 있고 방법을 찾는 데 시간을 덜 소비할 수 있습니다. 제안된 주문은 다음과 같습니다.

1. @extend 먼저 사용하세요. 이것은 처음에 이 클래스가 다른 곳에서 규칙을 상속한다는 것을 알려줍니다.
2. 다음에 @include 를 사용하십시오. 믹스인과 기능을 맨 위에 포함시키는 것은 좋은 일이며, 또한 덮어쓸 내용을 알 수 있게 해줍니다(필요한 경우).
3. 이제 일반 CSS 클래스 또는 요소 규칙을 작성할 수 있습니다.
4. 중첩된 의사 클래스와 의사 요소를 다른 요소 앞에 배치합니다.
5. 마지막으로 다음 예제와 같이 다른 중첩 선택기를 작성합니다.

 .homepage { @extend page; @include border-radius(5px); margin-left: 5px; &:after{ content: ''; } a { } ul { } }

몇 가지 명명 규칙

스타일 북의 명명 규칙 부분은 개발자들 사이에서 인기를 얻은 기존의 두 가지 BEM 및 SMACSS 명명 규칙을 기반으로 합니다. BEM은 Block, Element, Modifier의 약자입니다. 이것은 YANDEX 팀에 의해 개발되었으며 BEM의 배경은 개발자가 프로젝트에서 HTML과 CSS 간의 관계를 이해하도록 돕는 것이었습니다. 반면 SMACSS는 CSS를 위한 확장 가능 및 모듈식 아키텍처를 나타냅니다. 유지보수가 가능하도록 CSS를 구성하는 가이드입니다.

이에 영감을 받아 명명 규칙은 다음과 같습니다.

• 각 요소 유형에 접두어를 사용하십시오. 레이아웃( l- ), 모듈( m- ) 및 상태( is- )와 같이 블록에 접두사를 붙입니다.
• 모든 블록의 하위 요소에 두 개의 밑줄을 사용합니다.

 .m-tab__icon {}

• 모든 블록의 수정자에 두 개의 대시를 사용합니다.

 .m-tab--borderless {}

변수

변수를 사용합니다. 색상과 같은 보다 일반적이고 전역적인 변수로 시작하고 _colors.scss 에 대해 별도의 파일을 만듭니다. 스타일 시트에서 일부 값을 여러 번 반복하는 것을 발견하면 해당 값에 대한 새 변수를 생성하십시오. 건조하십시오. 그 값을 변경하고 싶을 때, 그리고 한 곳에서만 변경해야 할 때 감사할 것입니다.

또한 하이픈을 사용하여 변수 이름을 지정합니다.

 $red : #f44336; $secondary-red :#ebccd1;

미디어 쿼리

Sass를 사용하면 미디어 쿼리를 요소 쿼리로 작성할 수 있습니다. 대부분의 개발자는 별도의 파일이나 규칙 맨 아래에 미디어 쿼리를 작성하지만 권장하지 않습니다. Sass를 사용하면 미디어 쿼리를 중첩하여 다음 예제와 같은 것을 작성할 수 있습니다.

 // ScSS .m-block { &:after { @include breakpoint(tablet){ content: ''; width: 100%; } } }

이렇게 하면 다음과 같은 CSS가 생성됩니다.

 // Generated CSS @media screen and (min-width: 767px) { .m-block:after { content: ''; width: 100%; } }

이 중첩 미디어 쿼리 규칙을 사용하면 명명된 미디어 쿼리가 사용되는 Sass 스니펫에서 볼 수 있듯이 덮어쓰는 규칙을 매우 명확하게 알 수 있습니다.

명명된 미디어 쿼리를 만들려면 다음과 같이 믹스인을 만듭니다.

 @mixin breakpoint($point) { @if $point == tablet { @media (min-width: 768px) and (max-width: 1024px) { @content; } } @else if $point == phone { @media (max-width: 767px) { @content; } } @else if $point == desktop { @media (min-width: 1025px) { @content; } } }

미디어 쿼리 이름 지정에 대한 자세한 내용은 미디어 쿼리 이름 지정 및 Sass로 더 나은 미디어 쿼리 작성 문서를 참조하세요.

기타 고려 사항

마지막으로 다음은 염두에 두고 따라야 하는 몇 가지 다른 고려 사항입니다.

• 공급업체 접두사를 작성하지 마십시오. 대신 자동 접두사를 사용하십시오.
• 중첩 규칙에서 최대 3개 수준의 깊이를 사용합니다. 3개 이상의 중첩 레벨을 사용하면 코드를 읽기 어려울 수 있으며 아마도 형편없는 선택기를 작성하고 있을 것입니다. 결국 HTML과 결합할 CSS 코드를 작성하게 됩니다.

 .class1 { .class2 { li { //last rules } } }

• 50줄 이상의 중첩 코드를 작성하지 마십시오. 또는 X줄 이상의 중첩 코드를 작성하지 않는 것이 좋습니다. 자신의 X를 설정하지만 50은 좋은 제한처럼 보입니다. 그 한계를 넘으면 코드 블록이 텍스트 편집기 창에 맞지 ​​않을 수 있습니다.
• 모든 블록, 부분 및 구성을 가져올 기본 파일을 작성하십시오.
• 먼저 공급업체 및 글로벌 종속성을 가져온 다음 작성된 종속성을 가져온 다음 레이아웃, 패턴, 마지막으로 부품 및 블록을 가져옵니다. 공급업체 및 글로벌 규칙은 당사에서 관리할 수 없으므로 혼합 가져오기 및 규칙 덮어쓰기를 방지하는 것이 중요합니다.
• 부끄러워하지 말고 가능한 한 많은 파일로 코드를 나누십시오.

결론

이 스타일 가이드의 배경은 Sass 코드 작성 방식을 개선하는 방법에 대한 조언을 제공하는 것입니다. Sass를 사용하지 않는 경우에도 이 스타일 가이드에 제공된 팁과 규칙이 적용되며 Vanilla CSS 또는 다른 전처리기를 사용하는 경우 따를 것을 권장합니다. 다시 말하지만, 규칙에 동의하지 않는 경우 생각 방식에 맞게 규칙을 변경하십시오. 결국 이 스타일 가이드를 적용하거나 다른 스타일 가이드를 사용하거나 완전히 새로운 스타일 가이드를 만드는 것은 귀하와 귀하의 팀의 몫입니다. 가이드를 정의하고 멋진 코드 작성을 시작하세요.