Quora怎么设置语言(Quora上关于如何又好又快编写代码的回答)

管理员 2022-09-29 23:28:08 0
引言

程序Bug是可以避免的吗?如何编写没有错误(Bug-free)的代码?如何更快地编写代码?你是否被这些问题困扰过?是否系统地思考过这些问题?

人生中有个导师简直太难得了,本文将问答网站Quora上若干相关问题的精彩答案整理汇编一下,里面不乏一些看上去很朴素确很有效的做法,看看是否能够给我们一些启示。

是否可能编写无错代码?

对于这个问题,你可能会很意外,答案是可能的。

其实这也很好解释,这是一个相对问题,代码出错概率与程序员的能力、状态,以及要解决问题的难度、程序运行的条件是否稳定等有很大关系。当一个天才程序员去编写一段运行条件稳定、问题规模极小的代码时,是可以实现无错的。如果不是这样,我们现在建立起来的庞大的软件大厦随时都可能倾倒。

有一些人也提出了质疑,提出了无法通过科学方法证明代码绝对无错。的确如此,我们知道,代码都有其运行条件,虽然有些并不明显,而一旦运行条件不能**,就可能出现问题。很多即使当时固若金汤的代码,也会随着时间的推移,因运行条件发生变化而出现错误。所以,绝对无错的代码是不存在的,我们去谈论它也没有现实意义。

天才程序员是存在的,但是普通企业也无法雇佣他们为其写一行代码。对于我们绝大多数普通人来说,如何编写出无错的代码就成为了一个具有现实意义的问题。

Quora上关于如何又好又快编写代码的回答

是否需要编写无错代码?

对编写无错代码的可能性有了认识以后,我们再进一步看一下是否需要编写无错代码。

当然,你心中可能也有正确答案,那就是不一定。

我们知道,无错代码是有成本的,而且和问题域的复杂度正相关。我们追求几乎无错的代码,就要考虑其在人力、时间等方面的成本,评估其经济性和时效性等。很多时候,并不需要一味地追求完美无错,而有些场景则强调极致的无错。

Quora上关于如何又好又快编写代码的回答

影响编写无错代码的因素有哪些?

有了前面的基本认识,我们再来看一下哪些因素会影响我们写出无错的代码,以便我们针对性地做出对策。

下面我们来罗列一下:

可能误解了需求项目复杂性代码的可读性解决方案的简单程度人脑的处理能力所做的心理形象并不像你想象的那么完美程序员的编程**在输入代码时犯了一个愚蠢的错误Quora上关于如何又好又快编写代码的回答

如何编写无错代码

[微风]简化方案

根据项目目标而不是个人**为工作选择**的语言、工具花一些时间规划你的项目,但不要太多(花在规划上的过多时间可能会被浪费)如果可行,首选最简单的解决方案,优化可读性和透明度,而不是性能在您拥有多年的**之前,应避免使用聪明的代码程序的每一部分都应该一目了然地理解,或者至少适合大脑的工作记忆

​[微风]完善方案

不仅要考虑它应该如何工作,还要考虑当意外发生时它会做什么编写代码之前自动想到极端情况

​​[微风]提升能力

不断练习 for (;;) practice();了解如何不使用调试器或调试输出语句来查找 Bug,通过仔细阅读代码来查找错误仔细编码,不要依赖编译器来捕捉语法错误。您已经从大多数IDE**了很大的帮助。当你成为一名**丰富的程序员时,偶尔,你可以打出大量的代码,这些代码可以一次性完美地编译和运行,并通过所有测试,这是你应该瞄准的目标。

​[微风]****

找到一种方法来**数小时的集中时间,以便您可以在连贯的状态下编写代码充足的睡眠,定期锻炼,吃健康的食物,并经常休息

​​[微风]完善过程

训练自己不要编码,直到你对你想要完成的事情有了大致的了解放慢编码速度,花点时间思考一下问题,仔细编写代码,**简单不要害怕调试器。gdb乍一看似乎令人生畏,但它是一个很棒的节省时间的工具使用TDD。TDD是一个伟大的平衡器。对于摇滚明星来说,TDD不会**开销,也不会提供任何优势。TDD可以提升普通和初级程序员的速度结对编程"好代码"有层。如果在**过程中出现问题,他们可以轻松地返回到上一层,看看有什么不同或变化。设计、编码和演示最小的有用代码,并不断添加

​[微风]利用**

