同样，在 css 的世界里，代码的排列布局也是非常重要的。良好的代码书写习惯能够让代码看起来更加干净简洁，给阅读者一种赏心悦目的感觉；好的代码便于开发发现错误，提高工作效率。...所以作为一名好前端，很有必要养成一个良好的 css 编码习惯。 文件命名 web 项目中的所有资源文件名称应遵循相同的命名约定。...： 以字母开头，避免数字开头 全部用小写，这样的话不容易在引用的时候因为大小写而出错 用-来分隔单词，而不是下划线 对于压缩过的文件，比如 css 或者 js 文件，使用 .min 代替 -min 设置编码...在 css 文件的最顶部设置编码格式为 utf-8 ，否则有可能使得 css 文件出现乱码。...格式化里将要介绍的就是它们的结构和摆放位置，包括缩进、空格、换行以及个别声明的书写习惯等。
最近在整理公司编码规范方面的内容，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开发工具安装使用阿里巴巴国际编码规约插件，为良好的编码习惯打下基础
导读（请先仔细阅读）：分享我工作中制定配置文件的习惯 工作中少不了要制定各种各样的配置文件，这里和大家分享一下工作中我是如何制定配置文件的，这是个人习惯，结合强大的spring，效果很不错。...=========================编码习惯========================= 配置文件编码禁忌： 1. 读取配置的代码和业务代码耦合在一起！大忌！千万千万不要！...如下，业务代码里面出现了json的配置代码。 ? 2. 开发初期就定配置文件 毫无意义，还导致频繁改动！先定义bean，改bean简单多了。我的习惯是转测试前一天才生成配置文件。...另外，代码里面是使用spring的习惯，没有spring也是一样的，或者配置的bean你不用spring注入，而用工具类获取也是一样，区别不大。 呕心沥血苦口婆心之作，希望对大家有帮助！...其他人有好的习惯更加简洁的方式请在留言区留言，我会逐一回复的，谢谢阅读！
《吐槽我见过的最烂的Java代码》 2....《我的编码习惯 —— 接口定义》 第一篇文章中，我贴了2段代码，第1段是原生态的，第2段是我指定了接口定义规范，使用AOP技术之后最终交付的代码，从15行到1行，自己感受一下。...AOP代码，主要就是打印日志和捕获异常，异常要区分已知异常和未知异常，其中未知的异常是我们重点关注的，可以做一些邮件通知啥的，已知异常可以再细分一下，可以不同的异常返回不同的返回码： /** * 处理和包装异常...贴一个简单的controller（左边的箭头表示AOP拦截了）。请对比吐槽我见过的最烂的Java代码里面原来的代码查看，没有对比就没有伤害。 ? 最后说一句，先有统一的接口定义规范，然后有AOP实现。...技术不是关键，AOP技术也很简单，这个帖子的关键点不是技术，而是习惯和思想，不要捡了芝麻丢了西瓜。网络上讲技术的贴多，讲习惯、风格的少，这些都是我工作多年的行之有效的经验之谈，望有缘人珍惜。
实际工作中，我们会定义一个统一的格式，就是ResultBean，分页的有另外一个PageResultBean 错误范例： //返回map可读性不好，尽量不要 ＠PostMapping("/delete...除了代码可读性不好问题外，尤其是参数出现当前用户信息的，这是个严重问题。...错误范例： // 参数出现json格式，可读性不好，代码也难看 ＠PostMapping("/update") public Map update(long id...有些人误解了，我那篇文章说的都不是技术，重点说的是编码习惯工作方式，如果你重点还是放在什么技术上，那我也帮不了你了。...同样，如果我后面的关于习惯和规范的帖子，你重点还是放在技术上的话，那是丢了西瓜捡芝麻，有很多贴还是没有任何技术点呢。
第一篇文章中，我贴了2段代码，第一个是原生态的，第2段是我指定了接口定义规范，使用AOP技术之后最终交付的代码，从15行到1行，自己感受一下。今天来说说大家关注的AOP如何实现。...5 不需要打印日志 日志在AOP里面会打印，而且我的建议是大部分日志在Services这层打印。 规范里面大部分是 不要做的项多，要做的比较少，落地比较容易。...AOP代码，主要就是打印日志和捕获异常，异常要区分已知异常和未知异常，其中未知的异常是我们重点关注的，可以做一些邮件通知啥的，已知异常可以再细分一下，可以不同的异常返回不同的返回码： ? ?...贴一个简单的controller（左边的箭头表示AOP拦截了）。请对比 程序员你为什么这么累？里面原来的代码查看，没有对比就没有伤害。 ? 最后说一句，先有统一的接口定义规范，然后有AOP实现。...技术不是关键，AOP技术也很简单，这个帖子的关键点不是技术，而是习惯和思想，不要捡了芝麻丢了西瓜。网络上讲技术的贴多，讲习惯、风格的少，这些都是我工作多年的行之有效的经验之谈，望有缘人珍惜。
除了代码可读性不好问题外，尤其是参数出现当前用户信息的，这是个严重问题。 错误范例： ? 4. 出现复杂的输入参数 一般情况下，不允许出现例如json字符串这样的参数，这种参数可读性极差。...新手定义的时候因为前台没有用就不返回数据或者只返回true，这都是不恰当的。别人要不要是别人的事情，你该返回的还是应该返回。 错误范例： ?...很多人看了我的这篇文章吐槽我见过的最烂的Java代码，都觉得里面的技术也很简单，没有什么特别的地方，但是，实现这个代码框架之前，就是要你的接口的统一的格式ResultBean，aop才好做。...有些人误解了，我那篇文章说的都不是技术，重点说的是编码习惯工作方式，如果你重点还是放在什么技术上，那我也帮不了你了。...同样，如果我后面的关于习惯和规范的帖子，你重点还是放在技术上的话，那是丢了西瓜捡芝麻，有很多贴还是没有任何技术点呢。 附上ResultBean，没有任何技术含量： ? ?
---- 开发中日志这个问题，每个公司都强调，也制定了一大堆规范，但根据实际情况看，效果不是很明显，主要是这个东西不好测试和考核，没有日志功能一样跑啊。...所以我对日志的最少有以下2点要求： 1. 能找到那个机器 2. 能找到用户做了什么 针对第一点，我修改了一下nginx的配置文件，让返回头里面返回是那个机器处理的。...日志效果图 加上《我的编码习惯 —— Controller规范》这篇文章的AOP，最后的日志如下： ? 其实日志的级别我到不是很关注，还没有到关注这步到时候。...我分析了一下，为什么有些人没有打印日志的习惯，说了多次都改不过来。我建议大家养成下面的习惯，这样你的日志就会改善多了！ 1. 不要依赖debug，多依赖日志。 别人面对对象编程，你面对debug编程。...这个习惯非常非常不好！debug会让你写代码的时候偷懒不打日志，而且很浪费时间。改掉这个恶习。 2. 代码开发测试完成之后不要急着提交，先跑一遍看看日志是否看得懂。
Controller规范，主要的内容是就是接口定义里面的内容，你只要遵循里面的规范，controller就问题不大，除了这些，还有另外的几点： 1、所有函数返回统一的ResultBean/PageResultBean...a、不需要打印日志 日志在AOP里面会打印，而且我的建议是大部分日志在Services这层打印。 规范里面大部分是 不要做的项多，要做的比较少，落地比较容易。...AOP代码，主要就是打印日志和捕获异常，异常要区分已知异常和未知异常，其中未知的异常是我们重点关注的，可以做一些邮件通知啥的，已知异常可以再细分一下，可以不同的异常返回不同的返回码： public class...贴一个简单的controller（左边的箭头表示AOP拦截了）。 ? 最后说一句，先有统一的接口定义规范，然后有AOP实现。先有思想再有技术。...技术不是关键，AOP技术也很简单，这个帖子的关键点不是技术，而是习惯和思想，不要捡了芝麻丢了西瓜。
分享我工作中制定配置文件的习惯 工作中少不了要制定各种各样的配置文件，这里和大家分享一下工作中我是如何制定配置文件的，这是个人习惯，在我在的项目组中目前要定义配置文件都安装这个步骤，效果还不错。...我的xml是配置相关的bean完全测试通过之后，用xstream生成xml，读取的时候也是用xstream直接读成对象，完全不需要关注xml的读写。...还有最主要的是，我有中间的这一层配置的bean，这是我觉得最重要的。有了这层bean之后，就相当于有了一个中介。...写过代码的同学都应该知道，业务逻辑代码里面混杂着从xml里面读取配置项的代码，其实挺难看的。...千万业务代码里面不要和读取配置的代码耦合在一起。切记！ 这就是我今天给大家分享的。我个人非常喜欢的编码方式，使用简单，效果也很好。其实没有什么技术，技术一说都懂，但我觉得技术外的习惯才是最重要的！
异常就算打印了堆栈，也不会有人去看的！除非用户告诉你出问题了，你才会去找日志！所以，看着好像很严谨的代码，其实作用并不大 异常处理再加上框框2处的空判断，天衣无缝的避开了所有正确答案。...强调，有些空判断是要的，如：参数是用户输入的情况下。...导致的问题，第一代码可读性很差，你如果工作了看到一半代码是try-catch和空判断你会同意我的观点的，第二更加重要的掩盖了很多错误，如上面图片的例子！...见我的编码习惯 - Controller规范 所以上面的代码，我来写的话是这样的，清晰明了。 ? 另外一种后台定时任务队列的异常，其实思路是一样的，有个统一的地方处理异常，里面的代码同样不准捕获异常！...但是，你要知道你遇到的是什么问题，要解决的是什么问题？
实际工作中，我们会定义一个统一的格式，就是ResultBean，分页的有另外一个PageResultBean 错误范例： //返回map可读性不好，尽量不要 ＠PostMapping("/delete...除了代码可读性不好问题外，尤其是参数出现当前用户信息的，这是个严重问题。...错误范例： // 参数出现json格式，可读性不好，代码也难看 ＠PostMapping("/update") public Map update(long id, String...别人要不要是别人的事情，你该返回的还是应该返回。...，能帮忙规避很多无用的返工修改和可能出现的问题。
身为半个科研工作者，上网查查文献或者论文是一件很平常的事。虽然各大学校的图书馆都会买一些国内外数据库供学生使用，不过，这还是不够。...由于一些众所周知的原因，国内各大搜索引擎是不怎么让人放心的，又由于一些众所周知的原因，国内是打不开谷歌搜索和谷歌学术的，其实，有一批又一批的人前仆后继，为我们打开了另一扇可以使用谷歌学术的大门，那就是—...镜像站很好理解，镜像嘛，就是把你现有的东西放在另外一个地方，镜像站就是把某个网站的东西克隆到另一个网站，当网站不好访问时就访问克隆过的那个。...镜像站一般有两种，一种是真·镜像，把原网站的内容全部复制克隆下来，对于谷歌这种网站来说，想做一个完全克隆的镜像站，一般人是做不起的，还有一种是假·镜像，镜像站作为一个中转，把用户输入的内容反馈给源站，再把源站的结果反馈给用户...很多国外网站在国内都是有镜像站的，毕竟有时候国内下载国外的内容很慢，当然，很多国内的网站也有镜像站，并不固定。 浏览器打开下面推荐的网址，搜索即可。
身为一个科研工作者，上网查查文献或者论文是一件很平常的事。虽然各大学校的图书馆都会买一些数据库供学生使用，不过，还是以国内文献居多。...又由于一些众所周知的原因，国内是打不开谷歌搜索和谷歌学术的，其实，有一批又一批的人前仆后继，为我们打开了另一扇可以使用谷歌学术的大门，那就是——搭建使用谷歌/谷歌学术的镜像站。...打开下面推荐的网址，搜索即可。
多数公司有自己的编码规范，每个developer有自己的编码风格。...无关对错，只是记录一下我自己的习惯： Tab使用4个空格代替; 每次缩进4个空格 函数的每个入参及小括号单独占行并缩进 大括号单独占行并缩进 Function body与大括号缩进相同 Block
为防止头文件的重复引用，定义宏__INCfileNameh 为兼容C++，添加extern "C" /* semLib.h */ #ifndef __INCsemLibh #define __INCsemLibh...else 比较浮点数时，不使用==，用= 不使用goto 不使用continue switch必须包含default public函数入参需判断有效性 所有代码均可到达 递归深度必须有限 函数的圈复杂度不宜过高
multiline comment * this is the second line */ 注释之前若为同级代码，则有一个空行 注释之后没有空行 行尾如需注释，尽量使用单行注释 相同成员的行尾注释要对齐
一个项目不可能没有工具类，工具类的初衷是良好的，代码重用，但到了后面工具类越来越乱，有些项目工具类有几十个，看的眼花缭乱，还有不少重复。...如何编写出好的工具类，我有几点建议： 隐藏实现 就是要定义自己的工具类，尽量不要在业务代码里面直接调用第三方的工具类。这也是解耦的一种体现。...如果我们不定义自己的工具类而是直接使用第三方的工具类有2个不好的地方： 不同的人会使用不同的第三方工具库，会比较乱。 将来万一要修改工具类的实现逻辑会很痛苦。...再后面发现，不只是英文空格，如果是全角的空格，也要返回为true，怎么办？StringUtils上的方法已经不能满足我们的需求了，真不好改了。。。...物理上独立存放 这点是我的习惯，我习惯把和业务无关的代码放到独立的工程或者目录，在物理上要分开，专人维护。不是所有人都有能力写工具类，独立存放专门维护，专门的权限控制有助于保证代码的纯洁和质量。
多数公司有自己的编码规范，每个developer有自己的编码风格。...无关对错，只是记录一下我自己的习惯： 注释中的星号前后有空格，多行的星号用空格对齐 /* this is a single line comment */ /* * this...is a multiline comment */ 功能类似的相邻代码行使用空格对齐 指针型变量的星号前有空格，后无空格 char var1; char *var2;...a; char b; }myStr; do { }while(1); 空括号内无空格 int arrayA[] = {1, 2, 3}; doSth(); case语句的冒号前无空格...sizeof(b); 双目运算符前后有空格 a = b + c; a = b * c; if(a >= b) { a = b << 2; } 代码行过长时，适当压缩优先级较低表达式内的空格
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
腾讯会议
云直播
对象存储
