코드 냄새 159 - 혼합 케이스

진지한 개발은 다양한 사람들에 의해 이루어집니다. 동의를 시작해야 합니다.

TL;DR: Don't mix different case conversions



문제


  • 가독성
  • 유지 보수 용이성

  • 솔루션


  • 케이스 규격 선택
  • 힘내세요

  • 문맥



    서로 다른 사람들이 함께 소프트웨어를 만들 때 개인적 또는 문화적 차이가 있을 수 있습니다.

    일부는 camelCase 🐫, 다른 것들은 snake_case 🐍, MACRO_CASE🗣️ 및 many others 을 선호합니다.

    코드는 간단하고 읽기 쉬워야 합니다.

    샘플 코드



    잘못된




    {
        "id": 2,
        "userId": 666, 
        "accountNumber": "12345-12345-12345",
        "UPDATED_AT": "2022-01-07T02:23:41.305Z",
        "created_at": "2019-01-07T02:23:41.305Z",
        "deleted at": "2022-01-07T02:23:41.305Z"
    }
    

    오른쪽



    {
        "id": 2,
        "userId": 666, 
        "accountNumber": "12345-12345-12345",
        "updatedAt": "2022-01-07T02:23:41.305Z",
        "createdAt": "2019-01-07T02:23:41.305Z",
        "deletedAt": "2022-01-07T02:23:41.305Z"
      // This doesn't mean THIS standard is the right one
    }
    

    발각



    [X] 자동

    우리 린터들에게 우리 회사의 브로드에 대해 알리고 이를 집행할 수 있습니다.

    새로운 사람들이 조직에 도착할 때마다 자동 테스트는 그/그녀/..에게 코드를 변경하도록 정중하게 요청해야 합니다.

    예외



    범위 밖의 코드와 상호 작용해야 할 때마다 우리 표준이 아닌 클라이언트 표준을 사용해야 합니다.

    태그


  • 네이밍

  • 결론



    표준을 다루는 것은 쉽습니다.

    우리는 그것들을 강제할 필요가 있습니다.

    처지







    더 많은 정보






    All naming conventions

    부인 성명



    코드 냄새는 그냥 내 .

    학점



    사진 제공: Wolfgang Hasselmann on Unsplash


    If you have too many special cases, you are doing it wrong.



    크레이그 제로니






    이 기사는 CodeSmell 시리즈의 일부입니다.


    좋은 웹페이지 즐겨찾기