구문 강조 색 구성표 연구

대부분의 프로그래머는 구문 강조 색 구성표에 대해 개인적으로 선호하는 것이 있지만 최고의 색 구성표에 대한 실제 과학적 연구를 해 본 사람이 있습니까? 그런 연구가 프로그래머의 눈이 가장 중요한 부분에 끌리는 지 여부 등 코드의 가독성과 같은 것들을 볼 것이라고 생각합니다.

아마도 이것은 기본 Visual Studio 테마와 같은 것으로 이미 수행되었지만 공개적으로 사용할 수있는 연구가 있는지, 그리고 그들이 찾은 것을 알고 싶습니다.

특정 색 구성표는 다른 모든 색 구성표보다 객관적으로 나을 수 없으며, 순위는 취향과 문화적 요인에 따라 개별적으로 주관적입니다.

그러나 가독성 / 명확성에 대한 특정 규칙, 특히 주변 조명 환경에서의 사용 등이 적용될 수 있습니다. 이는 그래픽 디자인 / 인쇄 법, 휴먼 컴퓨터 인터페이스 및 기타 관련 연구에서 이어집니다.

Ethan Schoonover의 Solarized 프로젝트는 흥미로운 작업입니다 : http://ethanschoonover.com/solarized

: 원격으로 내가 알고있는 주제와 관련된 그들 만 적당히 최근의 연구는 2004 년이다 "가독성, 유지, 미학, 행동의도에 웹 페이지 텍스트 배경 색상 조합의 영향" 홀 & 한나에 의해 . 그러나 그것은 코드가 아니라 웹 페이지와 그들이 생각하는 유일한 색 구성표는 전경색과 배경색입니다.

: 나는 Skepics.SE에 프로그래머를위한 색 구성표 관련 연구에 대해 질문을했다 "더 나은 프로그래머를위한 컴퓨터 화면에 빛에 어두운 색 구성표를 있습니까?" . 거의 2 년 동안 답변을받지 못했지만 일반적으로 이러한 유형의 질문은 매우 빠르게 답변됩니다. 그런 과학적 연구가 없다고 믿게됩니다.

최근 구문 강조보다 시각적으로 풍부한 코드 프레젠테이션에 대한 사용자 연구를 수행했습니다. 구문 강조 체계에 대한 연구는 아니지만 통찰력이 있음을 알 수 있습니다.

D. Asenov 및 O. Hilliges 및 P. Müller- 풍부한 이해가 코드 이해에 미치는 영향 및 2016 년 CHI 의 10 분 강연 비디오 .

우리는 표준 Eclipse 구문 강조를 다음과 같은 시각적 추가 기능을 갖춘 두 가지 더 풍부한 코드 프레젠테이션과 비교했습니다.

• 중괄호 대신 윤곽선
• 목록 요소 분리를위한 쉼표 대신 대체 배경색
• 일부 키워드 대신 아이콘
• 일부 문장 및 표현에 대한 추가 배경색

이 연구는 시각적으로 다양한 프리젠 테이션을 증가 시키면 개발자가 코드 구조를 이해할 수있는 속도에 다소 큰 영향을 미쳤으며, 시간이 최대 75 % 단축되었음을 보여주었습니다. 이것은 코드 구조와 관련된 간단한 질문에 관한 것입니다 (예 : "메소드에 중첩 루프가 있습니까?"). 복잡한 생각이 필요한 작업 (예 : "이 방법의 기능은 무엇입니까?")은 테스트하지 않았습니다. 이러한 작업은 코드 표시의 영향보다는 사람의 기술이 지배하기 때문입니다.

이 연구에서 흥미로운 발견 은 더 풍부한 시각화로 인해 시각적 과부하가 관찰 되지 않았다는 것입니다. 많은 참가자들이 시각적 과부 하나 혼란을 느꼈다고 말했지만, 수집 한 데이터 (답변을 제공 할 시간과 정확한지 여부)는 더 풍부한 시각화로 개선 된 것만 보여주었습니다.

구문 강조와 관련하여 우리의 연구 결과는 더 다양한 시각적 다양성 (예 : 더 많은 색상 및 더 많은 유형의 프로그래밍 구성에 대한 색상)을 사용하는 것이 유리할 것이라고 간접적으로 제안합니다. 예를 들어 내장 유형, 제어 흐름 키워드 및 나머지 키워드에 대해 별도의 색상이있는 테마는 모든 경우에 단일 색상을 사용하는 일반 테마와 비교하여 코드 구조에 대한 이해를 향상시킬 수 있습니다. 키워드.

나는 그런 연구가 존재하지 않는다고 생각합니다. 실제로 회사에서 새 IDE를 만들 때 색상 강조 구문 구문 은 다른 IDE 의 기존 구성표 를 기반으로합니다 .

