干货| 关于代码对齐的探讨

点击上方“中兴开发者社区”,关注我们

每天读一篇一线开发者原创好文

1 为什么要代码对齐?

程序员的工作并不是仅仅编写程序,程序只是实现业务的一种方式而已。但是能够将实现业务的方式,变得艺术起来,就不是那么简单了。什么叫艺术呢?艺术并不是复杂的,艺术反而是简单的、清晰的、明了的。如同我们看到一幅画,就能够感受到美,这就是所谓的艺术最浅层的体现。在程序里,我认为艺术就是,编写简单清晰、明了的代码。说的再细一点,就是代码一定要排列的整齐,像写文章、设计平面作品一样。最起码保持等号的对齐,保持变量命名的规范。如果编程水平高一些,可以用一些更为简便的方法,来更高快速更快捷的实现功能。再其次就是实现一个功能的各个模块之间,要像搭积木一样,互相独立,然后能够保持模块功能重用性。每一块合规合矩的积木,最后才能搭建出一座美丽的宫殿。

代码像文章一样,总是要维护的。你是否还记得你看别人代码时候那种无名的烦躁心情。因为你看到了乱糟糟的代码,看到了没有注释的代码。你认为这一定是一个傻瓜写的代码。可是你自己写代码的时候,却沉浸在自己实现功能的成就感里,完全忘记了,多打几个空格,多摁几次tab键。

当你按几次空格,为了给代码的等号对齐。同事在一旁问你是不是有强迫症,你完全可以说,我有强迫症,并引以为豪。


2 代码对齐的方式

是Tab?还是空格? 使用空格又是几个空格?


2.1 Tab和空格的区别

Tab和空格其实只是两个不同的符号,但在编程对齐中的意义却大不一样。一个Tab可以占空个格的位置,但一个空格就只有一个空格的位置。

在Keil开发环境中可以显示出Tab和空格符,不妨看一下在Tab和空格交替编辑下,原本使用占2空格Tab符号,实际在4隔空Tab下看代码(和注释)就凌乱了。

离谱的代码中就会看见使用占3个空格的Tab,以上截图举例都还好,没有使用占用3个空格的Tab。

代码前面的对齐都还好处理,很多工具都可以自动排版,像IAR,只要选中需要对齐的代码,Ctrl + T就可以了。但代码后面的注释对齐就不是那么好处理了,如果使用Tab + 空格混合方式,更是容易混乱。


2.2 关于Tab和空格的调查

有人针对 GitHub 上多种语言的热门项目(star 数量高的),分析了代码对齐使用Tab和空格,以及空几格的使用情况。



关于代码对齐,代码编辑器既然支持Tab,也支持使用空格,所以个人觉得两种方式都可以,只看个人习惯使用那一个了。

代码对齐其实很好处理,选择可以自动对齐的工具对齐就OK了,但在代码后面的注释就不是那么容易对齐了(特别在Tab和空格混用情况下),我个人习惯在代码后面把注释也对齐,所以基本不用Tab符。

个人建议:对齐使用空格符,占2空格或4空格(常用)。其优势:1、方便跨平台使用;2、对齐注释。


2.3 tab设置

一份工整对齐的代码真的很重要!

现状是:一份代码多人维护,多种编辑器的混合使用,使得代码触目惊心,

关键原因是tab和空格键混合使用,加上各种编译器对tab的不同显示!

怎么解决?当然是取消tab,所有tab用4个空格代替!怎么操作?

在编码的时候不用tab键,连续敲4个空格,不可能!带来更差的效率!

统一使用一种编译器,不可能!

那怎么办?

有!就是在你敲一个tab的时候,编译器自动的用4个空格代替!

所以先把你手头上所有编译器的的tab 宽度设置为4,tab自动转化为空格。

Source Insight

打开 [Options]->[Documnet Options] 在右下角[Editing Options]->[Tab width]中填4

打开 [Options]->[Documnet Options] 钩选右下角[Editing Options]->[Expand tabs]

 

PSPad

打开 [设置]->[程序设置] 选择 [编辑设置] 在[制表符宽度]中填4

打开 [设置]->[程序设置] 选择 [编辑设置] 不钩选 [真实制表符]

 

EditPlus

打开 [Document]->[Tab Indent] 在[Tab]下的编辑框中填4

打开 [Document]->[Tab Indent] 钩选[Insert spaces instead of tab]

 

Notepad++

打开 [设置]->[制表符设置]->[大小] 填4

