程序员应该知道的 3 个排版原则

2022-06-29 14:52:41 浏览数 (1)

前两周有《手把手教你接入前端热门抓包神器 - whistle》这么一篇文章,我叫一个同学做一个推文封面,半小时后我收到了下面这张。

我的心情当然是一言难尽。

还有一次我和小伙伴一起讨论,团队技术氛围本来就好,讨论的话题更是让人手舞足蹈,最后得出下面这么一张图。

表情包之所以是好东西,是因为它能以搞笑的方式表达一些严肃的心情。

这两个事情确实让我有些触动,干了十年前端开发了,遇到的当然也远远不止这两件,我随便列几个,你们可以对号入座。

总觉得黑不溜丢、各种字符疯狂跳动的 `Terminal` 界面很酷,自己从视觉那边接过来的精美设计图不酷;总觉得写代码很酷,把一封邮件写的重点突出、表达顺畅不酷;总觉得高度浓缩晦涩难懂的代码很酷,通俗直白逻辑清晰的代码不酷……

如果你觉得这些确实是问题而不是什么引以为傲的情操,并且想加以改善,那我们继续,不然可以收藏此文,经受几年职场毒打后再来看。

心态摆正后,我们就来聊聊“排版”,维基百科对排版的描述如下:

在固定版面内,排版(英语:Typesetting)摆置各种不同类型的资料,如数字、文字、表格、图形和影像等等,以最合适的方法呈现。印刷品中的版面安排,网页文案的编排,若要引人注意和阅读上的舒适,皆应留意排版方面的问题。 对网页编辑器、电子邮件、操作系统等的软件操作画面编排,大都会以“用户界面”(UI)来称呼。 为什么排版构成如此重要?构图,简而言之,这就是你安排或组织内容的呈现方式。

这段描述里面提到了”网页”、“UI”,加上我从业前端这么多年,私以为排版也是前端该掌握的基本技能之一。排版远远没有大家想的那么难以掌握,相反,只要掌握几个原则,就会让你排版提高一个档次。让我们先看看改善后的封面:

从专业的设计角度来讲,这封面远算不上精美,但是非常契合我总结的排版三原则:分块,对齐,颜色。其实我有翻过一些排版的资料,但大多数都偏向专业设计,各种术语云里雾里的,不好理解也不够有程序员特色,远没我这三个简单粗暴容易实操,下面逐一聊聊。

分块

分块,或者叫分类,专业词汇是“亲密性原则”,就是把相同内容的东西放一起,并和其他内容区分。

上图我简单的划了下,当你分成三块后,考虑的就是这三个元素的排列,而不是一堆元素胡乱放置。

分块更多的是基于内容来组织的。比如你写代码,很长,你捋清逻辑分成几个不同的模块,比你一团乱麻、疯狂挤牙膏的代码要好的多。写文章、邮件也是一样,不管是事先规划后还是事后梳理总结,反正把你的内容归类成几个“模块”,再取个小标题,就非常容易被别人理解了。

分块其实是一种渐进式理念,先大后小,先整体再局部,这种方式也是符合绝大多数人的思维方式的,切忌一上来就是海量的细节填满别人的视野,别人不玩手机才怪了。

再看几个例子吧。

我们工作一般都会使用 IM 工具,在发消息之前,也可以试着把内容分成几块,而不是一股脑的发一堆消息。

下图是团队没有规范“Git 提交记录”之前:

而这个是规范之后:

这是遵守的规范,业界都已经约定俗成了。

代码语言:javascript复制
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]

规范前随意提交,规范化后就是得按一定格式了。不只是代码可以规范化,提交记录也行,当时我把这个规范后,成为了晋升 T10 的一部分素材。

再来看一个,这次是代码。

区别就是“空行”,多了两个空行后,首先是视觉上区分出来了,然后层次分明,一眼能找到主逻辑,写代码,善于利用“空行”啊。

其实“分割”是“分块”的影子,相辅相成的,多利用空白、分割线、引导线来“分割”,设计上这叫“留白”,看看下图,留白的重要性。

好了,整理内容,分门别类,这种事情早点做、随时做,这种习惯也早点养成,然后你升职加薪就很快了,毕竟别人还在搞代码规范的时候,你已经把团队的提交记录规范化,为后续的一些自动工具打好了基础。

对齐

分块不会分其实我能理解,毕竟分块和内容息息相关,是要充分理解的,但是对齐都做不到就有点过分了,最常见的反例是啥,无脑居中对齐。

再看看左对齐的效果:

这个例子里面,居中对齐真的很凌乱,一点秩序的感觉都没有。居中对齐一般都是少量文字,比如标题之类的。

对齐无非就是横向左、中、右对齐,纵向顶、中、底对齐。我们平时的阅读习惯都是上到下,左到右,如果真的想无脑操作,你就无脑左对齐。

看例子吧,经常有人找我看 PPT ,例子很多。

这算什么对齐?

