10 Tips for Writing Better Code (阅读理解)

出发点

http://www.tuicool.com/articles/A7VrE33

阅读中文版本《编写质优代码的十个技巧》,对于我编码十年的经验,也有相同感受,

太多的坑趟过,太多的经历走过,对良好编码的技巧,只能说更加心有灵犀。

下面从英文原版阅读,结合自己的理解,尝试注解下作者的观点。

注解 -- 原文见下网址

https://cdiggins.github.io/blog/programming-tips.html

10 Tips for Writing Better Code

注:翻译成编写更好代码的十个技巧,不如翻译成质量优良代码的十个技巧,更好合适。

30+ years experience trying to write better software distilled down into 10 best practices.

注:30多年努力编写质量优良软件的经验, 被提炼为10个最佳实践。为工匠精神点赞, 中国的程序员不用担心30岁以后要失业,看看人家干了30年了。

1. Follow the Single Responsibility Principle

Functions are the single most important form of abstraction in a programmer‘s arsenal. The more they can be reused the less code you have to write, and the more reliable they become. Smaller functions that follow the Single responsibility principle are more likely to be resued

注:一件函数只做一件事情, 此精神类似unix设计哲学, 极简而奢。 函数是程序的细胞, 每一个细胞是可复用的, 健康度良好的, 则使用函数组织起来软件,必然是健壮的, 并且更好维护, 更快地组建新的软件。

2. Minimize Shared State

You should minimize implicit shared state between functions, whether it is a file scoped variable or object‘s member fields, in favor of explicitly required values as arguments. Code becomes a lot easier to understand and reuse when it explicit what that function requires to produce the desired results.

A corrollary to this is that you should prefer static stateless variables to member variables on an object.

注: 共享状态本身就不应该存在, 不应该在不同的函数之前共享同一个变量, 特别是变量是全局变量,造成程序逻辑不清晰, 容易走到异常情况。

如果必须要有共享状态, 则必须使用函数入参的形式, 显示声明,函数依赖的变量, 不要去引用全局变量。

这种思想, 是函数式编程的思想, 对于纯函数, 即给定函数的输入, 函数的输出在任何情况下都是固定的, 可预期,不用担心依赖全局变量,产生的不可控制性。

