首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

不好的编码习惯

是指在软件开发过程中,开发者可能会养成的一些不规范、低效或易出错的编码习惯。这些习惯可能会导致代码质量下降、可维护性差、性能低下、安全性问题等。以下是一些常见的不好的编码习惯及其影响:

  1. 不遵循命名规范:命名不规范会导致代码可读性差,增加他人理解代码的难度。建议遵循常用的命名规范,如驼峰命名法或下划线命名法。
  2. 长方法或函数:过长的方法或函数难以理解和维护,建议将其拆分为多个小的、可复用的函数或方法。
  3. 复制粘贴代码:复制粘贴代码会导致代码冗余,增加维护成本,并且一处修改可能需要修改多处。建议将重复的代码抽象成函数或类,提高代码的复用性。
  4. 忽略异常处理:不处理异常或者简单地将异常抛出会导致程序崩溃或者不可预测的行为。建议在合适的地方捕获异常,并进行适当的处理或日志记录。
  5. 不合理的注释:注释应该清晰、准确地描述代码的功能和意图,而不是简单地重复代码。不合理的注释会增加维护成本,并且可能会误导他人。
  6. 不进行代码审查:缺乏代码审查会导致潜在的问题无法及时发现和修复,建议进行代码审查,提高代码质量和稳定性。
  7. 不使用版本控制工具:不使用版本控制工具会导致代码丢失、无法回滚、无法协作等问题。建议使用常见的版本控制工具,如Git,进行代码管理。
  8. 不进行单元测试:不进行单元测试会导致代码质量无法保证,难以发现潜在的问题。建议编写单元测试用例,覆盖关键逻辑,确保代码的正确性。
  9. 不合理的代码结构:不合理的代码结构会导致代码难以理解和维护,建议按照模块化、分层等原则组织代码,提高代码的可读性和可维护性。
  10. 不优化性能:不优化性能会导致程序运行缓慢、资源占用过多。建议在关键的性能瓶颈处进行优化,如减少不必要的循环、使用合适的数据结构等。

总结:良好的编码习惯对于软件开发至关重要,可以提高代码质量、可维护性和性能。开发者应该遵循命名规范、拆分长方法、避免复制粘贴、合理处理异常、编写清晰的注释、进行代码审查、使用版本控制工具、编写单元测试、优化性能和合理组织代码结构。这些习惯可以帮助开发者提高工作效率,减少错误,并提供更好的用户体验。

腾讯云相关产品和产品介绍链接地址:

  • 云服务器(CVM):https://cloud.tencent.com/product/cvm
  • 云数据库 MySQL 版(CDB):https://cloud.tencent.com/product/cdb
  • 云原生应用引擎(TKE):https://cloud.tencent.com/product/tke
  • 云存储(COS):https://cloud.tencent.com/product/cos
  • 人工智能(AI):https://cloud.tencent.com/product/ai
  • 物联网(IoT):https://cloud.tencent.com/product/iot
  • 移动开发(移动推送、移动分析):https://cloud.tencent.com/product/mps
  • 区块链(BCS):https://cloud.tencent.com/product/bcs
  • 元宇宙(Tencent XR):https://cloud.tencent.com/product/xr
页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

良好CSS编码习惯

同样,在 css 世界里,代码排列布局也是非常重要。良好代码书写习惯能够让代码看起来更加干净简洁,给阅读者一种赏心悦目的感觉;好代码便于开发发现错误,提高工作效率。...所以作为一名好前端,很有必要养成一个良好 css 编码习惯。 文件命名 web 项目中所有资源文件名称应遵循相同命名约定。...: 以字母开头,避免数字开头 全部用小写,这样的话不容易在引用时候因为大小写而出错 用-来分隔单词,而不是下划线 对于压缩过文件,比如 css 或者 js 文件,使用 .min 代替 -min 设置编码...在 css 文件最顶部设置编码格式为 utf-8 ,否则有可能使得 css 文件出现乱码。...格式化里将要介绍就是它们结构和摆放位置,包括缩进、空格、换行以及个别声明书写习惯等。

56220

编码规范 - 养成良好Java编码习惯

