코드 하이라이트, 정말 필요한가? 내가 신경 쓰는 만큼만 강조하기

이런 하이라이트 재고 글들은 항상 잘못된 전제에서 시작합니다. 제 코드에서 클래스 이름의 색은 모든 클래스 이름이 가진 색입니다. 잠시 코드로 작업하다 보면 하나가 이상해 보이면 알아차릴 것입니다.

뇌는 정말 효율적입니다. 문맥 없이 무작위로 회상하는 데 최적화하지 않습니다. 정말 그렇게 하려고 애쓰지 않는 한 말이죠. 그런 기억이 스킴의 효율성에 대해 말해주는 것은 없습니다.

저는 모든 사람이 구문 하이라이트를 잘못 이해하고 있다고 확신하며, 이 글이 제 생각을 뒷받침합니다.

제가 싫어하는 점:

- 현대 편집기에서 유행하는 비의미적 무지개 똥 테마로 어떻게 생산적으로 일할 수 있는지 모르겠습니다. 저는 ADHD가 있어서 쓸모없는 정보로 과도하게 자극받는 것을 원하지 않습니다.

- GitHub에서 Zig 코드를 볼 때마다 싫습니다. 거기 테마는 모든 것을 갈색으로 만드는데, 구조체 멤버라서 그렇다고 하더군요. 세상에, Zig에서는 모든 것이 구조체 멤버입니다. 소스 코드의 90%에 해당하는 것에 선명한 색을 할당하는 것은 어리석은 일입니다. 제 브라우저 기록에서 무작위 예: https://github.com/foxnne/aftersun/blob/main/src/time/enviro...

- 어제 KDE의 KWrite 텍스트 편집기에서 Lisp 코드를 열었는데, 모든 기본 테마가 괄호를 굵은 글꼴과 선명한 색으로 강조해서 눈에 띄게 만듭니다. Lisp에서 괄호는 배경에 희미해져야지, 눈에 튀어나오면 안 됩니다. 완전히 사용할 수 없어서 구문 하이라이트를 꺼야 했습니다.

항상 좋은, 최소한의, 차분한 색상 테마를 찾고 있습니다. 사용성과 편안함을 위해 테마를 디자인하는 진지한 디자이너가 있었으면 좋겠습니다. 색을 가지고 놀 자격이 없는 사람들이 아니라요.

구문 하이라이트를 끄고 코드를 작성하던 동료가 생각납니다. 그때는 그게 괴짜 같은 선택이라고 생각했는데, 나이가 들수록 그의 지혜를 더 깨닫게 됩니다. 나쁜 구문 하이라이트보다는 없는 편이 낫습니다. 적어도 구조만으로 코드를 쉽게 파싱하려고 할 테니까요. (잘림)

음, 이건 제가 예상한 것과는 다르네요.

복잡성/위험/중요성에 기반한 하이라이트일 거라고 생각했습니다. 그런데 그건 "왜 나는 그걸 생각 못 했지?!" 하는 순간이었는데, 실제로 그들도 그렇게 하지 않았습니다.

그래서 IDE에서 반복 작업하는 동안 LLM 에이전트의 diff를 검토해야 하는 시나리오를 상상할 수 있습니다. diff는 인간 검토를 위해 중요성/복잡성에 따라 강조될 것입니다. getter나 setter 같은 사소한 것은 회색으로 표시되고, 매우 복잡하거나 까다롭거나 위험한 코드는 대비가 높은 굵은 색(중요도에 따라 밝기 척도가 있을 수도 있음)으로 강조될 것입니다. 그러면 에이전트의 diff를 검토할 때 가장 주의가 필요한 중요한 부분을 즉시 보고 집중할 수 있습니다.

저는 그게 정말 유용할 것 같습니다.

제 함수나 구조체 구문의 색이 무엇인지 말할 수는 없지만, 코드를 볼 때 그 색의 존재 덕분에 그 순간 관심 있는 텍스트 부분으로 즉시 이동할 수 있다는 것은 말할 수 있습니다.