고치고 싶은 코딩 습관
글쓴이: geekforum / 작성시간: 토, 2002/05/25 - 1:38오후
개발자 여러분들....혹시 코딩하실 때 이렇게는 하지 말아야지...하는 경우 있지 않습니까? 코드가 지저분해지거나 뭔가 깔끔해 보이지 않는 것은 대체로 코드 작성자가 실력이 없어서이겠지만 잘못된 코딩 습관과 몸에 박힌 관습이 원인이 되는 경우도 많다고 생각합니다. 다른사람이 짠 코드도 마찬가지고요. 척 봐서 마음에 드는 코드도 있지만 대부분은 아마 마음에 들지 않는 코드들이 더 많을 것으로 생각합니다. 왜 저렇게 짰을까, 저렇게 안하면 참 좋으련만.... 하는 생각 한두번쯤은 다 해보셨을 테죠.
개인 취향이겠지만, 자기 코드를 보건 남의 코드를 보건 이렇게는 안했으면 좋겠다 하는 습관이나 방식에 대해서 이야기해 봤으면 좋겠습니다. 서로 비교도 해 보고요.
Forums:
이왕에... 버릇이라면 좋은 쪽으로 생각하세요.기존에 있던 함수를 계
이왕에... 버릇이라면 좋은 쪽으로 생각하세요.
기존에 있던 함수를 계속 업그레이드 하는 것입니다.
차라리 이렇게 버릇을 유도하는 것이 나을 것 같습니다.
함수의 유지 보수에도 도움이 될 것 같네요.
goto문 쓰는거 -_-;;;
goto문 쓰는거 -_-;;;
goto문도 필요할때에 잘만쓰면 코드의 가독성을 높여주는장점이 있더군
goto문도 필요할때에 잘만쓰면 코드의 가독성을 높여주는
장점이 있더군요.
하지만 goto문은 가독성의 기능외에, 어떤 기능적 장점을 가질수
있는지는 아는게 없네요.-_-;
아시는 없으세요?
3중 이상의 루프 빠져 나가기...단, 레이블은 3중 루프의 바로 밑
3중 이상의 루프 빠져 나가기...
단, 레이블은 3중 루프의 바로 밑에 달아야 합니다.
그런데 goto문도 쓸데가 있더군요..mutex같은 lock을 걸
그런데 goto문도 쓸데가 있더군요..
mutex같은 lock을 걸었다가
return하는 지점이 여러개가 생길경우에는
unlock하는걸 잊어버리고 return해버리는 경우가 있는데
return result;문을 함수맨 마지막에 한개만 두고 거기에 레이블을 단담에
return할 위치에서 적당한 return값을 result변수에 세팅해 주고 goto 해버리면
실수도 안하고 또 편하더군요..^^;
헉! 이... 이런 무시무시한 악습관을 ....
헉! 이... 이런 무시무시한 악습관을 ....
너무 신중한것..디자인이 완벽해질때까지 안 짜는 버릇물론
너무 신중한것..
디자인이 완벽해질때까지 안 짜는 버릇
물론 좋긴 한데..
그러다가 아예 못짜는 수가 있음..
그냥 되는데로 쉽게 쉽게 짜야 한다고 생각합니다..
주석을 달아야지 하는 생각을 항상 하면서도...고치고 고치고 하다
주석을 달아야지 하는 생각을 항상 하면서도...
고치고 고치고 하다보면 달았던 주석은 어디가 있는지 찾을 수가 없더군요..
주석달기를 좀 더 습관화 해야 겠군요..
나는 겁장이 창민(계정신청했는데, 메일이 좀 늦네요, 진작 할걸)
나는 겁장이 창민
(계정신청했는데, 메일이 좀 늦네요, 진작 할걸)
저는 간단한거 몇가지.
strtok 대신 sscanf쓰기.
pointer 쓰기 전에 null 확인하기.
기본에 기본이지만,
프로그램이 바로 죽어버리는 무서운 버그가
될수도 있으니깐요. 버릇을 잘들어야 하는데
힘드네요.
strtok 에 문제가 있나요?학교 숙제 나올 때 많이 사용했는데
strtok 에 문제가 있나요?
학교 숙제 나올 때 많이 사용했는데....
-_-;;;;;
쓰면 안되는 구나.....
흑....
저도 이 함수가 문제가 없을거라고 생각하고 쓰려고 마음 먹고 써보았다가.
저도 이 함수가 문제가 없을거라고 생각하고 쓰려고 마음 먹고 써보았다가... -.ㅡ 문제를 일으키는걸 보고 바로 버렸습니다. -.ㅡ
음냐..
결국은.. 비슷한걸 대체하도록 하나 만들어버렸지만.. --;;
아.. 이것도 악습관일듯..
미리 만들어진 함수들이 좋은것 많은데 찾기 귀찮다고 만들거나 조금 불편하다고 살짝 감싸는 함수 하나씩 더 만들어서 함수 무지하게 만들어버리는 악습관.. -.ㅡ 음.. 아주 간단한 프로그램에 함수가 어찌나 많은지.. --a
strtok는 thread safe하지 않고, tokenizing하는 s
strtok는 thread safe하지 않고, tokenizing하는 string을
변형시키기 때문에 constant string에 대해서는 사용할 수 없습니다.
manpage에 Never use these functions라고 되어 있는 함수 중 하나죠.
음, 주석코드를 넣지 않는 경우가 많은데 그 무엇보다도 중요하죠.
음, 주석코드를 넣지 않는 경우가 많은데 그 무엇보다도 중요하죠.
나머지 코딩 스타일은 개인 취향이기 때문에 그것을 언급하는 것 자체는 무리가 있고요..
저같은 경우는 너무 자신만의 스타일에 빠지는 경우 다른 사람의 코드 해석에 불편하기 때문에 일반적으로 개발툴을 만든 제품의 예제 스타일을 따라가는 편입니다.
정말 다양한 사람들의 코드를 수정하게 되면 짜증나는 주된 요인이 저와 스타일이 달라서가 아닐까 합니다.
표현의 자유는 나은 발전을 가져다 준다고 생각합니다.
"구분"컬럼 코딩할때 "gubun"쩝쩝...이런 명명법 고치고 시퍼영
"구분"컬럼 코딩할때 "gubun"
쩝쩝...이런 명명법 고치고 시퍼영..
T_T
그래도 급하면 꼭 일케 하되데져..쩝쩝
"구분"컬럼 코딩할때 "gubun"쩝쩝...이런 명명법 고치고 시퍼영
"구분"컬럼 코딩할때 "gubun"
쩝쩝...이런 명명법 고치고 시퍼영..
T_T
그래도 급하면 꼭 일케 하되데져..쩝쩝
자바의 경우 유니코드를 지원하니까 컬럼명 같은 건 한글로 써도 무방할 듯
자바의 경우 유니코드를 지원하니까 컬럼명 같은 건 한글로 써도 무방할 듯 싶습니다. 엔티티빈 클래스의 컬럼명 같은 건 한글로 하는 게 가독성도 높고 별 달리 소스 이해하는데 지장을 주거나 일관성을 깨는 것두 아니고 이름 따로 생각 안해도 되고 여러 모로 편리한 점이 많습니다. 전 아직 부분적으로만 시도해보고 있지만 잘 체계를 잡고 DB 컬럼명까지 한글을 쓰게 된다면 장점이 많을 것 같습니다.
전에 다른사람이 Visual Basic과 Access로 만들어 놓은 프로
전에 다른사람이 Visual Basic과 Access로 만들어 놓은 프로그램을 유지보수 하는 일을 한적이 있는데, 변수명콰 컬럼명을 한글로 썼더군여.
예를 들어. select 사번, 이름 from 사원
가독성은 좋아지는데, 코딩할 때 한영 키 전환하는게 영 거추장스럽더군여..
그리고, 다국어 버전을 만든다면.. 머 그 프로그램을 그럴일은 없었지만요,
어떤 문제가 생길까?? 란 생각이 들더군요..
변수명 정한다고 한영사전까지? (' ㅡㅡ)저 같은 경우에는
변수명 정한다고 한영사전까지?
(' ㅡㅡ)
저 같은 경우에는 dic.yahoo.co.kr 같은 온라인 사전 SITE에 접속해서
바로 바로 찾아 봅니다. ^^;
맞아요 참 고민이죠.. 변수 이름 정하기 .. ㅋㅋㅋ전 그래서 한
맞아요 참 고민이죠.. 변수 이름 정하기 .. ㅋㅋㅋ
전 그래서 한영사전을 샀답니다..
일단 우리말로 한담에 사젼뒤져서 ^^;
그럼. 수고하세용.
페이지