最近在整理公司编码规范方面的内容,2017年阿里巴巴发布了编码规范插件,强烈建议大家安装使用,好编码习惯是通往成功阶梯。...SpringBoot整合SpringDataJPA 004 SpringDataJPA 核心技术 全面讲解SpringDataJPA核心技术 文档目录 注释规范 类注释 方法注释 行级注释 DTO/Param注释 编码规范...private String userId; /** * 查询关键字 */ @Length(max = 30) private String keyWord; } 二、编码规范...集合处理 使用集合转数组方法,必须使用集合toArray(T[] array),传入是类型完全一样数组,大小则是list.size()。...正确示例: logger.error(参数或对象.toString() + "_" + e.getMessage(), e); 写在最后 强烈建议IDEA开发工具安装使用阿里巴巴国际编码规约插件,为良好编码习惯打下基础

1.5K10

编码习惯 - 配置规范

导读(请先仔细阅读):分享我工作中制定配置文件习惯 工作中少不了要制定各种各样配置文件,这里和大家分享一下工作中我是如何制定配置文件,这是个人习惯,结合强大spring,效果很不错。...=========================编码习惯========================= 配置文件编码禁忌: 1. 读取配置代码和业务代码耦合在一起!大忌!千万千万不要!...如下,业务代码里面出现了json配置代码。 ? 2. 开发初期就定配置文件 毫无意义,还导致频繁改动!先定义bean,改bean简单多了。我习惯是转测试前一天才生成配置文件。...另外,代码里面是使用spring习惯,没有spring也是一样,或者配置bean你不用spring注入,而用工具类获取也是一样,区别不大。 呕心沥血苦口婆心之作,希望对大家有帮助!...其他人有好习惯更加简洁方式请在留言区留言,我会逐一回复,谢谢阅读!

44220

编码习惯 —— Controller规范

