좋은 소스코드의 조건?

김태호_의 이미지

저는 프로그래밍을 그다지 잘 하는 편은 아니구요. 그냥 필요한 것이 있으면 다른 공개된 프로그램을 다운받아서 필요한 부분만 조금씩 고쳐서 사용하는 정도입니다. 겉모양을 조금 바꾸는 정도지요.

그러다 보니 어떤 것은 쉽게 파악이 되는 때도 있는데 어떤 것은 정말 뭐가 뭔지 모를 정도로 꼬여 있는 경우도 많고....프로그래밍을 오랫동안 해보신 분이라면 이런 경험이 더 많으실 겁니다.

과연 \"좋은 소스코드\"는 어떤 코드일까요? 어떻게 프로그래밍을 해야 좋은 코드를 만들어낼 수 있는 것일까요?
너무 궁금합니다.

혼자서 4-5000라인 정도 되는거 방학때 함 만들어볼라고 하는데 과연 될지는 모르겠지만 이정도 되는거 만들려면 쉽지는 않겠져?

조언을 해주시면 프로그램 짤때 마음에 새겨두려구요.

부탁드려요~~

댓글

익명 사용자의 이미지

좋은 소스코드의 조건?

님이 C로 짜는 것에대해 말씀하시는것 같은데..

전 Practical C Programming을 봤는데...
좋더군요...

그냥 그책 한번 보시면 좋을듯

저도 사고 좋게생각합니다.

전에는 포인터를써서 어렵게 보이는 소스보면
이야~ 이렇게 했는데.
이젠 아닙니다.
그렇게 짜나 보기쉽게짜나...

컴파일러 거치면 그게 그거라니깐~

객체지향 이런건~
휴~~~~~~~~
1년보니 약간 어슴프레....~

그냥 좋다는 책다사서 다보는 수밖에 없습니다.
그리고
자신이 만라인넘는 프로그램 짜면서 경험을 하지않으면.
헛꺼라고 생각됩니다.

전 이제 막 만라인을 넘은 상태

만라인이 넘으면 무턱대고 짜기시작하는 일은 없어야겠죠..

익명 사용자의 이미지

>>> 사용자 효율적인 측면:
무조건 빠른것이 좋다. 그래서 알고리즘 최적화 된 코드만을 사용한다. 디버깅 코드등은 전혀 필요한지 않다. 단 버그는 없어야 한다.

>>> 프로그래머 효율적인 측면:
코드의 길이가 짧을수록 좋다. 천천히 놀면서도 빨리 만들수 있으면 더욱 좋다. 알고리즘은 복잡하면 방해된다. 어쨋든 쉽게 프로그래밍 할 수 있을수록 좋다.

>>> 결론:
효율적인 프로그래밍이란 존재하지 않는다.

뒷말) 농담이긴 합니다만... -_-;;;;; 왠지 사실적인 면이...

다타만의 이미지

제 이야기는 아닙니다만..

변수명을 i 나 j 따위로 쓰는것은 나쁘다는것은 반대하실분이 그리 많지 않으실것 같은데여염.. 제가 아는 한넘은 변수명길게 주는걸 좋아함다..
저도 어느정도 구분해서 변수명은 3 - 4 단어의 약자를 박합해야 한다거 생각하는데엽.. 그 넘은 절대 약자 no 가능하면 조사까쥐..
전에 터미널에서 코딩하는걸 봤는데 단순 비교.. 두 변수의 크기를 비교하는건데.. 터미널 80 칼럼짜리 화면에서 if 문을 한줄에 못쓰더라구여
그넘 왈..
\"변수명을 길게쓰면 주석 달 필요도 없고 (보면 안다니깐..) 타이프 연습도 되고 좋자나.. ㅡ.,ㅡ\"
다른사람보다 소스가 30%는 더 큽니다... 시간도 약간 더걸리거.. 일많이하는거 같고..ㅡ.,ㅡ

익명 사용자의 이미지

