의미를 전달할 수 있는 변수 이름을 붙이세요
: 물론 함수만들고 코드 짜는 것보다 변수 이름 짓는게 더 어렵지만 매우 중요합니다.
매직 넘버에는 이름을 붙여주세요
: 작은 프로그램에는 코드를 짧게 해주지만 매직넘버는 코드를 스파게티로 만듭니다.
복잡한 조건식은 함수화해주세요
: 개인적으로 IF문 복잡한걸 굉장히 극혐합니다. 특히 조건문 안에서 변수 선언하니까 사람들이 화내더라ㅠ
:
계산식을 함수화해서 의미를 전달하세요.
: 변수 이름만큼이나 함수이름 짓는 것도 힘들기하지만;;
사소한 중복도 티끌모아 태산이 되므로 줄여주세요.
: 테트리스를 얼마전에 만들었는데 이거 하나로 코드가 20줄 줄었습니다.
조기 리턴을 활용해 주세요.
: 조기리턴 예제보고 허벅지 탁 쳤던 기억이 납니다. IF문 중첩을 막아주는 역활을 합니다.
:
자료구조를 활용해서 if 조건문을 줄여보세요.
: 그전에 사용하는 자료구조는 공부해야하는건 아시죠?
반복문 내의 처리는 최소한으로 만들어 주세요.
: 흔히 말하는 빅O에 대한 얘기 입니다...알고리즘 극혐...
반목분 내부에서는 1개의 처리만 수행하세요.
: 중괄호로 묶이는 건 거의 다 이 전제가 필요한것 같네요.
람다식을 사용해서 반복문을 일반화하세요.
: 근데 저는 람다를 아직 잘 못써서 남발하다가 스파게티를 보게되곤 합니다.
case 내부는 함수화해주세요.
:IF문은 물론 case는 특히 더 간결하게!
1개의 함수에는 1개의 역할만 주세요
: 단순한 함수일수록 재사용하기 좋아요
복잡한 복합 조건은 피해주세요.
: 물론 내가 그러고 싶어서 그러는게 아니지만...따흙흙
자연어처럼 읽을 수 있게 코드를 작성하세요.
:물론 내가 안그러고 싶어서 안그러는게 아니지만...따흙흙
변수를 클래스화해서 의도를 명확하게 전달해주세요.
: 코드가 요란해보일것 같았지만 실제로 해보니 코드 가독성은 좋아지더라구요(요란해지긴함ㅋ)
getter와 setter를 되도록 사용하지 마세요.
: 솔직히 아직 getter setter 왜쓰는지 몰겠음(신윤식교수님 죄송합니다ㅠ)
부모 자식 관계라도 private를 사용해주세요.
: 접근제어자는 될 수 있는한 권한을 적게주는게 맞습니다.
상속보다는 이양을 우선해주세요
: 상속 극혐!!!(신윤식 교수님 죄송합니다2222)
()
직접적인 친구와만 놀고, 친구의 친구와는 놀지마세요.
: 물론 저는 친구가 없어서 친구의 친구도 없답니다!!!!
...는 농담이고 매개변수가 함수를 타고 또다른 함수로 넘어가는 걸 방지하라는 말같습니다. 에이씨! 굴러만 가면 되짘ㅋㅋㅋㅋㅋ이라는 마인드로 개무시하고 프로그램 설계했다가 피봤습니다.
무리하게 디자인 패턴을 적용하려 하지 말아주세요.
: 코린이인 저와 여러분에겐 이릅니다.(는 나만 그럼)
중재자를 사용해 의존 관계를 단순화하세요.
: 무척 선호하는 프로그래밍 방식입니다. 접근제어자에 되게 민감한 편인데 중재자패턴 쓰고 나니까 디게 갬성이 편해 지더라구요.
외부와의 인터페이스 부분을 클래스화하세요.
: 함수로 구현하는 것보다 더 가독성이 좋습니다.
프로그래밍 갤러리에서 인상깊게 읽었던 글들 중,
개인적으로 직접 겪은 것들에 대해서 코멘트를 한줄씩 덧붙여봤습니다.
In case I don't see ya, good afternoon, good evening, and good night
출처 : https://gall.dcinside.com/board/view/?id=programming&no=638072
리르 금오
2020.07.21엄청 좋은 글 같네요!
김코비 글쓴이 금오
2020.07.21예전에 스크랩했던 저런 글들이 몇개 더있어요. 시간이 날때마다 하나씩 풀겠습니다.
리르 금오
2020.07.22오 자주 풀어주세요 ㅎㅎ
금오사이봇
2020.07.22김코비 글쓴이 금오
2020.07.24이런 별볼일 없는 게시글이...??
자취를 하고 싶은 까마귀 금오 익명
2020.07.22getter, setter을 쓰지 않으면 변수 접근은 뭐로 하라는 말씀이신지...
김코비 글쓴이 금오
2020.07.22우선 저는 절차형 프로그래밍보다는 객체지향 프로그램에 익숙한 사람이라는 것,
또한 저 역시 일개 학부생에 지나지 않는다는 점 참고해주시면 감사하겠습니다.
일단 getter와 setter(이하 엑세스 함수라 칭함)의 문제점부터 알려드리겠습니다.
엑세스 함수는 OOP의 철학인 캡슐화를 일부 따라가는듯하지만 실제로 완전히 캡슐화된 코딩 기법이라 할 수는 없습니다.
코드의 재사용적인 면에서는 확실히 실용적이지만 정보은닉는 많이 불리하기 때문입니다.
public으로 선언된 데이터에 직접적으로 접근하나
public으로 선언된 엑세스 함수를 이용하나 결국 둘다 추상화되었어야할 데이터를 외부로 노출시키는 문제를 발생시키기 때문입니다.
// 잘못된 예
// get과 set으로 내부 데이터 노출
Money a, b, c;
a.setvalue( b.getvalue() + c.getvalue() );
// 잘된 예
// Money 객체에 일을 해달라고 요청하라.
Money a, b;
a.increaseBy( b );
차이가 보십니까? 위의 코드는 접근제어자를 사용한 반면에 아래의 코드는 함수를 새로 만들었죠.
이 밖에도 유지보수에 불리하다던가 하는 이유들이 있긴했지만 그런 언급하지 않은 면들은 제가 겪은 일들이 아니라서 선뜻 적기가 어렵네요.
저 역시 액세스 함수의 편의성은 잘 알고 있지만 될 수 있으면 사용하지 않으려 노력하고있습니다.
하지만 이건 제가 단순한 OOP덕후라서 그런 것일뿐, 이렇게 극단 실제로 필요하다면 써야한다고는 생각하고 있습니다.
다만, 액세스 제어자가 명확한 단점을 가지고 있다는 사실을 인식하고 사용한다면 조금이라도 더 좋은 프로그램을 짤 수 있을거라 믿고있습니다.
출처 : https://kindtis.tistory.com/229 [Game Programmer Life], https://kldp.org/files/setter__getter_______________________176.pdf
자취를 하고 싶은 까마귀 금오 익명
2020.07.22getter, setter 가 아니라 필요한 일을 행하는 함수를 만들어 사용하는게 낫다는 말이군요.
순간 그런거 없는데 getter, setter 도 쓰지 말라는줄 알아 놀랐었습니다
김코비 글쓴이 금오
2020.07.22위 댓글 하나 달려고 이것저것 찾아봤는데 아무래도 선택사항인것같아요, 하지만 무조건 getter, setter를 고집해서는 안된다는 의견이 중론입니다. 단점이 명확한 방식이니 대체할 수 있는 방법들을 염두해주시면 좋을 것같습니다!
컴소공
2020.07.22잘보고가요