采取避免错误的简单习惯。一些结构,如指针,基于索引的循环和函数的多个出口点,很容易导致错误,谨慎使用它们或根本不使用它们整齐而完美地缩进您的代码。缩进不良会隐藏错误。可以通过尝试保留具有相似长度的相似变量名称,来快速发现错误完美地**一个编辑器,学习如何在其中自动执行常见操作永远不要使用搜索和替换手动重构代码,这往往会弄乱你的代码。使用重构工具当一个语句太长时,将其分解为多个语句当表达式很复杂时,通过使用临时变量以增量**存储中间结果来简化表达式。编译器足够智能,即使您使用许多临时结果,也可以生成有效的代码选择读起来更好的条件自由使用断言Quora上关于如何又好又快编写代码的回答

精彩留言

以下为从相关问答下面摘出的一些精彩留言,其中很多观点可以说是振聋发聩,让人耳目一新,我们一起来看一下。

​[微风]强调解决方案要尽可能简单

普通程序员用复杂的解决方案解决简单的问题。优秀程序员用复杂的解决方案解决复杂的问题。伟大程序员用简单的解决方案解决复杂的问题。

​[微风]如何用有限的智力对付无限的复杂性

如果你的智力一般,你的智力总是会小于你编写的程序的复杂性。如果不是这样,就没有人为你付钱了。作为程序员的你,处理比你的智力更大的复杂性的**,是将任务分成几个部分。你不断地分,直到达到一个复杂程度适合你头脑的地步。用于此过程的术语称为模块化。你在脑海中创建一个模块的图像,你看到它应有的样子,包括细节都是完美的。然后把代码敲出来。一旦你完成了模块,你扔掉那个完美的图像,拿另一个模块并创建它的图像。从本质上讲,你是在做一个心理背景转换。

​[微风]说明问题出在心理上下文切换,并给出TDD和结对编程两副良药

TDD让您在引入错误的那一刻就发现它,从而让您更快,它可以避免代价高昂的上下文切换。结对编程的原理是相同的。由于两个人在他们的头脑中创造了相同的心智模型,因此其中一个人更有可能看到缺陷。当心智模型在他们的头脑中时,修复缺陷更容易。这里的基本原则是,在你把代码弄好之前,不要放过这种心理形象。TDD和结对编程本质上是做同一件事的两种不同**。如果你是一个新手到中级程序员,你的大部分时间都花在做心理上下文切换上。通过执行 TDD或结对编程,您基本上消除了上下文切换的开销。你可能不像摇滚明星那样表演,因为你仍然在脑海中保留着微小的碎片。但是,你可以非常接近成为一个好程序员到伟大的程序员。

​[微风]强调“快即是慢,慢即是快”,想要做对,必先想好、想对

如果走得越是匆忙,那么拉下的东西就越多。同理,加快编码速度的愿望,反而会导致更大的错误。所以,我建议放慢速度,以充分理解和思考手头的问题,让它更接近答案。

出现设计错误是最糟糕的情况,因为很可能只顾着快速编码,后来发现解决方案并没有解决问题。

​[微风]通过模块化和事先想好的流程图,使编程时能够聚焦到更具体的问题

我从1970年开始编程,我的系统**师坚持要我们构建流程图。所有程序都是模块化的,所有模态都必须限制为单个A4页面的流程图(使用**流程图)。这个**在我三十五年的编程生涯中一直起着很好的作用,并且总是让我集中思考。

​[微风]先想好、分好,再专注于每个部分

训练自己不要编码,直到你对你想要完成的事情有了大致的了解。然后,

训练自己不要编码,直到你制定了解决问题的一般方法。然后,

训练自己不要编码,直到你隔离了解决问题所需的特定子例程(或对象,取决于你的世界)。

训练自己不要编码,直到你能在脑海中可视化流程中的数据流。

然后,也只有这样,开始编码时,要专注于拼图的每个部分,直到你创建了大局。

​[微风]编码前进行计划和设计,编码时要有效利用时间,复用已有**,编写可读性强的代码

1、在开始编码之前进行计划

许多**人员在计划之前开始编码。他们只是写下他们脑海中的想法,这会导致问题,引发不必要的代码和错误。为了防止这种情况,请拿起笔和纸,绘制或编写完成编码后应**的软件结构、流程。此外,考虑每个步骤、操作中可能出现的问题,以及在这些错误发生时该怎么做。这样可以防止不必要的代码,并**调试时间。

2、有效利用时间

