-
Notifications
You must be signed in to change notification settings - Fork 10
/
0256.txt
273 lines (273 loc) · 11 KB
/
0256.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
예 안녕하세요 포프입니다.
오늘은 주석에 대해 말해볼게요.
주석..이라면 코멘트(comment)죠?
코드에서
국가주석 이런게 아니라
이 주석이라는거에 대해 굉장히 의견이 분분해요
주석을 어디까지 달아야되냐?
아니면 뭘 주석으로 달아야되냐
여러사람들의 의견이 다르지만
저는 이렇게 생각을 해요
//주석은
//없을수록 좋아요
이러면 이제 돌 맞는데
제가 하려고 하는 얘기가 뭐냐면
제가 여태까지 비디오에서 말해놨고
제가 공개한 코딩스탠다드에서 말했지만
저는 기본적으로
'코드의 가독성'이 높아야된다고 생각해요
코드를 읽는 순간
그 코드가 무슨일을 하는지
일반적인 프로그래머가 알 수 있는 정도의
코드가 나와야된다고 보거든요?
그러면 어떤사람은 그런 얘기를 해요.
"코드가 읽기가 그렇게 쉬운게 아니다"
근데, 제가 그런말 하는 사람 코드를 받아봤을 때
정말 그 코드 읽기 힘들었어요.
그리고 그 코드를 제가 뒤엎으면
뭐..한 코드 절반을 지울 경우도 있어요.
근데 성능은 똑같거나 나아지죠.
그런 경우는 코드가 읽기가 훨씬 편해져요.
그래서 코드 가독성에 대해서는
변수 이름 (포맷)이라던가 뭐라던가
이런 거는 코딩스태다드 문제니 거기에 나두고
제가 하고자 하는 얘기는
코드는 그 자체로 읽을 수가 있어야 되요
코드를 그냥 읽는 것만으로
이게 뭐하는 건지 알아야 되고
거기에 중요한 역할을 하는게 변수 이름
그리고 음..
그.. 함수 이름들
'함수 이름'과 '매개변수 이름'들
이게 굉장히 중요해요.
그것만 읽는거만으로도
굉장히 코드 읽기편해지고
코드가 좀 길어지고
로직이 이해가 안될 때는
중간중간
temporary변수에 넣어가지고
변수 이름을 제대로 해줌으로써
가독성을 높이는 법도 있죠
뭐 그렇게 하려면 또 이제
spacing 잘하고 이런것도 있고
그런 부분은 되게 중요하고
주석보다 훨씬 중요한 거예요
심지어는 제가 실제 주석을 달지는 않지만
제가 볼 때는, 코드를 보면 이해가 되는 거 위에
똑같이 주석을 달아놓은 코드를 보면
전 주석을 지워버려요
왜냐하면 이거는 말 그대로
a = 1 + 1 넣어놓고
//1 더하기 1을 한다
라고 주석을 다는거랑 똑같은 거에요
그런거는 정말 쓸데없는 주석이고
또 하나의 문제는
이런 코드가 한 번 들어오기 시작하면
코드는 변하는거예요
누군가 그 코드를 터치하게 되고 코드를 바꾸게 되요
근데 그 사람이 백프로 주석을 바꾼다는 보장은 없어요
그러면 좋죠.
그런데 실제 회사에 다니면서 그렇게
쓸데없는 주석이 달려있는 경우에
코드가 바뀌면서 주석이 안바뀌는 경우를
정말 많이 봤고요.
심지어는 그 주석이 필요한 경우
보니까 코드를 봤는데,
잘 이해가 안되는 경우가 있어요 사실은
어쩔 수 없이 코드를 그렇게 밖에
못짜는 경우가 있어요
그런 경우에
주석에 달아 넣어줘요.
//이코드는 왜이렇게 짰고
//이래서 이렇게 작동한다
왜냐면 사람들이 그걸 이해하고
코드를 보면 이해가 쉬우니까
아니면은 코드에는 드러나있지 않지만
어떤 데이터라든가
다른 함수 호출을 하는 사람들
그쪽에서 만드는 가정이 있잖아요.
이 데이터를 반드시 뭐..
이렇게 이렇게 오기 때문에
이렇게 처리해야 한다는
그런거에서는 주석을 다는건
저는 찬성이에요.
코드만 보는걸로는 이해가 안되니까
한마디로 제가 하고 싶은 말은
코드가 읽히게 쓰고
코드가 안읽힐때
주석을 달으란 얘기예요.
그리고 아까 말했던 가정같은거 있잖아요.
그건 솔직히 주석에 달기보다는
assert를 박아서 무조건 디버그 중에
딱 멈추도록 만드는게 맞아요
여기까지는
'과연 어느부분에서 주석을 달아야되냐'라는 얘기했어요
그럼 이제 그 다음은
이게
저는 함수에도 가능하면
주석을 안다는 방향으로 가요.
함수 이름과 함수 매개변수가 분명하다면
그 자체로, 주석은 필요없다고 봐요.
근데 예외가 있어요.
예외가 뭐나면
'공개 API'
재밌는게 뭐냐면
제가 공개 API,
Public API라고 얘기를 하면
사람들이
내 엔진에 쓰는 모든 Public API
public으로 된 모든 함수에 주석을 달아야한다 생각해요
아니에요.
회사 안에서 쓰는 코드고
밖에 나가지 않는 라이브러리 코드라면
우리가 어차피 소스코드가 다 있는 상황이라면
굳이 거기에 주석을 다는건
시간낭비고 필요없다고 생각해요.
오히려 함수 이름과 함수 매개변수로 나와야 되지
그거에 대해서 무슨 세세한 거를 전부 다 쓰는거 자체가
저는 잘못된 거라고 봐요
근데 이 Public API가 라이브러리화가 돼서
소스 코드가 없이 남한테 준다.
남이 가지고 있는 거는 함수 API뿐이고
코드 내부를 못보게 돼있는 경우,
그런 경우에는 저는
public 함수에 주석이 들어가야된다고 봐요.
주석 들어가서
함수 이름에서 분명하지 않은 그런 것들 있잖아요
이 값은 범위가 몇이 아니면
exception을 던진다거나
이런거 까지도 주석은 자세히 써야 돼요.
그래서 라이브러리 개발자하시는 분들은
주석을 잘 유지하는 거에 대한
참, 오버헤드가 크죠.
스트레스도 좀 많고
그래서 지금 제가 여태까지 한 거를 정리하면
'코드의 기본은 주석이 없어야 된다'예요.
코드 자체로 읽혀지고 이해가 돼야 되지,
거기에 주석을 달아서 이해시키려 하면
코드를 깔끔하게 못짜는 가능성이 높고
단, 코드를 읽었는데
'정말 말도 안돼.'
'이게 왜 작동하는지도 모르겠어'
'이게 왜 이런 짓을 하지?' 라고 하는 부분이 있어요.
아까 말했듯이 코드 안에서 명백히 안드러나는 거.
그런 거는 주석을 달아야되요.
구로고 세번째
라이브러리화해서 소스코드 없이 남한테 주는
그런 패키지가 있다면
그거는 주석을 다는 게 맞아요
마지막으로 네번째
이거는 의견이 분분한걸 많이 봤어요.
코드에 주석을 달라고 하는 이유가,
함수 위에다가
요즘 웬만한 언어들은
아니면 다른 라이브러리를 써도 되고
뭐 툴을 써도 돼요.
그렇게 주석 위에 아니, 함수위에 주석을 달아 놓은거
그거를 이렇게 프로세싱을 해서
도큐먼트를 따로 뽑아줄수가 있어요.(documentation)
문서를 아예 뽑아줘요. 자동으로
저는 그래서 함수에 다는걸 되게 좋아해요.
그러나
어떤 사람들은 함수에 절대 달지 말고
차라리 문서를 따로 처음부터 만들어라라는 얘기를 해요.
그래서 DoSomething 이란 함수가 있다면
이 문서에 DoSomething을 쓰고
이거를 고친 다음에 매개변수도 만들어서
문서를 제대로 만들어서 이 문서를 줘라
라고 얘기를 하는데
이거는 그냥 의견이 분분해요
저는 이쪽 진영은 아니에요.(문서를 만드는 진영은)
저는 함수안에,
코드안에 차라리 그걸 박는 진영이고
그러고나서 그거를 그냥 간단하게
툴로 돌려가지고 문서를 만들자는 주의에요.
심지어는 뭐 C#이나 ASP.NET같은거 하면
자체 패기지가 딸려와요.
ASP.NET 웹페이지 만들면
고 위에 주석을 처리해가지고 그냥
/help인가? 들어가면
거기서 곧바로 모든 함수 API하고 매개변수 쫙 보여주는
그런 것도 자동으로 해주거든요.
저는 그런거를 자동으로 해주는데
왜 굳이 귀찮게 그러나 생각이 들고
그러고 제가 아까 말했듯이
코드 위에 주석이 있어도
가끔 주석과 코드가 따로 간다고 했잖아요?
똑같은 얘기로
함수 위에 주석이 있어도 따로 가요.
근데 그게 따로 가는 경우라도 이걸
어떻게든 좀 빡세게 고쳐야만
외부 라이브러리 쓰는 사람들한테 도움이 되니까
그런 걸 감안해서 하는 거죠
어.. 정확히 얘기하면
'실'보다 '득'이 많으니까
그래서 그렇게 가는 건데
문제는
이거를 다른 문서로 놔두면
오히려 더 틀려질 가능성이 높아요.
사실은.
그 코드 베이스에서 평생 일한 사람이면
좋지만
처음 온 신입은 이거 고치는데
문서가 어디서 고치는지 모르고,
뭐 이러면서 문제가 있거든요
완벽하게 도는 회사라면 그게 다 되는데
세상에서 완벽하게 도는 회사는
거의 없습니다
그래서 실수를 덜 할 수 있는
방향으로 그렇게 가는 거고
그래서 제가 생각한 주석이란건
그 정도인거 같아요.
남이 이해할 수 있을지 없을지 판단이 안된다?
"나는 코드가 이해가 잘되는데
왜 남은 안돼?" 하시는 분들 있는데
그분들은 그냥 어..
정신차리라고 하고 싶고
그런 분들이 보통 버그도 많이 만들고
자기 코드 써놓고
한달 뒤에 보고 자기도 이해 못해요.
자기는 지금 짰기 때문에
이해가 되는거 뿐이죠.
변수명 abcd적어 놓고 이런 사람들
그거는 그냥 뭐라 그럴까..
게으른 걸 변명하는 수단으로 밖에 안 보여요
그래서 내가 남의 코드를 봤을 때
이해가 안되는 부분이 있다면
내가 그따위로 코드짜면
남도 이해가 안 되는 거거든요
그런 좀 동일한 기준을
가지고 코딩을 짜다보면 되는데
이중잣대를 많이 가지는 사람들을
그런식으로 말하죠
"아 이 코드가 왜 이해가 안돼?"
근데 그 사람들은 남의 코드를 이해 못해요.
그런식으론
그렇게 얘기하고 싶었고
주석은 딱 4가지로 정리하면
일단 주석은 안적는게 원칙이다.
코드가 읽을수 있어야 된다.
그게 1번이고
2번
허나 코드가 이해가 안되는 경우
이해가 될수 없는 상황이 있어요.
그런 경우에는 주석을 단다.(고 위에)
3번
내부적으로 코드를 볼 수 없는
외부에 가져다 파는 라이브러리
이런 경우일때는
Public API
그러니까 private은 상관이 없죠
아무도 안보니까
우리끼리만 보니까
Public API쪽에 주석을 달도록 한다.
4번 문서화해서 문서를 따로 작성하냐
아니면 그냥 API 위, 코드 위에
주석을 작성하냐를 고려하면
이거는 어느 쪽으로 가도 되지만
저는 코드 안에 주석을 넣는거를
훨씬 선호해요.
한 4가지 정도로 정리를 하고
포프의 주석 얘기는 오늘
이 정도로 끝내도록하죠.
포프였습니다