MFC가 보기 좋던데..ㅡ.ㅡ;
돌은 던지지 마세요....ㅡ.ㅡ;

익명 사용자의 이미지

엥.. 한칸 쓰는 사람은 뭐쥐~!

익명 사용자의 이미지

좋은 코드의 조건은 여러가지가 있겠지만 간단하게 몇가지만 이야기 하겠습니다.

1. 다른 사람은 몰라도 자신이 나중에 보아도 알 수 있어야 한다.... 지금 열심히 짜 놓아도 나중에 보아서 알 수 없다면 지금은 노력을 다음번에 또 해야 합니다. 그래서 가급적이면 보기 쉽게 짜야하겠죠.... 만은 분들이 이렇게 이야기 합디다... (주석을 달아놓으면 좋겠지만 어찌 쉽게 되는 일이어야지 말이죠!)

2. 연장선에상에 있는 이야기 인데 .. 다음번에 사용할 수 있게 file로 분류해놓으면 좋겠죠....
C++로 짜지 않아도 함수별로 분류를 해놓으면 나중에 다시 쓸 수 있다는 것을 잘 알고 있는 사실일테니까요....

3. 프로그램을 짜다보면 다음에 사용할 수 있게 하기 위해서는 전역변수를 조금 사용하고 가급적이면 인자를 넘기는 방식을 쓰는 것이 좋더군요.... 제가 아는 고수들은 주로 그런 방식을 사용하지만 다음에 사용할 것이 아닌 것 또는 쉽게 바꿀 수 있는 것들을 제외하고는 전역 변수를 사용하고 있지 않습니다.

이정도를 고려하고 프로그램을 짜신다면 어느정도 좋은 소스코드에 해당되지 않을까 합니다.

어떤 선배가 그러더군요 자기는 잘짠 프로그램은 for문을 적게 사용하면서 짧게 짜는 것이 좋은 코드라고 그래야 보기도 편하고 속도도 빠르다나....

그럼 열심히 자보세요....
즐통... 휘리릭......

익명 사용자의 이미지

GNU 코딩 가이드도 참고하세요. :)
(주소는 몰라염.. GNU 사이트에 있습니다.)

익명 사용자의 이미지


냠-_-/~
열분 안령여 -_-/~

많은 분들이 코딩 규칙에 대해 얘기 하시는것 같아서....

제가 쓰는 코딩 규칙을 한번 말씀 드려 볼려구용.. ^^

1. scope

