다만 어떤 프로젝트를 진행하면서 서로를 위해 규칙이나

방식을 정하면 좋겠지만 특별히 하드웨어단처럼 제한된 조건이나 용량, 그에 따른 퍼포먼스가 중요한 특별한 경우가 아니라면 상의해서 정하면 되는 거 같은데.. 

동료분의 입지나 상황이 바뀐게 좀 큰게 아닐까하는 

생각이 드네요. 

설마 코딩 방식 때문에 그럴까 하는 생각이 듭니다. 

프로그래머에겐 늘 상 겪는 일인데 말이죠.

프로젝트의 패턴대로 작성해야 됩니다.

ㅡㅡ

신규라면 최신트렌드 및 플젝스타일에 맞춰서

이런데에 낄만한 주제는 안됩니다만...

레퍼런스는 레퍼런스일뿐이 아닌가 하는 개인적인  생각이 있네요

프리로 SI를 주로 하는 입장에서 완전히 신규의 경우 특별히 개발가이드가 있지 않은 이상에는 내 편한대로 코딩을 하고 남이 작성해 놓은 코드를 수정해야 할경우 특별한 경우가 아닌이상에는 최대한 기존 코드를 해치지 않는 선에서 코딩을 합니다

기존의 개발 스토리를 모르는 상황에서 괜히 급격히 코드변경을 했을시 나타날 수도 있는 오류가 염려 되기도 하고 기 개발자나 운영자가 봤을때의 혼선을 줄이기 위한 방편이기도 하다고 생각 하기 때문입니다.

하물며 확고한 개발철학이 있는 개발자가 완전히 떠난것도 아니고 잠시 자리를 비운 상황에서 코드 스타일(?)을 완전히 바꾼다는건 예의도 아닌것 같구요

애초에 처음부터 개발가이드가 있었다면 모르겠만

또,  완전히 업무를 인수 인계 하고 떠났다면 모르겠지만 임시 담당자가 멋대로 코드를 바꿨고 또 나머지 구성원들이 모두 그에 동조 및 옹호 하는 상황이라면..

글쎄요 그 상황에 직면한 사람이 어떤  생각을 하게 될까요?

좀 두서가 없었지만 전하고 싶은 의미는  전달이 되었기를 바랍니다.

모쪼록 좋은 결과 있기를 바랍니다

팀원이라면 그걸 가능한 구조가 되게 팀장이 이끌어줘야 하는 것이구요

음.. 댓글 주신분들하고 약간 핀트는 다른데 코딩 스타일은 pep8을 따르구요.. 이건 이견이 없습니다. 

다만 저는 lambda, map,  filter,  reduce 같은걸 잘 써서 simple 하고 반복이 없는코드를 만들자는 입장이구요.. 그 친구는 loop,  if else 같은걸 명시적으로 쓰자는 입장이에요...

람다를 예로 들어주시니 상황을 좀 알 듯 도 합니다.

저는 람다를 공부하지 않아서, lambda 코드를 보면 이해하기 어려워서 불편합니다.

게다가 제가 보기에 과거 스타일의 코드로 작성하면 누구나 이해할 수 있는데, 

람다 표현식으로 작성을 하면, 람다를 아는 사람만 알게되죠.

아직은 저처럼 람다를 모르는 사람도 많기 때문에, 누구나 알 수 있는 코드로 작성하는 것을 좋아합니다.

말씀하신 lambda, map, filter, reduce 같은 것들이 이제 일반화가 되고, 

그런 스타일의 코드를 작성하는 것이 매우 쉽고, 효율적이인 case라고 이해시켜야 할 듯 합니다.

저는 잘 모르지만, 그게 대세라면 익히고 사용해야죠. ^^

항상 모든 걸 아는 사람이 해당 프로그램을 유지보수하지는 않습니다.

어떤 기술들은 더 쉽고 좋은 방법 때문에 사장되기도 하구요.

동료분이 말씀하신 loop, if-else 는 제가 프로그래밍은 '이게' 다라고 말할 때, 예를 드는 두가지군요. ^^

누가봐도 의도가 명확한 코드가 좋은코드라고 생각합니다! 그게 군더더기가 좀 있을지언정...

먼저 토의를 해서 python like 라는 것에 대해서 먼저 정의를 하세요

그리고 if else vs map filter reduce 가 어떻게 왜 더 좋은지 설명, 이해 시킬 수 있으면 되는 거구요

설명, 이해를 시킬 수 없으면 python like 가 아니라 그냥 개인 기호인거죠

좋고 나쁨이 명확하면 이해 시킬 수 있는거고

그게 안되면 기호의 영역인거죠