函数式编程,典型代表语言有 haskell, js中有facebook出品的 immutablejs(https://github.com/facebook/immutable-js), 也是为了达到这种效果。

3. Localize Side Effects

Ideally side-effects (e.g. printing to console, logging, changing global state, file-system manipulations, etc.) should be placed in separate modules, and not scattered throughout the code. Often side-effects in functions are violating the single responsibility principle.

注: 局部化副作用, 对于存在副作用, 例如函数的执行, 改变的全局变量, 则尽量将副作用局部化, 例如局部化到模块, 不要让副作用散落在程序的任何地方。

即减少副作用的影响范围。

4. Prefer Immutable Objects

If an object‘s state is set once in its constructor and never changed again it become much easier to debug since it remains valid once it is constructed correctly. This is one of the easiest ways to reduce complexity in a software project.

注: 优选不可变对象。 对象的属性在程序运行过程中, 不被改变, 更加易于调试。 例如 array.map 接口设计, array.map(v=v+1), 此操作不改变array对象本身, map函数会产生一个新的 array,并返回。

5. Interfaces over Classes

Functions that accept an interface (or a template argument or concept in the case of C++) are more reusable than functions that operate on a class.

注: 函数接受接口, 更加具有复用性, 相比较函数接受 类。

面向接口的编程, 比面向类的编程, 更加具有灵活性。

一: 如果函数依赖与类, 则函数只能服务于此类, 和此类的子类。 如果依赖接口, 则函数可以服务于任何实现了此接口的任何对象。

二:如果函数依赖类, 函数依赖的对象变大, 实际其只需要依赖 接口, 容易在函数中 产生副作用, 调用了类的其它非接口的公共函数和属性。

6. Apply Good Principles to Modules

Look for opportunties to break up a software project into smaller modules (e.g. libraries and applications) to encourage module level reuse. Some key principles to follow for modules are:

  1. Minmize dependencies
  2. Each project should have a single well defined responsibility
  3. Don‘t repeat yourself

You should strive to keep your project small and well-defined.

注: 寻找机会分解软件项目为更小的模块, 例如库和应用, 这是为了鼓励 模块级别重用。一些关键的原则:1、 极小化模块之间的依赖, 2、每个模块有一个单一的定义良好的职责, 3、不要重复。

软件开发, 一个关键的环节就是设计, 设计就是要把整个系统 拆分为不同的子模块, 这样减少软件开发的复杂度,即使的复杂度处于可控范围内。 模块与模块之间的链接尽量小,并且明确, 符合 “高内聚、低耦合”原则。

7. Avoid Inheritance

In object-oriented programming, inheritance, especially with virtual functions tends to be a dead-end in terms of reusability. I have had very little success writing or working with libraries that encourage overriding classes.

注: 避免继承。 继承减少的服用性, 继承之后, 必然有一些函数或者属性, 是需要覆盖父亲类的, 或者新增父亲类没有的函数和属性。

如果一个对象, 其划分的比较合理, 职责比较单一, 则对象的所有属性和函数是一套整体的内容, 子类的函数覆盖, 或者新增, 很容易就割裂了对象的整体性,

一部分逻辑在父亲, 一部分逻辑在儿子, 实际上造成了逻辑的低耦合。

8. Test as you Design and Develop

I am not a hard-core advocate of test-driven development but writing tests as you go leads to code that naturally follows many of the guidelines. It also helps reveal n error earlier. Avoid writing useless tests though, good coding practices mean that higher level tests (e.g. integration tests or feature tests over unit tests) are much more effective at revealing defects.

注:当你开发过程中, 写测试, 有助于发现低水平的缺陷, 进而促进集成测试和功能测试, 更加有效地发现缺陷。

9. Prefer Standard Libraries to Hand-Rolled Ones

I can‘t tell you how often I have seen a better version of std::vector or std::string, but it almost invariably a waste of time and effort. Apart from the obvious fact that you are introducing a new place for bugs (see Tip #10), other programmers are far less likely to reuse your code as opposed to something that is widely understood, supported, and tested.

注: 优选标准库, 不要手工制造了。 自己造轮子, 则多出一个产生bug的口子, 使用标准库, 则不容易出现bug, 因为标准库已经被官方测试发布过, 更加质量优良, 且有bug, 也很快被修复。自己造, 一则浪费时间, 二则容易引入bug。

10. Avoid Writing New Code

This is the most important tip that every programmer should follow: the best code is the code that isn‘t written. The more lines of code you have, the more defects you will have, and the harder it is to find and fix bugs.

Before writing a line of code ask yourself, is there a tool, function, or library that already does what you need? Do you really need that function as opposed to calling another one that already exists?

注: 最好的代码就是自己不写代码。 以无招胜有招, 达到武学最高境界。  不说啥了,尽量不要自己造轮子, 使用别人造的轮子。 如果真想造, 就参加开源项目, 为开源事业贡献力量。

Final Words

I have found that programming is a skill very similar to learning an art form or a sport, you get better at it through mindful practice, and by learning from others. Continuously working to improve the quality of the code you produce will help you become a more effective programmer.

持续改进你的代码, 会帮助你称为一个更加高效的程序员。

致敬30年的老兵!!

时间: 2024-08-24 10:18:59

10 Tips for Writing Better Code (阅读理解)的相关文章

写出完美论文的十个技巧10 Tips for Writing the Perfect Paper

10 Tips for Writing the Perfect Paper Like a gourmet meal or an old master painting, the perfect college paper is carefully constructed – not thrown together the night before it’s due.   Each part is just right, and the pieces are assembled to form t

用Keras搞一个阅读理解机器人

catalogue 1. 训练集 2. 数据预处理 3. 神经网络模型设计(对话集 <-> 问题集) 4. 神经网络模型设计(问题集 <-> 回答集) 5. RNN神经网络 6. 训练 7. 效果验证 1. 训练集 1 Mary moved to the bathroom. 2 John went to the hallway. 3 Where is Mary? bathroom 1 4 Daniel went back to the hallway. 5 Sandra moved

10 Tips For C# Programmers

In this article I will write about my top 10 tips in C# programming. Each tip will be supported by the sample C# codes, which will make it easy for the C# newbies to get a hold on. Tip 1: Write Unit Test Cases for Non-Public Methods Have you ever tri

Ten Tips for Writing CS Papers, Part 2

Ten Tips for Writing CS Papers, Part 2 This continues the first part on tips to write computer science papers. 6. Ideal Structure of a Paragraph A paper has different levels of formal structure: sections, subsections, paragraphs, sentences. It is imp

Ten Tips for Writing CS Papers, Part 1

Ten Tips for Writing CS Papers, Part 1 As a non-native English speaker I can relate to the challenge of writing concise and clear English. Scientific writing is particularly challenging because the audience is only partially known at the time of writ

Tips for writing a paper

Tips for writing a paper 1. Tips for Paper Writing 2.• Before you write a paper • When you are writing a paper • The expression 3.Before you start writing a paper • State your Contribution • Organize your paper structure, See Everything as a Facet on

亲爱的,你已经连阅读理解都做不过AI了

提起阅读理解这四个字,你会想到什么? 被四六级雅思托福支配的恐惧?语文试卷上连原作者都搞不懂的选择题? 不管哪种答案,肯定都逃不出一个规律:进行阅读理解这项有益身心运动的主体,必然是跟你我一样的人类. 毕竟嘛,这东西堪称考试中最费脑筋,也最考验综合能力的一个环节.所以你的英语老师一定说过这样一句话:得阅读理解者得天下. 然而,可是,但是,如果告诉你今天得这个天下的已经不再是人类,而是AI了,你会怎么想?可事实就是这样,1月11日,斯坦福大学著名的机器阅读理解赛事SQuAD刷新了全球排名,令人惊奇

平安金融壹账通获机器阅读理解顶级赛事(SQuAD)世界第一

平安金融壹账通又有重大突破!继在人类情绪理解竞赛多次登顶之后, 平安金融壹账通GammaLab又在另一项国际顶级赛事上斩获第一.近日,在由斯坦福大学发起的机器阅读理解竞赛(Stanford Question Answering Dataset,SQuAD)中,平安金融壹账通以领先的技术脱颖而出,位列榜单第一位. SQuAD被誉为自然语言处理领域金字塔尖的比赛,旨在促进智能搜索引擎的发展.该赛事吸引了来自谷歌.微软亚研院.阿里达摩院.科大讯飞.IBM以及复旦大学等最顶尖的企业及学校的激烈角逐.平安

Writing Clean Code 读后感

最近花了一些时间看了这本书,书名是 <Writing Clean Code ── Microsoft Techniques for Developing Bug-free C Programs> 这里主要总结了一些里面的编程思想. 为空语句加上NULL 当需要使用空语句的时候,最好写上NULL, 比如: if (music_on()) NULL; else turn_it_on(); 参数类型相同的问题 如果函数中两个参数的类型相同,如果用户调用这个函数时错误替换了参数的顺序,就会出现问题.