좋은 코드는 언어나 기술에 종속되지 않는다.
그렇지만 코딩을 하면서 매일 드는 생각은 '그래서 이게 잘 짠 코드인가?' 이다.
결론부터 말하자면, 내가 생각하는 잘 짠코드의 정의는 단 두가지로 함축될 것 같다.
1. 남들이 읽기 쉬운가? a.k.a 가독성
이 '남'의 정의를 코드를 짠 이후의 미래의 '나'도 '남'에 포함해야한다고 본다.
시간이 지나고 다시 들여다 보면 내가 쓴 게 아닌 것 같다...
...그래서 보통 주석을 달곤하지만, 과연 그 주석도 잘 읽히던가?
2. 재사용이 가능한가 +모듈화
내가 짠 코드를 다른 프로젝트에서도 그대로 가져와 쓸 수 있는지,
그리고 타인이 사용했을 때도 간단하게 사용할 수 있는지
간단한 것 조차도 항상 확장성을 고려해서 짜야한다
위의 내용만 잘 지켜도 유지 보수가 쉽고 확장 가능한 프로그래밍이라 할 수 있을듯하다.
하지만, 그 디테일 함은 여전히 누구나 어려워한다. 그래서 나도 몇가지 규칙을 두고 코딩을 하려고 노력한다.
오늘은 그 규칙들 중 4가지 정도만 설명해보고자 한다.
1) 주석보다 코드내용에 집중하자
주석이 달린 코드는 이후 수정이 필요할때 수정하고 난 후 주석도 같이 수정해야하지만 생각보다 번거롭다.
특히나 협업의 경우 다른 팀원이 내 코드내용을 수정한 이후 주석도 같이 수정해주는 팀원은 희귀했다.
이런문제들로 쌓인 '잘못된 주석' 때문에 리딩을 다시 해야하는 경우도 종종 생긴다
2) 이름은 항상 중요
아래 3)항과 같은 내용이라고도 볼수 있을지 모르겠지만
변수명이 무엇을 담고있는 변수인지 구체적으로 명시하자.
string name; //(X)
string user_name; //(O)
마찬가지로 함수명도 어떠한 기능을 하는지에 대해 구체적이고 명확한게 좋다.
하지만, 이름을 짓는게 가장 고통스럽다
3) 조건은 항상 짧게
예시를 들어보면 바로 알 수 있다.
if(level > 1 && job == EJob.Designer && isWhiteUser)
{
//내용
}조건을 변수로 빼주고나면, 해당 조건문이 무엇을 뜻하는지 명확하게 알 수 있다.
bool isManager = level > 1 && job == EJob.Designer && isWhiteUser;
if(isManager)
{
//내용
}4) 리턴의 활용
코드를 보면 무슨 얘기를 할지 바로 이해할듯하다.
1.
public int GetUserPermission()
{
int permission;
if (IsWhiteUser()) //화이트유저인지체크
{
if (job == EJob.none) //Job이 공란일 경우
{
permission = 0;
}
else //Job이 공란이 아닐때
{
permission = level;
}
}
else
{
permission = 0;
}
return permission; //권한값을 리턴
}2.
public int GetUserPermission()
{
if (IsWhiteUser() && job != EJob.none) return level;
return 0;
}위 2개의 함수는 같은 기능을 한다.
그러나 1번 함수는 쓸데없이 이중 조건을 걸고 있다. (읽는데 거부감이 있다)
그리고 return에 대한 의미를 정확히 이해를 하지 못해 사족이 많이 길다.
당연하겠지만 if문에 들어가서 return이 되면 그 함수는 종료가 된다.
그럼 else는 필요가 없다.
//더 줄이자면 이렇게 변태같이 줄일 수도 있겠지만 좋은 예시는 아니라고 생각이 든다
public int GetUserPermission()=> (IsWhiteUser() && job != EJob.none) ? level : 0;
본인은 병적으로 코드최적화에 집착한다.
줄 수를 줄이면 최적화가 된다고 생각하는 사람이 많은 것 같은데, 맞는 말 같기도 틀린말 같기도 하다.
줄 수에 집착하기 보다는 정확한 플로우를 이해하는게 중요한 것같다.
즉, '실행 시점'과 '조건'을 잘 생각한다면 많은 것이 해결되더라.
더불어 enum의 활용과 코딩컨벤션, 상수활용 등 많은 방법이 있지만 커먼한 방법들이라 판단이되어 따로 게제하지는 않았다.
추후에 시간이 된다면 해볼지도..