저는 return func(args val) { 모양을 쓰지 않습니다.
ret func(Args val)
{
}
의 요양을 쓰지용..
나중에 볼때 열고 닫음을 확실히 볼수 있다 생각하기에..
이 방법을 사용합니다.
vi팁.. 요기서 { 나 }에 커서를 놓고 %를 누르면
match 되는 곳으로 이동합니다...소스의 indent가 엉망이 됐을때
match 되는 ( 나 {를 쉽게 찾으실 수 있을 겁니다용 ^^
아! 그리고 중요한 습관 하나.....
{를 치셨으면 습관적으로 } 를 치도록 노력하세요....
나중에(compile 할 때) 수고 한가지를 덜게 됩니다...^^
(윈개쪽 editor들에서는 Ctrl - B를 누르니 되는것 같아용..)

2. 변수명 규칙

변수명이나 함수명은 최대한 길게 씁니다. 주석 대신에 변수명
자체로서이놈이 뭘 하는 놈인지 알게 하는 거져 -_- 무.. 물론
주석도 -_- 써야겠져
소스 보다보면 이 변수가 뭔지 자꾸 까먹어서 -_-;;
(근데 길어지면 변수 이름이 기억이 안나서 자꾸 되올라가져 -_-
이럴때 vi에서는 mark를 쓸 수 있어 좋아용 ^^*~)
C에서는 단어 구별로 대개 _ 를 씁니다. java에서는 단어 시작을
대문자를 씀으로서 구별하져.
즉, message_sender(char *str) 나 messageSender(String str)
등이졍...
자바의 경우 Class이름은 시작도 대문자.public class ObjectPool

3. indentation

들여 쓰기를 말하는데용.. tab을 사용하셔용..
이유는..모든 편집기들은 tab을 사용하는것을 지원하기 때문입니다
vi의 경우 :set sw=4 (Shift Width)를 지정함으로서
>> 를 했을 때 sw만큼 한줄을 오른쪽으로 이동시킵니다.
( << 은 왼쪽으로 이동 시키겠져 ^^)
숫자를 누르고 >> 한다면 현재줄부터 아래로 (숫자)줄 만큼
오른쪽으로 이동하겠져....
그리고 대개의 윈개 편집기들의 경우는
여러 줄을 블럭으로 지정해 놓고, tab을 누르면
블럭 지정된 모든 줄이 tab만큼 오른쪽으로 이동합니다.
그리고 Shift - tab을 누르면 왼쪽으로 이동하구요.

냠..또 취향이겠지만 저같은 경우는 tab을 4를 씁니다용.. 호홍
vi에서는 sw와 ts(tap stop)이 다른 개념이오니..
두개의 값을 똑같이 해놔야 나중에 안헛갈리졍 냠 _-_
윈개 편집기들도 각각 tab size를 설정할 수 있으니...
취향에 맞게 사용하세여 -_-/~

4. 가독성을 높이기 위한 자잘한 것들...

위에 어떤분이 말씀해 주신 내용입니당...

for( a=1; a 이런 식으로 쓰는걸 말하는거졍.. ^^;;
특히 함수 호출할 때
send_message( argument ); 이렇게( ) 사이를 하나씩 띄우면
이상하게 깨끗하게 보이더군여 (저의 경우 -_-)
if문의 경우.. if ( a>b || b>c ) 이런 식으로....
연산 부호는 붙이고.. ||나 &&등은 띄우고...

허헐 -_- 이상은 제가 여태까지 이눔.. 저눔 에게서 주서 듣고..
또 나름대로의 버릇으로서 가장 좋다고 느낀내용 들입니당...
일케 함 보이기는 참 깔끔해 보여여 냥 -_-;;
더욱 좋은 방법을 아시는 분은 꼬옥~ 말씀해 주셔용...
써먹어야징.. 호홍..

글엄 열업운 안령 -_-/~

익명 사용자의 이미지

\"좋은 코드는 생명력이 느껴진다.\"

저 자신이 좋은 코드를 만들어내는 지는 잘 모르겠습니다만,
많은 코드를 읽었다고는 할 수 있을 것 같습니다.

그로부터 느낀 건데 좋은 코드는 마치 살아숨쉬는 듯 합니다.
프로그래머에겐 코드를 짜는 능력만큼이나 코드를 읽는 능력도 중요하다고 생각합니다.

코드를 많이 읽을 수록 읽는 능력은 향상되는 것 같습니다.

프로그램은 하나의 큰 덩어리지만 그것을 비슷한 level의 여러 작은 덩어리로 나눌 수 있고, 또 나눈 덩어리들이 더 작은 덩어리로 나누어 집니다. 그렇게 hierarchy가 이루어집니다.
마치 많은 세포들이 우리 몸을 이루는 것 처럼 말입니다.

숙련된 프로그래머일수록 한번에 처리하는(읽어내려가는) 덩어리의 크가가 큰 것 같습니다.
처음 시작할 땐 한 줄 한 줄 읽다가도 경험이 쌓이면 detail한 스타일에 구애를 덜 받는 것 같습니다.

비록 프로그램 스타일이 문제가 될 수는 있겠지만, 좋은 코드는
유기적으로 동작합니다. 그리고 robust합니다.

잘난 체 하는 글이 길어지는 것 같아 죄송하지만 제가 프로그램을 처음 배웠던 교수님께서 좋은 코드를 항상 이렇게 표현했던 것을 적고 싶습니다.

\"아름답다\"

익명 사용자의 이미지



* Readability * - 즉 프로그램 가독성

이 젤 중요하다고 생각합니다. (물론 작동은 해야죠!)

혼자 짜는 프로그램이라 하더라도, 나중에 업그레이
하기 위해 소스보면, 이것이 젤 중요한것 같더라구요.
읽기 쉽고,이해하기 빠르면 바로 또 고칠수
있거든요..

더군다나 여럿이서 짠다던가, 아님 Open소스같은 경우
라면 더욱 그렇겠죠.

주석이 있어야 좋은지 없어야 좋은지는,
그 주석이 있음으로 해서 소스 가독력이 올라가는가
그렇지 않은가에 달려 있습니다.

============================================
PS. 한때 자기만의 스타일을 찾아, 또는 천재처럼
보이구 싶어서, C소스의 별의별것을 다 써보던
때가 있었습니다.

이후, 한달정도 있다가 저는 바보되고 말았습니다.
제가 짜 놓고도 그게 뭔지 설명을 못했으니까요..

하물며 이런 소스가 오픈소스로 올라온다면..
쩌업..

제발, 다른사람이 이해하기 쉽게 소스 짭시다~
-------------
(젤 중요!!!!)

익명 사용자의 이미지

저는 초보라도 주어 들은것들을 조합하여 감히 이글을 씁니다.
좋은 소스라..

* 좋은 알고리즘을 이용한 지저분한 소스가 그 반대인것보다
두배정도 성능의 차이가 난다.

* 필요에 의한 개발이 좋은 프로그램을 만든다. 게다가 여러사람이 참여하면 효과를 더욱 높일 수 있다. 그 만큼 아이디어가
생겨날 수 있다는 뜻이겠죠..

* 저는 무조건 무에서 시작하는 것이 반드시 창조적인 것이라고 생각되지 않습니다.
어떤 프로그램을 만드냐 또는 훌륭한 프로그램을 모방하여 어떻게 하면 더 좋은 성능의 프로그램을 만들어 내는가에 대한 연구를 하는것도 좋은 방법이라 생각됩니다.

조금 허접한 내용이었습니다.

익명 사용자의 이미지

여러분 UML, Pattern, Refatoring, XP에 대해 들어보신
적이 있나요? UML은 모델링 언어로 OMG에서 표준으로
정한... 소프트웨어 개발에 대해 전체적인 설계를 하는
비주얼한 모델링 언어죠... 왜 좋은 소스란 무엇일까
라는 토론에 UML이란 모델링 언어가 나올까 의아해 하실
분도 계실줄 알지만... 지금 여러분이 보고 계신 책중에
도 어떤 문제에 대해 설명할때 UML을 사용하고 있을겁니
다. 그만큼 국제표준 언어이니 알고리즘이나 로직 설계
등에 많이 사용되니 공부해야 하는 한 분야구요... 자신
이 짠 소스에 대해 남들에게 체계적으로 이해시킬려면
표준적인 UML이 최선의 방책이겠죠...

그리고 Pattern 이란? 우리가 자주 프로그램 개발할때
접하게 되는 그런 문제들에 대해 고수(?)들이 미리 초짜
들을 위해 준비해 놓은 아주 좋은 해결책이라고 생각
하시면 됩니다. 그러니 고수들이 수십년간 쌓은 그런
경험을 우린 거의 꽁짜로 얻을 수 있죠... 그래서 우리
가 좋은 소스를 만들려면 패턴에 대해 공부를 해야죠...
그리고 물론 적용도요...

그리고 Refatoring 이란? 이건 저도 자세히는 모르지만
패턴이 적용안된 소스(삽질소스)를 패턴을 적용시켜 끝
내주는 소스로 만드는 그런 방법이라고 보시면 됩니다.
제가 이걸 처음 접할때 충격을 받은 부분이 바로... 주
석에 대한 내용입니다. 위에 몇분들은 좋은 소스의 조
건에 주석을 포함시켰는데... 리펙토링에서는 주석도
스멜(악취)라고 생각합니다. 결국 주석을 달으는건..
그만큼 이해하기 어려운 부분이라는걸 의미하기 때문에
이런 부분도 리펙토링해 스멜이 안나는 그런 소스로
만들자는 그런 거죠... 좋죠?

글구 XP... 이건 뭐랄까... 잠시만요... 제가 세미나때
들었던 내용에 대해 설명드리죠... 흑~ 자료가 없어졌
네요... 죄송... 하지만 URL을 아니... 직접 보시길...
www.extremeprogramming.org
www.extremeprogramming.com

익명 사용자의 이미지

저 역시 초보?입니다.
국민학교 때 처음 gw-basic를 시작해서, 전산학과를
졸업할때까지 거의 모든 언어를 작성해 보았지만,
아직도 초보라는 생각을 떨쳐버리기 힘들군요.
프로그래밍할때 이렇게 생각하고 짜세요.
자신이 짜는 프로그래밍이 껌 ^^;; 이라 생각하세요.
특별히 창조적인 프로그래밍말고는 다른사람들이 이미
비슷한 프로그래밍을 만들어 놓았습니다. 그 소스를
활용하세요. 어느정도 인지도가 있는 프로그래밍이라면,
수차례의 디버깅과 업그레이디를 통해서 소스가
정립되어 있을 것입니다. 그리고 몇가지 소스를 분석해보고,
전체적인 프로그래밍 구조를 잡습니다. 이제 각종 프로그래밍에서 구한 함수, 클래스 같은 것을 하나씩 조립해서
원하는 프로그래밍을 만드는 것입니다.
프로그래밍이라는 자체가 원래 다른사람의 도움없이는
불가능한 것입니다. 같이 공유라고 서로를 존중하고자 할때
보다 쉽고, 빠르고, 안정적인 프로그래밍이 탄생합니다.
자신의 맘을 열면 더 큰세상이 보입니다.
전 애인말고는 뭐든지 공유할라고 노력합니다.
돈도 인생에 있어서 별루 중요한게 아니고,
그냥 먹고 살 정도 있음되죠.
그리고 다른 사람과는 다른 창조적이고 효율적이고
공유하기 프로그래밍을 짜을때 가장 큰 행복감을 느낍니다.

keizie의 이미지

근데, 대부분의 경우 제가 짜려는 건
꽤나 남다른 것들이 되더군요.
검증되지 않은 방식을 써야 하는데 어디에도 참고할 자료가 없으니.. 그렇게 막막할 수가 없어요.

from [ke\'izi] : where is [r]?

덧. 뭔가를 짰다면 \'이건 내꺼야. 유니크해!\'라고 말할 수 있어야 한다고 봅니다.

익명 사용자의 이미지

명료하게 뭐가 좋고 뭐가 나쁘다고 말할 수 있을 정도의 실력을 가지지 못한 저의 습관은...

똑같은 프로그램을 여러번 만듭니다.
한 30~40번 정도 똑같은걸 만들다보면 점점 정교해집니다. 사실 한번도 경험못해본 라이브러리나 어떤 기교를 부릴 때에 한번에 잘 짤 수는 없거든요. 시행착오를 거치면서 점점 나아집니다.

keizie의 이미지

방금 제가 짜고 있는 게시판 소스를 붙잡고는
주석을 제거한 뒤에 바뀐 크기를 보니까..... 글쎄...
13459 바이트가 줄었더군요. -.-;
징하게도 적었지.... 천육백 줄짜리 소스에 무슨...

from [ke\'izi] : where is [r]?

익명 사용자의 이미지

저는 프로그램을 짤때 다음을 기준으로 짭니다.

1. 명료한 알고리즘,
2. 최대한 간단한 자료구조,
3. 일관된 인터페이스,
4. 적절한 주석

그런데, 자료구조 선택하기가 제일 힘들더군요.
그 다음에 힘든 것은 알고리즘.

주석은 생각날때마다 답니다. (나쁜버릇 ??)

전 아직 5천줄 넘어가는 프로그램을 짜 본 경험은 없습니다. -_-;;

white23의 이미지

정말 좋은 소스 코드는 주석이 없이도 이해가 가능한 코드가 아닐지???
그렇찮나요???
그러나 현실은 그렇지가 않겠죠...
제가 보기엔 그러면 주석은 최소화하되...
더욱더 이해하기 쉽게 짜는게 아닐까 생각을 합니다...

<어떠한 역경에도 굴하지 않는 \'하양 지훈\'>

어떠한 역경에도 굴하지 않는 '하양 지훈' - It's Now or Never!!!

keizie의 이미지

소스가 없어도 이해가 쉬운 코드라는 건,
소스의 문제보다는 알고리즘이나 프로세스 얘기이지 않을까요?

익명 사용자의 이미지

아직 혼자서 프로젝트를 진행하기에는 좀 덜된
시스템 프로그래머 입니다.
해서 이런데 글 올린다고 돌을 던지셔도 맞고서
눈물을 훔칠 수 밖에 없는 처지지만....

현업에 있다보니 보는게 약간은 있습니다.
물론 본다고 다 보는 것은 아닙니다만...

좋은 소스코드 작성하는 법은 위에 많은 분들이
이야기하셨으니까 전 좀 다른 걸 이야기 하려고
합니다.

저의 과장님과의 이야기 도중에 나온 얘긴데요.
처음에 프로그램을 짜기 전에 과연 무슨 생각으로
프로그램을 짜는가 하는 겁니다.

다시 말하면, 어떤 철학을 가지고 프로그래밍을
하는가 하는 것인데요.

무슨 멍멍이 소리냐고 하시겠지만, 이런 겁니다.
요즘은 OOP에 대해 많이들 듣잖아요? 그것도 결국
철학이라는 겁니다.
누군가 삼각형을 클래스화 한다면 그 사람이 생각하고 있는 삼각형이 그 클래스 안에 반영이 된다는 것이죠.

단순한 삼각형이라면 이미 유클리드라는 남자의 생각에
우리모두 동의하고 따르고 있는 것이니까 문제가 덜
됩니다만, 다른 어떤 것들을 클래스로 표현할 경우에
특히 자신이 처음일 때는 더욱 깊은 생각이 필요하겠죠

그리고 구조라는 것도 염두에 두어야 한다는 것이죠.
작은 프로그램이란 게 그렇게 많지는 않잖아요.

큰 프로그램일수록 어떤 구조를 선택하고 얼마나 잘 지켜 나가는가 하는 게 중요한 것 같습니다.

제가 보고 있는 프로그램은 embedded os인데요. 이놈이 처음엔 어땠는지 모르지만, 지금은 여러가지 기능이
얽혀서 거미줄 같은 구조입니다. 직관적으로 파고들기가 힘들게 되어 있죠. 함수들이 서로를 마구 콜하고 있는 상태거든요.

프로그램을 개발하는 초기에는 충분히 생각해 보아야 할 문제라고 생각되었습니다.

- 건방초보 -

익명 사용자의 이미지

전 알 스티븐인가 하는 분이 쓴 C
로 짜는 데이터 베이스 같은 구조
의 프로그램이 젤 조터군요

1. 무슨 말인가 하면 최대한 함수
화 할 것.
2. 함수는 최대한 100 Line을 넘지
않게 작성할 것(부득이한 경우 빼고).
3. 함수의 시작부분 및 함수 내부
에 최대한 많은 주석을 달아둘 것.
특히 함수의 시작부에 기능에 해당
하는 주석달기는 필수

keizie의 이미지

들여쓰기, 정말 중요하죠.
스페이스보다는 탭이 낫더군요.

그리고 함수와 변수, 배열과 첨자, 연산자와 연산식 등에서의 배치 있잖습니까..
그런 것들도 소스를 보는 데 참 중요하더군요.
괄호는 앞 뒤로 꼭 띄워준다거나...
예를 들어, 저는 이렇게 쓰죠.
for( argx = 0; argx < argy; argx++ )
이런 게
for(argx=0;argx 보다는 훨씬 보기 쉽더라구요. 이쁘기도 하고.. ;)

한 가지 작업을 위한 몇 줄씩의 코드는 적당히 묶어서 아래 위로 빈줄을 넣어준다거나 하는 것도 좋구요..

주석은..
한 함수 머리에서 함수의 목적만 말하고 치우는 것보다는
코드 중간 중간에 이 코드가 무슨 일을 하는 건지, 왜 이런 건지 설명을 붙여주는 게 좋더군요.
나중에라도 훨씬 알기 쉽고..

이천 줄쯤 되는 코드를 짜다보니
한 부분을 끝내고 다른 부분을 볼 때
주석이 없으면 저부터가 헤매게 될 수도 있더라구요...

from [ke\'izi] : where is [r]?

익명 사용자의 이미지


- Code Complete -
steve mcconenell
microsoft press

rainlood의 이미지


GNOME Programming Guidelines
http://developer.gnome.org/doc/guides/programming-guidelines/book1.html

가이드가 되어 줄 것입니다.

익명 사용자의 이미지

요즘 X 소스를 보는데..
그 대단한 프로그램도..... 자신들 코드가.. ugly하다면서..
고치고 싶은데.... 호환성때문에.. 제대로 못고치고 있다면서..
고쳐달라는 코드들이 많더군요..

그런걸 보면서.................. 개나소나..
소스코드는 그렇다 치고..README랑 함수 주석이라도 자세히 달아야지.... 그런 생각이 들더군요.. 허허.

익명 사용자의 이미지

안녕하세요. ^_^

좋은 소스 코드의 조건이라면

다른 분이 쓰신 저 조건도 중요하구요.

1. 잘 쓰여진 README
- 쓰여진 소스에 대한 자세한 설명이 있어야 겠죠
전체적인 구조에서 시작해서 세세한 부분은 주석으로..

2. 잘 정의된 자료구조
- 프로그램이 사용할 자료 구조를 잘 짜야하겠지요.

3. 잘 구성된 프로그램
- 하나의 파일에, 또는 하나의 object (OOP 언어에서는)에
무지 하게 많은 함수, 메쏘드들이 있으면 알아보기도
어렵고, 나중에 maintain하기도 어렵겠죠.
모듈화를 잘 시켜서 짜는 것도 중요한 소스 코드 요건중
하나라고 생각합니다.

익명 사용자의 이미지

내가 그 프로그램을 비록 작성하였다 하여도,
시간이 흐른 후 보게 된다면 나도 남입니다.

그렇다면 남이 봐도 알아 볼 수 있는 소스가....

자룡의 이미지

저도 실제로 그러지 못하지만..
\"코드를 보면서 야 이건 정말 잘짠 소스다~~\" 라는 생각이 드는건

잘 쓰여진 주석
완벽한 들여쓰기
이해하기 쉬운 변수명
이해하기 쉬운 파일명

입니다...
알고리즘이야 봐도 잘 모르니깐.. -.-;;
학부때 교수님께 하도 당해놔서 들여쓰기는
어느정도 되는데 (무조건 들여쓰기 3칸!!! 을 요구하는 교수님이였죠.)

다른건 아직도 저언혀 안되는 중입니다..
켁..

-----
이글을 읽는 모든 이에게 평화가 함께 하기를... ^^;

익명 사용자의 이미지

요즈음 공자에 관한 동양학 프로를 좀 보고 있었는데요.
그걸 좀 패러디해서,
the code codes, the function functions, the object objects, etc.
(번역: 코드는 코드 다워야하고, 펑션은 펑션다워야하고, 옵젝트는 옵젝트다워야하고, 등등)
:)

수우_의 이미지

네칸 정도를 요구하시던데요-_-;;;
긁적긁적

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.