《吐槽我见过最烂Java代码》 2....《我编码习惯 —— 接口定义》 第一篇文章中,我贴了2段代码,第1段是原生态,第2段是我指定了接口定义规范,使用AOP技术之后最终交付代码,从15行到1行,自己感受一下。...AOP代码,主要就是打印日志和捕获异常,异常要区分已知异常和未知异常,其中未知异常是我们重点关注,可以做一些邮件通知啥,已知异常可以再细分一下,可以不同异常返回不同返回码: /** * 处理和包装异常...贴一个简单controller(左边箭头表示AOP拦截了)。请对比吐槽我见过最烂Java代码里面原来代码查看,没有对比就没有伤害。 ? 最后说一句,先有统一接口定义规范,然后有AOP实现。...技术不是关键,AOP技术也很简单,这个帖子关键点不是技术,而是习惯和思想,不要捡了芝麻丢了西瓜。网络上讲技术贴多,讲习惯、风格少,这些都是我工作多年行之有效经验之谈,望有缘人珍惜。

52240

编码习惯 —— 接口定义

除了代码可读性不好问题外,尤其是参数出现当前用户信息,这是个严重问题。 错误范例: ? 4. 出现复杂输入参数 一般情况下,不允许出现例如json字符串这样参数,这种参数可读性极差。...新手定义时候因为前台没有用就不返回数据或者只返回true,这都是不恰当。别人要不要是别人事情,你该返回还是应该返回。 错误范例: ?...很多人看了我这篇文章吐槽我见过最烂Java代码,都觉得里面的技术也很简单,没有什么特别的地方,但是,实现这个代码框架之前,就是要你接口统一格式ResultBean,aop才好做。...有些人误解了,我那篇文章说都不是技术,重点说编码习惯工作方式,如果你重点还是放在什么技术上,那我也帮不了你了。...同样,如果我后面的关于习惯和规范帖子,你重点还是放在技术上的话,那是丢了西瓜捡芝麻,有很多贴还是没有任何技术点呢。 附上ResultBean,没有任何技术含量: ? ?

57200

编码习惯 —— 日志规范

---- 开发中日志这个问题,每个公司都强调,也制定了一大堆规范,但根据实际情况看,效果不是很明显,主要是这个东西不好测试和考核,没有日志功能一样跑啊。...所以我对日志最少有以下2点要求: 1. 能找到那个机器 2. 能找到用户做了什么 针对第一点,我修改了一下nginx配置文件,让返回头里面返回是那个机器处理。...日志效果图 加上《我编码习惯 —— Controller规范》这篇文章AOP,最后日志如下: ? 其实日志级别我到不是很关注,还没有到关注这步到时候。...我分析了一下,为什么有些人没有打印日志习惯,说了多次都改不过来。我建议大家养成下面的习惯,这样你日志就会改善多了! 1. 不要依赖debug,多依赖日志。 别人面对对象编程,你面对debug编程。...这个习惯非常非常不好!debug会让你写代码时候偷懒不打日志,而且很浪费时间。改掉这个恶习。 2. 代码开发测试完成之后不要急着提交,先跑一遍看看日志是否看得懂。

67820

编码习惯 - Controller规范

第一篇文章中,我贴了2段代码,第一个是原生态,第2段是我指定了接口定义规范,使用AOP技术之后最终交付代码,从15行到1行,自己感受一下。今天来说说大家关注AOP如何实现。...5 不需要打印日志 日志在AOP里面会打印,而且我建议是大部分日志在Services这层打印。 规范里面大部分是 不要做项多,要做比较少,落地比较容易。...AOP代码,主要就是打印日志和捕获异常,异常要区分已知异常和未知异常,其中未知异常是我们重点关注,可以做一些邮件通知啥,已知异常可以再细分一下,可以不同异常返回不同返回码: ? ?...贴一个简单controller(左边箭头表示AOP拦截了)。请对比 程序员你为什么这么累?里面原来代码查看,没有对比就没有伤害。 ? 最后说一句,先有统一接口定义规范,然后有AOP实现。...技术不是关键,AOP技术也很简单,这个帖子关键点不是技术,而是习惯和思想,不要捡了芝麻丢了西瓜。网络上讲技术贴多,讲习惯、风格少,这些都是我工作多年行之有效经验之谈,望有缘人珍惜。

41210

编码习惯 - 接口定义

实际工作中,我们会定义一个统一格式,就是ResultBean,分页有另外一个PageResultBean 错误范例: //返回map可读性不好,尽量不要  @PostMapping("/delete...除了代码可读性不好问题外,尤其是参数出现当前用户信息,这是个严重问题。...错误范例: // 参数出现json格式,可读性不好,代码也难看  @PostMapping("/update") public Map update(long id...有些人误解了,我那篇文章说都不是技术,重点说编码习惯工作方式,如果你重点还是放在什么技术上,那我也帮不了你了。...同样,如果我后面的关于习惯和规范帖子,你重点还是放在技术上的话,那是丢了西瓜捡芝麻,有很多贴还是没有任何技术点呢。

49830

编码习惯之Controller规范

Controller规范,主要内容是就是接口定义里面的内容,你只要遵循里面的规范,controller就问题不大,除了这些,还有另外几点: 1、所有函数返回统一ResultBean/PageResultBean...a、不需要打印日志 日志在AOP里面会打印,而且我建议是大部分日志在Services这层打印。 规范里面大部分是 不要做项多,要做比较少,落地比较容易。...AOP代码,主要就是打印日志和捕获异常,异常要区分已知异常和未知异常,其中未知异常是我们重点关注,可以做一些邮件通知啥,已知异常可以再细分一下,可以不同异常返回不同返回码: public class...贴一个简单controller(左边箭头表示AOP拦截了)。 ? 最后说一句,先有统一接口定义规范,然后有AOP实现。先有思想再有技术。...技术不是关键,AOP技术也很简单,这个帖子关键点不是技术,而是习惯和思想,不要捡了芝麻丢了西瓜。

1.1K80

编码习惯 - 配置规范(导读)

分享我工作中制定配置文件习惯 工作中少不了要制定各种各样配置文件,这里和大家分享一下工作中我是如何制定配置文件,这是个人习惯,在我在项目组中目前要定义配置文件都安装这个步骤,效果还不错。...我xml是配置相关bean完全测试通过之后,用xstream生成xml,读取时候也是用xstream直接读成对象,完全不需要关注xml读写。...还有最主要是,我有中间这一层配置bean,这是我觉得最重要。有了这层bean之后,就相当于有了一个中介。...写过代码同学都应该知道,业务逻辑代码里面混杂着从xml里面读取配置项代码,其实挺难看。...千万业务代码里面不要和读取配置代码耦合在一起。切记! 这就是我今天给大家分享。我个人非常喜欢编码方式,使用简单,效果也很好。其实没有什么技术,技术一说都懂,但我觉得技术外习惯才是最重要

38120

编码习惯之异常处理

异常就算打印了堆栈,也不会有人去看!除非用户告诉你出问题了,你才会去找日志!所以,看着好像很严谨代码,其实作用并不大 异常处理再加上框框2处空判断,天衣无缝避开了所有正确答案。...强调,有些空判断是要,如:参数是用户输入情况下。...导致问题,第一代码可读性很差,你如果工作了看到一半代码是try-catch和空判断你会同意我观点,第二更加重要掩盖了很多错误,如上面图片例子!...见我编码习惯 - Controller规范 所以上面的代码,我来写的话是这样,清晰明了。 ? 另外一种后台定时任务队列异常,其实思路是一样,有个统一地方处理异常,里面的代码同样不准捕获异常!...但是,你要知道你遇到是什么问题,要解决是什么问题?

82190

不好意思,我还是习惯“谷歌”

身为半个科研工作者,上网查查文献或者论文是一件很平常事。虽然各大学校图书馆都会买一些国内外数据库供学生使用,不过,这还是不够。...由于一些众所周知原因,国内各大搜索引擎是不怎么让人放心,又由于一些众所周知原因,国内是打不开谷歌搜索和谷歌学术,其实,有一批又一批的人前仆后继,为我们打开了另一扇可以使用谷歌学术大门,那就是—...镜像站很好理解,镜像嘛,就是把你现有的东西放在另外一个地方,镜像站就是把某个网站东西克隆到另一个网站,当网站不好访问时就访问克隆过那个。...镜像站一般有两种,一种是真·镜像,把原网站内容全部复制克隆下来,对于谷歌这种网站来说,想做一个完全克隆镜像站,一般人是做不起,还有一种是假·镜像,镜像站作为一个中转,把用户输入内容反馈给源站,再把源站结果反馈给用户...很多国外网站在国内都是有镜像站,毕竟有时候国内下载国外内容很慢,当然,很多国内网站也有镜像站,并不固定。 浏览器打开下面推荐网址,搜索即可。

1.4K30

编码习惯 —— API 接口定义

实际工作中,我们会定义一个统一格式,就是ResultBean,分页有另外一个PageResultBean 错误范例: //返回map可读性不好,尽量不要  @PostMapping("/delete...除了代码可读性不好问题外,尤其是参数出现当前用户信息,这是个严重问题。...错误范例: // 参数出现json格式,可读性不好,代码也难看  @PostMapping("/update") public Map update(long id...有些人误解了,我那篇文章说都不是技术,重点说编码习惯工作方式,如果你重点还是放在什么技术上,那我也帮不了你了。...同样,如果我后面的关于习惯和规范帖子,你重点还是放在技术上的话,那是丢了西瓜捡芝麻,有很多贴还是没有任何技术点呢。

75840

编码习惯之工具类规范

一个项目不可能没有工具类,工具类初衷是良好,代码重用,但到了后面工具类越来越乱,有些项目工具类有几十个,看眼花缭乱,还有不少重复。...如何编写出好工具类,我有几点建议: 隐藏实现 就是要定义自己工具类,尽量不要在业务代码里面直接调用第三方工具类。这也是解耦一种体现。...如果我们不定义自己工具类而是直接使用第三方工具类有2个不好地方: 不同的人会使用不同第三方工具库,会比较乱。 将来万一要修改工具类实现逻辑会很痛苦。...再后面发现,不只是英文空格,如果是全角空格,也要返回为true,怎么办?StringUtils上方法已经不能满足我们需求了,真不好改了。。。...物理上独立存放 这点是我习惯,我习惯把和业务无关代码放到独立工程或者目录,在物理上要分开,专人维护。不是所有人都有能力写工具类,独立存放专门维护,专门权限控制有助于保证代码纯洁和质量。

89190
领券