진실은 이 모든 것의 유용성을 아주 잘 해결하는 것이 필요하다는 것입니다. 그리고 가장 필요한 것이 무엇인지 이해하십시오. 저것들. 모든 상호 연결의 전체 발판을 보여주는 것은 확실히 의미가 없습니다. 왜냐하면 많은 첨부 파일이 있는 개체에 대해 각각 20개의 상속이 있을 수 있습니다(자세한 내용은 여기에서 설명). 그러나 이 객체가 상위 구조에서 언급된 위치 또는 구문 분석되는 코드에서 객체의 외부 세부 초기화를 작성한 경우 초기화되는 위치를 찾는 것과 같습니다. 또는 특정 기능 을 다시 로드하여 새로운 중간 개체를 빠르게 생성하고 상위 기능에서 무엇이 잘못되었는지 이해하십시오. 일반적으로 이 작업은 검색에 의해 처리되지만 컴파일러는
그래픽 코드 표현 언어를 고안하고, 좋은 탐색에 대해 생각하고, 표시되는 정보의 중요도의 우선순위를 결정합니다(중요한 정보는 표시하는 데 더 적은 노력이 필요하고 덜 중요합니다. 그 반대의 경우도 마찬가지입니다). 여전히 코드에 대한 전체 분석이 필요합니다.
확실히 쉽지는 않을 것입니다. 좋아, 실현 가능성이 희박하다는 걸 알아...
예를 들어 정유 공장 의 3D 설계 와 같은 프로그램이 있습니다. 배관 연결 다이어그램이 있습니다. 처음에는 숙련된 프로세스 엔지니어가 하나의 "시각적" 다이어그램보다 도면 더미를 읽는 것이 더 쉽고 익숙해집니다. 복잡한 코드는 시각화하더라도 인식하기 어려울 것입니다. 모든 규칙을 따르면 코드는 원래 형식으로 읽기가 매우 쉽습니다.
Реter Konow : 예, 하지만 그의 방향은 정확합니다. 코딩은 뇌의 잠재력을 사용하기 위한 좁은 통로입니다. 코드로 설명된 패턴은 눈으로 인식되는 동일한 패턴보다 수백 배 더 오래 이해됩니다. 각 랩에서 속도가 느려지고 경사각이 약간 증가하는 팽이를 상상해보십시오. 이 과정을 수식으로 설명하고 카메라에 담아보세요. 프로그래머가 그것들이 동일하다는 것을 깨닫는 데 걸리는 시간을 측정하십시오.
모든 사람은 자신의 접근 방식을 가지고 있습니다. 개인적으로 다이어그램은 나를 약간 귀찮게합니다. 나는 Donald Knuth 의 문학 프로그래밍 접근 방식 (어떤 이유로 러시아어에서는 "유능한"으로 번역 됨)과 예를 들어 R 언어 (R 가격 인하)
당신은 헛되이 상단에 대해 썼습니다) 이것은 역학의 풀리지 않은 문제입니다. 운동에 대한 일반 공식은 없습니다(마찰이 무시되더라도).
The literate programming paradigm, as conceived by Knuth, represents a move away from writing computer programs in the manner and order imposed by the computer, and instead enables programmers to develop programs in the order demanded by the logic and flow of their thoughts.[2] Literate programs are written as an uninterrupted exposition of...
Aleksey Mavrin : 예를 들어 정유 공장의 3D 설계와 같은 프로그램이 있습니다. 배관 연결 다이어그램이 있습니다. 처음에는 숙련된 프로세스 엔지니어가 하나의 "시각적" 다이어그램보다 도면 더미를 읽는 것이 더 쉽고 익숙해집니다. 복잡한 코드는 시각화하더라도 인식하기 어려울 것입니다. 모든 규칙을 따르면 코드는 원래 형식으로 읽기가 매우 쉽습니다.
다음 두 코드 표시 옵션이 다르게 인식되는 이유가 궁금할 수 있습니다.
//+------------------------------------------------------------------+//| Initialization of the indicators |//+------------------------------------------------------------------+bool CSampleExpert::InitIndicators( void )
{
//--- create MACD indicatorif (m_handle_macd== INVALID_HANDLE )
if ((m_handle_macd= iMACD ( NULL , 0 , 12 , 26 , 9 , PRICE_CLOSE ))== INVALID_HANDLE )
{
printf ( "Error creating MACD indicator" );
return ( false );
}
//--- create EMA indicator and add it to collectionif (m_handle_ema== INVALID_HANDLE )
if ((m_handle_ema= iMA ( NULL , 0 ,InpMATrendPeriod, 0 , MODE_EMA , PRICE_CLOSE ))== INVALID_HANDLE )
{
printf ( "Error creating EMA indicator" );
return ( false );
}
//--- succeedreturn ( true );
}
물론, 체계를 모르는 것보다 체계를 알고 코드를 구문 분석하는 것이 더 쉽습니다.
기술적으로는 코드 시각화 도우미가 있으면 편리할 것입니다. 특히 하나가 다른 하나를 취소하지 않고 보완하는 경우에 그렇습니다.
물론, 체계를 모르는 것보다 체계를 알고 코드를 구문 분석하는 것이 더 쉽습니다.
기술적으로는 코드 시각화 도우미가 있으면 편리할 것입니다. 특히 하나가 다른 하나를 취소하지 않고 보완하는 경우에 그렇습니다.
자급자족할 수 있는 본격적인 코드 시각화 도우미를 만들어 보지 않겠습니까?
그래픽 코드 표현 언어를 생각해내고, 그 안에서의 좋은 탐색에 대해 생각하고, 표시된 정보의 중요도의 우선순위를 결정하십시오(중요한 정보는 표시하는 데 더 적은 노력이 필요하고 덜 중요하며 그 반대의 경우도 마찬가지입니다). 여전히 코드에 대한 전체 분석이 필요합니다.
확실히 쉽지는 않을 것입니다. 좋아, 실현 가능성이 희박하다는 걸 알아...
자급자족할 수 있는 본격적인 코드 시각화 도우미를 만들어 보지 않겠습니까?
그래픽 코드 표현 언어를 고안하고, 좋은 탐색에 대해 생각하고, 표시되는 정보의 중요도의 우선순위를 결정합니다(중요한 정보는 표시하는 데 더 적은 노력이 필요하고 덜 중요합니다. 그 반대의 경우도 마찬가지입니다). 여전히 코드에 대한 전체 분석이 필요합니다.
확실히 쉽지는 않을 것입니다. 좋아, 실현 가능성이 희박하다는 걸 알아...
자급자족할 수 있는 본격적인 코드 시각화 도우미를 만들어 보지 않겠습니까?
그래픽 코드 표현 언어를 생각해내고, 그 안에서의 좋은 탐색에 대해 생각하고, 표시된 정보의 중요도의 우선순위를 결정하십시오(중요한 정보는 표시하는 데 더 적은 노력이 필요하고 덜 중요하며 그 반대의 경우도 마찬가지입니다). 여전히 코드에 대한 전체 분석이 필요합니다.
확실히 쉽지는 않을 것입니다. 좋아, 실현 가능성이 희박하다는 걸 알아...
자신의 코드와 시각 디자인으로 자신만의 설정을 생성할 수 있고 다른 사람의 시각 디자인을 위해 기성품 템플릿을 사용할 수 있으므로 몇 줄을 쓰기에는 너무 게으르다고 합니다.))
프로그래밍에서 내가 사용하는 첫 번째 장소는 아마도 함수를 다시 로드하는 것입니다. 그러나 코드에서 모든 것이 이미 매우 간단하고 새 이름을 작성하고 상속받은 위치를 작성하고(원칙적으로 이것은 템플릿임) 무엇으로 대체하는지 작성합니다. 모두!
나는 이러한 트릭이 빠르게 거대한 라이브러리로 성장할 것이며 이 모든 것을 기억하기 어려울 것이라고 생각합니다.
예, 하지만 그의 방향은 정확합니다. 코딩은 뇌의 잠재력을 사용하기 위한 좁은 통로입니다. 코드로 설명된 패턴은 눈으로 인식되는 동일한 패턴보다 수백 배 더 오래 이해됩니다. 각 랩에서 속도가 느려지고 경사각이 약간 증가하는 팽이를 상상해보십시오. 이 과정을 수식으로 설명하고 카메라에 담아보세요. 프로그래머가 그것들이 동일하다는 것을 깨닫는 데 걸리는 시간을 측정하십시오.
모든 사람은 자신의 접근 방식을 가지고 있습니다. 개인적으로 다이어그램은 나를 약간 귀찮게합니다. 나는 Donald Knuth 의 문학 프로그래밍 접근 방식 (어떤 이유로 러시아어에서는 "유능한"으로 번역 됨)과 예를 들어 R 언어 (R 가격 인하)
당신은 헛되이 상단에 대해 썼습니다) 이것은 역학의 풀리지 않은 문제입니다. 운동에 대한 일반 공식은 없습니다(마찰이 무시되더라도).
당신은 헛되이 상단에 대해 썼습니다) 이것은 역학의 풀리지 않은 문제입니다. 운동에 대한 일반 공식은 없습니다(마찰이 무시되더라도).
그리고 켈트 스톤도 탑)
...
당신은 헛되이 상단에 대해 썼습니다) 이것은 역학의 풀리지 않은 문제입니다. 운동에 대한 일반 공식은 없습니다(마찰이 무시되더라도).
어쩐지 생각이 안 나더라. )
예를 들어 정유 공장의 3D 설계와 같은 프로그램이 있습니다. 배관 연결 다이어그램이 있습니다. 처음에는 숙련된 프로세스 엔지니어가 하나의 "시각적" 다이어그램보다 도면 더미를 읽는 것이 더 쉽고 익숙해집니다. 복잡한 코드는 시각화하더라도 인식하기 어려울 것입니다. 모든 규칙을 따르면 코드는 원래 형식으로 읽기가 매우 쉽습니다.
다음 두 코드 표시 옵션이 다르게 인식되는 이유가 궁금할 수 있습니다.
그런 다음 그래픽 "틴셀"을 제거했습니다. 마이너스 색상, 마이너스 패딩(상대 위치).
가독성이 현저히 떨어집니다. 이는 그래픽 표현이 가독성을 크게 향상시킬 수 있음을 시사합니다. 다이어그램에 대해 구체적으로 말하는 것이 아니라 많은 옵션이 있을 수 있습니다.