经验丰富的程序员和一般程序员之间的最大区别,不仅体现在解决问题的能力上, 还体现在日常代码的风格上.掌握一门技术可能需要几月,甚至几周就够了. 好的习惯风格养成却需数年. 团队成员之间需要合作,代码需要日后可维护,个体的能力和习惯存在差异. 故保证代码质量及风格,就需要制定一定的规则,按项目周期(最好是在上预发之前)组织进行集体代码review. 一 目的 1 保证代码质量 自己的代码要给别人看,在开发过程中就会刻意的注意一些规范,写法及逻辑严谨性. 2 扼杀潜在的风险 程序员会去自测,即使有某

mocha mocha是JavaScript的一种单元测试框架,既可以在浏览器环境下运行,也可以在Node.js环境下运行. 使用mocha,我们就只需要专注于编写单元测试本身,然后,让mocha去自动运行所有的测试,并给出测试结果. mocha的特点主要有: 既可以测试简单的JavaScript函数,又可以测试异步代码,因为异步是JavaScript的特性之一: 可以自动运行所有测试,也可以只运行特定的测试: 可以支持before.after.beforeEach和afterEach来编写初始

重读code complete 说说代码质量 2014年的第一篇文章本来计划写些过去一年的总结和新年展望,但是因为还有一些事情要过一阵才能完成,所以姑且不谈这个,说说最近重读code complete 的收获吧. 记得第一次读code complete 还是刚毕业的时候,身边好多朋友极力向我推荐此书,于是我就买了一本读起来,可能是当时功力不够,读起来总是觉得没啥味道,而且极为枯燥,总觉得不如<深入浅出MFC>,<CLR Var C#>,<Windows Internals&g

前言 现代软件开发团队面临着很多挑战,这些挑战包括:产品交付期限越来越紧,团队的分布越来越广,软件的复杂度越来越高,而且对软件的质量要求越来越高. 本文分为两个章节.第一章讨论持续集成的原理,持续集成如何简化软件开发生命周期,以及静态分析如何配合持续集成.第二章研究特定的工具套件,以及在实际使 用中如何获得该套件.主要研究Jenkins持续集成和Perforce的静态分析工具(Helix QAC),并说明他们是怎样结合在一起使用,以及他们所生成的信息. 第一章 第一部分:持续集成和持续交付 持续

程序员的恶性循环:加班->没空学习->老是写同等水平代码->无法提升代码质量->老是出BUG->老是需要修改->加班->...

本章内容: 揭秘前端开发工程师 欲精一行,必先通十行 增加代码的可读性--注释 提高重用性--公共组件和私有组件的维护 冗余和精简的矛盾--选择集中还是选择分散 磨刀不误砍柴工--前期的构思很重要 制订规范 团队合作最大的难度不是技术,是人 揭秘前端开发工程师 CSS布局是前端开发工程师的基本功,一定要熟练: 不仅要会使用原生的JavaScript,还要会是使用JavaScript类库和Ajax; 了解一门后台语言 1.有助于编写方便服务端工程师套脚本的模板: 2.在写Ajax应用的时候,可以自

c#封装DBHelper类   public enum EffentNextType { /// <summary> /// 对其他语句无任何影响 /// </summary> None, /// <summary> /// 当前语句必须为"select count(1) from .."格式,如果存在则继续执行,不存在回滚事务 /// </summary> WhenHaveContine, /// <summary> ///

提高代码质量-工具篇 注:这是一篇翻译文章,原文:How to improve quality and syntax of your Android code,为了理解连贯,翻译过程中我修改了一些陈述逻辑和顺序,同时也加了一些自己的补充. 在这片文章中,我将从工具使用的角度上讲述如何提高 Android 代码质量,这些自动化工具包括 Checksytle.Findbugs.PMD 和 Android Lint. 团队中代码意识不一致,水平参差不齐,代码风格迥异,定下的规范也是熟视无睹.这时候就需

随着富 Web 前端应用的出现,开发人员不得不重新审视并重视 JavaScript 语言的能力和使用,抛弃过去那种只靠“复制 / 粘贴”常用脚本完成简单前端任务的模式.JavaScript 语言本身是一种弱类型脚本语言,具有相对于 C++ 或 Java 语言更为松散的限制,一切以函数为中心的函数式编程思想也为开发人员提供了更加灵活的语法实现.然而,这种灵活性在带来高效的同时,也成为初学或者经验不足的 JavaScript 开发人员的噩梦.形式各异的代码风格.隐含错误的代码行为,严重影响了整体代码

什么是'git-pylint-commit-hook' 我在工作中,团队为了保证代码和提高代码的质量,要求每个项目都要求安装git-pylint-commit-hook,它是个钩子,会在你提交代码到本地版本库的时候,自动运行,根据配置文件pylintrc中的配置,去检测改动过文件中的代码,并会对其进行评分,如果未达到设置的分数线,则这次提交到本地版本库的操作(commit),强制取消.需要修改代码后,评分超过设定的分数,才可以提交到本地版本库. 我发现这个是个很好的东西,所以就在自己的项目中也尝

