From 0c8a17a8f345beab608bb0d5fd1736501990323d Mon Sep 17 00:00:00 2001 From: metacode22 Date: Tue, 9 Dec 2025 22:00:21 +0900 Subject: [PATCH] =?UTF-8?q?8=EC=9E=A5=20=EC=8B=A0=EC=8A=B9=EC=A4=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\354\213\240\354\212\271\354\244\200.md" | 29 +++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 "8\354\236\245/\354\213\240\354\212\271\354\244\200.md" diff --git "a/8\354\236\245/\354\213\240\354\212\271\354\244\200.md" "b/8\354\236\245/\354\213\240\354\212\271\354\244\200.md" new file mode 100644 index 0000000..db31ac8 --- /dev/null +++ "b/8\354\236\245/\354\213\240\354\212\271\354\244\200.md" @@ -0,0 +1,29 @@ +# 명명을 잘하는 방법 + +좋은 이름을 사용하면 LTM을 활성화하여 코드 도메인에 대해 이미 알고 있는 관련 정보를 찾을 수 있다. +반면 나쁜 이름은 코드에 대한 잘못된 추측을 하게 하고 오개념을 유발할 수 있다. + +## 이름이 중요한 이유 + +- 버틀러의 명명 규약 목록 + - 식별자는 대문자를 올바르게 사용해야 한다. 잘못된 예로는 paGecoUnter + +> 처음 보았을 땐 뭔지 진짜 1도 알아채지 못했었네요... + +### 이름의 품질 평가 시기 + +부하가 너무 높으면 좋은 변수 이름을 생각할 여유가 없을 수 있다. 당면한 문제 해결에 너무 골몰하여 좋은 이름을 떠올리지 못할 수 있다. +따라서 코딩 이외의 시간에 이름의 품질을 숙고하는 것이 바람직하다. 코드 리뷰는 식별자 이름의 품질을 검토하기에 좋은 기회다. + +## 이름이 버그에 미치는 영향 + +잘못된 명명 방식은 유지보수하기 어려운 코드일뿐만 아니라 잘못된 코드일 가능성이 높다. +따라서 잘못된 이름이 발생하는 위치를 찾아내는 것은 버그 발생 가능성이 있는 위치를 찾는 데 도움이 된다. + +## 더 나은 이름을 선택하는 방법 + +유사한 이름 틀을 사용하면 작업 기억 공간과 LTM에 큰 도움이 되기 때문에 각 코드베이스에서 사용할 수 있는 여러 가지 이름 틀을 미리 정해놓는 것이 좋다. + +> 정말 이전부터 고민하는 것인데요, 열린 상태를 다들 어떻게 표현하시나요? isOpen, opened, isOpened 등등 여러 가지가 있는데 다들 어떻게 하시는지 궁금해요. + +자연어에 맞춰 이름 틀을 사용하자. 영어 문장에서는 점수 최대라고 하지 않고 최대 점수라고 말한다. 따라서 points_max가 아니라 max_points가 더 좋다.