예를 들어, 기본 Visual Studio 테마에는 new 또는 original이 없습니다 . 오래된 Ada IDE를 포함하여 수년간 키워드에 파란색이 사용되었습니다. 녹색 의견도 마찬가지입니다. 클래스 이름에 대한 청록색과 같은 일부 색상은 다소 "새"색상이지만, 해당 색상을 선택하는 이유를 쉽게 이해할 수 있습니다. 파란색에서 멀지 않은 색상을 설정하는 것이 합리적입니다 ( 예약어 : Int32.NET, intC # 등)와 비슷하지만 이미 사용 된 파란색과는 다른 기본 색상을 유지해야합니다.

이제 어두운 배경에 널리 사용되는 밝은 텍스트와 같은 대체 체계는 어떻습니까? 그것들은 수년간 대상을 연구 한 과학자에 의해 만들어지지 않았으며 정확한 완벽한 일치를 얻기 위해 복잡한 미적분학을 만들었습니다. 대신에 개발자는 읽을 수있는 체계를 만듭니다. 그는 그것을 웹 사이트에서 공유하고 인기를 얻게 됩니다. 그게 다 마술이야.

마지막으로 : 가독성 규칙이 있습니까? 너무 많이하지.

• 대부분 의 경우 주관적인 것 입니다. 파란색 키워드보다 보라색 키워드가 더 읽기 쉽다고 주장 할 수는 없습니다. 다른 사람이 자신보다 답장을 할 수 있기 때문에 모니터에서 보라색 키워드는 파란색 키워드보다 훨씬 읽기 쉽습니다. .

• 다른 부분 은 논리적 입니다. 흑백 구성표는 기본 구성표만큼 읽을 수 없습니다. 같은 방식으로 키워드를 밝은 노란색으로 설정하고 설명을 밝은 회색 (말하자 #eee)으로 흰색 배경에 설정할 수 없습니다. 읽을 수없고 이유를 설명 할 필요가 없기 때문입니다. 웹 사이트를 만들거나 책을 인쇄 할 때에도 같은 규칙이 적용됩니다.

일종의 대략적인 연구로서, 아래 스크린 샷은 XSLT의 구문 강조에 사용되는 3 가지 색상 테마를 보여줍니다. XSLT는 언어 요소의 수가 많고 많은 개발자가 그것을 추악하다고 묘사하기 때문에 특정 과제를 제기하기 때문에 XSLT를 선택했습니다.

태양 광

톰 모로우 나이트

깃 허브

관찰

샘플에 사용 된 색상의 수는 다른 언어 요소를 구별하는 데 도움이되지만 개발자에게는 혼란 스러울 수 있습니다.

언어의 더 중립적 인 부분에 차가운 색을 사용하여 가능하면 차가운 색에서 따뜻한 색으로 진행하는 데 도움이됩니다. 대안은 파스텔 색조에서보다 생생한 색조 (채도)로 전환하는 것입니다.

배경색은 전경색의 인식에 큰 차이를 만듭니다.

일부 인접한 전경색은 눈을 교란시키는 나쁜 충돌을 일으킬 수 있으며, 특히 빨간색과 녹색이 잘 어울리지 않는 것 같습니다.

어두운 배경에서는 서로 및 배경과의 대비가 충분한 넓은 전경색을 제공하는 것이 더 쉽습니다.

마지막으로, 주변 광 및 모니터의 품질 및 교정과 같은 외부 요인이 큰 차이를 만듭니다.

결론

단일 색상 테마가 모든 개발자의 요구를 충족시킬 가능성이 거의 없기 때문에 색상 테마를 설정하는 확장 가능한 방법을 제공하는 도구를 사용하는 것이 가장 좋습니다. 동일한 개발자도 다양한 요인에 따라 선호도를 자주 변경할 수 있습니다.

글쎄, 첫 번째 질문은 흰색 배경이 좋은 아이디어인지 아닌지에 대한 것입니다. 실제 종이에 가깝고 요즘 인터넷의 모든 곳을 찾을 수 있다고해서 반드시 좋은 선택이 될 수는 없습니다.

나는 (많은) 몇 년 전에 우리는 노란색-검정색 "색상 체계"만을 가졌다는 것을 기억합니다. 그리고 나쁘지 않았다는 것도 기억합니다. 흑백과는 대조가 없었습니다. 오래지 않아 나는 그것이 사람의 눈에도 좋다는 것을 알게되었습니다.

때로는 운영 체제와 함께 제공되는 색상 구성표를 누가 디자인하는지 궁금합니다. 나는 보통 그것들을 무시하지만 분홍색과 녹색과 그 밖의 것들이 정말 훌륭하게 혼합되어 있음을 기억합니다. 글쎄, 나는 마약을하지 않습니다 ...

잠재 의식에 색이 어떤 영향을 미치는지에 대한 연구가 있습니다 (진정, 침략 등). 나는 일반적으로 사용되는 색 구성표가 다소 기반이 있다고 생각합니다. 아마 그들은 가독성을 추가했을 것입니다. 코딩은 자살 임무가되어서는 안됩니다.

그러나 현재 IDE의 색상 구성에 관한 한 괜찮습니다. 현실을 직시하자 : 그 뒤에 숨겨진 간단한 아이디어는 일반적인 "코드 노이즈"와 다른 것을 쉽게 찾을 수 있도록하는 것입니다. 그리고 솔직히 말해서 나는 그들이 그것을 허용하기 위해 어떤 색을 사용하는지 신경 쓰지 않습니다. 그것은 녹색 톤에 눈부신 빨강처럼 눈을 다치거나 코드의 일부를 머리 뒤쪽에 태워서는 안됩니다.

코딩은 편안해야합니다. 그리고 그것이 저에게 있습니다.