가독성 저해요인
1. 나쁜 네이밍 ( 변수, 상수, 함수, 클래스, 파일명 공통 )
의미 불명확
의미 부적절
쓸데없이 김
자주 사용되지 않는 단어 ( 일반적이지 않은 네이밍이나 문학적 고유명사화 ) 사용
2. 내용이 너무 긴 함수
3. 이름이 갖는 직관적 의미보다 기능이 많은 클래스 및 파일
4. 의미가 과적된 숫자 ( 네이밍되지 않은 상수 )의 남용
5. 쓸데없이 남발된 괄호 및 기호
6. 불필요한 주석
당연한 주석
너무 긴 주석
7. 사용되지 않거나 가능성이 희박한 코드
주석처리된 역사 코드 포함
8. 띄어쓰기 및 들여쓰기가 제대로 되지 않은 코드
9. 너무 많은 preprocessor directives
#if 어쩌구 #else 어쩌구 #endif 의 남용
10. 너무 세세한 파일 나눔
이 외에 연산자, 재귀, 템플릿을 성능, 간략하고 효과적인 표현을 위해 현란하게 사용하는 경우를
가독성 저해라고 하는 사람들은 허접 ok?
의견 추가 바람.
ㄴ 실력좀 보여봐~
보여줄 실력 없음?
@악플러 효율성을 높이면 가독성이 저해된다? 예시 좀 보여주기 바람.
예시는 무슨 다 알아들었으면서 모른척 하는것봐.
효율성과 가독성이 역관계라는건 대표적인 오개념. 전 코세님 코드 보면서 효율성이 높은 코드가 읽기에 효율적일 수도 있다고 느꼈음. 난 오히려 그런 주장이 프로그래머를 코딩 노예로 만든다고 봅니다
예시를 보이면 반례를 들어주려고 하는거지.
애초에 가독성이라는게 개인마다 생각하는게 달라서 그렇게 말할수 있는거지. 주관적이니까.
나도 템플릿을 적극적으로 쓰게 된지 오래지 않았고, 협업을 위한 코딩을 고민한것도 오래진 않았는데, 파라다임이 이동하는걸 느낌. 두 마리 다 잡을 수 있다.
만약 사용하기 편한 어떤 툴셋 코드를 준비하기 위해서 매크로를 현란하게 쓴다. 라면 그 코드 자체는 좀 복잡할 수 있겠지. 하지만 그건 그 코드가 갖는 가치만큼 가독성 문제( 실제 가져다 쓸땐 세세한 구조를 몰라도 되니 )에서 별도의 평가를 받아야 된다는 거지.
물론 그런 툴셋코드의 남발도 문제가 되니 충분한 격리가 필요한 것이고.
bool이랑 정수가 분리되지 않으면 변수의 의미가 모호해지잖아. 1에 걸리는거 아님?
그러니까 개개인이 판단해서 본인이 중요시 하게 생각되는 쪽으로 코딩을 하는거지. 나같은 경우는 직관성 확장성을 최우선으로 생각하는 편이라서 필요없는 함수도 다 만들어 놓는 편인데
가령 이런거지. std::string yes_or_no[] { "no", "yes" }; cout << yes_or_no[ answer == 'y' ] << endl;
이런 코드가 C / C++ 에선 가능해. 논리 연산의 결과를 산술 연산에서 사용할 수 있고 반대도 되거든.
위에서 예를 든 a=a!=-5; 같은 경우에도, 변수 a가 전혀 의미를 모르겠는 이름을 가지고 있으니 적절한 이름으로 바꿔야할텐데, bool도 될수있고 정수도 될수 있으면 변수의 역할도 모호해지고 이름도 적절히 고르기 어려워지잖아
성능이나 효율성면에서 저하되겠지만 수정이 편하고, 다른사람이 봐도 분석이 빠르게 되는게 좋다고 생각함. 주관적으로 판단하는 부분을 마냥 허접이라고 폄하하는건 아니지
차라리 병신이라고 하든가. 허접은 아님.
위의 예시로 든 a = a != 5; 는 a 의 이름 때문에 문제가 아니라 a = a + 1 만큼 단순한 연산자의 기능을 사용한 것인데 가독성을 해친다고 하니 하는 소리.
저런거라면 차라리 Dictionary형 자료구조가 훨씬 더 가독성이 좋지않음??
@악플러 개방과 폐쇄의 원칙.
저건 간단한 예고 저런걸 수천만번 돌아야 될 때 Dictionary 면 삽질이지.
( 콘솔 출력 말고 boolean 과 arithmetic 을 혼용하는 경우 )
특별히 arithmetic 과 logical operator 간의 교환이 준비되지 않은 CPU 들은 C / C++ 의 저런 연산도 다 if else 로 내부적으로 바꿔버리긴 하는데, 난 쓸데없는 branch 가 싫기 땜에 그런 하드웨어적 구조도 별로 좋아하지 않기 때문.
수정이라는게 코어단을 말하는게 아니고, 인젝션한 인터페이스를 말하는거임
작성된 코드는 최대한 수정으로 부터 폐쇄되어야 하기 때문에 손댈 필요 없게 폐쇄시켜 나가는게 맞음. 안그러면 누군가는 똥칠하게 되고 책임이 부유함.
가독성이 좋은 코드는 코드 그 자체만으로 역할을 파악할 수 있는 self-describing의 성격을 가져야 한다는건 동의하시리라 짐작하고, a = a!= -5가 가독성이 안좋은 이유는 변수 a가 부울과 정수 두 기능을 모두 가지고있기 때문에 변수 a의 역할이 모호하기 때문이라는거죠.
응 기능추가를 독립적으로 만들기 위한 많은 패턴들이 있잖아. 그런 접근 없이는 소프트웨어의 무결성을 유지하지 못한단 말임.
boolean 이란 것의 취지는 논리의 산술화인데 논리를 격리 시키는게 모호성에 도움이 되기 보단 성능적 단점이 크다고 생각합니다.
아까까지 말했던거 재귀임. 난 딴건 모르겠고
그리고 이미 특정언어에서 만들어져 있고 지원하는 연산자의 간단한 기능에 대해 가독성을 운운하는게 좀 아니란거죠.
a = a != -5; 를 읽으면 -5 / non - (-5) ... 0 / non - zero의 대응 관계를 떠올리게 되죠. 코드의 목적과 관계없이 충분히 머리속에서 처리할 수 있는 의미 단위로 이해되기에 이 또한 가독성이 높은 코드라고 생각되네요. 효율성 문제와는 완전히 별개로요.
아니 당연히 돌아가는 코드인데요, 만약 프로그램을 짜다가 저런 코드가 등장하면 저기서 쓰인 변수 a가 무슨 의미를 갖겠냐구요.. 효율성을 따지는게 아니라, a의 의미를 파악하기 어렵게 bool 성격의 값과 정수 성격의 값을 섞어쓰고 있잖아요
변수 하나를 쓴건 귀찮아서임다.
위에 적었듯 의미를 갖는 변수 둘이 사용되겠죠.
제가 의미를 분명히하지 않고 하나의 변수를 temporal 하게 사용하는 경우는 좀 드문데, sum 과 average 정도는 귀찮아서 그렇게 하긴 하죠.
bool이랑 정수를 완전히 분리시키겠단 얘기가 아니구요.. 만약 디버깅 시점에서 a값을 까봤더니 0이었다, 그러면 이 0이 의미하는게 뭔지 알수 있나요?? a가 -5여서 0이 대입된건지, 아니면 애초에 0이었는지 코드 흐름을 훑어보지 않으면 짐작도 못하는거니 가독성이 안좋은거죠
연산자의 예시를 댓글에 쓰려니 저렇게 쓴거라는 말씀.
귀찮아서 그렇게 한다는게 효울성과 가독성을 트레이드오프한다는 얘기 아닙나까?
result = input != -5; 라고 해 두면 되나요?
저는 연산자를 이야기 한 것이었습니다만? 연산자 재귀 템플릿을 자유롭게 하기 위해 굳이 썼어요. a = a != -5; 같은게 가독성 해친다는 찐따들이 있어서. <---
라고 말씀 드렸습니다.
가독성을 해친다고 주장하던 찐따들도 연산자만 가지고 후드러패던가요
뭐 그랬다면야 할말은 없지만여..
호들갑을 떨더군요. ㅋㅋ
뭐 사실 코세님도 b = a!= 3 같은 코드로 예를 들자니 전혀 까이는 코드가 아니라서 어쩔수 없었을것 같긴 합니다..
( 패긴 제가 팼죠 )
문제를 냈었거든요. a 가 -5이면 a 에 0을 대입, 그렇지 않으면 a 에 1 을 대입하는 코드를 작성하세요. 라고.
if ~ else ~ 가길래 a = a != -5 하면 되지. 그러니 가독성이!!!! 막 요럼.
그 때 냈던 문제 중 다른건 이거죠.
1. scanf 같은걸로 a 에 정수를 입력 받았다고 가정하자.
2. a 의 범위가 0 ~ 9 면 a 에 1 을 대입,
3. a 의 범위가 10 ~ 29 면 a 에 2 를 대입.
3. a 의 범위가 30 ~ 49 면 a 에 3 을 대입.
( 아 위에 4 )
5. 그 외의 a 에 대해서는 아무값이나 와도 좋습니다.
라고 문제를 냈었죠.
입력은 a 에 들어 있다고 가정하고 C 로 필요한 코드를 작성해 보세요.
풀어 보시겠습니까?
뭐 문제를 그렇게 냈다곤 하지만 그렇게 치면 a = a != -5는 너무 확장할수 없는 솔루션 아닌가 싶음.. 꼭 ICPC 애들의 문제풀이에 특화된 코드마냥.. 뭐 문제니까 그럴순 있지만 플젝에서 그렇게 쓰면 욕들어먹을듯
덧셈과 뭐가 다르죠? 덧셈은 확장 가능합니까?
a < 10 + a < 30 + a < 50 해야겠죠 머
제가 문제 제기한건 그거죠. if 가 필요할때랑, 논리 연산이 필요할 때를 사람들이 구별하지 않는게 문제라고.
아뇨 제말은 if else와 비교해서요
ㅇㅇ 님의 답도 좋습니다. 저는 ( a + 10 ) / 20 + 1 을 했죠.
ㅇㅇ 님 부호가 반대인것 같은데?
a 에 0 이 들어오면 3 이 되겠군요.
0이아니지만1이라는보장이표준에있었냐고질문을받은사람이물어보지않더냐능 - dc App
뭐 애초에 플젝이었다면 a의 비교결과를 a에 다시집어넣는게 문제일테니 확장성 얘기는 무시하시죵
@sloth_ 무슨 말인지 잘 못알아 듣겠음 ㅋㅋ
글게용 멍청 ㅜㅜ
0이 아니지만 1 이라는 보장? 논리 연산의 결과는 0 이 아니면 1 입니당. ( 논리 연산의 입력은 0 이 아니면 다 참이지만요 )
거짓이면0인데참이면0이아닌값이라고만정의되있지않난구묻지않았었냐능 - dc App
ㄴC 스펙상 연산결과가 참이면 무조건 1이긴 해용
웅 표준에 정의 되어 있죠. ( 물어보는 사람 있었음 )
군사정권시절씨표준은그랬었던거같은데 - dc App
근데 C 스펙에 있는 연산 말고 라이브러리같은 경우엔 참일 경우에 1을 내놓지 않을 수 있음
이것땜에 참 쓰기 좆같다고 생각함..
글구나그럼내가잘못알구있었군요 - dc App
그건 참 거짓이 아니니깐 뭐. 그냥 함수의 약속이죠.
걍 리턴할때 !!만 붙여주면 되는거 아닌가 흑흑
진짜 별 의미도 없는데 그렇게 나와서 정말 당황한 기억이 이써서..
근데 ㅇㅇ 님은 자각 못하시는 것 같은데 저 문제의 답은 ㅇㅇ님이 더 유리하네요.
나눗셈이 코스트가 크니가요..
연산 회수가 좀 많긴 하지만요. ( 5 회 vs 3 회 )
한 바이트 이내 정수 나눗셈은 펜티엄 이후 1 클럭에 구동돼요. 그건 문제가 아님.
어디서 유리하냐 하면, 코어당 논리 연산 회로를 여러개 갖고 있는 CPU 구성일 때죠.
사실 제가 플젝에서 저런거 만나면 걍 if else 씁니당.. 자바스크립트로 3D꼐임도 만드는 시대에 저런 micro-optimization은 별 이득도 없이 시간만 잡아먹어서
1비트 연산 단위라 ( 최종 2비트지만 ) instruction level SIMD 를 적용 받을 가능성이 있습니다.
ㄷㄷ그쿤요 배워갑니당..
하나의 연산이 아니라 저런게 루프 언롤링 되어 반복될때 성능이 올라갈 수 있죠 : )
그러니까 내부적으로 32비트나 64비트 논리 연산 게이트의 일부를 나눠서 동시에 여러개 출력할 가능성이 있다는것.
( 옛날 같으면 어림반푼의 소리지만 요즘은 또 그게 됨 ㅋㅋ )
그러니까 보편적으론 제 답이 적합하지만, 님의 답이 유리한 하드웨어도 있다는것. 정도.
자바스크립트로 3D 만들어두 셰이더 같은걸 자바스크립트로 할 순 없고, CPU 에서 리소스를 중계해야하면 당연히 저런 테크닉도 필요하죠.
하드웨어가 발전해도 요구사항도 같이 증가하니깐요.
푸하하하왜표준이그렇다고생각하고있었지방금찾아봤음나도케이엔알부터다시공부해야겠다능ㅋ - dc App - dc App
가독성은 두 종륜데 readability 는 글꼴, 글자크기 등 시인성에 관한 거고 legibility 는 내용의 어려움을 말합니다. 16년 전에 배운 거라 가물가물.
ㄴ OB 시군요~ 반갑습니다.
그냥 괄호로 묶어서 제공하는게 낫지않을까요
얘들아 여기서 배우지말고 그시간에 외국인 저서 한장을 더봐ㅋㅋ 교보문고가면 널린게 외국 서적 - dc App