钩选 [设置]->[制表符设置]->[用空格替换]

 

UE

打开 [高级]->[配置]->[编辑] 在[制表符宽度]中填4

打开 [高级]->[配置]->[编辑] 钩选[用空格代替制表符]

 

VC

[tools]->[options] -> [tabs]-> [tab size] 填4


[tools]->[options] -> [tabs]-> [indent size] 填4

[tools]->[options] -> [tabs]-> [insert spaces] 选中


3怎么把代码自动排版对齐

看到这里,你可能已经对代码的排版对齐有了深刻的认识,且想把自己的代码作一下调整,那么你是想一行一行的调整么?当然不用了,下面告诉你很好的方法。


3.1先把代码对齐

1)VC方法

假设有test.c

第一步:先用VC打开文件,如下图:

第二步:CTRL + A 选中所有的代码。

第三步:CTRL+F8,看到没有全对齐了。


2)VI方法

如果你没有装VC的话,就使用该方法

第一步:打开test.c文件,这个有人不会吗?上网查查吧!

第二步:在浏览模式下输入命令“1G=G”

注意:G一定得是大写的,则变为:

第三步:最后记住保存该文件

输入“:wq ”命令即可。

 

3)验证是否tab键

 当你把代码对齐之后不要窃喜,因为以上两种方法对齐的时候都是用了tab键。

用UE打开该文件,

选中[视图]->[显示制表符和空格],将看到如下请情况:

“>”表示tab ,“–”表示空格。

可以看出在自动对齐的时候产生了很多tab。

 

3)一次性将tab转换为空格

目前我只发现UE具有该功能。

选中[格式]->[全部制表符转为空格]

5)手工调整

完成以上处理之后,还需要把代码整个看看,有些地方可能处理有问题,主要是以下几个地方:

l 对开源代码中的部分风格会对齐得不是很理想。

l 一行代码太长的情况,需要手工换行。

 

比如以下代码,开源代码中最喜欢这么搞了。

用VC和VI自动对齐后都会出现以下的情况:

可能你希望的是这样的吧,怎么办呢?手工调吧!不知道有没有更好的工具一步到位。

3.2 Merge设置

现在大功告成了,记住这个时候,立马作个简单验证后提单入库,保证下次从最新版本中得到的是对齐的代码了。

但是入库的时候要千万注意了,必须把空格作为差异入库,否则你辛苦排版好的代码,下次从库里看还是不对齐的。

 

选上 [检视]->[选项]红色圈圈的部分。

看看没有选中的情况,这样你去入库,merge认为你什么都没有改哦。

选中的情况是这样的,没错,就是调整了几个空格而已,把这几个空格入库吧!还犹豫什么呢?

3.3 Source Insight高级设置

1Draft View选中

选中[View] ->[Draft View]

没有选中的情况,本来很对齐的代码,没有tab键,看起来是以下的样子,以为代码本身不对齐。

选中的情况,一下子就全对齐了。

2)怎样让{}和if对齐

 写代码经常这样 

你需要手动把 { } 向左移动四个空格,真郁闷。

在[Options ]->[Documents Options] ,点击 Auto Indent。请选择左边的Smart,并且把右边的两个勾都去掉。即可!

