报名参加CloudWeGo黑客松,奖金直推双丰收! 了解详情
写点什么

如何使用编程规则和指南

作者:Ben Linders

  • 2024-12-20
    北京
  • 本文字数:1919 字

    阅读完需:约 6 分钟

如何使用编程规则和指南

根据 Arne Mertz 的说法,使用编程规则和指南有助于开发人员协同工作,因为它们可以产生更一致、更好的代码。然而,如果使用不当,则会产生相反的结果——代码难以阅读,或者以次优甚至错误的方式解决问题。


Arne Mertz 在 NDC Tech Town 发表了关于编程规则和指南的演讲。


Mertz 解释了规则和指南之间的区别:


规则或多或少是绝对的。无论规则应用在哪里,都必须遵守,违反规则通常是不可接受的。

指南是一种最佳实践或合理的默认做法——我们可能有产生分歧的理由,但这没关系。


了解这种差异是很重要的,因为将指南解释或陈述为规则会导致开发人员破坏代码,而不是破坏指南本身,Mertz 认为:


指南的本质是,在某些情况下,它们并不适用,并且在这种情况下,试图坚持应用它们往往会导致代码变繁琐、可读性变差,甚至导致完全的错误。


Mertz 说,对于开发人员来说,严格的规则似乎更方便。编译器对其接受的内容非常严格。我们有太多复杂的问题需要解决,盲目遵循一套规则会让我们负担过重。


在他的演讲中,Mertz 探讨了一些规则和指南。他解释了“不要使用异常”(“don’t use exceptions”)规则的由来:


近二十年来,我看到“不要使用异常”规则(或指南)在各种情况下出现。当你追溯它的起源时,你会发现它是来自谷歌风格指南,其中说到“我们不使用异常”。


Mertz 表示,这种微小的差异非常重要,因为它表明谷歌不使用异常。该风格指南阐述了原因;这并不是因为异常被认为是不好的,而是因为在谷歌,有很多代码在编写时并没有考虑异常。对这样的代码库引入异常会带来引入未定义行为的风险,并且需要重新编写其现有代码库的大部分内容,正如 Mertz 所解释的那样:


Mertz 说道:“谷歌是出于必要才采用了这一指南的,而且,据我从在谷歌工作过的人那里了解到的情况看,并不是所有地方都遵循了这一指南。”。


Mertz 表示,在项目中应用这一指南时,指出它的起源以及它是针对旧的大型项目这一事实可能会导致该指南被弃用;当然,除非到那时,这个有问题的项目也已经发展了多年,并且没有考虑异常,而引入异常到这些项目中会导致与谷歌采用该指南同样的问题,他补充道。


Mertz 探索的另一条规则是“每个函数都应有一个返回(return)语句”。该规则是几组指南和规则的一部分,例如 MISRA C 和 MISRA C++ 规则。正如 Mertz 所解释的那样,制定这一规则的原因各不相同:


一些人认为长函数的可读性更高,但反驳的观点是首先应该缩短函数。在像 C 这样的语言中,过早返回可能会意外忽略资源清理,这样是很糟糕的。


Mertz 提到,当你将 C++ 与 RAII 类一起使用,该论点并不适用,因为编译器能通过析构函数来保障资源的清理。


InfoQ 就遵循编程规则和指南可能产生的影响采访了 Arne Mertz。

InfoQ:你对“不要使用异常”的指南有什么看法?


Arne Mertz:异常是 C++ 语言报告错误的核心特性。不经常使用异常会导致过多地使用错误返回码和输出参数,从而使代码变得更难阅读和推理。像 std::expected 这样的现代库解决方案可以在一定程度上缓解这些问题,但我从未见过它们被用于因谷歌指南而避免异常的项目中。


我推测,尤其是在 21 世纪初,谷歌作为一家软件公司是一个时髦的榜样,所以人们都想要效仿他们。他们在完全不同的代码库中采用了这一指南,而没有质疑它的必要性。

InfoQ:遵循“每个函数都应该有一个返回语句”的规则会有什么影响?


Mertz:遵循该规则通常会导致“retVal”变量的某些变体,这些变体通常会被初始化为一个无意义的值,希望稍后能被赋值为实际的返回值。此外,我们经常看到用一个变量来跟踪我们是否在一条正确的道路上,或者跟踪一个深度嵌套的控制流。所有这些模式都会使代码变得更加复杂,并降低可读性。

作者介绍


