중괄호를 생략하는 것이 왜 나쁜 습관으로 간주됩니까? [닫은]
왜 이런 식으로 코드를 작성하는 것이 나쁜 습관이라고 말합니까?
if (foo)
Bar();
//or
for(int i = 0 i < count; i++)
Bar(i);
중괄호를 생략하는 가장 큰 주장은 때로는 두 배가 될 수 있다는 것입니다. 예를 들어 다음은 C #에서 레이블의 광선 효과를 페인트하는 코드입니다.
using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
{
for (int x = 0; x <= GlowAmount; x++)
{
for (int y = 0; y <= GlowAmount; y++)
{
g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));
}
}
}
//versus
using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
for (int x = 0; x <= GlowAmount; x++)
for (int y = 0; y <= GlowAmount; y++)
g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));
또한 usings백만 번 들여 쓰기하지 않고도 체인 연결의 추가 이점을 얻을 수 있습니다 .
using (Graphics g = Graphics.FromImage(bmp))
{
using (Brush brush = new SolidBrush(backgroundColor))
{
using (Pen pen = new Pen(Color.FromArgb(penColor)))
{
//do lots of work
}
}
}
//versus
using (Graphics g = Graphics.FromImage(bmp))
using (Brush brush = new SolidBrush(backgroundColor))
using (Pen pen = new Pen(Color.FromArgb(penColor)))
{
//do lots of work
}
중괄호에 대한 가장 일반적인 주장은 유지 보수 프로그래밍과 원래 if 문과 의도 된 결과 사이에 코드를 삽입하여 발생할 수있는 문제를 중심으로합니다.
if (foo)
Bar();
Biz();
질문 :
- 언어가 제공하는보다 간결한 구문을 사용하고 싶습니까? 이 언어를 디자인하는 사람들은 영리합니다. 항상 사용하기에 좋지 않은 기능을 사용한다고 상상할 수 없습니다.
- 가장 낮은 공통 분모를 이해하고 처리하는 데 아무런 문제가 없도록 코드를 작성해야합니까?
- 내가 놓친 또 다른 주장이 있습니까?
실제로, 내가 정말로 물린 유일한 시간은 내가 디버깅 할 때 였고 bar ()를 주석 처리했습니다.
if(foo)
// bar();
doSomethingElse();
그 외에는 다음을 사용하는 경향이 있습니다.
if(foo) bar();
위의 경우를 처리합니다.
편집 질문을 분명히 해 주셔서 감사합니다. 최저 공통 분모에 코드를 작성해서는 안됩니다.
읽는 속도 ...
이미 언급 한 것 말고는. 이 시점에서 나는 중괄호와 공백이있는 if 문을 구문 분석하도록 이미 조건화되었습니다. 그래서 나는 읽었습니다.
if (condition)
{
DoSomething();
}
DoSomethingElse();
내가 읽는 것보다 약간 빠릅니다.
if (condition) DoSomething();
DoSomethingElse();
다음과 같은 경우 조금 느리게 읽습니다.
if (condition) DoSomething();
DoSomethingElse();
나는 이것을 이전보다 상당히 느리게 읽었습니다.
if (condition)
DoSomething();
DoSomethingElse();
나는 도움이 될 수 없기 때문에 단지 그것을 다시 읽고 저자가 의도했는지 궁금해합니다.
if (condition)
{
DoSomething();
DoSomethingElse();
}
일반적으로 이미 다루었지만 아래 내용 을 읽을 때 저자가 의도 한 내용을 확인하기 위해 잠시 동안 살펴볼 것입니다. 원래 저자를 찾아서 확인하기도합니다.
if (condition)
DoSomething();
DoSomethingElse();
작은 것이면 다음과 같이 작성하십시오.
if(foo()) bar();두 줄로 나눌 수있을 정도로 긴 경우 중괄호를 사용하십시오.
또한 실제로 필요할 때만 중괄호를 사용하는 것이 더 좋다고 생각했습니다. 그러나 더 이상, 주된 이유는, 코드가 많을 때 더 읽기 쉽고 일관된 브레이싱 스타일이있을 때 코드를 더 빨리 파싱 할 수 있다는 것입니다.
if에 두 번째 문장을 추가하는 것 외에도 항상 중괄호를 사용하는 또 다른 좋은 이유는 다음과 같은 일이 발생할 수 있습니다.
if(a)
if(b)
c();
else
d();
else 절이 실제로 "if (b)"의 절이라는 것을 알고 계셨습니까? 당신은 아마했을 것입니다,하지만 당신은이 문제에 익숙한 사람을 믿습니까?
따라서 일관성을 유지하고 다른 사람 (항상 바보 인 다른 사람)이 코드를 변경할 때 예기치 않은 일이 발생할 수있는 일을 알지 못 하기 때문에 소스 코드를 더 읽기 쉽고 빠르게 파싱하기 때문에 항상 중괄호를 넣습니다. 당신의 두뇌. 위임이 이루어 지거나 스위치와 같은 if와 같은 가장 간단한 if 문에 대해서만 절이 확장되지 않는다는 것을 알고 있다면 중괄호를 생략합니다.
나는 중괄호가 제공하는 선명도를 선호합니다. 당신은 무엇을 의미하는지 정확히 알고 있으며 누군가가 방금 그들을 막아 냈는지 추측 할 필요가 없습니다 (버그를 도입했습니다). 내가 그들을 생략하는 유일한 경우는 if와 action을 같은 줄에 넣을 때입니다. 나도 그렇게 자주하지 않습니다. 나는 수년간의 K & R C 유사 프로그래밍에서 중괄호로 줄을 끝내는 것이 IDE가 그것을 강제하지 않으면 극복하기 위해 노력해야하는 연습이지만, 실제로 중괄호를 자체 줄에 넣음으로써 도입 된 공백을 선호합니다. 나를.
if (condition) action(); // ok by me
if (condition) // normal/standard for me
{
action();
}
이것이 항상 나쁜 습관으로 여겨지는 것은 아닙니다. 모노 프로젝트 코딩 가이드 라인 은 필요가 없습니다 중괄호를 사용하지 것이 좋습니다. GNU 코딩 표준도 마찬가지입니다 . 코딩 표준과 마찬가지로 개인적 취향의 문제라고 생각합니다.
줄이 싸다. 프로세서 성능이 저렴합니다. 개발자 시간은 매우 비쌉니다.
일반적으로 절대적으로 리소스 / 속도 중요한 응용 프로그램을 개발하지 않는 한 항상 코드 작성 측면에서 실수를합니다.
(a) 다른 개발자가 내가하고있는 일을 쉽게 수행 할 수 있습니다.
(b) 필요할 수있는 코드의 특정 부분에 대한 주석
(c) 무언가 잘못되면 쉽게 디버깅
(d) 향후에 필요할 경우 쉽게 수정할 수 있습니다 (예 : 코드 추가 / 제거)
코드의 속도 또는 학문적 우아함은 비즈니스 관점에서 이러한 요소에 부차적입니다. 이것은 내가 어색하거나 못생긴 코드를 작성하기로 설정 한 것은 아니지만 이것이 나의 우선 순위입니다.
대부분의 경우 중괄호를 생략하면 (b), (c) 및 (d)가 더 어려워집니다 (그러나 불가능하지는 않습니다). 중괄호를 사용하거나 사용하지 않아도 (a)에 영향을 미치지 않습니다.
나는 그것이 당신이 작업하는 프로젝트와 개인적인 취향에 대한 지침의 문제라고 생각합니다.
나는 보통 다음과 같은 경우를 제외하고 필요하지 않을 때 생략합니다.
if (something)
just one statement; // i find this ugly
else
{
// many
// lines
// of code
}
나는 선호한다
if (something)
{
just one statement; // looks better:)
}
else
{
// many
// lines
// of code
}
이것이 당신을 물릴 수있는 인스턴스 중 하나는 옛날 C / C ++ 매크로로 돌아 왔습니다. 나는 이것이 C # 질문이라는 것을 알고 있지만, 표준이 처음 만들어진 이유없이 코딩 표준이 종종 이어집니다.
매크로를 만들 때주의하지 않으면 {}를 사용하지 않는 if 문에 문제가 발생할 수 있습니다.
#define BADLY_MADE_MACRO(x) function1(x); function2(x);
if (myCondition) BADLY_MADE_MACRO(myValue)
자, 내가 틀리지 말아라. 나는 C / C ++ 에서이 문제를 피하기 위해 항상 {}을해야한다고 말하지는 않지만, 이것 때문에 매우 이상한 버그를 다루어야했다.
나는 같은 방식으로 생각합니다.
언젠가 (왜 당신의 삶을 영원히 변화시키는 "하루"가 항상 존재 하는가?)) 우리는 누군가가 검색 / 대체 변경과 결합 된 괄호를 넣지 않은 것을 발견하기 위해 생산 코드를 디버깅하지 않고 24-36 시간 연속으로 보냅니다. .
이런 식이었습니다.
if( debugEnabled )
println( "About to save 1 day of work to some very important place.");
saveDayData();
뒤에 온 것은
if( debugEnabled )
// println( "About to save 1 day of work to some very important place.");
saveDayData();
시스템에서 매일 500MB의 로그를 생성하는 것으로 나타 났으며 중지하라는 요청을 받았습니다. 디버그 플래그가 충분하지 않아서 println을 검색하고 교체했습니다.
여전히 앱이 프로덕션 환경으로 전환되었을 때 디버그 플래그가 해제되었고 중요한 "saveDayData"가 호출되지 않았습니다.
편집하다
이제 중괄호를 사용하지 않는 유일한 장소는 if / try 구문입니다.
if( object != null ) try {
object.close();
} catch( .....
그렇게하는 슈퍼 스타 개발자를 본 후.
나는 매우 행복하다 :
foreach (Foo f in foos)
foreach (Bar b in bars)
if (f.Equals(b))
return true;
return false;
개인적으로 나는 왜 그런지 모르겠다
foreach (Foo f in foos)
{
foreach (Bar b in bars)
{
if (f.Equals(b))
{
return true;
}
}
}
return false;
더 읽을 수 있습니다.
예, 줄은 비어 있지만 크기와 크기가 절반 일 때 왜 페이지와 코드 페이지를 스크롤해야합니까?
가독성이나 유지 관리성에 차이가 있다면, 중괄호를 넣으십시오 ...하지만이 경우에는 아무런 이유가 없습니다.
또한, 나는 항상 중첩 된 곳에 중괄호를 넣을 것입니다.
if (condition1)
if (condition2)
doSomething();
else (condition2)
doSomethingElse();
vs
if (condition1)
if (condition2)
doSomething();
else (condition2)
doSomethingElse();
매우 혼란 스럽기 때문에 항상 다음과 같이 씁니다.
if (condition1)
{
if (condition2)
doSomething();
else (condition2)
doSomethingElse();
}
가능할 때마다 삼항 연산자를 사용하지만 결코 중첩 하지 않습니다 .
무딘하기 위해 나는 그것을 다음과 같이 본다 :
좋은 프로그래머는 방어 적으로 프로그램하지만 나쁜 프로그래머는 그렇지 않습니다.
위의 몇 가지 예와 중괄호를 잊어 버리는 것과 관련된 버그에 대한 비슷한 경험이 있기 때문에 항상 괄호를 넣는 어려운 방법을 배웠습니다.
다른 어떤 것도 안전보다 개인 스타일을 선택하고 있으며 이는 분명히 나쁜 프로그래밍입니다.
Joel은 심지어 잘못된 코드를 잘못 보이게 만들기 에서 이것을 언급했습니다.
괄호가 누락되어 버그가 생기면 누락 된 괄호가 다른 버그가 발생할 가능성이 있다는 것을 알고 있기 때문에 누락 된 괄호가 잘못 표시되는 것을 알게됩니다.
"만약 누군가가 코드를 작성하도록 돈을 지불 할만큼 똑똑하다면, 코드의 흐름을보기 위해 들여 쓰기에만 의존하지 않을만큼 똑똑해야합니다."
그러나 ... 실수를 할 수 있으며 이것은 특히 다른 사람의 코드를 볼 때 디버깅하는 데 어려움이 있습니다.
내 철학은 코드를 더 읽기 쉽게 만든다면 왜 그렇지 않습니까?
분명히 간결하고 지나치게 변수 이름이 명확한 매체를 찾는 것처럼 어딘가에 선을 그려야합니다. 그러나 대괄호는 실제로 오류를 피하고 코드의 가독성을 향상시킵니다.
사람들은 코더가 될만큼 똑똑한 사람들이 대괄호가없는 버그를 피할만큼 똑똑 할 것이라고 주장 할 수 있습니다. 그러나 철자 오류만큼 단순한 문제에 빠진 적이 없다고 정직하게 말할 수 있습니까? 큰 프로젝트를 볼 때 이와 같은 Minutia는 압도적 일 수 있습니다.
항상 예외가 있지만 양식 중 하나에있을 때만 중괄호를 생략하는 것에 대해 논쟁합니다.
if(x == y) for(/* loop */) { //200 lines } //rampion's example: for(/* loop */) { for(/* loop */) for(/* loop */) { //several lines } }
그렇지 않으면 문제가 없습니다.
나는 종종 맨 아래 코드 (여러 명령문을 사용하여)를 사용하지만 그 외에는 항상 중괄호를 넣습니다. 코드가 더 명확 해집니다. 문장이 블록의 일부라는 것 (그리고 아마도 if 등의 일부)이라는 단순한 들여 쓰기가 아니라는 것은 명백하다.
나는 보았다
if (...)
foo();
bar();
버그 나에게 물린 (또는 오히려 "나와 동료"-실제로 버그를 소개하지 않았다) 한 번 . 이것은 당시의 코딩 표준이 모든 곳에서 중괄호 사용을 권장한다는 사실에도 불구하고있었습니다. 보고 싶은 것을 알기 때문에 놀랍게도 오랜 시간이 걸렸습니다. (이것은 약 10 년 전입니다. 아마도 더 빨리 찾을 수있을 것입니다.)
물론 "줄 끝에 괄호"를 사용하면 추가 줄이 줄어든다. 그러나 나는 개인적으로 그 스타일을 싫어한다. (나는 직장에서 그것을 사용하고 예상보다 덜 불쾌한 것을 발견했지만 여전히 약간 불쾌합니다.)
한 줄 블록에서 중괄호를 건너 뛸 때 잠재적 인 버그가 발생할 가능성이 컴퓨터 프로그래밍 분야의 동료들에게 많은 관심을 기울이지 않는다는 것에 깊은 인상을 받았습니다.
나는 그것이 똑똑하지 않다는 것을 의미한다고 생각합니다. 이 문제를 여러 번 실수했습니다. 나는 이것에 관한 다른 사람들의 실수를 디버깅했다. 이 때문에 버그가있는 소프트웨어가 제공되는 것을 보았습니다 (VS2002를 실행하는 컴퓨터에 대한 RDP 및 시계 창 글꼴이 불안정합니다).
코딩 스타일을 변경하여 피할 수 있었던 모든 실수를 살펴보면 목록이 매우 깁니다. 이 각각의 경우에 접근 방식을 변경하지 않았다면 아마도 프로그래머로 만들지 않았을 것입니다. 다시, 나는 똑똑하지 않다고 생각한다. 보상하기 위해, 나는 오랫동안 한 줄 블록에 중괄호를 꾸준히 사용했습니다.
즉, 오늘날 모세가 그것을 우리에게 가져 왔을 때보 다 오늘날에는 "한 줄 블록에 버팀대를 사용해야한다"라는 규칙이 덜 관련이 있도록하는 몇 가지 사항이 바뀌 었습니다.
일부 유명한 언어는 프로그래머가하는 것처럼 컴퓨터가 들여 쓰기를 읽음으로써 문제를 해결합니다 (예 : Python).
편집자가 자동으로 서식 을 지정하므로 들여 쓰기로 오인 될 가능성이 크게 줄어 듭니다.
TDD 는 한 줄 블록으로 혼란스러워서 버그를 도입하면 버그를 빨리 발견 할 가능성이 훨씬 높다는 것을 의미합니다.
리팩토링과 언어 표현 은 내 블록이 훨씬 짧고 한 줄 블록이 이전보다 훨씬 자주 발생한다는 것을 의미합니다. 가설 적으로, ExtractMethod를 무자비하게 적용하면 전체 프로그램에서 단일 행 블록 만 가질 수 있습니다 . (어떻게 생겼는지 궁금 하신가요?)
사실, 무자비하게 리팩토링하고 한 줄 블록에서 중괄호를 생략하면 뚜렷한 이점이 있습니다. 중괄호를 볼 때 머리에 "복잡함을 조심하십시오!"라는 작은 경보가 울릴 수 있습니다. 이것이 표준이라면 상상해보십시오.
if (condition) Foo(); // normal, everyday code
if (condition)
{
// something non-trivial hapening; pay attention!
Foo();
Bar();
}
코딩 규칙을 "단일 블록에는 중괄호가 없을 수 있습니다"또는 "조건과 같은 줄에 블록을 넣을 수 있고 80 자 이내로 입력 할 수있는 경우" 괄호 생략 ". 우리는 볼 수 있습니다.
세 가지 규칙 중 :
if(addCurleyBraces()) bugFreeSofware.hooray();
과:
if(addCurleyBraces())
bugFreeSofware.hooray();
및 (열기와 닫는 중괄호를 사용하여 들여 쓰기 스타일을 나타냅니다) :
if(addCurleyBraces()) {
bugFreeSofware.hooray();
}
나는 마지막 것을 선호합니다 :
- 모든 if 문이 균일 한 방식으로 작성되면 더 쉽게 읽을 수 있습니다.
- 소프트웨어를 조금 더 강력하고 버그없이 만들 수 있습니다. 그러나 모든 최신 IDE 및 고급 텍스트 편집기에는 멋진 자동 들여 쓰기 기능이있어 주석 형식을 엉망으로 만들거나 팀 표준에 위배되지 않는 한 모든 사람이 사용해야한다고 생각합니다 (많은 경우 사용자 정의 형식 지정 체계를 만들 수 있음) 팀과 공유하십시오). 여기서 요점은 들여 쓰기가 올바르게 수행되면 버그 도입 위험이 약간 줄어 듭니다.
- 부울 식과 문을 실행하여 다른 줄에있는 것을 선호합니다. 디버깅 목적으로 행을 표시하고 싶습니다. 명령문을 표시하고 단계를 수행 할 수있는 IDE를 사용하더라도 대화 형 작업이며 디버깅을 시작한 위치를 잊어 버릴 수 있습니다. 적어도 몇 가지 코드를 단계별로 실행하는 데 약간의 시간이 더 걸립니다. 시간 (디버깅 중에 매번 수동으로 위치를 표시해야하기 때문에).
중괄호 사용에 대한 주요 주장은 추가 줄을 사용하고 추가 들여 쓰기가 필요하다는 것입니다.
줄은 (거의) 무료이므로 코드의 줄 수를 최소화하는 것이 목표가되어서는 안됩니다.
들여 쓰기는 중괄호 사용법과 무관합니다. 계단식 '사용'예에서 여전히 중괄호를 생략하더라도 들여 쓰기해야한다고 생각합니다.
단정하고 간결한 코드를 작성하는 데는 강한 신자이지만 항상 중괄호를 사용합니다. 특정 코드 줄이 존재하는 범위를 신속하게 볼 수있는 편리한 방법이라는 것을 알았습니다. 모호함이 없으며, 그것은 분명히 당신 앞에서 명시됩니다.
어떤 사람들은 그것이 선호되는 경우라고 말할 수도 있지만, 내부적으로 일관성이 있다면 프로그램의 논리적 흐름을 따르기가 훨씬 쉽다는 것을 알았으며, 이와 같은 IF 문을 작성하는 것이 일관성이 없다고 생각합니다.
if(x < y)
x = y;
else
y = x;
그리고 이와 같은 또 다른 것;
if(x < y)
{
x = y;
x++;
}
else
{
y = x;
y++;
}
나는 단지 하나의 일반적인 스타일을 고르고 그것을 선호합니다 :)
주된 문제 중 하나는 한 줄짜리 라이너와 하나가 아닌 라이너의 영역이 있고 제어문 ( for,, if가지고있는 것)과 그 끝이 분리 된 상태입니다.
예를 들면 다음과 같습니다.
for (...)
{
for (...)
for (...)
{
// a couple pages of code
}
// which for block is ending here? A good text editor will tell you,
// but it's not obvious when you're reading the code
}
I used to be a huge supporter of "curly braces are a MUST!", but since adopting unit testing, I find that my unit tests protect braceless statements from the scenarios like:
if (foo)
snafu();
bar();
With good unit tests, I can confidently omit curly braces for simple statements to improve readability (yes, that can be subjective).
Alternatively, for something like the above, I would likely inline that to look like:
if (foo) snafu();
That way, the developer who needs to add bar() to the condition, would be more apt to recognize the lack of curly braces, and add them.
Use some personal judgement.
if (foo)
bar();
is fine by itself. Unless you're really worried about morons putting in something like this later:
if (foo)
bar();
baz();
If you're not worried about morons, you're fine (I'm not -- if they can't get basic code syntax right, this is the least of their problems)>
In exchange, it's a lot more readable.
The rest of the time:
if (foo) {
bar();
baz();
}
Which has been my favorite as long as I can remember. Additionally:
if (foo) {
bar();
baz();
} else {
qux();
}
Works for me.
Vertical space by itself isn't terribly relevant, readability is. The opening brace on a line by itself just stops the conversation for a syntactic element, until your eye moves down to the next line. Not what I like.
Okay, this is an old question that has been answered to death. I have something to add.
First I just have to say USE THE BRACES. They can only help readability, and readability (for yourself and others!) should be very high on your priority list unless you're writing assembly. Unreadable code always, always leads to bugs. If you find that braces make your code take up too much space, your methods are probably too long. Most or all of any method should fit within one screen height if you're doing it right, and Find (F3) is your friend.
Now for my addition: There is a problem with this:
if (foo) bar();
Try setting a breakpoint that will only be hit if bar() is going to run. You can do this in C# by putting the cursor on the second half of the code, but that is not obvious and is a bit of a pain. In C++ you couldn't do it at all. One of our most senior developers working on C++ code insists on breaking 'if' statements into two lines for this reason. And I agree with him.
So do this:
if (foo)
{
bar(); //It is easy to put a breakpoint here, and that is useful.
}
Let's say you have some code:
if (foo)
bar();
and then someone else comes along and adds:
if (foo)
snafu();
bar();
According to the way it's written, bar(); is now executed unconditionally. By including the curly braces, you prevent this kind of accidental error. Code should be written in such a way as to make such mistakes difficult or impossible to make. If I was doing a code review and saw the missing braces, especially spread across multiple lines, I would create a defect. In cases where it is justified, keep it on one line so that the chance of making such an error is again kept to a minimum.
Reducing lines is not really a good argument for dropping braces. If your method is too big, it should probably be refactored into smaller pieces or restructured. Doing that will no doubt increase readability more than simply taking out braces.
in order to keep the code with braces from taking up lots of space, I use the technique recommended in the book Code Complete:
if (...) {
foo();
bar();
}
else {
...
}
I always omit them when appropriate, such as in your first example. Clean, concise code I can see and understand by glancing at is easier to maintain, debug and understand than code I have to scroll through and read line by line. I think most programmers will agree with this.
It is easy for it to get out of hand if you start doing multiple nesting, if/else clauses and so on, but I think most programmers should be able to tell where to draw the line.
I see it kind of like the argument for if ( foo == 0 ) vs if ( 0 == foo ). The latter may prevent bugs for new programmers (and maybe even occasionally for veterans), while the former is easier to quickly read and understand when you're maintaining code.
Most times it is ingrained as a coding standard, whether for a company or an FOSS project.
Ultimately someone else will need to grok your code and it is a major time drain for each developer to have to figure out the specific style of the section of code they are working on.
Also, imagine that someone is going between Python and a Cish language more than once a day... In Python indenting is part of the block symantics of the language and it would be quite easy to make a mistake like the one you quote.
Err on the side of more secure - just one more bug you potentially won't have to fix.
I personally feel more secure if all of my blocks are wrapped in curlys. Even for one-liners, these are simple notations that easily prevent mistakes. It makes the code more readable in the sense that you clearly see what is in the block as not to confuse the body of the block with the following statements outside of the block.
If I have a one-liner, I typically format it as follows:
if( some_condition ) { do_some_operation; }
If the line is just too cumbersome then use the following:
if( some_condition )
{
do_some_operation;
}
참고URL : https://stackoverflow.com/questions/359732/why-is-it-considered-a-bad-practice-to-omit-curly-braces
'IT story' 카테고리의 다른 글
| UINavigationController의 back bar 버튼을 눌렀을 때 동작 실행 (0) | 2020.05.22 |
|---|---|
| MySQL 오류 : '사용자'root '@'localhost '에 대한 액세스가 거부되었습니다. (0) | 2020.05.22 |
| OS X에 PG gem 설치-기본 확장 빌드 실패 (0) | 2020.05.22 |
| 해시 키를 다른 키로 바꾸는 방법 (0) | 2020.05.22 |
| 문자열에서 정규식 패턴이 일치하지 않습니까? (0) | 2020.05.22 |