根据关注程度高亮代码
Highlighting My Code Based on How Much I Care
受 Nikita Prokopov 关于语法高亮观点的启发，我反思了自己长期使用的 VSCode 默认主题。我发现自己根本无法记住类名等关键元素的颜色，这说明现有主题并未真正辅助阅读。在尝试制作极简浅色主题失败后，我意识到高亮的核心不应是色彩，而应是对比度。我最终设计了一套基于灰度的方案：将注释、变量定义和控制流关键字设为高对比度，而将 let、const 等常用词及标点符号淡化处理。这种“按需高亮”的策略让眼睛能自动跳过无关细节，聚焦于代码的语义逻辑，真正实现了根据“我在乎什么”来呈现代码。
如果无法记住颜色主题中类名的颜色，那么这个主题就不是功能性的，它无法作为工具来帮助你。
HN 评论区
70- nrabulinski
> 试着回想一下你的配色方案里类名是什么颜色？
虽然我总体上同意这篇帖子以及被引用帖子的观点，但我不同意其前提，即你需要能够主动回忆起这类事实。我个人使用的主题色调比较柔和，但它确实对变量、关键字、参数、类型名称以及几类其他标记使用了不同的颜色。我并不会刻意去想“嗯，参数是什么颜色”然后在代码里寻找它们——我只是能直接看到，经过多年的学习，这已经成了肌肉记忆，有助于我阅读代码。就像我记不住公寓大楼的门禁密码，却每天都要输入好几次一样。
- wzdd
这类关于重新思考高亮显示的帖子总是从一个错误的前提开始。我代码中类名的颜色就是所有类名共用的颜色。在接触代码一段时间后，如果某个类名看起来不对劲，我就能注意到。
大脑其实非常高效。除非你刻意努力，否则你不会为了随机脱离语境的回忆去优化它。这并不能说明该方案是否有效。
- sph
我确信每个人对语法高亮的理解都是错的，这篇文章也证实了我的观点。
我的几个槽点：
- 我完全不明白，人们怎么能在现代编辑器中流行的那种非语义的“彩虹呕吐”主题下保持高效。我 ADHD 太严重，不想被无用的信息过度刺激。
- 我每次在 Github 上遇到 Zig 代码都很头疼，因为那里的主题把一切都染成了棕色。哦，原来是因为那是结构体成员。伙计，在 Zig 里几乎一切都是结构体成员，把占源代码 90% 的内容用鲜艳的颜色标出来真是荒谬。随手从我的浏览器历史里找个例子：https://github.com/foxnne/aftersun/blob/main/src/time/enviro...
- 昨天我在 KDE 的 KWrite 文本编辑器里打开了一段 Lisp 代码，每个默认主题都用加粗字体和鲜艳颜色高亮括号，让它们格外醒目。但 Lisp 里的括号本该融入背景，而不是跳出来怼你脸上。这完全没法用，我不得不关掉语法高亮。
我一直在为我的编辑器寻找优秀、极简、柔和的配色主题。真希望有真正专业的设计师来为可用性和舒适度设计主题，而不是让那些根本不该碰颜色的人来瞎搞。
我记得有个同事以前是关闭语法高亮写代码的，当时我觉得这是个怪癖。年纪越大，我越欣赏他的智慧。我宁愿没有语法高亮，也不要糟糕的高亮；至少那样人们会尝试仅通过代码结构本身（缩进、……）来让代码易于解析。
- mattlondon
嗯，这和我预期的不太一样。
我本以为这可能是某种基于复杂度/风险/重要性的突出显示。这瞬间让我觉得“我怎么没想到呢？！”，结果发现他们也没想到。
所以我能想象这样一个场景：你在 IDE 中迭代时，需要审查 LLM 代理生成的 diff。这个 diff 会根据重要性/复杂度进行高亮，供人工审查。像 getter 和 setter 这类琐碎内容会被标成灰色。而高度复杂、繁琐或高风险的代码则会用高对比度的粗体颜色高亮（也许根据关键程度使用亮度等级）。这样，当你审查代理生成的 diff 时，就能瞬间看到并聚焦于最需要关注的关键部分。
我觉得那会非常有用。
- FridgeSeal
我说不清我的函数或结构体语法是什么颜色，但我可以告诉你，当我看代码时，颜色的存在能让我瞬间定位到我此刻关心的那部分文本。