20条开发规范,写出诗一样的代码

阿里巴巴Java开发编程规约(整理详细版) 对软件来说,适当的 规范和标准绝不是消灭代码内容的创造性、优雅性,而是限制过度个性化,以一种普遍认可的统一 方式一起做事,提升协作效率,降低沟通成本。代码的字里行间流淌的是软件系统的血液,代码质 量的提升是尽可能少踩坑,杜绝踩重复的坑,切实提升系统稳定性,码出质量。 阅读详情

简介

写出诗一样的代码,不要写出屎一样的代码

命名

大到项目名、模块名、包名、对外暴露的接口,小到类名、函数名、变量名、参数名,只要是做开发,我们就逃不过“起名字”这一关。

命名的好坏,对于代码的可读性来说非常重要,甚至可以说是起决定性作用的。– 命名会影响可读性

1.命名的长度,多长合适

长的命名:

尽管长的命名可以包含更多的信息,更能准确直观地表达意图。

缺点:代码会很长,可能被分割成两行,影响可读性

短的命名:

变量推荐命名使用缩写,sec表示second,str表示string,num 表示number,doc表示document。

不影响变量表达意图,也能控制代码长度

类名这种作用域比较大的,推荐使用长命名,可以准确直观的表达意图

​

2.利用上下文简化命名

2.1 利用类class上下文简化命名

User是userName的上下文,因此定义为name更合适


public class User {
  private String userName;
  private String userPassword;
  private String userAvatarUrl;
 
}

ex:

public class User{
  private String name;
  private String password;
  private String avatarUrl;
}

当进行属性访问时

User user=new User();
user.getName();
2.2 利用函数function上下文简化命名
public void uploadUserAvatarImageToAliyun(String userAvatarImageUri);

利用上下文简化命名

public void uploadUserAvatarImage(String imageUri);

3. 命名可读、可搜索

3.1 命名可读

也就是命名要好念,不要绕口,大家都不是raper,不需要饶舌

我这里所说的“可读”,指的是不要用一些特别生僻、难发音的英文单词来命名,比如bob这种就很好发音

然而比如以下这些单词 你自己念念,哈哈哈

