如何判断一个程序员写代码好与不好?

一句话,功能实现,bug少,可持续升级。


1.代码结构清晰

2.注释简洁易懂

3.各个功能模块有序耦合

3.单元测试完整

4.debug方便

5.扩张功能简单

6.让后来开发人员易接手

7.用最简单的逻辑处理复杂的功能(化繁为简)


看完秒懂,还能让人有点收获,就是好代码


结果导向,看代码运行出来的软件稳不稳定!


努力提高自身判断力后再去判断。


判断一个程序员写代码好不好可以从以下这几点来看,1.是否规范,规每个行业都有规范的,可以看看他写的代码是不是清晰规范一目了然。

2.简洁性,和写作文一样,用精炼的话表达出想要表达的意思。代码也一样,能用一行实现的尽量不要使用两行。

3、代码是否可重用,同一个功能尽量不要在多处重复书写。

4、代码是否安全,代码是否有考虑一些常见的安全问题和边界问题,如SQL注入、XSS攻击、CSRF攻击等等。

5、性能是否好,你写的代码最终是要运行的,如果性能不好,是会影响用户体验的。


我看不懂的,能让我学到的,都是好代码。


第一,代码规范很重要。第二,代码一定要注释清楚。第三,能否通过编程模式简化代码,提高代码复用性,如果用了编程模式代码还是一团糟那就是装逼。第四,算法效率高,能精简的就精简,总之就是要尽量减少消耗。第五,能从架构方面优化项目,架构设计从很大程度上决定了项目能否走得更远,比如说后续的可扩展性。


扩展性,健壮。


我觉得最关键的是

1.先看在取数时复杂sql有没写对和优化上,很多工作十几年的大佬,滥用嵌套语句,占用大量资源。

2.在看代码,很多人喜欢把代码写在一个文件里。

3.然后看会不会写设计模式。

4.最后看代码优化


代码规范,简洁这些都是基本功,就不多说了。好的代码是能让不懂编程的人能看懂的代码。可以说所有的代码都是数学模型,是对现实事物的模拟。不过很多程序不得不处理存储之类计算机硬件环境带来的特有的问题,这部分处理使代码变得晦涩难懂。将计算机硬件的痕迹从编程语言中去除,让编程语言更接近自然语言一直都是编程语言的发展方向之一。在制定代码时,能将注意力集中在业务逻辑上,让代码和业务逻辑有明确的对应关系,这样的代码才是高手所为。这也是面向对象的程序设计所追求的。


没bug,高效率,低资源


编码规范

要写出好的代码首先要遵循的就是编码规范,在工作中遇到过好多人,总是不注重细节,比如规范中明确规定,如if括号内,条件和左右括号不留空格,if条件即便是只有一条语句也必须用括号包括起来等等,有些程序员总是做不到这些,仍然按自己的风格写代码,甚至是代码缩进都经常做不到,对于这样的程序员,即便他是个技术大牛,我也会瞧不起他。

段落清晰

好的代码排版很重要,块儿与块儿之间要有空行间隔,方法与方法之间也要有空行间隔,方法内步骤与步骤之间要有空行间隔,一个方法只干一件事,不要一锅粥,一个类只做与该类相关的功能。

通俗易懂

在团队开发中,代码写出来并不是只给自己看的,有些人总喜欢使用一些比较生僻的语法,而显得自己很牛逼,然而这些生僻的语法用普通表达式很容易实现,也没有性能的影响时,我还是更喜欢通俗的代码。

代码健壮

代码写的再漂亮,跑不起来也是不行的,或者说由于产品需求的一个小改动,就得改写大量代码,耗费巨大精力就说明代码写的不够健壮,或者说代码在开发阶段自测都通过了,但是到了测试验收阶段,或生产环境,各种问题都出现了,这就说明在开发阶段考虑的不够周全,代码不够健壮。

总之,写出好代码是靠一个人平时细节方面习惯的养成才能做到的,有些人说他一千遍都可能做不到,这样的人还是趁早砍掉吧。


一个系统的代码好与不好,不是一个程序员决定的。

其实,泛泛的说代码好坏,没有意义。

比如,一个针对提高运行速度有特殊要求模块,根本不必考虑其他人的阅读理解。

又比如,应用逻辑的实现,策略化、规则化、流程化,需要严格的遵守规范,代码审查合规工作,比写代码更重要。因此,代码的可读性就比较重要。

而策略引擎、规则引擎、流程引擎,等等,基础代码的可读性就不是主要问题了。


很简单。看代码里有没有拼音。水货程序员喜欢用拼音。


这段时间,大部分精力在评审团队小伙伴的代码上,感触颇多。总结下来,好的代码千篇一律,烂的代码各有不同。

所谓好代码无外乎这三点,功能正确,逻辑清晰,可读性强。写代码与写公文有异曲同工之处。

写公文时,不需要华丽优美的词句,能让读者领会上级精神,准确无误地贯彻落实,就是一篇好文。

写代码时,前沿技术,精妙算法都是点睛之笔。编出来的程序准确、平稳运行,写的代码,后续可维护,易扩展才是第一要务。

再来简单说说,上面三个关键点。

一是功能正确。这是判断代码好坏的先决条件,拥有一票否决权。

二是逻辑清晰。编码者能给其他人讲明白自己的程序的运作原理和设计思路。让不懂编码的人,都能理解才行。

三是可读性强。其他小伙伴拿到你的代码和文档,能无障碍地走查你的代码时,能找出问题,并能按照你的思路提出解决方案。

实际工作中,第一点大家做得都还不错,不然负责测试小伙伴那里就过不去。第二点就有点马虎了,文档能与代码匹配起来的就没几个。第三点比较难,大多代码还没走查完,评审人员就阵亡了。

朋友们,你们怎么看?


程序猿用的是什么语言,C、Java、Python、SQL?

找个不会该语言的猿去阅读维护,如果还行,说明代码写的还好。


一.注释

好的代码,后面都有注释。即使你对代码一窍不通,你通过注释的解释也能明白代码的思路和功能。但是你的代码很乱或者连注释都没有,那么测试,以及运维的时候,花费的时间成本就会很大。还会让同事对你有意见。

二.整齐

好的代码,它的行数,间隔都是很整齐的,有严格的标准。你的代码必须要让看你代码的一目了然,如果杂七杂八,那么你的代码就是一堆垃圾,看的眼睛痛

三.效率快,灵活

代码运行的速度,实现功能的快慢,需求变化时候能否满足。这是作为一个成熟的程序员想要去考虑的,在你的代码中就可以直观的体现出来。当产品需求变化的时候,一个好的代码可能就不需要更改,而差的代码只能不断的去应付需求,而不是灵活的解决需求


看其他人的答案,其实往往也不用那么复杂。在实现同样功能的情况下,数数他的代码行数就可以。在对功能、容错性、性能和可读性没有负面影响的情况下,写出来的代码越少,作者水平越高。


能让人看的懂。


原始地址:/shijie/570.html