对齐的潜台词是有一个对齐基准的,基准让事物整齐、有条理,明确不同的事物之间的逻辑关联。从这个案例来看,这三个模块之间的逻辑关联是啥呢?大家没把握或者不理解的时候,宁愿简单一点,先把事情描述清楚(如下图),不然做多错多。就算深谙美化技巧,那也还是要牢记一根“基准线”。

PPT 或者 Keynote 里面,都有一个参考线的概念,我随便问了几个人,都不知道参考线在哪里调出来,简直让人发指啊!我这里做个简单的小调查吧,此时此刻你会不会设置参考线:

PPT 的对齐要说起来得说一箩筐,开始的那张“封面”,大家可以回滚回去体会下那个对齐。

代码也是要对齐的,应该没有人代码不缩进的吧,像链式调用的对齐,HTML/JSX 属性的对齐等一些容易争议的地方,都是要制定团队规范的。

对齐是竖立基准让相关事务靠齐的一个过程,在日常生活中无处不在的……比如产品说“对齐一下”,那是要开会了。

颜色

终于要聊聊颜色了。

颜色有很多表示法,比较常见的是 RGB ,但是 RGB 更多的是方便机器识别,而不是人类感知,当前谈“颜”色变的人,大多是被 RGB 荼毒的人。

HSL 也是一种颜色表示法,CSS 里面有,可能大家从未用过,Windows 系统的颜色选择器也是 HSL 。还有一种与 HSL 很相似的,叫 HSB 或者 HSV ,MacOS 里的颜色选择基于这个,和 HSL 相比,我觉得这个更接近人类的直观感受,下面就详细聊聊这个 HSV 。

HSV 即色相、饱和度、明度(英语:Hue, Saturation, Value),又称 HSB,其中 B 即英语:Brightness 。 * 色相(H)是色彩的基本属性,就是平常所说的颜色名称,如红色、黄色等。 * 饱和度(S)是指色彩的纯度,越高色彩越纯,低则逐渐变灰,取 0-100% 的数值。 * 明度(V),亮度(L),取 0-100% 。

上面是维基百科的描述,很清楚了,我对着下图解释一下:

* 绕圆一周就是色相,表示各种颜色,红黄蓝什么的

* 从圆心到圆周,则是饱和度,越靠近边缘饱和度越高

* 下面那个渐变的横条就是表示亮度,最不亮的时候就是黑色

我们经常讲不要用“大红大蓝”,这个图就很好解释,大红大蓝饱和度最高、亮度最亮,是很刺眼。

把饱和度、亮度随便降点,就会好很多。

所以说为啥大家是被 RGB 荼毒了,这些颜色的直观感受,用 RGB 是很难描述的,以后用颜色,饱和度、亮度别 100% 就不会有大错

除了颜色表示法,颜色的种类切忌太多,一般四种足够了:主色、辅助色、强调色和背景色

如果不是很有研究,背景色默认白色就好,经常有同学搞些花里胡哨的背景,导致文字都看不清,何必呢,白底黑字是阻碍你表达了么。

背景色白色,主色黑色,辅助色深灰,强调色橙色,这四个颜色容错率最高,无脑用就行。当然有同学说想有自己的个性,那也不要瞎折腾,在这里 `coolors.co` 找一些成熟的配色,还是那句话,如果没研究,就找现成的,何必吃力不讨好呢。

这里提一个问题:把这些颜色保存下来,你能导进 PPT 或 Keynote 方便日后取用吗?

代码编辑器里面的颜色又是另外一种说法,我觉得是越多越好,“无色编码”可能只在装 X 的时候好使。

这是我 16 年给 VSCode 提的 Issue ,那个时候他们的着色真的不行,应该是基于 TextMate 的,纯正则来高亮,不能分析各种语言的语义,现在是有一套 Semantic Highlight ,相对好的多。

我的编码习惯是,每一种变量的颜色都不一样,全局变量、局部变量甚至参数颜色都不一样,其他场景可以类推。

分块,对齐,颜色,平时随便留意下就会让你的表达质量提升很多,何乐而不为呢。

整个文章写下来,我就觉得如果有娃了,得给报个美术补习班。


程序员这个职业之所以特别,是因为这个职业的门槛确实不小,以至于大部分心力都要用于学习编码技能,也因此,职场人该有的一些其他能力对程序员来说,掌握程度几乎可以忽略不计。程序员在成为程序员之前,你得先是个职场人,有些技能可以现在不会,但不要打心里抵触甚至瞧不起,都是职场人,自视甚高就会引来群嘲了。

这就是话题“程序员不只是编码”的出发点了,欢迎订阅哦。

参考文章

代码语言:javascript复制
https://www.w3.org/TR/clreq/http://colorizer.org/https://coolors.co/https://zh.wikipedia.org/wiki/HSL和HSV色彩空间https://cdc.tencent.com/2011/05/09/色生心中:人性化的hsl模型/

紧追技术前沿,深挖专业领域

扫码关注我们吧!

0 人点赞