1、phenomenon (fi-nom-uh-non),[fɪ'nɒmɪnən]n. 现象

2、anaesthetist (uh-nes-thi-tist),[ə'nisθətɪst] n. 麻醉师

3、remuneration (ri-myoo - nuh-reyshun),[rɪ,mjuːnə'reɪʃ(ə)n]n. 报酬

4、statistics (stuh-tis-tiks), [stə'tɪstɪks] n. 统计

5、ethnicity (eth-nis-i-tee),[eθ'nɪsɪtɪ]n. 种族划分

6、philosophical (fil-uh-sof-i-kuhl), [fɪlə'sɒfɪk(ə)l]adj. 哲学的

7、provocatively(pruh-vok-uh-tiv),[pru'vktivl]adv.煽动地

8、anonymous (uh-non-uh-muhs),[ə'nɒnɪməs]adj. 匿名的

9、thesaurus (thi-sawr-uhs),[θɪ'sɔːrəs]n. 宝库;辞典

10、aluminium (al-yuh-min-ee-uhm),[æl(j)ʊ'mɪnɪəm]adj. 铝的
3.2 命名可搜索

命名可搜索。我们在 IDE 中编写代码的时候,经常会用**“关键词联想”**的方法来自动补全和搜索

最主要的就是 关键字要统一:

方法命令-”关键字联想“

大家都用select,insert,update,delete的时候

都用select的时候:你就不要别出新格的用 find,query,get
都用insert的时候:你就不要用 add,save
都用update的时候:你就不要用 put,modify
都用delete的时候:你就不要用 remove

这样你用IDEA,CTRL+SHIFT+F的时候就可以快速定位,当你使用”关键字联想“的技能时,也可以不费脑子的快速定位到自己想要的元素

命名接口和抽象类

接口命名:比较固定的方式

一种是加前缀“I”,表示一个 Interface – IUserService

实现类加后缀“Impl” – UserServiceImpl

抽象类:带上前缀“Abstract”-- AbstractConfiguration

注释

注释的目的就是让代码更容易看懂

注释的内容主要包含这样三个方面:做什么、为什么、怎么做

注释比代码承载的信息更多:

​ 命名的主要目的是解释“做什么” – 比如这个函数做了什么 --what

1.函数和变量如果命名得好,确实可以不用再在注释中解释它是做什么的

2.对于类来说,包含的信息比较多,一个简单的命名就不够全面详尽了。这个时候,在注释中写明“做什么”就合情合理了。

注释起到总结性作用、文档的作用:

​ 阅读代码可以明确地知道代码“怎么做”的。-- 比如这个函数实现的某个功能是怎么实现的-- how

在注释中,关于具体的代码实现思路,我们可以写一些总结性的说明、特殊情况的说明。这样能够让阅读代码的人通过注释就能大概了解代码的实现思路,阅读起来就会更加容易。

​ 一些总结性注释能让代码结构更清晰

注释起到解释为什么会创建这个类或函数的意图:

​ 比较复杂的类,如果已经有其他相同功能的类或函数了: 需要解释为什么这么做–why

下面这个就是比较经典的例子了 ,一个具有重复功能的国能

what: 做了什么

why:为什么做,因为更轻量

how:怎么做的,user specified object > SPI > configuration > default object.


/**
* (what) Bean factory to create beans. 
* 
* (why) The class likes Spring IOC framework, but is more lightweight. 
*
* (how) Create objects from different sources sequentially:
* user specified object > SPI > configuration > default object.
*/
public class BeansFactory {
  // ...
}

总结性注释:


public boolean isValidPasword(String password) {
  // check if password is null or empty
  if (StringUtils.isBlank(password)) {
    return false;
  }

  // check if the length of password is between 4 and 64
  int length = password.length();
  if (length < 4 || length > 64) {
    return false;
  }
    
  // check if password contains only a~z,0~9,dot
  for (int i = 0; i < length; ++i) {
    char c = password.charAt(i);
    if (!((c >= 'a' && c <= 'z') || (c >= '0' && c <= '9') || c == '.')) {
      return false;
    }
  }
  return true;
}

注释是不是越多越好?

不是…

太多的问题的原因:就是代码写的可能不太好,要用很多注释来解释,但注释多了可能反而让代码可读性变差

太少:就需要费脑子来一句一句看代码想表达的真实意图。

按照我的经验来说,类和函数一定要写注释,而且要写得尽可能全面、详细,

而函数内部的注释要相对少一些,一般都是靠好的命名、提炼函数、解释性变量、总结性注释来提高代码的可读性。

总结性注释:

这样就只用看注释就知道干了什么,不用读代码


public boolean isValidPasword(String password) {
  // check if password is null or empty
  if (StringUtils.isBlank(password)) {
    return false;
  }

  // check if the length of password is between 4 and 64
  int length = password.length();
  if (length < 4 || length > 64) {
    return false;
  }
    
  // check if password contains only a~z,0~9,dot
  for (int i = 0; i < length; ++i) {
    char c = password.charAt(i);
    if (!((c >= 'a' && c <= 'z') || (c >= '0' && c <= '9') || c == '.')) {
      return false;
    }
  }
  return true;
}

函数多大合适

类或函数的代码行数不能太多,但也不能太少。

类或函数的代码行数太多,一个类上千行,一个函数几百行,逻辑过于繁杂,阅读代码的时候,很容易就会看了后面忘了前面。

相反,类或函数的代码行数太少,在代码总量相同的情况下,被分割成的类和函数就会相应增多,调用关系就会变得更复杂

标准:

当一个类的代码读起来让你感觉头大了,实现某个功能时不知道该用哪个函数了,想用哪个函数翻半天都找不到了,只用到一个小功能要引入整个类(类中包含很多无关此功能实现的函数)的时候,这就说明类的行数过多了。

这个时候就需要做类拆分

一行代码多长合适

标准:一行代码最长不能超过 IDE 显示的宽度

善用空行分割代码块

对于比较长的函数,

如果逻辑上可以分为几个独立的代码块,

在不方便将这些独立的代码块抽取成小函数的情况下,

为了让逻辑更加清晰,结构也更清晰

public class Test {
  public void execFunc(){
    // 参数校验
     chkParam();
    
    // 处理数据
     doData();
    
    // 入库
    insertData();
  }
}

四行缩进还是两行缩进

个人比较推荐使用两格缩进,这样可以节省空间。特别是在代码嵌套层次比较深的情况下,累计缩进较多的话,容易导致一个语句被折成两行,影响代码可读性

​ 不管是用两格缩进还是四格缩进,一定不要用 tab 键缩进

​ 因为在不同的 IDE 下,tab 键的显示宽度不同,有的显示为四格缩进,有的显示为两格缩进

大括号是否要另起一行


// PHP
class ClassName
{
    public function foo()
    {
        // method body
    }
}

// Java
public class ClassName {
  public void foo() {
    // method body
  }
}

个人还是比较推荐,将括号放到跟语句同一行的风格。理由跟上面类似,节省代码行数。

但是将大括号另起新的一行的方式,也有它的优势。这样的话,左右括号可以垂直对齐,哪些代码属于哪一个代码块,更一目了然

主要是团队要统一

类中成员的排列顺序

在java类文件中:

​ 1.先要书写类所属的包名

​ 2.罗列 import 引入的依赖类, Google 编码规范中,依赖类按照字母序从小到大排列

在类中:

​ 成员变量排在函数的前面。

​ 先定义变量 public int num=1;

​ 再定义函数 public void func(){}

成员变量之间或函数之间,都是按照

​ “先静态(静态函数或静态成员变量)、

​ 后普通(非静态函数或非静态成员变量)”的方式来排列的。

除此之外,成员变量之间或函数之间,

​ 还会按照作用域范围从大到小的顺序来排列,

​ 先写 public 成员变量或函数,

​ 然后是 protected 的,最后是 private 的。

还有另外一种排列习惯,那就是把有调用关系的函数放到一块

代码分割成更小的代码块

大部分人阅读代码的习惯都是,先看整体再看细节。

​ 所以,我们要有模块化和抽象思维,善于将大块的复杂逻辑提炼成类或者函数,屏蔽掉细节,–屏蔽掉细节

让阅读代码的人不至于迷失在细节中,这样能极大地提高代码的可读性。

不过,只有代码逻辑比较复杂的时候,我们其实才建议提炼类或者函数。

​ 毕竟如果提炼出的函数只包含两三行代码,在阅读代码的时候,还得跳过去看一下,这样反倒增加了阅读成本

举例子:

invest函数中的最开始的时间处理的代码是不是很难懂?


// 重构前的代码
public void invest(long userId, long financialProductId) {
  Calendar calendar = Calendar.getInstance();
  calendar.setTime(date);
  calendar.set(Calendar.DATE, (calendar.get(Calendar.DATE) + 1));
  if (calendar.get(Calendar.DAY_OF_MONTH) == 1) {
    return;
  }
  //...
}

// 重构后的代码:提炼函数之后逻辑更加清晰
public void invest(long userId, long financialProductId) {
  if (isLastDayOfMonth(new Date())) {
    return;
  }
  //...
}

public boolean isLastDayOfMonth(Date date) {
  Calendar calendar = Calendar.getInstance();
  calendar.setTime(date);
  calendar.set(Calendar.DATE, (calendar.get(Calendar.DATE) + 1));
  if (calendar.get(Calendar.DAY_OF_MONTH) == 1) {
   return true;
  }
  return false;
}

重构后

我们将这部分逻辑抽象成一个函数,

并且命名为 isLastDayOfMonth,从名字就能清晰地了解它的功能,判断今天是不是当月的最后一天。

这里,我们就是通过将复杂的逻辑代码提炼成函数,大大提高了代码的可读性。

避免参数过多

个人觉得,函数包含 3、4 个参数的时候还是能接受的,

大于等于 5 个的时候,我们就觉得参数有点过多了,会影响到代码的可读性,使用起来也不方便。

两种处理方式:

​ 考虑函数是否职责单一,是否能通过拆分多个函数的方式来减少参数。


public User getUser(String username, String telephone, String email);

// 拆分成多个函数
public User getUserByUsername(String username);
public User getUserByTelephone(String telephone);
public User getUserByEmail(String email);

​ 将函数的参数封装成对象


public void postBlog(String title, String summary, String keywords, String content, String category, long authorId);

// 将参数封装成对象
public class Blog {
  private String title;
  private String summary;
  private String keywords;
  private Strint content;
  private String category;
  private long authorId;
}
public void postBlog(Blog blog);

除此之外,如果函数是对外暴露的远程接口,将参数封装成对象,还可以提高接口的兼容性。

​ 在往接口中添加新的参数的时候,老的远程接口调用者有可能就不需要修改代码来兼容新的接口了

勿用函数参数来控制逻辑

不要在函数中使用布尔类型的标识参数来控制内部逻辑,true 的时候走这块逻辑,false 的时候走另一块逻辑。

​ 这明显违背了单一职责原则和接口隔离原则。我建议将其拆成两个函数,可读性上也要更好


public void buyCourse(long userId, long courseId, boolean isVip);

// 将其拆分成两个函数
public void buyCourse(long userId, long courseId);
public void buyCourseForVip(long userId, long courseId);

不过,如果函数是 private 私有函数,影响范围有限,

或者拆分之后的两个函数经常同时被调用,我们可以酌情考虑保留标识参数。示例代码如下所示:


// 拆分成两个函数的调用方式
boolean isVip = false;
//...省略其他逻辑...
if (isVip) {
  buyCourseForVip(userId, courseId);
} else {
  buyCourse(userId, courseId);
}

// 保留标识参数的调用方式更加简洁
boolean isVip = false;
//...省略其他逻辑...
buyCourse(userId, courseId, isVip);

还有一种“根据参数是否为 null”来控制逻辑的情况:

我们也应该将其拆分成多个函数。拆分之后的函数职责更明确,不容易用错


public List<Transaction> selectTransactions(Long userId, Date startDate, Date endDate) {
  if (startDate != null && endDate != null) {
    // 查询两个时间区间的transactions
  }
  if (startDate != null && endDate == null) {
    // 查询startDate之后的所有transactions
  }
  if (startDate == null && endDate != null) {
    // 查询endDate之前的所有transactions
  }
  if (startDate == null && endDate == null) {
    // 查询所有的transactions
  }
}

// 拆分成多个public函数,更加清晰、易用
public List<Transaction> selectTransactionsBetween(Long userId, Date startDate, Date endDate) {
  return selectTransactions(userId, startDate, endDate);
}

public List<Transaction> selectTransactionsStartWith(Long userId, Date startDate) {
  return selectTransactions(userId, startDate, null);
}

public List<Transaction> selectTransactionsEndWith(Long userId, Date endDate) {
  return selectTransactions(userId, null, endDate);
}

public List<Transaction> selectAllTransactions(Long userId) {
  return selectTransactions(userId, null, null);
}

private List<Transaction> selectTransactions(Long userId, Date startDate, Date endDate) {
  // ...
  //具体执行的查询 --值负责查询
}
public static void main(String[] args){
  //调用方来判断参数
  if (startDate != null && endDate != null) {
    // 查询两个时间区间的transactions
    selectTransactionsBetween();
  }
  if (startDate != null && endDate == null) {
    // 查询startDate之后的所有transactions
    selectTransactionsStartWith()
  }
  if (startDate == null && endDate != null) {
    // 查询endDate之前的所有transactions
    selectTransactionsEndWith()
  }
  if (startDate == null && endDate == null) {
    // 查询所有的transactions
    selectAllTransactions();
  }
  
}

函数设计要职责单一

我们在前面讲到单一职责原则的时候,针对的是类、模块这样的应用对象。

实际上,对于函数的设计来说,更要满足单一职责原则。

相对于类和模块,函数的粒度比较小,代码行数少,所以在应用函数设计的单一职责原则的时候,没有像应用到类或者模块那样模棱两可,能多单一就多单一。


public boolean checkUserIfExisting(String telephone, String username, String email)  { 
  if (!StringUtils.isBlank(telephone)) {
    User user = userRepo.selectUserByTelephone(telephone);
    return user != null;
  }
  
  if (!StringUtils.isBlank(username)) {
    User user = userRepo.selectUserByUsername(username);
    return user != null;
  }
  
  if (!StringUtils.isBlank(email)) {
    User user = userRepo.selectUserByEmail(email);
    return user != null;
  }
  
  return false;
}

// 拆分成三个函数
public boolean checkUserIfExistingByTelephone(String telephone);
public boolean checkUserIfExistingByUsername(String username);
public boolean checkUserIfExistingByEmail(String email);

移除过深嵌套层次

代码嵌套层次过深往往是因为 if-else、switch-case、for 循环过度嵌套导致的。

我个人建议,嵌套最好不超过两层,超过两层之后就要思考一下是否可以减少嵌套。

过深的嵌套本身理解起来就比较费劲,除此之外,嵌套过深很容易因为代码多次缩进,导致嵌套内部的语句超过一行的长度而折成两行,影响代码的整洁。


// 示例一
public double caculateTotalAmount(List<Order> orders) {
  if (orders == null || orders.isEmpty()) {
    return 0.0;
  } else { // 此处的else可以去掉
    double amount = 0.0;
    for (Order order : orders) {
      if (order != null) {
        amount += (order.getCount() * order.getPrice());
      }
    }
    return amount;
  }
}

// 示例二
public List<String> matchStrings(List<String> strList,String substr) {
  List<String> matchedStrings = new ArrayList<>();
  if (strList != null && substr != null) {
    for (String str : strList) {
      if (str != null) { // 跟下面的if语句可以合并在一起
        if (str.contains(substr)) {
          matchedStrings.add(str);
        }
      }
    }
  }
  return matchedStrings;
}

使用编程语言提供的 continue、break、return 关键字,提前退出嵌套


// 重构前的代码
public List<String> matchStrings(List<String> strList,String substr) {
  List<String> matchedStrings = new ArrayList<>();
  if (strList != null && substr != null){ 
    for (String str : strList) {
      if (str != null && str.contains(substr)) {
        matchedStrings.add(str);
        // 此处还有10行代码...
      }
    }
  }
  return matchedStrings;
}

// 重构后的代码:使用continue提前退出
public List<String> matchStrings(List<String> strList,String substr) {
  List<String> matchedStrings = new ArrayList<>();
  if (strList != null && substr != null){ 
    for (String str : strList) {
      if (str == null || !str.contains(substr)) {
        continue; 
      }
      matchedStrings.add(str);
      // 此处还有10行代码...
    }
  }
  return matchedStrings;
}

调整执行顺序来减少嵌套:


// 重构前的代码
public List<String> matchStrings(List<String> strList,String substr) {
  List<String> matchedStrings = new ArrayList<>();
  if (strList != null && substr != null) {
    for (String str : strList) {
      if (str != null) {
        if (str.contains(substr)) {
          matchedStrings.add(str);
        }
      }
    }
  }
  return matchedStrings;
}

// 重构后的代码:先执行判空逻辑,再执行正常逻辑
public List<String> matchStrings(List<String> strList,String substr) {
  if (strList == null || substr == null) { //先判空
    return Collections.emptyList();
  }

  List<String> matchedStrings = new ArrayList<>();
  for (String str : strList) { // 再执行具体逻辑
    if (str != null) {
      if (str.contains(substr)) {
        matchedStrings.add(str);
      }
    }
  }
  return matchedStrings;
}

将部分嵌套逻辑封装成函数调用,以此来减少嵌套


// 重构前的代码
public List<String> appendSalts(List<String> passwords) {
  if (passwords == null || passwords.isEmpty()) {
    return Collections.emptyList();
  }
  
  List<String> passwordsWithSalt = new ArrayList<>();
  for (String password : passwords) {
    if (password == null) {
      continue;
    }
    // 下面是执行加salt的逻辑,应该封装成函数
    if (password.length() < 8) {
      // ...
    } else {
      // ...
    }
  }
  return passwordsWithSalt;
}

// 重构后的代码:将部分逻辑抽成函数
public List<String> appendSalts(List<String> passwords) {
  if (passwords == null || passwords.isEmpty()) {
    return Collections.emptyList();
  }
	
  
  List<String> passwordsWithSalt = new ArrayList<>();
  for (String password : passwords) {
    if (password == null) {
      continue;
    }
    passwordsWithSalt.add(appendSalt(password));
  }
  return passwordsWithSalt;
}

private String appendSalt(String password) { // 封装password 加salt
  String passwordWithSalt = password;
  if (password.length() < 8) {
    // ...
  } else {
    // ...
  }
  return passwordWithSalt;
}

学会使用解释性变量

常用的用解释性变量来提高代码的可读性的情况有下面 2 种。

常量取代魔法数字。示例代码如下所示:


public double CalculateCircularArea(double radius) {
  return (3.1415) * radius * radius;
}

// 常量替代魔法数字
public static final Double PI = 3.1415; //把PI抽离出来 定义为常量
public double CalculateCircularArea(double radius) {
  return PI * radius * radius;
}

使用解释性变量来解释复杂表达式。示例代码如下所示:


if (date.after(SUMMER_START) && date.before(SUMMER_END)) { //这个应该使用解释性变量
  // ...
} else {
  // ...
}

// 引入解释性变量后逻辑更加清晰
boolean isSummer = date.after(SUMMER_START)&&date.before(SUMMER_END);
if (isSummer) {
  // ...
} else {
  // ...
} 
前端代码开发规范总结 必须使用 camelCase 驼峰命名必须指定类型必须加上注释,表明其含义必须加上 required 或者 default,两者二选其一如果有业务需要,必须加上 validator 验证props: { // 组件状态,用于控制组件的颜色 status: { type: String, required: true, validator: function (value) { return [ 'succ', 'info', 'error' ].indexOf(value)! 阅读详情

相关推荐

HarmonyOS组件开发规范文档之理解与总结

HarmonyOS组件开发规范文档之理解与总结

T_iAn_T的博客 1413

【规范】代码编写规范

*用业务语言写代码。**这里业务语言,指的是描述的语言,应该更倾向于业务而不是技术维度。**编写可维护的代码要使用业务语言。**如何判断是否使用的是业务语言呢?将语言给业务成员看,如果能看懂,则表示使用的业务语言已经符合标准了。**建立团队词汇表。**使团队业务对于业务有共同理解,不至于出现一个变量含义多种命名方式。如果命名不确定,可以在业务层面进行更深的讨论。好的命名,是体现业务含义的命名。**制定代码规范。**比如,类名要用名词,函数名要用动词或动宾短语;

雨下一整晚real的博客 3620

20个闭环渗透测试项目:从漏洞发现到简历突围

渗透测试不仅是工具使用,更是对系统设计缺陷与实现偏差的深度推演。理解OWASP Top 10、Burp Suite等基础能力只是起点,真正具备工程价值的是能复现、可验证、可协作的完整攻击链。本文聚焦真实业务场景下的SSRF协议绕过、JWT签名机制缺陷、Redis未授权利用、Kong网关配置风险及etcd存储结构分析等核心热词,揭示漏洞本质在于架构决策与配置偏差的叠加态。适用于红队实战、甲方安全建设与乙方渗透审计等多类岗位,帮助从业者将技术动作升维为技术叙事。

weixin_32234493的博客 414

开发代码规范

平日java开发规范手册

qq_56734899的博客 2579

基于价值的深度强化学习:DQN

本文主要是介绍DQN原理和算法伪代码和代码实现,算法实现包括pytorch版本和stable-baselines3版本

溯源的专栏 1083

一步一步搭建S32K14x的AutoSar项目----MCAL工程创建及说明

一步一步搭建S32K14X的Autosar项目--MCAL工程创建及说明

wo580231的博客 2493

代码规范要求

必须使用 camelCase 驼峰命名必须指定类型必须加上注释,表明其含义必须加上 required 或者 default,两者二选其一如果有业务需要,必须加上 validator 验证props: {// 组件状态,用于控制组件的颜色status: {return ['succ','info','error'== -1},// 用户级别,用于显示皇冠个数。

2201_75579672的博客 1646

多目标优化NSGA-II(快速精英非支配排序遗传算法)及python实现

文章目录前言一、什么是NSGA-II?二、学习NSGA-II1.快速非支配排序算法2.密度估计3.拥挤比较算子4.主循环5.代码6.总结 前言 NSGA-II适用于复杂的多目标优化问题,是K-Deb教授在2000年在一篇paper《MOEAs — A fast and elitist multi-objective genetic algorithm: nsga2》提出。 Keywords: optimization; multi-objective evolutionary algorithm; no

ricky_blog 9744

10.日常开发代码规范

日常代码编写规范

罐装七喜的博客 1109

【知识分享】高速印刷电路板(PCB)寄生参数计算指南

对于高速PCB设计而言,寄生参数一直是令人讨厌的问题,它们会悄悄潜入PCB并在电路中造成严重的破坏,具体来说,它们是渗透到高速电路中的隐藏杂散电容器和电感器,包括由封装引线和长走线形成的电感器、PCB焊盘对金属平面形成的电容器、走线之间形成的电容器等等。

一只豌豆象的博客 1780

RK3568 上C图像camera图像采集应用实例(二)

本文探索rk3568上实现C语言的 通过C v4l2 接口 采集图像 ,刷屏控制 drm的显示camera图像中 实现camera preview 预览 的实践和探索。

luoshanxuli2010的专栏 760

有了这款 IDEA 神器,领导都夸我代码写得像诗一样

关注公众号:woniuxgg,在公众号中回复:笔记 就可以获得蜗牛为你精心准备的java实战语雀笔记,回复面试、开发手册、有超赞的粉丝福利!

竹林幽深 120

C语言使用开源库libusb进行USB设备操作

https://libusb.info/libusb is a C library that provides generic access to USB devices. It is intended to be used by developers to facilitate the production of applications that communicate with USB hardware. It is portable: Using a single cross-platform AP

m0_60352504的博客 1554

企业实施RPA需考虑的20条建议

流程挖掘可查看流程中有多少异常情况,及时反馈哪些流程会导致延误、潜在危险和漏洞,帮助企业在部署RPA前发现瓶颈,改进流程,使RPA实施更加顺利。此外,使用流程挖掘还可以检测RPA的部署是否达到了预期效果,以及流程是否按照设计执行、是否合规,以便企业持续监测、评估RPA自动化项目,获得更高的投资回报。在部署RPA前,首先要评估现有流程的整体状况,找出最适合实施自动化的流程,确定最有可能看到积极业务影响的流程,以增加成功部署RPA的可能性。当整个项目都处在统一的、标准化的要求下,项目部署的各阶段都会从中受益。

Sheilasi的博客 2079

042、双管反激的电压应力优势

【摘要】本文通过300W工业电源炸管案例,对比分析了单管与双管反激拓扑的电压应力差异。单管反激因漏感能量难以处理,尖峰电压可达1180V,需依赖RCD吸收电路但效率低下;双管反激通过钳位二极管将漏极电压限制在输入电压水平(实测650V),能量回馈使效率提升2-3%。虽增加两个MOS管,但可选用600V器件(单管需1200V),总成本反降15%以上。作者建议150W以上或高压输入场景优先采用双管反激,其确定的电压应力可显著提升可靠性,避免单管反激的参数玄学问题。关键设计要点包括快恢复二极管选型、紧凑布局及漏感

Jack010169的博客 80

jdk-8u144-linux-x64.tar.gz.

该资源为搭建Linux系统Java环境用,资源的后缀为tar.gz格式的压缩包

Python 基础教学 - 开发规范

在 Python 编程中,遵循良好的开发规范是编写高质量、可维护代码的关键。本文将为您详细介绍 Python 开发中的一些重要规范,帮助您养成良好的编程习惯。

道长的博客 573

STM32F407中文手册

STM32f407中文手册 本参考手册面向应用开发人员,提供有关使用 STM32F405xx/07xx、STM32F415xx/17xx、 STM32F42xxx 和 STM32F43xxx 微控制器存储器与外设的完整信息。STM32F405xx/07xx、STM32F415xx/17xx、STM32F42xxx 和 STM32F43xxx 构成一个微 控制器系列,各产品具有不同的存储器大小、封装和外设。有关订购信息以及器件的机械与电气特性,请参见数据手册。有关 ARM Cortex™-M4F 内核的信息,请参见《Cortex™-M4F 技术参考手册》。

代码规范 —— Redis 开发规范

除了带来极大的内存占用外,在访问量高时,很容易就会将网卡流量占满,进而造成整个服务器上的所有服务不可用,并引发雪崩效应,造成各个系统瘫痪。的多数据库较弱,使用数字进行区分,很多客户端支持较差,同时多业务用多数据库实际还是单线程处理,会有干扰。等基于磁盘的存储方式,不仅节省内存成本,而且数据量小在操作时速度更快、效率更高。设置过期时间(条件允许可以打散过期时间,防止集中过期),不过期的数据重点关注。☑️ 禁止包含特殊字符如空格,换行,单双引号,其他转义字符。不能被不同的应用,不同的场景使用。

程序猿进阶 2780

蓝牙模块HM-10手册

蓝牙模块HM-10手册,该手册对蓝牙模块HM-10进行了详细的介绍和使用方法以及一些AT指令。

RU DOS版、EFI版32bit/64bit BIOS常用工具

DOS版、EFI版的RU工具,可用来查看IO、MEM、PCI、SMBIOS等资源。亲测在EFI SHELL下可用。

建立开发规范:从混乱到有序的团队协作指南

摘要: 开发规范是提升团队协作效率的关键。通过统一代码风格(命名、格式、语法)、建立清晰流程(需求开发、代码提交、发布管理)和完善文档体系(架构、接口、注释),可显著降低维护成本。规范落地需结合自动化工具强制检查(如ESLint、GitHooks)、严格的代码评审和定期培训,使其从"纸上规定"转化为团队习惯。良好的开发规范能减少理解成本,避免知识断层,最终实现"1+1>2"的协作效能,为团队可持续发展奠定基础。(149字)

weixin_43883508的博客 1204

Mindustry开发规范与最佳实践:从代码风格到提交指南的全面解析

你是否在Mindustry项目贡献中遇到过代码格式混乱、提交信息不清晰等问题?本文将系统梳理Mindustry项目的开发规范与最佳实践,帮助开发者高效协作,提升代码质量。读完本文,你将掌握代码风格配置、提交规范、贡献流程等核心要点,轻松参与开源贡献。 ## 开发环境准备 Mindustry项目推荐使用IntelliJ IDEA(社区版免费)进行开发,以确保代码风格一致性。通过导入项目提供的代码

gitblog_00164的博客 744

工程代码开发规范

一般地,类名的书写尽量使其保持简单和描述的完整性,因此在书写类名时不建议使用缩写(一些约定俗成的命名除外。变量命名通常以小写字母开头,如果变量名由多个单词构成,则从第二个单词起首字母需要大写,在变量命名过程中,不建议使用“_”作为前缀或者单词之间的分割符号。此外,非常重要的一点是,不论执行语句有多少行,就算只有一行也要加{},并且遵循对齐的原则,这样可以防止书写失误。边写代码边注释,修改代码的同时要修改相应的注释,以保证注释与代码的一致性,不再有用的注释要删除。这样的代码容易阅读,并且便于写注释。

Q13165406614的博客 1511

[inBuilder x UBML]关于开发规范,一些可能要说的点(一)

开发规范(Development Standards)是软件开发过程中至关重要的指导性文件,它定义了团队在编码、设计、测试、部署等环节的统一规则。对于这个词而言,很多人可能只会将其与代码规范划为等号,简单的理解为代码风格一致,正确缩进,正确注释等内容,但其作用不仅限于代码风格的一致性,还涉及项目管理、质量保障、团队协作等多个维度。在做项目时如果没法做到开发规范,人员之间的相互对接就会出现困难,导致项目人月成本上升,成果交付困难。

Z200444_81的博客 1033

html css js文件开发规范

这些优化措施可以显著降低资源体积,减少网络请求时间,提升页面加载性能。建议通过Lighthouse等工具定期检测网站性能指标,持续优化。遵循以上规范可提升代码可读性、可维护性和团队协作效率。

qq_63084249的博客 764

Claude Code 开发规范:从架构设计到代码审查的全流程指南

本文提供了一份全面的Claude Code开发规范指南,涵盖从架构设计、代码质量到开发流程和项目管理的全流程。通过制定明确的CLAUDE.md规范,团队可以高效利用AI辅助编程,统一代码风格,提升代码可读性、可维护性与安全性,并系统化代码审查,从而显著提高开发效率与协作质量。

e3f4g5的博客 787

MySQL开发规范

MySQL开发规范 文章目录MySQL开发规范一、命名规范二、基本规范三、库表设计规范四、索引设计规范五、字段设计规范六、SQL设计规范七、行为规范 一、命名规范 1、库名、表名、字段名必须使用小写字母并采用下划线分割; 2、库名、表名、字段名支持最多32个字符,统一规范、易于辨识以及减少传输量不要超过32; 3、库名、表名、字段名禁止使用MySQL保留关键字; 4、临时库、临时表名必须以tmp为...

Hello Word 408

简明 HTML CSS 开发规范

document.title="简明 HTML CSS 开发规范 - "+document.title作者:wjack    文章来源:蓝色理想//总论本规范既是一个开发规范,也是一个脚本语言参考,本规范并不是一个一成不变的必须严格遵守的条文,特殊情况下要灵活运用,做一定的变通。但是,请大家千万不要随意更改规范。如果有任何问题,请及时与我联系,我会及时更改本规范的相关代码样例和文档。/基

waterfireman的专栏 3012

React代码开发规范

前言 一般在团队开发中每个人的代码习惯都不太一样,这样就会导致代码风格不一致,以致于维护和修改bug的时候看别人的代码成为一种痛苦... 这种情况尤其在前端开发中尤为明显。因为关于前端的开发规范貌似也没有行业权威标准。这几天在网上看了下,基本上在开发中通过eslint进行约束,airbnb的标准貌似颇为推崇,今天稍微整理下,准备在日后开发中形成习惯。 基本规则 每个文件只包含一个React组件。eslint: react/no-multi-comp;(官方表示在无状态,或者Pure组件允许一个文件包含

江湖行骗老中医 620
上一篇: 程序员命名缩写
code222vip
博客等级 码龄12年 33粉丝 30原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值