wordpress开发复杂网站,海南省住房和城乡建设厅网站,wordpress 多站,注册一家有限公司需要多少钱在项目开发过程中#xff0c;由于时间紧、任务重#xff0c;很容易导致面向功能编程。实现相同的功能#xff0c;代码可以写的很优雅#xff0c;也可以写的很晦涩和复杂。现在的工作#xff0c;都需要进行团队协作#xff0c;代码就需要有一定的规范进行指引#xff0c;… 在项目开发过程中由于时间紧、任务重很容易导致面向功能编程。实现相同的功能代码可以写的很优雅也可以写的很晦涩和复杂。现在的工作都需要进行团队协作代码就需要有一定的规范进行指引因为我们需要写出让人可以轻易读懂的代码而不仅仅是机器。规范没有绝对的标准遵循大部分人都认可的一种方式就可以了保持统一。比如在 dotNET Core 中我们可以参考下 dotNET Core 的源码最终制定一个适合团队的规范即可。下面是我理解的正确的一些规范基本准则1、命名的规范分为两种Pascal大驼峰和驼峰小驼峰示例如下:• PascalUserName• 驼峰userName2、命名要有意义需要看到名称知其含义。少用拼音和匈牙利命名法。示例Int price20;√UserInfo userInfoGetUserInfo(userId);√Int p20;×Int intPrice20;×3、对于类的成员变量用this关键字增强代码可读性。4、对于基类的成员变量用base关键字增强代码可读性。名称规范好的名称可以让我们减少很多不必要的注释可以让代码阅读者很容易就理解代码的意思。但命名不是一件容易的事情在命名的时候通常伴随着我们对代码逻辑的思考。比如如果你不能给一个函数很准确地命名那可能这个函数的职责不单一做的事情太多才导致一个名称很难概括意味着代码可能需要重构。好的命名是我们写好代码的基础。命名空间命名空间采用Pascal命名法namespace Fw.Application{}
namespace Fw.SmartFlow.Acitivity{}
实际工作中我们会将很多逻辑上属于同一类的文件在物理上分成不同的目录这时建议修改命名空间为相同的命名空间。类类采用Pascal命名法public class UserService{}
类是对属性和方法的封装类有很多的种类跟数据库表对应的实体类处理业务逻辑的业务类提供扩展方法的扩展类接口层的数据传输类不同的种类可以约定俗成地进行一些名称的约束比如扩展类用 Extension 结尾、接口层的使用 Request、Response 结尾等等这样在阅读代码时就知道什么类的职责是什么。接口接口采用大写IPascal命名法public interface IUserService{}
方法方法采用Passcal命名法public string GetUserName(){}
方法的命名需要比较具体越抽象的名称越难以理解。例如InitData() 就是一个不太好的名称改成 InitConfiginfo() 会更好些。另外方法的命名在同一类型的语义下要保持一致在一些项目中看到查找类的方法有 GetXXX、QueryXXX、FindXXX 等等。五花八门的方式会提升阅读的成本。变量变量分为类变量、静态类变量、只读变量、静态只读变量、方法变量。类变量private string _userName;
类变量只能使用 private 修饰符如果需要暴漏出去或是给子类使用使用属性来进行封装。静态类变量、只读变量、静态只读变量private static readonly ResourceManager _resourceManager;
public static readonly IRouter Instance new MockRouter();
• 修饰符为 private: _ 驼峰命名法• 修饰符为 public: Pascal 命名法• 修饰符为 protectedPascal 命名法方法变量bool isCheck;
常量常量采用Pascal命名法public const string AuthorizationFilter Authorization Filter;
属性属性采用 Pascal 命名法public BasicApiContext DbContext { get; }
参数参数采用驼峰命名法public ListBizApp GetBizAppList(string userId,DeviceType deviceType)
注释规范注释是一把双刃剑当代码中存在大量的注释的时候我们第一反应会先看注释并会默认注释中写的内容是对的真实情况是注释往往会给我们错误的指导。有两个原因当代码逻辑发生变化时只修改了代码注释没有调整不同的人员都对注释进行编辑慢慢注释会变得和代码不匹配。Martin Fowler 在他的经典书籍 《重构》 中也提到过多的注释是一种坏味道的体现他认为当你觉得需要写注释的时候应该先想想是不是可以进行重构。那是不是程序中就不应该出现注释呢当然不是我认为下几种情况是需要写注释的时间紧急临时写的一些 ”烂代码“需要写注释说明原因一般需要加上 TODO 复杂算法类的方法可以写注释说明逻辑写的是偏底层的类库对外暴露的方法需要写注释调用方能方便在智能提示中显示如果你的能力写不好代码那还是先把注释写上吧。异常规范异常的目的是用来报告错误这也是他的唯一目的所以避免在返回值中来返回错误信息所有的地方都应该使用抛异常的方式来报告错误使用抛异常的方式可以防止错误的操作继续执行要能够预估到会出现什么异常知道是什么类型的异常才 Try 住做相关的处理最终用户友好和对开发者友好暴漏问题比隐藏问题要好隐藏问题只会导致更严重的问题。详细的异常处理可以参考之前的文章dotNET怎样处理程序中的异常理论篇dotNET怎样处理程序中的异常实战篇空行规范空行规范是一个很简单的规范就是在每个方法中代码应该按照不同逻辑的逻辑块进行分割显示虽然简单但如果不注意还是会对代码的阅读带来很大的障碍。下面看看 dotNET Core 的源码 CreateDefaultBuilder 方法public static IHostBuilder CreateDefaultBuilder(string[] args)
{var builder new HostBuilder();builder.UseContentRoot(Directory.GetCurrentDirectory());builder.ConfigureHostConfiguration(config {config.AddEnvironmentVariables(prefix: DOTNET_);if (args ! null){config.AddCommandLine(args);}});builder.ConfigureAppConfiguration((hostingContext, config) {var env hostingContext.HostingEnvironment;config.AddJsonFile(appsettings.json, optional: true, reloadOnChange: true).AddJsonFile($appsettings.{env.EnvironmentName}.json, optional: true, reloadOnChange: true);if (env.IsDevelopment() !string.IsNullOrEmpty(env.ApplicationName)){var appAssembly Assembly.Load(new AssemblyName(env.ApplicationName));if (appAssembly ! null){config.AddUserSecrets(appAssembly, optional: true);}}config.AddEnvironmentVariables();if (args ! null){config.AddCommandLine(args);}}).UseDefaultServiceProvider((context, options) {var isDevelopment context.HostingEnvironment.IsDevelopment();options.ValidateScopes isDevelopment;options.ValidateOnBuild isDevelopment;});return builder;
}
想想看上面代码中如果去掉空行会读起来是什么样的感受日志规范在一个完整的系统中日志非常的重要。在 dotNET Core 中自带了日志功能当然我们也可以使用第三方的 NLog、Serillog 等。这些日志框架都提供日志级别功能比如INFO、DEBUG、WARN 和 ERROR 等这些级别对程序出错时的排查非常有用所以在记录日志时一定不要都使用 INFO 或者都使用 ERROR 了。除了级别日志的类型有这么几类操作日志业务日志错误日志操作日志系统中所有的操作的都记录下来包括登录、数据的增删改等主要用来做审计数据异常操作时的追责等。随着时间的推移日志的数据量会越来越大所以需要考虑存储的方式比如阶段性地将历史日志进行存档。业务日志用户在界面中输入数据点击一个按钮程序中会进行一系列的处理最终返回结果给用户在这个过程中对一些关键的业务信息进行记录可以在系统出现问题时方便排查和追踪。错误日志错误日志的主要目的就是排错所以记录的信息一定要是对排错有帮助的信息尽可能地记录详细比如整个堆栈信息、调用链等。比如你去进行错误排查时发现记录的信息是”未将对象引用到对象的实例“你依然不知道错误的原因是什么。总结谈及代码的时候都会去聊架构、模式这些固然重要但编码习惯和规范也不可小视。一份产品的代码怎样才能变得越来越好这需要团队每个人成员共同的努力一个人掉链子很容易就形成破窗效应导致坏味道越来越多。写好的代码是每个有追求的技术人的使命和职责。希望本文对您有所帮助。
