그러나 그것이 구문이나 논리에 대한 도움을 요청하는 경우 코드가 ".. 구문상 논리적으로 정확하지 않을 것"이라는 의미는 아닙니다. ?
그래, 너가 맞아. 그러나 더(또는 덜) 효과적인 코딩 스타일/관행을 논의하는 맥락에서 가장 중요한 측면은 사용된 코딩 스타일에 관계없이 코드가 구문론적으로나 논리적으로 정확해야 한다는 것입니다. 스타일이 문법적으로나 논리적으로 올바른 코드에 양보해야 한다는 것입니다. 가장 중요한 문제는 코드가 보기 좋고 쉽게 읽을 수 있는지가 아니라 작업을 수행하는 데 구문적으로나 논리적으로 올바른지 여부입니다. 그것을 위해 쓰여진 것입니다. :)
나는 또한 // 의견에 동의합니다. // 코드의 다양한 부분의 세부 사항에 대한 원래 프로그래머의 마음을 새롭게 하고 완성/구현 후 코드에 대한 다른 사람의 이해를 돕거나 돕기 위해 너무 많은 주석을 가질 수 없습니다.
그래, 너가 맞아. 그러나 더(또는 덜) 효과적인 코딩 스타일/관행을 논의하는 맥락에서 가장 중요한 측면은 사용된 코딩 스타일에 관계없이 코드가 구문론적으로나 논리적으로 정확해야 한다는 것입니다. 스타일이 문법적으로나 논리적으로 올바른 코드에 양보해야 한다는 것입니다. 가장 중요한 문제는 코드가 보기 좋고 쉽게 읽을 수 있는지가 아니라 작업을 수행하는 데 구문적으로나 논리적으로 올바른지 여부입니다. 그것을 위해 쓰여진 것입니다. :)
알겠습니다. 말씀하신 내용을 알겠습니다. . . 아름답게 표현된 코드는 작동하지 않으면 아무 소용이 없습니다. . . . 하지만 수정이 더 쉬울까요?
RaptorUK : 아 그래, 무슨 말인지 알겠어. . . 아름답게 표현된 코드는 작동하지 않으면 아무 소용이 없습니다. . . . 하지만 수정이 더 쉬울까요?
옳은. 즉, 프로그래머가 주로 선택하는 코딩 스타일/관행 및 프리젠테이션은 목적을 위한 수단입니다(목적은 구문 및 논리적으로 올바른 코드임). :) 프로그래머가 코드를 쉽게 읽고 이해할 수 있을 때(그리고 코드를 작성하지 않은 다른 사람들도) 구문 및/또는 논리적 오류를 감지하고 수정하는 것이 훨씬 쉽습니다.
대부분의 코딩 스타일은 코더가 원하거나 필요로 하는 만큼의 가독성을 허용한다고 생각합니다. 코드가 완료되고 작동하면 닫지만 공유해야 할 경우 몇 줄 공백으로 다시 여는 것이 쉽습니다. 그것에 대해 토론하십시오. 코딩 형식은 누락된 중괄호를 쉽게 식별하고 여러 분기가 있는 복잡한 if else 트리가 있을 때 if else 쌍을 쉽게 식별할 수 있어야 한다고 생각합니다. 저는 K&R 스타일을 채택한 적이 없어서 K&R 스타일 코더 들이 어떻게 하는지 보고 싶습니다.
왜 아예 닫아? 나는 정말로 찌그러진 코드의 요점을 이해하지 못합니다. 공유/토론을 위해 그것을 열어야 한다면 그것이 의미하는 바는 무엇입니까?
K&R 스타일의 경우 하단 중괄호는 조건 일치에 맞춰 정렬됩니다. 나는 개인적으로 사용
1. 일관된 들여쓰기
2. 단일 명령문 절의 경우 중괄호 및 들여쓰기 또는 조건 뒤에 오는 중괄호가 없는 경우 ie.
3. 중괄호와 일치하는 괜찮은 프로그래머 편집기를 사용하십시오.
중괄호 일치는 문제가 되지 않습니다. 대부분의 Linux 커널은 이 스타일로 작성되었으며 Java 표준입니다. Allman 스타일의 매력을 알 수 있지만 K&R 스타일의 경우 코드를 정리하기 위해 조건 뒤에 빈 줄을 추가하는 경우가 많습니다. 흠 개종될지도 몰라 :)
화면 공간을 덜 차지하기 위해 닫습니다. 나는 화면에 들어갈 수 있는 한 많은 것을 동시에 보는 것을 좋아한다. 중괄호 매처가 필요하지 않습니다. 형식을 지정하므로 중괄호 뒤에 커서를 놓고 화살표 키로 줄 위로 수직으로 실행하면 다른 중괄호에 닿으면 그 중 하나가 쌍입니다. 만약 내가 그것을 else 뒤에 놓고 같은 일을 한다면, 그것이 if에 닿으면 그것이 if else 쌍입니다.
이 코드 섹션에서는 else 뒤에 있는 중괄호가 해당 if 중괄호 뒤에 수직으로 정렬되기 때문에 세 번째 else가 첫 번째 if와 쌍을 이루고 두 번째 else가 첫 번째 else가 세 번째 if와 쌍을 이루는 것을 쉽게 볼 수 있습니다. 마찬가지로 각각의 if 중괄호가 else 뒤의 클러스터에서 해당 닫는 중괄호와 수직으로 정렬되기 때문에 어떤 if에 else가 없는지 쉽게 알 수 있습니다. 내가 좋아하기 때문에 다른 모든 사람들이 이런 방식 으로 코드를 포맷 해야 한다고 제안하는 것은 아니지만 나에게 는 간결하고 논리적입니다.
SDC : 대부분의 코딩 스타일은 코더가 원하거나 필요로 하는 만큼의 가독성을 허용한다고 생각합니다. 코드가 완료되고 작동하면 닫지만 공유해야 할 경우 몇 줄 공백으로 다시 여는 것이 쉽습니다. 그것을 논의하거나. 코딩 형식은 누락된 중괄호를 쉽게 식별하고 여러 분기가 있는 복잡한 if else 트리 가 있을 때 if else 쌍을 쉽게 식별할 수 있어야 한다고 생각합니다. 저는 K&R 스타일을 채택한 적이 없어서 K&R 스타일 코더들이 어떻게 하는지 보고 싶습니다.
k&r을 사용하는 모든 코더에 대해 이 질문에 답할 수는 없습니다. 솔직히 당신의 형식은 보면 볼수록 마음에 들어요. Allman 스타일을 채택했다면 수정 버전을 사용하는 내 자신을 확실히 볼 수 있었습니다. 중괄호 line_up은 서로 아래에 있으며 전체 줄을 차지하는 여는 중괄호와 닫는 중괄호를 제거합니다. if에서 커서를 i 아래로 실행하고 누락된 중괄호를 찾을 수 있으며 탭/ 들여쓰기 크기 규칙에 대해 걱정할 필요가 없으며 컴팩트 모드 {화면에서 대부분의 코드 참조}. 예, 꽤 멋지네요. 처음에는 익숙하지 않아서 혼란스러워 보였습니다. 그리고 이것이 문제의 핵심입니다.
내가 보기에는 많은 미국 코더들이 [KnR & Allman]을 채택하고 있으며 Whitesmiths 스타일이 유럽인들에게 인기가 있는 것처럼 보입니다. Whitesmith는 Mt4의 기본 스타일이기도 합니다. 이제 이러한 스타일에는 아무 문제가 없습니다. 누군가를 도울 때만 K&R 스타일을 무시하고 Whitesmith를 더 생각해야 한다는 것을 계속 상기시켜야 합니다. 또는 코드 포맷터를 사용하십시오.
왜 누군가가 "complex if else tree"를 쓰고 싶어 하는지는 저 너머에 있습니다. 누군가가 모든 White_Space와 서식을 복잡한 if_nest 안에 남겨두면 Snake | 스파게티 | 페이지 전체에 지그재그로. 첫 번째 if는 1번 줄에서 시작하여 300번 줄에서 끝나는 경우, 해당 줄 중 약 150 또는 %50이 중괄호로 묶여 있습니다. "복잡한 if else 트리" 대신에 함수를 만드는 것이 아닙니다. 그런 다음 line_1이 실제로 line_1에서 종료되도록 하고 if( false ){ return; }.
고마워 ubzen 누군가 내 형식을 좋아해줘서 기쁩니다 lol. 나는 if else를 많이 사용하는데, 아마도 내가 처음 코딩을 시작했을 때 누군가 나에게 if else가 빠른 코드를 만든다고 말했기 때문에 그렇게 하는 습관을 갖게 되었기 때문일 것입니다.
개인적인 일이 아니다
모든 사람이 일할 수 있는 공식적인 강제 표준이 있으면 좋을 때입니다. . . . 그러면 우리는 모두 같은 일을 하고 당신의 코드를 좋아할 것입니다. 그리고 당신이 묻기 전에, 아니요, 저는 제 Whitesmiths 스타일을 고수할 것입니다. . . 적어도 나는 지금 그것을 무엇이라고 불러야하는지 알고 있습니다. 감사 합니다. ubzen
그러나 그것이 구문이나 논리에 대한 도움을 요청하는 경우 코드가 ".. 구문상 논리적으로 정확하지 않을 것"이라는 의미는 아닙니다. ?
그래, 너가 맞아. 그러나 더(또는 덜) 효과적인 코딩 스타일/관행을 논의하는 맥락에서 가장 중요한 측면은 사용된 코딩 스타일에 관계없이 코드가 구문론적으로나 논리적으로 정확해야 한다는 것입니다. 스타일이 문법적으로나 논리적으로 올바른 코드에 양보해야 한다는 것입니다. 가장 중요한 문제는 코드가 보기 좋고 쉽게 읽을 수 있는지가 아니라 작업을 수행하는 데 구문적으로나 논리적으로 올바른지 여부입니다. 그것을 위해 쓰여진 것입니다. :)
나는 또한 // 의견에 동의합니다. // 코드의 다양한 부분의 세부 사항에 대한 원래 프로그래머의 마음을 새롭게 하고 완성/구현 후 코드에 대한 다른 사람의 이해를 돕거나 돕기 위해 너무 많은 주석을 가질 수 없습니다.
그래, 너가 맞아. 그러나 더(또는 덜) 효과적인 코딩 스타일/관행을 논의하는 맥락에서 가장 중요한 측면은 사용된 코딩 스타일에 관계없이 코드가 구문론적으로나 논리적으로 정확해야 한다는 것입니다. 스타일이 문법적으로나 논리적으로 올바른 코드에 양보해야 한다는 것입니다. 가장 중요한 문제는 코드가 보기 좋고 쉽게 읽을 수 있는지가 아니라 작업을 수행하는 데 구문적으로나 논리적으로 올바른지 여부입니다. 그것을 위해 쓰여진 것입니다. :)
아 그래, 무슨 말인지 알겠어. . . 아름답게 표현된 코드는 작동하지 않으면 아무 소용이 없습니다. . . . 하지만 수정이 더 쉬울까요?
대부분의 코딩 스타일은 코더가 원하거나 필요로 하는 만큼의 가독성을 허용한다고 생각합니다. 코드가 완료되고 작동하면 닫지만 공유해야 할 경우 몇 줄 공백으로 다시 여는 것이 쉽습니다. 그것에 대해 토론하십시오. 코딩 형식은 누락된 중괄호를 쉽게 식별하고 여러 분기가 있는 복잡한 if else 트리가 있을 때 if else 쌍을 쉽게 식별할 수 있어야 한다고 생각합니다. 저는 K&R 스타일을 채택한 적이 없어서 K&R 스타일 코더 들이 어떻게 하는지 보고 싶습니다.
코드가 완료되고 작동하면 닫지만 공유하거나 토론해야 하는 경우 몇 줄 공백으로 다시 여는 것이 쉽습니다.
왜 아예 닫아? 나는 정말로 찌그러진 코드의 요점을 이해하지 못합니다. 공유/토론을 위해 그것을 열어야 한다면 그것이 의미하는 바는 무엇입니까?
코딩 형식은 누락된 중괄호를 쉽게 식별하고 여러 분기가 있는 복잡한 if else 트리가 있을 때 if else 쌍을 쉽게 식별할 수 있어야 한다고 생각합니다. 저는 K&R 스타일을 채택한 적이 없어서 K&R 스타일 코더들이 어떻게 하는지 보고 싶습니다.
K&R 스타일의 경우 하단 중괄호는 조건 일치에 맞춰 정렬됩니다. 나는 개인적으로 사용
1. 일관된 들여쓰기
2. 단일 명령문 절의 경우 중괄호 및 들여쓰기 또는 조건 뒤에 오는 중괄호가 없는 경우 ie.
3. 중괄호와 일치하는 괜찮은 프로그래머 편집기를 사용하십시오.
중괄호 일치는 문제가 되지 않습니다. 대부분의 Linux 커널 은 이 스타일로 작성되었으며 Java 표준입니다. Allman 스타일의 매력을 알 수 있지만 K&R 스타일의 경우 코드를 정리하기 위해 조건 뒤에 빈 줄을 추가하는 경우가 많습니다. 흠 개종될지도 몰라 :)
왜 아예 닫아? 나는 정말로 찌그러진 코드의 요점을 이해하지 못합니다. 공유/토론을 위해 그것을 열어야 한다면 그것이 의미하는 바는 무엇입니까?
K&R 스타일의 경우 하단 중괄호는 조건 일치에 맞춰 정렬됩니다. 나는 개인적으로 사용
1. 일관된 들여쓰기
2. 단일 명령문 절의 경우 중괄호 및 들여쓰기 또는 조건 뒤에 오는 중괄호가 없는 경우 ie.
3. 중괄호와 일치하는 괜찮은 프로그래머 편집기를 사용하십시오.
중괄호 일치는 문제가 되지 않습니다. 대부분의 Linux 커널은 이 스타일로 작성되었으며 Java 표준입니다. Allman 스타일의 매력을 알 수 있지만 K&R 스타일의 경우 코드를 정리하기 위해 조건 뒤에 빈 줄을 추가하는 경우가 많습니다. 흠 개종될지도 몰라 :)
화면 공간을 덜 차지하기 위해 닫습니다. 나는 화면에 들어갈 수 있는 한 많은 것을 동시에 보는 것을 좋아한다. 중괄호 매처가 필요하지 않습니다. 형식을 지정하므로 중괄호 뒤에 커서를 놓고 화살표 키로 줄 위로 수직으로 실행하면 다른 중괄호에 닿으면 그 중 하나가 쌍입니다. 만약 내가 그것을 else 뒤에 놓고 같은 일을 한다면, 그것이 if에 닿으면 그것이 if else 쌍입니다.
이 코드 섹션에서는 else 뒤에 있는 중괄호가 해당 if 중괄호 뒤에 수직으로 정렬되기 때문에 세 번째 else가 첫 번째 if와 쌍을 이루고 두 번째 else가 첫 번째 else가 세 번째 if와 쌍을 이루는 것을 쉽게 볼 수 있습니다. 마찬가지로 각각의 if 중괄호가 else 뒤의 클러스터에서 해당 닫는 중괄호와 수직으로 정렬되기 때문에 어떤 if에 else가 없는지 쉽게 알 수 있습니다. 내가 좋아하기 때문에 다른 모든 사람들이 이런 방식 으로 코드를 포맷 해야 한다고 제안하는 것은 아니지만 나에게 는 간결하고 논리적입니다.
k&r을 사용하는 모든 코더에 대해 이 질문에 답할 수는 없습니다. 솔직히 당신의 형식은 보면 볼수록 마음에 들어요. Allman 스타일을 채택했다면 수정 버전을 사용하는 내 자신을 확실히 볼 수 있었습니다. 중괄호 line_up은 서로 아래에 있으며 전체 줄을 차지하는 여는 중괄호와 닫는 중괄호를 제거합니다. if에서 커서를 i 아래로 실행하고 누락된 중괄호를 찾을 수 있으며 탭/ 들여쓰기 크기 규칙에 대해 걱정할 필요가 없으며 컴팩트 모드 {화면에서 대부분의 코드 참조}. 예, 꽤 멋지네요. 처음에는 익숙하지 않아서 혼란스러워 보였습니다. 그리고 이것이 문제의 핵심입니다.
내가 보기에는 많은 미국 코더들이 [KnR & Allman]을 채택하고 있으며 Whitesmiths 스타일이 유럽인들에게 인기가 있는 것처럼 보입니다. Whitesmith는 Mt4의 기본 스타일이기도 합니다. 이제 이러한 스타일에는 아무 문제가 없습니다. 누군가를 도울 때만 K&R 스타일을 무시하고 Whitesmith를 더 생각해야 한다는 것을 계속 상기시켜야 합니다. 또는 코드 포맷터를 사용하십시오.
왜 누군가가 "complex if else tree"를 쓰고 싶어 하는지는 저 너머에 있습니다. 누군가가 모든 White_Space와 서식을 복잡한 if_nest 안에 남겨두면 Snake | 스파게티 | 페이지 전체에 지그재그로. 첫 번째 if는 1번 줄에서 시작하여 300번 줄에서 끝나는 경우, 해당 줄 중 약 150 또는 %50이 중괄호로 묶여 있습니다. "복잡한 if else 트리" 대신에 함수를 만드는 것이 아닙니다. 그런 다음 line_1이 실제로 line_1에서 종료되도록 하고 if( false ){ return; }.
고마워 ubzen 누군가 내 형식을 좋아해줘서 기쁩니다 lol. 나는 if else를 많이 사용하는데, 아마도 내가 처음 코딩을 시작했을 때 누군가가 if else가 빠른 코드를 만든다고 말해줘서 그렇게 하는 습관을 들였기 때문일 것입니다.
고마워 ubzen 누군가 내 형식을 좋아해줘서 기쁩니다 lol. 나는 if else를 많이 사용하는데, 아마도 내가 처음 코딩을 시작했을 때 누군가 나에게 if else가 빠른 코드를 만든다고 말했기 때문에 그렇게 하는 습관을 갖게 되었기 때문일 것입니다.
개인적인 일이 아니다
모든 사람이 일할 수 있는 공식적인 강제 표준이 있으면 좋을 때입니다. . . . 그러면 우리는 모두 같은 일을 하고 당신의 코드를 좋아할 것입니다. 그리고 당신이 묻기 전에, 아니요, 저는 제 Whitesmiths 스타일을 고수할 것입니다. . . 적어도 나는 지금 그것을 무엇이라고 불러야하는지 알고 있습니다. 감사 합니다. ubzen