在开始编写软件的一部分之前,请估计需要多少时间。如果此时间超过 20 分钟,请将其分成较小的部分。设置一个计时器(在您的手机、计算机、手表中),该计时器将在时间结束时通知您。或者使用计算机的时钟,但不要忘记检查它(您可能在编码时会忘记检查时间)。尝试在这段时间内完成代码。这将使您集中注意力并防止分心。如果时间到了,就对刚才的流程进行评估。看看是否编写了任何不必要的代码?花了多少时间在解决问题上?是不是真的很重要?哪些部分花费了大部分时间?可以用更短的代码做同样的事情,还是干脆省略它?这将防止编写代码时效率低下,并使您更有效地利用时间。

3、在设计结构之前,不要编写代码

软件不仅仅是逐行执行的代码行,在大多数情况下,它们是执行特定任务的不同单元的联**,像人体各种器官一样。您应该将代码划分为具有自己目的的单元,并设计一个结构,解释它们将如何协同工作以及它们将如何处理数据。那些逐行编写的程序(缺少仔细规划)是不灵活的,在开始时编写代码可能会更快,但一段时间后,您会注意到,这种编写代码的**不适合添加新功能,您将不得不更改它,甚至要从零开始编写它。而维护它需要太多时间,从长远来看,将花费更多时间。设计结构一开始需要一些时间,但以后花费的时间会更少。

4、了解设计**和编程技术我们在编写软件时解决的大多数问题之前都**和测试过解决方案。我们可以在谷歌上搜索"设计**"和"编程技术",了解它们,并在项目中使用它们,不要重新发明轮子。

5、编写可读性好的代码,并添加注释

缩进并对齐代码,必要时使用空格和空行分离执行整个过程中特定步骤的代码块。为每个步骤编写注释。编写错误的代码里可能包含语法错误,对于要求严格编写的语言,您可以找到大多数错误,但其他不太严格的语言就可能会运行它们,并且您的代码将完成一些您无法想象的惊人事情。此外,使用良好的语法编写代码,并使用注释将提高其可读性,使其易于查看错误。

​[微风]先利用纯文本编辑器,而不是IDE,来对自己进行艰苦的训练

不要使用任何IDE,如eclipse或netbeans,虽然他们看上去提供了很大的帮助。开始在一些简单的文本编辑器(如记事本)上编码,这样会没有语法着色,没有自动识别,大括号关闭和所有神奇的奇迹,会迫使我们在编码时考虑更多,也将习惯于解决一些小问题,例如导入那些在IDE中会自动键入的库,利用这种方**对你进行艰苦的训练。

​[微风]理解-思考-组织,完美的三步法

1. 理解。研究问题和解决方案,以及它们的所有排列。

2. 思考。让所有新**的知识煮熟和炖煮,直到好的想法和明确的解决方案自然出现。

3. 组织。简单的代码组织良好,只能由有组织的程序员编写。

​[微风]通过严格次序、绝妙设计、良好抽象结构来消除错误

1、严格的优先次序

一次做完所有事情,会导致不可预见的复杂情况。构建、调试、优化、测试...这些都不必一次完成,有些根本不需要。

2、绝妙的想法

如果一个好主意可以取代十个主意,那么代码就简单了十倍。简单性不是删除功能或不愿意添加任何功能。简单本身就是一种功能和结果,它是通过以正确的**组合正确的想法来实现的。协同、团结、实用、优雅...简单只能通过设计来实现。

3、创新抽象

程序只是一个具有具体后果的巨**象,这些后果一旦发生,就无法控制或组织。但是,导致它们的抽象可以随心所欲地塑造。某些语言可能比其他语言更容易创建抽象,但从更高层次来看,解决方案的结构是独立于平台和语言的,之后的实现只是一个后勤问题。结构的完整性和简单性完全取决于架构师。

​[微风]不**简单性的程序员是一种病毒

人们会意识到,我们是自己代码的受害者,那些我们与之合作或使用软件的每个人也是。

不**简单性的程序员是一种病毒,“他们”是必须首先调试的错误。优秀的程序员发明了简单性,而糟糕的程序员是问题的一部分。

简单就是有价值,价值就是简单。

复杂性是时间的函数,简单性是程序员的功能。

想得简单。

​[微风]涉及方面很多,仔细体会一下

集中精力,在一个你感觉良好和舒适的**中;

**;

**一致性,坚持使用**样式(例如,在 =之前有一个空格);

定义确切的问题,检查是否已经解决,可以立即使用,还是应该更改某些内容?

如果您需要编写的内容较大,请创建一个关于它如何工作以及如何与其他组件通信的图形;

编写测试,然后实现,重复这个过程;

编写自解释代码,在注释中解释原因,有时甚至需要在涉及更多组件时创建wiki;

创建一个博客并撰写有关编程的文章,将其作为您和其他人的笔记本;

每天编程,但要休息一下。是的,在周末关掉那台电视,在你的业余项目上工作;

