bunho가 더 직관적 아니냐? no는 무슨 약어일수도 있고 얼마든지 꼬이기 딱 좋은 네이밍이지 임마.
ㅇㅇㅇ(121.144)2015-09-13 00:18
vb만 해도 vbyes vbno라는 상수가 존재한다.
ㅇㅇㅇ(121.144)2015-09-13 00:18
변수의 유니크함이 또 중요한 이유는 "변수를 어디어디 쓰는지 검색해야할때" 필요함. 어떤 변수를 더 사용하거나 덜 사용해야하는 상황에서 변수이름을 no라고 해놓으면 ㅅㅂ 존나 빡친다. 되려 무식해보여도 직관적이고 흔하지 않은(?)이름이 유지보수에는 훨씬 유리함.
ㅇㅇㅇ(121.144)2015-09-13 00:20
그리고 그 변수이름을 바꾸려고 할때 no 따위로 되어 있으면 no라고 붙인놈을 명치 세게 때리고 싶어질걸?
ㅇㅇㅇ(121.144)2015-09-13 00:21
죄송합니다
nono(121.180)2015-09-13 00:23
무식한넘들 상식적인 표준화를 말하는거
딴넘은 sunbun 이렇게 쓰는넘있는 한글표기는
너무 많은 단어 표현이 있어서 절대 사용하믄 안되
익명(182.219)2015-09-13 00:23
Num이겠지
관노(211.108)2015-09-13 00:24
노..? 일베하노?
?(61.83)2015-09-13 00:40
no보단 num이 더 좋지만 bunho는 좀 아닌듯
나라뜨(skfhddlg)2015-09-13 01:48
변수명 짓는게 젤 어려움. 변수명 짓는 것도 책으로 있는 것 같던데요.
비욘드(211.203)2015-09-13 02:41
글쓴이가 잘 못했네
이힝(66.249)2015-09-13 02:58
실무에서 한다면 무슨 공개 프로젝트도 아니고 상식적인 표준화가 왜 필요한데? 저런 네이밍이 무식해보여도 유니크한게 오히려 유지보수에 도움된다니까 그러네. 누구나 알 필요는 없어. 명세만 분명하면 인수인계도 못할거 없고. 그리고 num이라면 그나마 좀 낫긴 한데, no보다는 낫다는 정도지, num도 또이또이. num 하느니 bunho가 더 낫다고 봄. 답도없이 dfvnjvsdhfdqour3ew 이딴식으로 난독화 시키는게 문제지, bunho나 sunbun은 조금만 살펴보면 파악이 되잖아? 변수는 애매한게 가장 나쁘고, 뜻을 도저히 알수 없는게 그 다음 나쁜거임.
ㅇㅇㅇ(121.144)2015-09-13 11:54
애새끼들 프로그래밍 처음 배울때 int a,b 한다고 이런게 좋은건줄 착각하고 있는놈들 많던데, 이건 그냥 교육용 변수지, 실무에서 난독화 혹은 코드 길이 축소 용도가 아닌한, 변수 저따구로 쓰는 새끼들 존나 욕먹는다. 적어도 한눈에 흐름이 보이는 scope내에서 쓰는 지역 변수라면 그나마 어느정도 봐줄 수 있지만 길이가 어느정도 길때 변수명 저따위로 붙이면 개새끼. 전역변수를 저따구로 붙였다면 개 미친 새끼.
ㅇㅇㅇ(121.144)2015-09-13 11:57
아 그래도 그런건 있다. "no"라고 딱 2글자만 쓰면 미친놈이지만, "무슨table_no"이런거는 인정. 오히려 더 권장될 수 있음. 기본적으로 유니크함이 확보되는지가 문제인거지, no라는 글자가 금지라는 얘기가 아님.
말해예스올노
bunho가 더 직관적 아니냐? no는 무슨 약어일수도 있고 얼마든지 꼬이기 딱 좋은 네이밍이지 임마.
vb만 해도 vbyes vbno라는 상수가 존재한다.
변수의 유니크함이 또 중요한 이유는 "변수를 어디어디 쓰는지 검색해야할때" 필요함. 어떤 변수를 더 사용하거나 덜 사용해야하는 상황에서 변수이름을 no라고 해놓으면 ㅅㅂ 존나 빡친다. 되려 무식해보여도 직관적이고 흔하지 않은(?)이름이 유지보수에는 훨씬 유리함.
그리고 그 변수이름을 바꾸려고 할때 no 따위로 되어 있으면 no라고 붙인놈을 명치 세게 때리고 싶어질걸?
죄송합니다
무식한넘들 상식적인 표준화를 말하는거 딴넘은 sunbun 이렇게 쓰는넘있는 한글표기는 너무 많은 단어 표현이 있어서 절대 사용하믄 안되
Num이겠지
노..? 일베하노?
no보단 num이 더 좋지만 bunho는 좀 아닌듯
변수명 짓는게 젤 어려움. 변수명 짓는 것도 책으로 있는 것 같던데요.
글쓴이가 잘 못했네
실무에서 한다면 무슨 공개 프로젝트도 아니고 상식적인 표준화가 왜 필요한데? 저런 네이밍이 무식해보여도 유니크한게 오히려 유지보수에 도움된다니까 그러네. 누구나 알 필요는 없어. 명세만 분명하면 인수인계도 못할거 없고. 그리고 num이라면 그나마 좀 낫긴 한데, no보다는 낫다는 정도지, num도 또이또이. num 하느니 bunho가 더 낫다고 봄. 답도없이 dfvnjvsdhfdqour3ew 이딴식으로 난독화 시키는게 문제지, bunho나 sunbun은 조금만 살펴보면 파악이 되잖아? 변수는 애매한게 가장 나쁘고, 뜻을 도저히 알수 없는게 그 다음 나쁜거임.
애새끼들 프로그래밍 처음 배울때 int a,b 한다고 이런게 좋은건줄 착각하고 있는놈들 많던데, 이건 그냥 교육용 변수지, 실무에서 난독화 혹은 코드 길이 축소 용도가 아닌한, 변수 저따구로 쓰는 새끼들 존나 욕먹는다. 적어도 한눈에 흐름이 보이는 scope내에서 쓰는 지역 변수라면 그나마 어느정도 봐줄 수 있지만 길이가 어느정도 길때 변수명 저따위로 붙이면 개새끼. 전역변수를 저따구로 붙였다면 개 미친 새끼.
아 그래도 그런건 있다. "no"라고 딱 2글자만 쓰면 미친놈이지만, "무슨table_no"이런거는 인정. 오히려 더 권장될 수 있음. 기본적으로 유니크함이 확보되는지가 문제인거지, no라는 글자가 금지라는 얘기가 아님.
유니크하면서도 짧은게 유리한거. "무슨table_bunho"는 "무슨table_no"보다 쓸데없이 길잖아.