들어가기에 앞서 이 질문이 나온 이유 (구구절절)
현재 서버상태관리 라이브러리로 react-query(TanStack Query v4) 를 사용하면서
queryKey를 각 사용되는 useQuery에서 string으로 사용하고 있어서
ex) ('user' , getSomething)
- 어느 쿼리에서 어떤 쿼리키를 가지고 있는지
- 현재 어떤 쿼리키가 사용중인지
한눈에 파악하기 어려웠다.
현재 정의되어있는 API에서 비슷한 맥락의 API가 추가되면
이미 사용중이던 쿼리키를 쓰는 경우가 발생했고,
그러지 않기위해 생성되어있는 쿼리들에 어떠한 queryKey를 수동으로 확인하게 되면서
불편함을 느껴 주위에 다른 프론트엔드분들은 어떻게 queryKey를 사용하지는지 궁금해 여쭤보게 되었는데 아래와 같이 사용하고 있는 예시를 보게되어 적용하게 되었는데..
export const QUERY_KEYS = [
USER : "USER"
]각 단어들을 구분지어주게 될 경우에는 아래와 같이 가독성이 매우매우 떨어지는.. 쿼리키가 생기게 되었다.
예시는 두개뿐이지만 많은 쿼리키들이 생기게 되면서 눈이 혼란스러워졌고,
사용하는쪽에서도 그렇게 썩 좋지 않은 가독성을 가지게 되었다...
export const QUERY_KEYS = [
USER : "USER" ,
"USER_NAME" : "USER_NAME"
]
// 사용될 때
[QUERY_KEY['USER-NAME']],하지만 초기에 잡고자 하는 목표는 해결되었기에
- 쿼리키 한눈에 파악하기
- 참조해서 사용하여 휴먼에러 줄이기
이상하다는 생각이 듦(가독성이 구리다)에도 불구하고 !
문제가 없다고 생각되어 PR을 올렸고
이러한 질문을 받게 되었다
상수에 왜 대문자를 썼나요
상수가 뭐라고 생각하나요
(가독성이 안좋다고는 생각했다는 의견을 들으시고는) 왜 그렇게 생각했는지
더 좋은 참조방법에는 무엇이 있을지
놀랍게도 문제라고 생각했던 부분임을 인지하였음에도
이러한 질문을 받고 단 하나도 제대로 대답하지 못했다.
1) 말하면서도 자신이 없으니 제대로 된 문장을 구사하지 못했고
2) 상수가 뭐라고 생각하는지에 명확하게 설명하지 못했고
3) 문제를 인지하였음에도 불구하고 제대로 찾아보지 못한 내 자신이 부끄러웠다
위 질문을 듣고
(1) 뒤늦게라도 .. 답변을 드리기 위해 🥲
(2) 정말 왜 대문자로 쓰는가? 에 대한 궁금증
(3) 질문에 대한 답변을 머릿속에서 띄워놓지말고 글로 정리해놓기
를 위해 찾아보면서 간략하게 정리하고자 한다
본문
상수란 ?
프로그래밍에서 상수는 변하지 않는 것
⇒ 변수 : 데이터를 저장할 때 쓰이는 ‘이름이 붙은 저장소’
⇒ 상수 : 변화하지 않는 변수를 선언할 때 쓰임
- 자바스크립트 객체 [key:value / property] 에서 상수
대문자로 쓴 일반적인 프로퍼티를 상수로 간주하는 것.object.property object['property']
그래서 나는 왜 대문자를 썼는가 ?
내가 사용한 쿼리 키는 변하지 않는 값이였기에 타당한 사용이라 생각되었다
그리고 이렇게 값이 정해져있다면 대문자로 쓰는 관례가 있었기에 별 생각 없이 사용했던거 같다.
찾아본 내용
⇒ 변수명과 구분되게 대문자로 하는것이 관례 , 가독성을 높일 수 있다 (자바)
⇒ 일반적으로 말해서 상수를 대문자로 표시하는 것이 일반적입니다. 이것은 값이 고정되어 있음을 다른 프로그래머에게 알리는 규칙입니다
⇒ 대문자 상수 : 기억하기 힘든 값을 변수에 할당해 별칭으로 사용되는 관습
=== 대문자 상수는 ‘하드 코딩한’ 값의 별칭을 만들 때 사용
사용하는 이유
→ 값보다 상수가 더 기억하기 쉬워야한다
→ 값보다 상수를 사용하는 것이 오타를 낼 확률이 낮다
→ 값보다 상수가 훨씬 유의미함으로써 코드 가독성이 증가한다
그렇다면 나는 맞게 적용하였는가 ? ❌
지금 바뀐 QUERY_KEYS는 위와 같은 장점이 있는가?라고 생각하면 키와 값이 동일하게 사용되기때문에 하나도 가지고 있지않음
참조할 수 있기때문에 여러곳에서 사용하게 될 경우 오타를 낼 수 있는 장점만 가져갈 수 있음
간단하게 요약되어있는 내용들을 보면서 key와 value 값을 동일하게 사용하였기에 사용하여야 되는 이유를 가지지 못한채로 사용하게 된 것 같았다.
다음에 상수를 사용해야하나 라는 생각이 들때 다시 한번 고민해볼 수 있는 지표가 생겼다.
그 외 여러 아티클 요약
이 부분에서 여러 아티클을 참조해보았는데 이런 글을 보게되었다.
대문자 사용 규칙은 C에 뿌리를 두고 있다.
C는 컴포일 된 언어(다른 프로그램이 실행되기 전에 모든 코드를 기계코드로 변환)
Javascript는 인터프리터 언어(코드가 실행될 때 줄 단위로 코드를 읽음)
C에서 상수 값을 선언하는 방식에 영향을 미친다
컴파일 하기 전 사전컴파일 단계에서 컴파일러는 상수의 모든 인스턴스를 해당 값으로 바꿈
#define hoursInDay 24 // 24C에서는 한번에 기계코드로 변하기에 명확한 값을 상수로 유지하였고,
javascript 에서 이와 같은 뜻을 유지하고자
const, let 이 도입되기 전 var를 사용할 때에는
대문자를 이용해 일정하게 유지하고자 하는 가치를 볼 수 있게 해주었다고 한다.
여기서 저자는 아래와 같이 const 상수에 대해 언제 써야하는지 말한다.
const변수는 참조하는 값은 변경할 수 있기에 대문자로 사용할 것이라면 두가지를 확인해야 된다.
1. 변수의 값이 기본 값 입니까?
2. 프로그램 전체에서 동일한 값을 가리키는 변수 이름을 유지하려고 합니까?
⇒ 둘다 예 일때 consf 선언 요점은 자바스크립트에서 상수를 정의할때 프로그래머의 의도가 포함되어야 한다
const는 object 내부의 값을 변경할 수 있기에 상수로써의 쓰임은 명확하다고 볼 수 없다.
만약 정말 변하지 않는다면 그때 const로 선언해야 한다고 말한다
하고 에어비앤비 스타일 가이드를 링크로 걸어놔주어서 따라 들어가봤다.
(약간 요지가 어긋난거 같기도..)
에어비앤비 스타일 가이드
// bad - unnecessarily uppercases key while adding no semantic value
의미론적 값을 추가하지 않으면서 불필요하게 키를 대문자로 함
-> 이 부분이 내가 한 행동이라고 생각 되었다
// bad
const PRIVATE_VARIABLE = 'should not be unnecessarily uppercased within a file';
// bad
export const THING_TO_BE_CHANGED = 'should obviously not be uppercased';
// bad
export let REASSIGNABLE_VARIABLE = 'do not use let with uppercase variables';
// ---
// allowed but does not supply semantic value
export const apiKey = 'SOMEKEY';
// better in most cases
export const API_KEY = 'SOMEKEY';
// ---
// bad - unnecessarily uppercases key while adding no semantic value
export const MAPPING = {
KEY: 'value'
};
// good
export const MAPPING = {
key: 'value',
};오버스택플로우
위 글에서도 상수를 대문자로 표시하는 것이 일반적이라고 한다.
대문자로 표기함은 값이 고정되어 있음을 다른 프로그래머에게 알리는 규칙이기에
관례를 지키되 CONSTANT와 관련된 경우에만 사용하라고 답변에 나와있다.
그 아래 다른 답변으로는 이런 내용이 있었는데 맞는 말인거 같아서 가져오게되었다 👀
나는 당신과 당신의 코드로 작업할 수 있는 다른 사람들을 위해 좋은 것을 코딩하는 것이 중요하다고 생각합니다.
프로젝트와 일관성을 유지하고 팀이 코드를 작성하는 것과 동일한 방식을 따르는 한 괜찮을 것이라고 확신합니다.결론
결국 대문자는 고정값임을 알리는 프로그래머들의 약속인거 같다.
하지만 우리팀에서는 가독성을 더 중시하고싶기에 위에서 알아본 내용을 토대로 정리해서
userName : "userName"
과 같이 쿼리키를 정리해보겠다고 말씀을 드려볼 예정이다.
이 규칙이 C에서 뿌리를 두었다는 내용은 처음 알게되어 신기했다.
회고 겸 ,,
우선, 왜 문제를 인지하고도 제대로 찾아보려하지 않았음에 대해서 스스로 고민하게되었고
다음부터 문제를 인지하였다면
- 왜 이상하다고 느꼈는지
- 이상하다고 생각되는 부분은 어떻게 되어서 사용하게 된 것인지
- 개선점이 있는지
위 세가지를 중점으로 다시 한번 더 생각해야겠다 😌
새벽에 써서 글이 엉망진창인거같은데 아침에 다시 한번 읽어보고 정리해야겠다.
