프로그래밍 언어는 기계가 아닌 사람을 위해 쓰였다.
컴퓨터는 코드를 실행하고, 사람은 코드를 읽는다.
누가 했는지는 잘 모르지만, 유명한 말이 있다.
프로그램은 읽을 수 있게 작성되어야 한다. 실행은 부차적인 일이다.
뭣도 모르고 프로그래밍을 처음 시작했을 땐, 구현이 전부라고 생각했었지만
개인프로젝트를 하면서 이제 정말 저 말이 깊게 와닿는 거 같다.
기나긴 로직을 구현한다면 오류하나 없는 복잡한 코드보다
오류가 있는 읽기 쉬운 코드가 좋다.
코드가 읽기 쉽다면 버그가 발생해도 금방 찾을 수 있다.
유지보수가 쉬운 스타일과 (객체지향 SOLID라던가), 읽기 쉬운 스타일은 같은 개념은 아니다.
하지만 읽기 쉽다면 유지보수 역시 쉽다.
다음 코드는 내가 처음 짠 코드이다.
# 이름의 길이를 계산해주는 프로그램
print(len(input("what is your name?")))이 코드는 다음과 같이 고쳐 쓸 수 있다.
user_name = input("what is your name?")
len_user_name = len(user_name)
print(len_user_name)아래의 코드는 위의 코드보다 장황하지만 그 과정을 명확히 이해할 수 있다.
그리고 아마도 저게 더 잘 쓰인 코드일 것이다.
만약 코드에 오타가 있을 경우,
아래의 코드에서 더 찾기 쉽다.
또 실행 과정의 순서가 더 명백하며,
user_name과 len_user_name를 재활용할 수도 있다.
*물론 위의 코드정도도 허용범위 이내이긴 하다.
앞으로 이 게시판에선
내가 그동안 실습했던 코드들을 리팩터링 할 예정이다.
파이썬에는 스타일 가이드만을 위한 문서도있다.
멍청한 일관성은 홉고블린의 작은 지성이다.
귀도*(파이썬 창시자)의 핵심적인 직관 중 하나는,
코드는 쓰이는 것보다 읽히는 일이 훨씬 많다는 것이다.
이 가이드라인은 가독성을 향상하기 위해 소개되었으며
다양한 형태의 파이썬 코드들에 일관적으로 적용될 수 있다.
pep20이 말하는 것처럼, "가독성은 중요하다."
대문의 세 번째에 걸려있는 섹션이다.
little minds는 *집단지성 + 아름다운 지성을 포괄하는 반대말인듯하다
pep20의 파이썬의 철학으로 글을 마무리하겠다.
https://peps.python.org/pep-0020/
Beautiful is better than ugly.
아름다운 것이 못생긴 것보다 낫다.
Explicit is better than implicit.
명백한 것이 암시적인 것보다 낫다.
Simple is better than complex.
간단한 것이 복합적인 것보다 낫다.
Complex is better than complicated.
복합적인 것이 복잡한 것보다 낫다.
Flat is better than nested.
평평한 것이 중첩된 것보다 낫다.
Sparse is better than dense.
여유로운 것이 빽뺵한것보다 낫다.
Readability counts.
가독성은 계산되어야 할 것이다 (중요하다.)
Special cases aren't special enough to break the rules.
특별 항목들은 규칙을 깰 만큼 특별하지 않다.
Although practicality beats purity.
비록 실용성이 순수함을 이길지라도
Errors should never pass silently.
오류들은 침묵을 지켜선 안된다.
Unless explicitly silenced.
명백하게 고요한경우를 제외한다면
In the face of ambiguity, refuse the temptation to guess.
모호함을 직면할 때, 추측의 유혹을 억제하라.
There should be one-- and preferably only one --obvious way to do it.
그곳엔 하나의, -- 아마도 단 하나의- 명백한 길이 있다.
Although that way may not be obvious at first unless you're Dutch.
당신이 네덜란드인이 아니라면 길은 원래 처음부터 명백한 것은 아니다. * 네덜란드인은 왜...?
Now is better than never. Although never is often better than *right* now.
지금이 기약 없는 영원 보단 낫다. 그것이 때때로는 지금 "당장"보단 낫더라도.
If the implementation is hard to explain, it's a bad idea.
만약 실행의 설명이 어렵다면, 그것은 나쁜 생각이다.
If the implementation is easy to explain, it may be a good idea.
하지만 이행을 말하기에 주저함이 없다면, 그것은 좋은 생각일 수 있다.
Namespaces are one honking great idea -- let's do more of those!
네임스페이스는 포효 중인 굉장한 아이디어다. -- 어서 그런 것을 좀 더 해보자.
읽어주셔서 감사합니다.
오탈자나 에러가 있다면 댓글로 알려주세요.
* 제 코드는 pep을 적용하여 리팩터링 한 것은 아닙니다.