有一个副业项目;

当你发现难以理解一些代码反应器时,尽快;

当您发现错误时,请尽快修复它;

当您被打断并且必须停止时,请使软件抛出错误;

在每一层软件中都要遵循DRY原则,但需要避免**太复杂;

阅读别人的选择,小心做好代码;

兴奋地做你所做的事情,你会更加关注;

写代码是为了可读性,因为编码是至少60%以上的读取;

审查其他人代码;

记录并使您的****自动设置;

尝试使几乎每个任务都自动化;

阅读有关编程的书籍和博客,阅读每个主题,不要认为你最了解它,再读一遍那本书;

学习正确的错误管理,如何以及何时抛出错误,制作关于如何抛出的**文档;

如果可能的话,使用单线程软件,比如Node.js;

使用版本控制;

一旦你有了第一个原型,就部署。部署时可能会遇到问题,但这比有一万行代码时更好地找到错误;

学习设计**;

使用适当的调试器,如果很难使用,找另一个;

尝试验证大多数方法的输入参数;

在知道存在性能问题之前,不要进行优化,始终像往常一样编程;

使用好的变量名称;

​[微风]非常朴素的方法,很多人都提到了,但是也有很多人都不相信

首先,拿一个白板或一张白纸作为记事本,在输入任何东西之前写出你所有的算法。你需要这种二维的手写自由来很好地及时解决问题。

然后,在纸上或记事本程序中写出伪代码,找出必要的变量和方法。

最后,编写代码。此过程将算法与编码实现、语言、API问题分开,试图同时处理所有这些问题会让你发疯并兜圈子。

如果你很难弄清楚如何在纸上做一些事情,你会很高兴你没有在IDE或库上搞砸。而当你对你的算法有信心时,你将能够辨别你的问题何时是由于缺乏对语言、库的理解。

​[微风]简单性和模块化

对我来说,有两个相关的想法都很有效: 简单性和模块化。

某些工具支持这两个核心概念,最明显的是静态类型和函数式编程。

简单的代码不会做过多的事情,它没有多余的部分:事物只与少数其他事物直接相关,而不是依赖于一切。

尽可能地,一切都应服务于一个具体的目的。模块化与简单性是密切相关的,是将代码分离成具有明确接口的独立部分的想法。这些不同的部分只以明确、规定的**相互依赖——它们不知道彼此的内部。

我说简单性和模块化是相关的,因为更多的模块化代码会更简单,而更简单的代码更具模块化。还记得拥有简单的内部结构是多么简单吗?模块化是这个概念在规模上重新定义。

类型和函数式编程都有助于以多种不同的**防止错误。使用类型会排除整个类型相关的错误,如空指针错误或不兼容的参数值。而函数式编程使并发性和并行性更安全。它们都使重构**更好。

尽管有这些优点,但迄今为止最大的改进是它们使编写更简单,更模块化的代码更加自然。

​[微风]了解、检查、测试、找人帮忙检查,了解更高层次的目标

根据我个人的**,

#1:是知道你在做什么。了解您正在使用的语言的行为及其特定特性。可以具体到比如语言的版本,它们也会包含各自的错误。

#2:与所有事情一样,检查您的工作。编写完成后检查一次,在一夜好眠后再检查一次。以批判的眼光,并遵循逻辑,看看你是否能发现任何明显的错误。

#3:始终测试您的代码。编译和执行并不等同于执行预期操作,要尝试使用不同的方案来打破它。这可能是大多数错误溜走的地方,因为人类提出每种可能情况的能力是有限的。因此,您至少可以提出最有可能的情况以及不太可能但仍然可能的情况("边缘情况"),并对其进行彻底测试。回顾过去,您可能能够预测 2000 年即将到来,但无法知道有一天会有一种字符编码方案,它不是 ASCII 和 EBCDIC,但它会**你的代码。

#4:**第二双(或第三双)眼睛。这对所有的事情都是一样的,其他人可能会发现您没有注意到或考虑过的事情。

#5:了解你的代码如何适应更大的计划。这可能是一个挑战,但值得花费时间和精力。这可能被认为是一个系统**师的职能,但如果你个人对整个系统和要实现的目标有更好的了解,你会发现自己处于一个更好的位置。

结语

本文到这里就结束了,做好编码和做好任何其它事,其实是一样的,都需要确保想对并且做对,要了解问题、要事先设计、要进行拆分、要了解实现技术、要有计划安排、要逐个聚焦、要检查试验等等,有些笨功夫,其实透着聪明,你觉得呢?

相关资讯

热门资讯

热门话题