슭의 개발 블로그

이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다. 보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다. 이때까지 정규식에서 \d는 당연히 [0-9]와 동일하다고 생각했는데 아니였다... c#에서는 \d가 digit이라는 이름에 걸맞게 아라비안 숫자[0-9]뿐이 아닌 페르시안 숫자[۱۲۳۴۵۶۷۸۹] 등 유니코드 평면에 존재하는 모든 숫자 노테이션을 매칭함. 그래서 [0-9]와 \d는 interchangeable 하지 않음... pic.twitter.com/7i4cnzeECU — 전세계 300억개의 장비가 (@devunt) 2018년 3월 28일 정규 표현식 에서 \d 가 의미하는 것이 언어마다 다 다르다고 한다. 언어가 지원하는 문자열이 single byte문자열이면, \d가 [0-9]를 의미하는 것이 맞지만, 유니코드라면 [0-9] 이외의 문자열도 처리할 것을 고려했어야 한다. 그런 의미에서 파이썬 2의 string literal은 유니코드가 아니기 때문에 [0-9]를 처리하는 것이 이상하지 않지만, Java나 JavaScript처럼 유니코드 string literal을 지원하는 언어에서 \d를 [0-9]에만 대응하는 건 조금 안일한 결정이 아니었나 싶다 자바스크립트 디자인 패턴: RORO RORO는 Receive an Object, Return an Object의 약자로, 이름 그대로 함수에 넘기는 인자와 함수가 넘기는 인자를 object로 하자는 것이다. 함수의 인자로 object를 넘기자는 것은 꽤 옛날부터 있었던 주장이다. 최소한 내가 처음 웹 개발을 했던 2009년경에는 이미 함수의 인자로 객체를 넘기는 패턴이 유행했다. 함수의 인자로 객체를 넘겼을 때의 장점은 두 가지로 정리할 수 ...

https://www.reddit.com/r/ProgrammerHumor/comments/1rfstw/there_are_two_types_of_people/ 위의 meem에서 알 수 있듯이 프로그래머는 괄호를 같은 라인에 붙여 쓰는가 띄어 쓰는가 하는 별 중요하지 않은 것으로 끊임없이 논쟁을 벌이고 있다. 여기에 조건문뿐 아니라 함수의 선언에 괄호를 어디에 붙이는가 까지 해서 4가지 조합을 가지고 끊임없이 싸운다. 뭐 나는 개인적으로 함수의 선언이나 조건문에 붙는 괄호를 한 라인에 붙여 쓰는 걸 선호하지만, 그에 대해서 딱히 내 의견을 강요하지 않는다. 그냥 프로젝트에서 기존에 쓰이던 것이나, 다른 팀원들이 원하는 스타일을 따른다. 하지만 괄호에 관해서 절대 양보 못 하는 것이 하나 있다. 한 줄짜리 statement를 위해서 괄호를 사용할 것인가 말 것인가 하는 것이다. 이유를 알 수 없지만, 조건문이나 for 문에 한 줄짜리 statement가 들어갈 일이 있으면, 괄호를 생략하고 쓰는 사람들이 많다. 괄호를 생략하는 사람들은 이것저것 이상한 주장을 한다. 쓸데없이 바이트를 낭비한다거나, 오히려 한 줄짜리 코드라는 것을 명시해주어야 한다거나, 이유 없이 타이핑할 이유가 없다거나, 뭐 이것저것 이유를 대는데 전부 20세기라면 의미 있을지도 모르지만, 지금이라면 전혀 의미 없는 이유다. 21세기에는 괄호를 생략할 이유가 전혀 없다. 오히려 괄호를 생략해서는 안되는 절대적인 이유가 있다. 코딩할 때 언제나 버젼 컨트롤 시스템을 사용하기 때문이다. git을 사용하든 머큐리얼을 사용하든 심지어 subversion을 사용하든 상관없지만 어찌 됐든 코딩할 때는 언제나 버젼 컨트롤 시스템과 함께하며 소스의 변경을 추적한다. 이때, 괄호를 생략했던 한 문장의 코드가 여러 줄로 나누어지면 괄호를 해서 불필요한 변경사항이 두 코드의 diff에 나오게 된다. 이러한 불필요한 변경 이력이 코드에 나오는 것을 막기 위해서 한 줄의 코드에도 반드시 괄호를 써...

위에서 보듯이 Scala에서는 인자가 0개인 함수를 선언하거나 호출할 때 괄호를 생략할 수 있다. 1) 컴파일 타임에 괄호 생략에 대해 아무런 제약도 하지 않고, 컴파일된 byte code에도 차이가 없다. 그렇다고 아무 괄호나 생략해도 되는 것은 아니다. 언어적으로는 괄호 생략에 관해 아무 제약을 하지 않지만, side-effect가 없을 때만 괄호를 생략하여야 한다. 2) side-effect가 없는 함수에 대해서만 괄호를 생략하는 것은 함수가 선언된 모양만으로 그 함수가 하는 일을 추측할 수 있기 때문에 코드의 가독성을 높이는 데 도움이 된다. 그렇다면 어째서 컴파일 타임에 side-effect가 없는 함수에 대해서만 괄호를 생략할 수 있도록 강제하지 않을까? 이유는 간단하다. 컴파일러가 함수가 side-effect가 있는지 없는지 구분할 수 없기 때문이다. Haskel 의 monad 같은 개념을 도입하여 side-effect를 분리해 낼 수 있을지도 모르지만, Scala는 그런 개념을 도입하지 않고, 사용자에게 책임을 넘겼다. side-effect는 functional 프로그래밍에서 매우 중요한 부분이기 때문에 이것에 대한 책임을 프로그래머에게 넘겼다는 점에서, Scala의 안 좋은 부분이라고 평하는 사람도 있다. 하지만 나는 이 정도 자유는 프로그래머에게 넘기는 것이 적당하다고 생각한다. 예를 들어, 무언가 side-effect가 없는 일을 하는 함수가 있을 때 그 함수가 호출되면 logging을 하도록 수정하였다고 생각해보자. 이 함수는 side-effect가 있는 함수라고 봐야 할까? side-effect가 없는 함수라고 봐야 할까? 엄밀한 의미에서 따져본다면 side-effect가 있는 함수라고 분류해야겠지만, 실제 돌아가는 logic을 생각해보면 이 함수를 side-effect가 있다고 구분하는 것은 뭔가 억울(?)하다. 1) https://docs.scala-lang.org/style/method-invocation...