Unity 之命名规范(一)

最新推荐文章于 2024-04-07 01:28:05 发布

weixin_34320724

最新推荐文章于 2024-04-07 01:28:05 发布

阅读量743

点赞数

文章标签：游戏 c#

原文链接：https://yq.aliyun.com/articles/666181

版权

一个优良的架构，个人认为不仅仅体现在设计的思想结构上，代码的命名规范也是至关重要的，一段的优雅的代码会让人看着赏心悦目，一个结构混乱，命名随意的代码会让人狂抓，尤其是在项目交接的时候，如果项目属于后者，那我只能说祝你好运了~
微软的C#是结合众多开发者心血的结晶，但是C# 的命名看上去貌似就是一个人写的，每一行代码都遵循相同的准则。所以说，一个实力出众的公司都这么做，那么自己还有什么理由乱写呢？编写的代码，不仅仅是自己查阅修改，别人也能会来查阅、学习，本着互联网精神,我们更应该严格要求自己，让代码规范深深的烙印在我们潜意识中~

最近也读到一篇文章 浅谈软件工程师的代码素养，【素养】这个词个人感觉在恰到不过了，素养二字不仅仅体现对技能的要求，又体现出一个软件工程师对自身的高标准和完美代码的追求（虽然这个世界上不存在完美的事情）~

因为Unity 2018.1 ：停止对MonoDevelop-Unity的支持，所以下面谈到的命名方式是以微软官方的命名方式为参考

有错误或者不准确的地方欢迎留言指正

风格指南

Tabs&缩进

Tab 字符(\0x09) 不应在代码中使用。所有缩进应该用4个空格字符完成。（换句话说，一个Tab键的缩进应该用4个空格来代替）

Bracing

打开花括号总是应该在开始块的语句后面的行首。大括号内容应缩进4个空格。例如：

        if (SomeExpression)
        {
            DoSomething();
        }
        else
        {
            DoSomethingElse();
        }

case”语句应该像switch语句一样缩进：

        switch (SomeNumber)
        {

            case 0:
                DoSomething();
                break;
            case 1:
                DoSomethingElse();
                break;
            case 2:
                {
                    int n = 1;
                    DoAnotherThing(n);
                }
                break;
        }

大括号永远不应被视为可选项。即使对于单个语句块，您也应该始终使用大括号。这增加了代码的可读性和可维护性。(换句话说：就算一行函数也给老子加上大括号！！！)

for (int i=0; i<100; i++) { DoSomething(i); }

单行语句

单行语句可以有在同一条线上开始和结束的括号。

public class Foo
{
   int bar;
   public int Bar
   {
      get { return bar; }
      set { bar = value; }
   }
}

据建议，所有的控制结构（if, while, for, etc）使用大括号，但它不是必需的。

评论应该用来描述意图，算法概述和/或逻辑流程。如果仅通过阅读评论，作者以外的人可以理解功能的预期行为和一般操作，那将是理想的。虽然没有最低评论要求，当然也有一些非常小的程序根本不需要评论，但希望大多数程序都会有反映程序员意图和方法的评论。（就是说说这些函数干什么的，为什么这么写，当时怎么想的）

版权声明

每个文件都应以版权声明开始。为了避免文档评论构建中出现错误，您不希望使用三斜杠文档评论，但使用XML可以使评论容易在未来取代。最终文本将因产品而异（您应该联系法律确切的文字），但应该类似于：

//-----------------------------------------------------------------------
// <copyright file="ContainerControl.cs" company="Microsoft">
//     Copyright (c) Microsoft Corporation.  All rights reserved.
// </copyright>
//-----------------------------------------------------------------------

文件评论 (可以理解为代码注释)

所有方法都应该使用XML文档注释。对于内部开发者评论，应该使用<devdoc>标签

public class Foo 
{
/// <summary>Public stuff about the method</summary>
/// <param name=”bar”>What a neat parameter!</param>
/// <devdoc>Cool internal stuff!</devdoc>
///
public void MyMethod(int bar) { … }
}

UNDONE§有一个大文档，里面有我们应该使用的所有评论标签......那是哪里？

评论风格

该//注释标记（两个斜杠）风格应该在大多数情况下使用。在可能的情况下，将注释放在代码上方而不是旁边。这里有些例子：

//这是WebClient通过代理工作所必需的
GlobalProxySelection.Select = new WebProxy("http://itgproxy");

//创建访问Internet资源的对象
WebClient myClient = new WebClient();