Ben Linders 是一位来自荷兰的敏捷、精益、质量和持续改进方面的独立顾问。他著有《从敏捷回顾中获得价值(Getting Value out of Agile Retrospectives)》、《Waardevolle 敏捷回顾(Waardevolle Agile Retrospectives)》、《是什么推动了质量(What Drives Quality)》、《敏捷自我评估游戏(The Agile Self-assessment Game)》、《问题?什么问题?(Problem? What Problem?)》以及《持续改进(Continuous Improvement)》。并且是许多敏捷辅导工具的创建者,例如敏捷自我评估游戏。作为一名顾问、教练和培训师,他通过部署有效的软件开发和管理实践来帮助组织。他专注于持续改进、协作和沟通以及专业发展,为客户提供商业价值。Ben 是敏捷、精益和质量网络的活跃成员,也是一位经常演讲和写作的人。他在一个双语博客(荷兰语和英语) 中分享自己的经验,并在 InfoQ 担任敏捷方面的编辑。可以通过 @BenLinders 在推特上关注他。


查看原文链接:

https://www.infoq.com/news/2024/11/programming-rules-guidelines/

2024-12-20 08:048966

评论

发布
暂无评论
发现更多内容

帮助文档——助客户快速了解您的产品如何使用

小炮

帮助文档

短短6小时,AI设计出40000种毒气分子,很多毒性远超战用神经毒剂

图灵教育

AI

如何完成与龙蜥操作系统的兼容验证,看这里! | 一周动态

OpenAnolis小助手

操作系统 龙蜥社区 一周动态

毕业总结

孙强

#架构实战营

TiFlash 源码阅读(一) TiFlash 存储层概览

PingCAP

等保2.0国家标准是什么?与等保1.0有啥变化?

行云管家

网络安全 等保 等级保护 等保2.0

基于场景文字的多模态融合的图像分类

华为云开发者联盟

计算机视觉 图像分类 场景文本 图像视觉 多模态融合分析

深入微服务-SpringCloud调用组件Feign

janyxe

spring Spring Cloud Feign OpenFegin

无聊科技正经事周刊(第4期):理性囤货与人工智能预测

潘大壮

程序员 科技 行业趋势 科技周刊

分布式数据对象:超级终端的"全局变量"

科技汇

10 个 web 在线前端资源,优雅永不过时~

前端 网页设计 在线资源

分享一个JDK批量异步任务工具Completion Service,超好用

华为云开发者联盟

jdk 线程 异步 CompletionService 批量异步任务工具

TiDB 查询优化及调优系列(二)TiDB 查询计划简介

PingCAP

为什么 Rust 是 Stack Overflow 最受欢迎语言?

非凸科技

c++ rust 性能 Stack Overflow 内存安全

好的每日站会,应该这么开 | 敏捷开发落地指南

阿里云云效

云计算 阿里云 敏捷开发 研发敏捷 每日站会

架构实战营 - 方案设计文档模板

华仔

架构实战营 文档模板 方案设计

不要再焦虑了,进大厂真的没你想象的那么困难

Java架构追梦

Java java面试 后端开发

【IT运维】如何又快又好的进行数据备份?

行云管家

运维 快照 数据备份 IT运维 行云管家

解析数仓OLAP函数:ROLLUP、CUBE、GROUPING SETS

华为云开发者联盟

Rollup GaussDB(DWS) cube GROUPING SETS OLAP函数

圈重点!一图读懂OpenHarmony技术日

OpenHarmony开发者

OpenHarmony 技术日

IOS技术分享| ARCallPlus 开源项目(二)

anyRTC开发者

ios 开源 音视频 移动开发 呼叫邀请

稳定性领导者!阿里云获得信通院多项系统稳定性最高级认证

阿里巴巴云原生

阿里云 云原生 可观测 性能压测 获奖

面试突击43:lock、tryLock、lockInterruptibly有什么区别?

王磊

Java 面试题

ArkUI框架又有哪些新增能力?

科技汇

阿里云机器学习PAI开源中文NLP算法框架EasyNLP,助力NLP大模型落地

阿里云大数据AI技术

深度学习 nlp 开源技术

浅谈小程序开源业务架构建设之路

百度Geek说

小程序自动化测试框架原理剖析

百度Geek说

小程序 百度

活动报名|OpenHarmony 战“码”先锋,PR征集令

OpenHarmony开发者

OpenHarmony

得物技术浅谈深入浅出的Redis分布式锁

得物技术

redis 分布式 分布式锁 CAP 一致性

一文掌握 Docker 技术体系

博文视点Broadview

Enhanced SWAP内存管理 OpenHarmony构建新的内存管理优化方案——ESWAP

科技汇

如何使用编程规则和指南_编程语言_InfoQ精选文章