var 사용에 관한 고민
var가 편하긴 하지만 적재적소에 잘 사용해야 한다.
결국 코드가 읽기 쉬워야 하는데 var를 사용함으로써 코드가 읽기 힘들어 진다면 피해야할 부분이다.
"난 객체를 만들땐 사용하고 자료형 변수를 선언할 땐 사용하지 않는다.
if와 swith의 사용 고민
결국 이 코드를 나중에 수정할 때 버그가 나올수 있는 여지를 주느냐 마느냐에 대한 고민, if를 쓰면 조건을 확장하기 편한 대신에 코드 가독성이 떨어진다 이 부분을 명심하고 잘 사용해야 한다.
for와 foreach 사용 고민
컴퓨터가 좋아져서 성능에 대한 고민은 불필요 하다. 결국 if와 switch같이 for를 쓰면 i Index를 활용할 수 있다. 인덱스가 필요 없다면 foreach를 이용하자
while 사용 고민
난 보통 while를 피하긴한다 하지만 꼭 필요한 순간이 있다. (계속 루프를 돌다가 어떤 상황에서 그만두어야 할 때) 아니라면 for와 if로 쓰는것이 훨씬 가독성이 좋다
do의 사용고민
개발자하면서 꼭 필요했던적이 두세번 있었던 것 같다. 꼭 필요할 때 빼고는 쓰지말자 가독성 떨어 진다.
루프는 꼭 필요한 순간에만 쓰자
습관적으로 루프를 쓰는 경우가 있는데 되도록 뺄수 있으면 빼고 되도록 쓰지말자. 루프의 남용은 프로그램의 성능을 크게 하락시킨다.
사용자 클라이언트라하면 루프는 되도록 비동기적으로 구현하자
스마트폰이튼 응용프로그램이든 루프는 사용자를 기다리게 하는 요소중 하나이다 async, await키워드를 잘 사용해서 비동기적으로 구현하는 생각을 해야한다.
해제되지 않는 참조
GC가 많이 좋아졌고, 사용자의 메모리량이 좋아졌지만 개발자는 항상 메모리를 신경써야 한다. 사용하지 않는 참조는 null로 초기화 해주고 다른 클래스 끼리 순환참조가 되지 않도록 주의해야 한다.
그리고 왠만하면 배열은 쓰지말자..배열은 생성때 부터 메모리가 고정되어 추가/삭제가 까다롭다 동적메모리 객체를 사용하자
너무 어렵게 표현된 코드
보통 짧은 경력을 가진 개발자는 표현력이 너무좋아서 프로그램을 좀 장황하게 짜는 경우가 많다. 되도록 간결하게 짜서 프로그램이 잘 돌아가는게 가장 좋은 코드다 항상 의심하고 줄일 수 있는 코드가 있는지 확인해 보자
(너무 줄일려고 노력하다보면 가독성이 엄청 떨어지는 코드를 짜게된다. 남들이 보고도 잘 이해 될 수 있도록 중간지점을 잘 찾아야 한다.)
형변환은 컴퓨터의 리소스를 많이 사용한다.
개발을 하면서 형변환을 하게될텐데 이 형변환을 얼마나 적게 잘 하느냐가 좋은 코드와 나쁜 코드가 될 수 있는 갈림길이다.
짬뽕클래스
간혹, 클래스 하나가 엄청 길어지는 코드를 볼 때가 있다. 클래스 안의 정의된 함수도 짬뽕이다. 정확한 사용처, 분류, 활용목적등을 생각해서 클래스는 확실하게 분리하자!, 그리고 나중에 확장성을 생각해서도 분리해야 한다.
public 남용
클래스나 함수를 만들때 습관적으로 public으로 선언하는데 이건 엄청 위험한 생각이다. 나중에 버그로 이어질 수 있기 때문이다. 꼭 필요한 함수만 public을 붙여주자
static 남용
static으로 선언된 변수는 프로그램에서 단 하나의 인스턴스만 생성이 된다. static은 웹에서는 절대 사용하지 말아야하고(간혹 필요할 경우가 있긴하지만..)프로그램에서도 사용하지 않는게 좋지만 꼭 필요하면 싱글톤패턴을 이용해서 확실히 명시해놓고 사용하는게 좋다.
using의 사용
사용하려는 클래스가 dispose를 상속받고 있다면 꼭 using을 사용해주는 것이 좋다.
const, readonly키워드 사용
해당 변수가 상수의 역할이라면 (선언과 함께 초기화) 꼭 const, readonly키워드를 붙여주자 가독성이 많이 차이난다.
if else if는 순서가 중요하다!
if문은 위에서부터 조건이 처리가 되므로 순서가 중요하다 꼭 순서를 잘 생각해서 조건문을 만들자
클래스를 포함하는 클래스 즉 깊은 클래스 계층 꼭 필요할 경우에만
귀찮아서 클래스 안에 클래스를 만드는 경우는 프로그램이 허용하지만 가독성이 많이 떨어지게 된다. 꼭 필요한 경우가 아니라면 하지말자.
네임스페스는 서로 다르게
상위네임스페이스가 다르다고 같이 네임스페이스를 사용하지 말자 이건 나중에 엄청난 버그를 몰고 온다 (리팩토링도 힘들어 진다. )되도록 개발자들 끼리 의논을 하여 서로 다른 네임스페이스를 사용해야 한다.
같은 인수인데 호출하는 쪽에서 서로 다른 의미의 인수를 사용하지 말자
두개의 인수를 받는 함수가 있다고 하면 X에서 호출할땐 인수가 A,B의미이고 Y에서 호출할땐 A,C의미의 인수일땐 A,B,C이렇게 인수를 만들어 주자
except 계층을 잘 활요하자
간혹 catch문에 아무것도 적히지 않는 코드를 본다. 하지말자. 해당 함수가 호출 최상단이라면 except를 꼭 처리해주고 만약 호출 당하는 클래스라면 throw를 통해서 밖에다 예외를 전달해주자. 필요없는 예외라면 넘거야 겠지만 이러면 버그 찾기가 힘들어 진다.
throw를 활요하자
클래스를 만들때 인수나 예외적인 상황이 나왔을 때 if를 통해 조기리턴을 해주고 꼭 throw통해 알려주자
의미없는 상속은 피하자
상속해놓고 코드는 상속이 필요없는 코딩만 하고 있으면 해당 코드를 읽는 개발자는 왜 상속을 했는지 찾게 될것이다.
변수명, 클래스명, 함수명
변수명, 클래스명, 함수명은 길어져도 되니 의미를 알수 없는 그런 단어는 피하자. 정확한 의미를 알 수 있도록 변수명을 정하자 보통 2~4단어의 조합정도가 좋은거 같다.
책을보다 같이 공유하면 좋을거 같아서 정리합니다.
항상 코딩할 때 다른 개발자를 의식하며 코딩을 하는 습관을 갖는게 좋습니다.
대부분 혼자 개발하는건 아니니깐요.
'[개발] 이야기' 카테고리의 다른 글
xamarin 빌드 출력파일 apk => aab로 변경하기 (0) | 2022.04.06 |
---|---|
개발자 무료 가독성 폰트 추천 K-Font - d2coding (0) | 2022.04.06 |
2021맥북 M1 Pro/Max는 아직 우리가 받아들이기에는 제세상 제품인가 - 개발자가 느끼는 M1칩 (0) | 2021.12.07 |
VSCode의 '파일' 메뉴에 대해서 잘 아시나요 - 하나하나 뜯어보기 (0) | 2021.12.06 |
VSCode 작업영역(WorkSpace)을 아직 사용하지 않는다구요!? (0) | 2021.12.06 |
댓글