当空间允许时，注释可以放在行的末尾

public class SomethingUseful 
{
    private int          itemHash;            // instance member
    private static bool  hasDoneSomething;    // static member
}

间距

空间通过减少代码密度来提高可读性。以下是在代码中使用空格字符的一些准则：

请在函数参数之间逗号后使用单个空格。

Right:          Console.In.Read(myChar, 0, 1);
Wrong:       Console.In.Read(myChar,0,1);

不要在圆括号和函数参数后面使用空格

Right:          CreateFoo(myChar, 0, 1)
Wrong:       CreateFoo( myChar, 0, 1 )

不要在函数名称和括号之间使用空格。

Right:          CreateFoo()
Wrong:       CreateFoo ()

不要在括号内使用空格

Right:    x = dataArray[index];
Wrong:       x = dataArray[ index ];

在流控制语句之前使用单个空格

Right:          while (x == y)
Wrong:       while(x==y)

在比较运算符之前和之后使用单个空格

Right:          if (x == y)
Wrong:       if (x==y)

命名

遵循内部和外部成员的所有.NET Framework设计指南。其中的要点包括：

不要使用匈牙利符号
不要为成员变量（，m，s_等）使用前缀。如果你想区分本地变量和成员变量，你应该在C＃中使用“this。”和“me。“在VB.NET中
请使用成员变量驼峰规则
请使用camelCasing作为参数
请使用局部变量驼峰规则
请使用PascalCasing的函数，属性，事件和类名
接口名称前缀加“I”
不要在枚举，类或委托前加任何字母

扩展公共规则（没有匈牙利语，没有成员变量的前缀等）的原因是产生一致的源代码外观。另外一个目标是拥有干净可读的来源。代码可读性应该是主要目标。

命名约定

Interop类

Interop包装器（DllImport语句）的类应遵循下面的命名约定：

NativeMethods 不抑制非托管代码属性，这些方法可以在任何地方使用，因为将执行堆栈审核。
UnsafeNativeMethods 禁止非托管代码属性。这些方法具有潜在的危险性，任何这些方法的调用者都必须进行全面的安全检查，以确保使用安全并受到保护，因为不会执行堆栈审核。
SafeNativeMethods 禁止非托管代码属性。这些方法是安全的，并且可以相当安全地使用，即使不执行堆栈审核，调用者也不需要进行全面的安全性评估

class NativeMethods 
{
   private NativeMethods() {}

   [DllImport(“user32”)]
   internal static extern void FormatHardDrive(string driveName);
}

[SuppressUnmanagedCode]
class UnsafeNativeMethods 
{
   private UnsafeNativeMethods() {}

   [DllImport(“user32”)]
   internal static extern void CreateFile(string fileName);
}

[SuppressUnmanagedCode]
class SafeNativeMethods 
{
   private SafeNativeMethods() {}

   [DllImport(“user32”)]
   internal static extern void MessageBox(string text);
}

所有互操作类必须是私有的，所有方法都必须是内部的。另外应该提供一个私有构造函数来防止实例化。

文件组织

源文件应该只包含一个公共类型，尽管允许多个内部类
源文件应该被赋予文件中公共类的名称
目录名称应该遵循该类的命名空间

例如，我期望在"System\Windows\Forms\Control.cs"找到公共类“System.Windows.Forms.Control”

类成员应该按照字母顺序排列，并分组成部分（字段，构造函数，属性，事件，方法，专用接口实现，嵌套类型）
using语句应该在名称空间声明中

namespace MyNamespace
{

    using System;

    public class MyClass : IFoo
    {

        // fields
        int foo;

        // constructors
        public MyClass() { … }

        // properties
        public int Foo { get { … } set { … } }

        // events
        public event EventHandler FooChanged { add { … } remove { … } }

        // methods
        void DoSomething() { … }
        void FindSomethind() { … }

        //private interface implementations
        void IFoo.DoSomething() { DoSomething(); }

        // nested types
        class NestedType { … }

    }

}

weixin_34320724

关注

0
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
Unity 之命名规范(一)

一个优良的架构，个人认为不仅仅体现在设计的思想结构上，代码的命名规范也是至关重要的，一段的优雅的代码会让人看着赏心悦目，一个结构混乱，命名随意的代码会让人狂抓，尤其是在项目交接的时候，如果项目属于后者，那我只能说祝你好运了~微软的C#是结合众多开发者心血的结晶，但是C# 的命名看上去貌似就是一个人写的，每...
复制链接

扫一扫