자신의 코드 규칙 작성

프로젝트 개발이 특정 단계에 도달하면 코드 보호 메커니즘 구축에 자원을 투자해야합니다. 이 기회는 정확하게 정의하기가 어렵습니다. 프로젝트가 오랫동안 안정적으로 실행되고 일부 문제가 발생하기 시작하지만 아직 혼란에 빠지지 않습니다. 조기 최적화를 피하고 너무 늦은 최적화를 피하십시오.

일부 도구는 구현하기가 매우 쉽고 일반적으로 프로젝트 초기에 사용할 수 있습니다. 예를 들어, 더 예쁜 코드 형식 도구는 코드 사양을 실시간으로 유지할 수 있습니다. 접근성, 호환성, 보안 코드 점검 등 인코딩 프로세스 중에 직접 사용할 수있는 유사한 도구도 많이 있습니다. Webhint는 많은 수의 도구를 통합하여 시도해 볼 가치가 있습니다.

코드를 보호하기 위해 더 많은 코드를 작성 해야하는 도구도 있습니다. 테스트는 그것의 중요한 부분이며 인코딩 중에 실행되도록 설정할 수도 있습니다. 테스트를 통해 코드가 예상대로 실행되므로 가치가 높습니다.

이 기사는 더 많은 코드를 작성하여 코드를 보호하는 데 중점을 두지만 전통적인 테스트가 아니라 사용자 정의 코드 확인 규칙입니다. 최근에 저는 사용자 정의 코드 확인 규칙에 관한 두 가지 기사를 발견했습니다.

• Benedict Quinn의 "Custom Eslint 규칙을 작성하는 방법"
• Omri Lavi의 "Custom Stylelint Rules- 첫 번째 규칙 작성"

나는 주로 코드베이스에서 eslint와 stylelint를 사용합니다. 그러나이 두 도구의 맞춤형 규칙 작성 프로세스는 상당히 복잡하다는 점에 유의해야합니다. AST (Abstract Syntax Tree)를 이해해야합니다. 이것은 if (rules.find.selector.startsWith("old")) throw("Deprecated selector.") 와 같은 간단한 진술과 완전히 다릅니다.

이것은 흥미로운 질문을 생각 나게합니다.

우리 팀은 오래된 프로젝트를 유지하고 있으며 많은 오래된 문제가있는 CSS 선택기를 제거하기를 희망합니다. 예를 들어, 누군가 HTML 파일을 열었고, 우리의 목표는 IDE를 코드 deprecated-selector 표시하고 오류를 확인 .ui-fresh\_\_selector 것입니다.

가장 먼저 떠오르는 것은 팀에 알려진 감가 상승 관계자를 찾아 경고를 발행하는 커스텀 스타일 린트 규칙을 작성하는 것입니다. 그러나 불행히도 스타일 린트는 CSS를 확인하는 데 사용되며 여기서 주요 문제는 HTML 인 것 같습니다. 나는 HTML-Inspector가 사용자 정의 규칙을 작성할 수 있다는 것을 알고 있지만 약간 구식이므로 성공할 것인지 확실하지 않습니다.

위 내용은 자신의 코드 규칙 작성의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!