利用 ESLint 检查代码质量 其实很早的时候就想尝试 ESLint 了,但是很多次都是玩了一下就觉得这东西巨复杂,一执行检查就是满屏的error,简直是不堪入目,遂放弃.直到某天终于下定决心深入看了文档,才发现其实挺简单的,只是当时没有看到合适入门教程而已.我相信很多人也有着跟我一样的经历,所以希望将自己的踩坑心得记录下来,让后来者更轻易地掌握 ESLint 的使用,因为它确实是个好东西. JavaScript 是一门神奇的动态语言,它在带给我们编程的灵活性的同时也悄悄埋下了一些地雷.除了基

提高你的Java代码质量吧:推荐使用枚举定义常量 一.分析 常量的声明是每一个项目中不可或缺的,在Java1.5之前,我们只有两种方式的声明:类常量和接口常量.不过,在1.5版之后有了改进,即新增了一种常量声明方式,枚举常量.代码如下: enum Season{ Spring,Summer,Autumn,Winter; } 二.场景 那么枚举常量与我们的经常使用的类常量和静态常量比有什么优势呢? 1.枚举常量更简单  先把Season枚举翻译成接口,代码如下: interface Season{

作者:Williammao, 腾讯移动客户端开发工程师 商业转载请联系腾讯WeTest获得授权,非商业转载请注明出处. 原文链接:http://wetest.qq.com/lab/view/290.html WeTest 导读 我们知道,在C++领域,作为进阶阅读材料,必看的书是<Effective C++>. 而<Effective C#>之于C# ,是类似<Effective C++>之于C++一样的存在. 这篇文章,将<Effective C# Second

首先,为什么需要SonarQube? 1.WriteClean Code 1)全局健康报告  2)关注新增的问题  3)强制QualityGate 4)Issue详情及建议- 详情参考:https://www.sonarqube.org/features/clean-code/ 2.DevOps Integration 1)支持多种BuildSystem集成: Maven,Gradle,Ant- 2)支持多种CIEngines: Bamboo,Jenkins- 3)成功.失败通知- 详情参考:h

说明 本文参考MDU系列某产品OMCI模块现有代码,提取若干实例以说明目前的代码质量,亦可作为甄别不良代码的参考. 本文旨在就事论事,而非否定前人(没有前人的努力也难有后人的进步).希望以史为鉴,不破不立,最终产出高质量的代码. 一  质量现状 不考虑业务实现,现有的OMCI模块代码质量不甚理想.无论是理解上手.修改扩展和测试排障,可以用举步维艰形容.尤其是二层通道计算相关代码,堪比令史前动物无法自拔的“焦油坑”. 本节将不考虑流程设计,仅就函数粒度列举目前存在的较为突出的代码质量问题. 1.1

欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~ 本文由鹅厂优文发表于云+社区专栏 作者:朱雷 | 腾讯IEG高级工程师 『Python 工匠』是什么? 我一直觉得编程某种意义上是一门『手艺』,因为优雅而高效的代码,就如同完美的手工艺品一样让人赏心悦目. 在雕琢代码的过程中,有大工程:比如应该用什么架构.哪种设计模式.也有更多的小细节,比如何时使用异常(Exceptions).或怎么给变量起名.那些真正优秀的代码,正是由无数优秀的细节造就的. 『Python 工匠』这个系列文章,是我的

引言 原则1尽可能地使用属性而不是可直接访问的数据成员 原则2偏向于使用运行时常量而不是编译时常量 原则3 推荐使用is 或as操作符而不是强制类型转换 原则4 推荐使用条件属性而不是if条件编译 原则5理解几个等同性判断之间的关系 原则6了解GetHashCode 的一些坑 原则7理解短小方法的优势 原则8选择变量初始化而不是赋值语句 原则9正确地初始化静态成员变量 原则10使用构造函数链减少重复的初始化逻辑 原则11实现标准的销毁模式 原则12区分值类型和引用类型 原则13保证0为值类型的有

原文发表于作者的个人博客:http://morning.work/page/maintainable-nodejs/getting-started-with-eslint.html 其实很早的时候就想尝试ESLint了,但是很多次都是玩了一下就觉得这东西巨复杂,一执行检查就是满屏的error,简直是不堪入目,遂放弃.直到某天终于下定决心深入看了文档,才发现其实挺简单的,只是当时没有看到合适入门教程而已.我相信很多人也有着跟我一样的经历,所以希望将自己的踩坑心得记录下来,让后来者更轻易地掌握ESL

转自:http://blog.csdn.net/swj524152416/article/details/75418162 我们知道,在C++领域,作为进阶阅读材料,必看的书是<Effective C++>. 而<Effective C#>之于C# ,是类似<Effective C++>之于C++一样的存在. 这篇文章,将<Effective C# Second Edition>一书中适用于Unity游戏引擎里使用C#的经验之谈进行了提炼,总结成为21条(一

前言 项目中代码质量,往往需要比较有经验的程序员的审查来保证.但是随着项目越来越大,代码审查会变得越来越复杂,需要耗费越来越多的人力.而且程序员的经验和精力都是有限的,能审查出问题必定有限.而在对代码质量要求越来越严格的当今IT界,这无疑是个矛盾点.幸运的是,不少公司发布了代码扫描工具,来检测代码中存在的问题.尽管它们无法扫描出所有的bug,但仍然能够为我们的工作带来极大的便利.其中FindBugs就是这其中的佼佼者,本文将结合Android Studio来介绍该工具的使用. 一.FindBug