### 回答1: Spark Streaming 和 Flink 都是流处理框架,但在一些方面有所不同。 1. 数据处理模型 Spark Streaming 基于批处理模型,将流数据分成一批批进行处理。而 Flink 则是基于流处理模型,可以实时处理数据流。 2. 窗口处理 Spark Streaming 的窗口处理是基于时间的,即将一段时间内的数据作为一个窗口进行处理。而 Flink 的窗口处理可以基于时间和数据量,可以更加灵活地进行窗口处理。 3. 状态管理 Spark Streaming 的状态管理是基于 RDD 的,需要将状态存储在内存中。而 Flink 的状态管理是基于内存和磁盘的,可以更加灵活地管理状态。 4. 容错性 Flink 的容错性比 Spark Streaming 更加强大,可以在节点故障时快速恢复,而 Spark Streaming 则需要重新计算整个批次的数据。 总的来说,Flink 在流处理方面更加强大和灵活,而 Spark Streaming 则更适合批处理和数据仓库等场景。 ### 回答2: Spark Streaming 和 Flink 都是流处理框架,它们都支持低延迟的流处理和高吞吐量的批处理。但是,它们在处理数据流的方式和性能上有许多不同之处。下面是它们的详细比较: 1. 处理模型 Spark Streaming 采用离散化流处理模型(DPM),将长周期的数据流划分为离散化的小批量,每个批次的数据被存储在 RDD 中进行处理,因此 Spark Streaming 具有较好的容错性和可靠性。而 Flink 采用连续流处理模型(CPM),能够在其流处理过程中进行事件时间处理和状态管理,因此 Flink 更适合处理需要精确时间戳和状态管理的应用场景。 2. 数据延迟 Spark Streaming 在处理数据流时会有一定的延迟,主要是由于对数据进行缓存和离散化处理的原因。而 Flink 的数据延迟比 Spark Streaming 更低,因为 Flink 的数据处理和计算过程是实时进行的,不需要缓存和离散化处理。 3. 机器资源和负载均衡 Spark Streaming 采用了 Spark 的机器资源调度和负载均衡机制,它们之间具有相同的容错和资源管理特性。而 Flink 使用 Yarn 和 Mesos 等分布式计算框架进行机器资源调度和负载均衡,因此 Flink 在大规模集群上的性能表现更好。 4. 数据窗口处理 Spark Streaming 提供了滑动、翻转和窗口操作等灵活的数据窗口处理功能,可以使用户更好地控制数据处理的逻辑。而 Flink 也提供了滚动窗口和滑动窗口处理功能,但相对于 Spark Streaming 更加灵活,可以在事件时间和处理时间上进行窗口处理,并且支持增量聚合和全量聚合两种方式。 5. 集成生态系统 Spark Streaming 作为 Apache Spark 的一部分,可以充分利用 Spark 的分布式计算和批处理生态系统,并且支持许多不同类型的数据源,包括Kafka、Flume和HDFS等。而 Flink 提供了完整的流处理生态系统,包括流SQL查询、流机器学习和流图形处理等功能,能够灵活地适应不同的业务场景。 总之,Spark Streaming 和 Flink 都是出色的流处理框架,在不同的场景下都能够发挥出很好的性能。选择哪种框架取决于实际需求和业务场景。 ### 回答3: Spark Streaming和Flink都是流处理引擎,但它们的设计和实现方式有所不同。在下面的对比中,我们将比较这两种流处理引擎的主要特点和差异。 1. 处理模型 Spark Streaming采用离散流处理模型,即将数据按时间间隔分割成一批一批数据进行处理。这种方式可以使得Spark Streaming具有高吞吐量和低延迟,但也会导致数据处理的粒度比较粗,难以应对大量实时事件的高吞吐量。 相比之下,Flink采用连续流处理模型,即数据的处理是连续的、实时的。与Spark Streaming不同,Flink的流处理引擎能够应对各种不同的实时场景。Flink的实时流处理能力更强,因此在某些特定的场景下,它的性能可能比Spark Streaming更好。 2. 窗口计算 Spark Streaming内置了许多的窗口计算支持,如滑动窗口、滚动窗口,但支持的窗口计算的灵活性较低,只适合于一些简单的窗口计算。而Flink的窗口计算支持非常灵活,可以支持任意窗口大小或滑动跨度。 3. 数据库支持 在处理大数据时,存储和读取数据是非常重要的。Spark Streaming通常使用HDFS作为其数据存储底层的系统。而Flink支持许多不同的数据存储形式,包括HDFS,以及许多其他开源和商业的数据存储,如Kafka、Cassandra和Elasticsearch等。 4. 处理性能 Spark Streaming的性能比Flink慢一些,尤其是在特定的情况下,例如在处理高吞吐量的数据时,在某些情况下可能受制于分批处理的架构。Flink通过其流处理模型和不同的调度器和优化器来支持更高效的实时数据处理。 5. 生态系统 Spark有着庞大的生态系统,具有成熟的ML库、图处理库、SQL框架等等。而Flink的生态系统相对较小,但它正在不断地发展壮大。 6. 规模性 Spark Streaming适用于规模小且不太复杂的项目。而Flink可扩展性更好,适用于更大、更复杂的项目。Flink也可以处理无限制的数据流。 综上所述,Spark Streaming和Flink都是流处理引擎,它们有各自的优缺点。在选择使用哪一个流处理引擎时,需要根据实际业务场景和需求进行选择。如果你的业务场景较为复杂,需要处理海量数据并且需要比较灵活的窗口计算支持,那么Flink可能是更好的选择;如果你只需要简单的流处理和一些通用的窗口计算,Spark Streaming是更为简单的选择。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值