/bemaru/dev/log

개요

• 최근 python 코드를 리팩토링하는 일이 많은데, 그 이유는 분석을 잘하기 위해서다.
• 기존 시스템 코드 대부분이 남이 만든 코드가 90% 이상인데, 읽기 좋은 코드는 아니다. 
• 물론, 리팩토링을 하지 않아도 분석 할 수는 있다.
• 하지만, 나는 리팩토링을 했다. 왜?
• 기존 코드를 그대로 분석 vs 리팩토링 + 가독성 개선 후 분석 에 들어가는 리소스(시간)만 봤을때
  후자가 더 효율적이기 때문이다. (이 이야기는 여기서 길게 할 필요는 없으므로 생략한다..)
• 여튼, 리팩토링을 계속 하면서 반복되는 패턴이 생겨, 이 글에서 규칙을 정리하려 한다.
• 보편적인 python 코딩 컨벤션의 기본적인 내용도 일부 포함된다.

규칙

1. import 문 정리
   • import 문을 알파벳 순서로 정렬한다.
   • IDE를 통해 없는 package 를 자동으로 import 하면, 알아서 적절한 곳에 배치할 수 있다.
   • isort 를 사용하는 방법도 있다.
   • import 문 순서가 안맞더라도 사실 코드 분석에 크게 영향이 있진 않지만, 안맞으면 거슬린다..
2. 네이밍 스타일
   • https://peps.python.org/pep-0008/#naming-conventions
   • PEP8에 네이밍 스타일에 대한 설명을 읽어보면 도움이된다.
   • 변수, 함수이름은 snake_case
   • 함수는 PascalCase
   • Pylint 나 IDE의 intellisense 에서도 PEP 에 맞지 않는 스타일에 대해 경고 알림을 얻을 수 있다.
   • 레거시 코드에서 이런 기본적인 네이밍 스타일이 안지켜지면 너무 속상하다.
3. 클래스
   • 클래스 없이 많은 함수가 나열된 py 파일을 보면 한숨나온다.
   • 기본적으로 모듈(.py 파일)과 클래스는 1:1 대응을 선호한다. ( 그렇게 안되는 경우도 당연히 있다.)
   • 클래스 멤버 함수 네이밍
     • python에서 공식적인 private 함수는 없지만, 관례상 _로 시작하곤 한다.
       • ex> def _my_private_method(self):
     • 멤버 변수, 함수의 정의 순서도 가독성에 많은 영향을 끼친다.
     • writer는 reader 에게 중요한 정보가 먼저 보이도록 고려하며 작성해야한다.
     • 멤버 정의 순서
       • 클래스 상수: _MY_CONSTANT
       • __init__ 함수
       • 오버라이딩 함수: @override
       • public 함수: my_public()
       • private 함수: _my_private()
       • 호출 계층 깊이가 얕은 함수
       • 호출 계층 깊이가 깊은 함수
4. 데코레이터 표기하기
   • @override
   • @deprecated
   • @property
   • 기타 등등 알맞은 데코레이터 표기로 가독성을 개선하면 코드가 읽기 수월하다.
5.  기타
   • IDE 가 알려주는 경고는 웬만하면 모두 해결하기.
     • for key in my_dict -> for key, value in my_dict.items()
   • early return
   • 함수 호출 계층 참고하기. (vscode F12)
     • 어디서 호출되고 사용되는지 참고하여, 리팩토링 후 영향도를 고려한다.

In C90, main() must have an explicit return statement at the end to avoid undefined behaviour. In C99 and newer, you may omit the return statement from main(). If you do, and main() finished, there is an implicit return 0.

C90에선 main() 함수에서 무조건 반환 타입을 정의 해야했지만,

C99부터 묵시적으로 return 0 를 수행하기 때문에 생략가능해졌다.

참고 : https://stackoverflow.com/questions/204476/what-should-main-return-in-c-and-c

gitlab 사용하다보면 이모지 쓰기가 어렵다

따로 메뉴가 없고 이모지 코드를 써야하는데

괜찮은 cheat sheet이 있어서 메모한다.

https://github.com/yodamad/gitlab-emoji

아래 이거 퍼온건데 우리쪽 gitlab 저장소에도 적용해봐야겠다. 귀엽네.

현회사 컨벤션 중 커밋 메세지에 #으로 시작하는 부분이 있는데,

git bash 에서 하려니 생략되어 버림.

왜냐하면 #을 주석으로 처리하기 때문인데..

git commit -a 를 하게 되면 아래처럼 자동으로 주석이 생긴다.

검색해보니 stack overflow 형님들이 알려주신다

https://stackoverflow.com/questions/2788092/start-a-git-commit-message-with-a-hashmark

결론적으로, 아래 명령어를 통해 주석 문자를 지정할 수 있고

git config core.commentChar ";"

아래처럼 자동 생성되는 주석에도 자연스럽게 반영되는걸 확인했다.

(근데 하이라이트는 왜 없어졌을까? 하이라이터에서 #을 인식하는듯하다. 다른 PC에서 했을땐 괜찮았는데;;)

끝