요거는 사실 스타일 차이이다 보니까, ESLint, Biome 등으로 포매팅만 될 수 있다면 어느 한 쪽으로 정하면 될 것 같은데요 ㅎㅎ;;

굳이 정하자면 개인적으로는 C처럼 중괄호가 있는 세 줄을 선호해요. 추후 수정사항이 생겼을 때 Diff가 최소화될 수 있는 코드 스타일이 추후 Pull Request를 리뷰할 때 수월한 것 같아서요.

1안: 중괄호 있는 한 줄

예를 들어, 다음과 같이 조건이 만족될 때return null; 을 한 줄로 표현하는 상황을 가정해 볼게요.

if (condition1) return null;

추후condition1 인 경우에만 실행되는 새로운 코드가 추가되면 다음과 같이 여러 줄의 불필요한 Diff가 생겨요.

-if (condition1) return null;+if (condition1) {+  /* ... 추가적인 로직 ... */+  return null;+}

2안: 중괄호 있는 세 줄

다음과 같이 조건이 만족될 때return null; 을 세 줄로 표현하는 상황을 가정해 볼게요.

if(condition1){returnnull;}

추후condition1 인 경우에만 실행되는 새로운 코드가 있다면, Diff가 1줄로 최소화돼요.

if (condition1) {+  /* ... 추가적인 로직 ... */  return null;}

저같은 경우curly 규칙을 활용해서 린트로 통일해서 쓰고자 합니다..! 🙇‍♂️

전 초기에는 C로 쓰고, MR 올리기전에 만든거 코드 검수하면서 정말 변화가 없을 거 같다고 생각되는 조건문에 한하여,{} 를 지웁니다.

처음부터 A,B로 했다가 나중에 코드 한줄이라도 더 추가되면, 없던{} 다시 만들어야 하는게, 은근 스트레스더라구요!

큰 이유는 아니고 한 줄이 아닌 if 구문들하고 포멧이 다른 게 싫어서 C로 통일하는 편입니다

저는debugger; 를 추가해서 디버깅한다던지 잠깐 잠깐 diff 를 만들 때{}가 없으면 불편해서 그냥 C로 통일하는 편이에유

저는 C로 사용합니다.
중괄호 쓰는 방식과 한 줄 반환을 섞어쓰면 코드 읽을 때 일관성이 떨어져서,
저는 중괄호 스타일 하나만 쓰는 편입니다!

저는 C를 주로 사용하는 편입니다!
아무리 생각해도 정말 변화가 없을거 생각이 드는 부분에 대해서는 간단하게 A 방식을 사용하기도 합니다~

선호도 차이인거 같은데 C 같은 경우엔 한여름에 패딩입힌 느낌이라고 해야하나....

개인적으로는 A를 선호합니다.

저도 거의 C를 사용하되 가끔 A방식을 사용하기도 합니다.

중괄호를 사용해서 구문을 확실하게 표현하는걸 선호하여 저도 C를 선호 합니다.

A, C 를 적절하게 사용합니다.
보통의 개발자분들이 두가지 방식 모두 눈에 익어서 그렇게 코드 가독성을 해치는 것 같지 않아요.

저는 강력한 A파입니다 ㅎㅎㅎ 기왕 간결하게할수 있다면 줄이는게 깔끔하지요.

저도 개인적으로 A처럼 한 줄로 작성하는 것을 선호합니다. 하지만 상황에 따라 적절히 스타일을 섞어 사용하는 편입니다.

예를 들어, isLoading 상태처럼 빠르게 반환해야 하는 경우에는 A처럼 간결한 Early Return 스타일을 선호하고, 여러 조건에 대한 분기 처리를 해야 할 때는 가독성을 고려해 C 스타일을 사용하는 편입니다.

결국, 코드의 목적과 상황에 맞게 작성하는 것이 가장 중요한 것 같아요!

저는 원래 A를 선호했습니다. 간단해 보였거든요. 그런데 이제는 C처럼 작성합니다.

이유는 두 가지인데요.

• Diff가 세밀해 진다.
• 시선의 진행이 유지된다.

Diff가 세밀해 진다.

A처럼 조건과 해당 조건에서의 로직이 한 줄에 있을 때, 조건만 혹은 로직만 수정하였을 때 Diff만으로 한 눈에 둘 중 무엇이 수정되었는 지 알기 어렵습니다.

조건이 수정되었는지, return이 수정되었는지, 둘 다 수정되었는지 알기 위해서는 더 자세히 봐야만 합니다. 반면 C는 Diff가 어느 줄인지만 확인하면 되죠.

-if (condition1) return null;+if (condition2) return null;// 변경을 알기 위해선 조건과 리턴 모두 살펴야함-if (condition1) {+if (condition2) {// 조건문만 수정되었음을 쉽게 알 수 있음

시선의 진행이 유지된다.

C의 경우 첫 줄에서 조건을 확인 하고 다음 줄부터 해당 조건에서의 코드 진행을 확인 할 수 있습니다. 그러나 A의 경우 조건과 코드의 진행이 같은 줄이라 시선이 옆으로 이동하게 되는 차이가 있습니다.

return까지 여러 로직이 필요한 코드는 C처럼 작성할 수 밖에 없습니다. 그런데 이런 코드 사이사이에 A와 같은 코드가 있으면 시선의 진행이 달라지게 되고 별로일 수 있겠다고 생각이 들었어요. 물론 큰 차이는 아닌 것 같아서 "이런 생각도 해보았다..."정도입니다.

그런데 이런 이유들이 엄청나게 큰 영향을 미칠 것 같진 않아서 통일만 된다면 어떤 방법이든 좋을 것 같습니다.

개인적으로는 �Early Return을 위한 조건문이라는 의도를 확실히 보여주기 위해 A처럼 작성하는걸 선호 합니다.

그러나 간혹 if 블럭 내부에서 추가적인 작업이 필요할 경우 어쩔 수 없이 C 처럼 작성하게 되는데
이럴거면 그냥 다 C로 통일해야 하나 하는 작은 고민이 있습니다 ㅋㅋㅋ

그런데#41 (comment) 을 살펴보니, 지금은 C 쪽으로 생각이 조금 기울어 가는 것 같아요
Diff의 세밀함과 시선의 진행까지 고려하시다니 ... 👍👍👍

Early Return의 의도를 빠르고 명확하게 보여주기 위해서 A를 선호합니다.
눈에 익다보면 이 한 줄의 if문이 시각적인 필터링 처럼 느껴지는 효과도 있는 것 같아요.

Early Return 의 경우 대부분 간단한 로직이 많아서 A를 선호합니다.

누가 로직을 추가 해야 할 일이 절대 없다 가 아니면 3번

1번의 경우
영역 선택 > { 키 입력> 코드 입력

다음 사람을 위해 3번

저는 그나마 B 또는 C를 선호하는 편이에요.
수정사항이 없을 것 같을땐 2번, 수정사항이 있을 예정이라면 3번인데 아무래도 다음줄에 다음 코드가 나오는게 적절하다고 생각하거든요.

거의 A와 C의 용호쌍박...

저는 A, C 를 상황에 따라 구분해서 사용하는 편입니다.

A Case. 함수의 메인 로직 실행 전 검증 로직의 경우 한 줄로 사용합니다.
C Case. 함수의 메인 로직에 포함되는 경우 중괄호를 사용합니다.

functionfoo(){// Validation Logicif(!ref)return;// Main Logicif(typeofref.current==="number"){returnref.current+1;}if(typeofref.current==="function"){returnref.current();}return0;}