一个游戏程序员的代码书写观(二)

引子

对于稍有工作经验的程序员而言,或多或少都会关注到一个老生常谈的问题:代码风格(ProgrammingStyle)，而这个话题可能也是程序员间争论最多的话题之一，不过争论归争论，一个原则大家基本都还是认同的：风格保持统一

网上对于这个话题自然也有大量的信息，其中最出名的还是Google的代码风格指南，里面详细记录了很多语言风格的细节，有兴趣的朋友估计也都看过了，这里不想做文字搬运工，仅想根据自己的一点经验来总结一篇极简的ProgrammingStyle

文件头注释

见过很多开源项目的文件头注释，基本都是一大段版权说明(Copyright)，随便贴一个：

//-----------------------------------------------------------------------------
// Copyright (c) Time Company etc.
//
// Permission is hereby granted, free of charge, to any person obtaining a copy
// of this software and associated documentation files (the "Software"), to
// deal in the Software without restriction, including without limitation the
// rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
// sell copies of the Software, and to permit persons to whom the Software is
// furnished to do so, subject to the following conditions:
//
// The above copyright notice and this permission notice shall be included in
// all copies or substantial portions of the Software.
//
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
// FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
// IN THE SOFTWARE.
//-----------------------------------------------------------------------------

简单一点的，则是列出了文件名、文件创建时间、公司名称以及文件创建者等信息，当然，文件头为空的情况也遇到过。
关于添加版权说明的必要性，个人觉得可能是License的原因，不过本着KISS原则，个人还是倾向于省略一切可以省略的注，所以在一般情况下，我选择去除重复的版权说明注释，至于后面提到的那种列出文件名、创建时间等信息的注释方式，
个人觉得基本就属于无用注释了，不仅没有什么实用信息，反而会增加阅读代码的“视力”负担，应该第一时间去除，个人觉得文件头注释的真正意义还是在于帮助阅读者理解代码，综合考虑下来，添加一个文件代码的简要信息和维护者的信息是我目前对于文件头注释的选择：

// desc ugui rich text game object manager, simple object pool implementation
// maintainer hugoyu

(代码来自自己的一个开源项目)

类名方法名与变量名

这个话题没有标准答案，还是那句话：统一就好。不过OOP下还是驼峰式命名法较为常见，自己也采用了这种命名方法，一般类名及接口方法名都是首字母大写，非接口方法名及变量名则采用首字母小写，至于业界知名的匈牙利命名法，建议大家还是忘记他吧，现在任何一个合格的IDE都已经能准确的提示变量的类型了，不再需要我们画蛇添足，不过现在自己还是习惯会为成员名加上前缀m_，为的是最快的分辨普通变量和成员变量

public class UGUIGameObjectManager : SimpleSingleton<UGUIGameObjectManager>, IGameObjectManager
{
    // ...

    ObjectPool GetTextPool(string style)
    {
        if (m_textPools.ContainsKey(style))
        {
            return m_textPools[style];
        }
        else
        {
            var textPool = new ObjectPool(OnSpawnText, OnReleaseText);
            m_textPools.Add(style, textPool);

            return textPool;
        }
    }

    // ...
}

(代码来自自己的一个开源项目)

缩进空格与空行

缩进一般采用四个空格的方式，不采用Tab是因为移植性的原因，至于为什么是四个空格而不是两个空格则属于个人偏好了，因为个人觉得四个空格让代码显得不拥挤、更清晰，而空行，个人会用在代码逻辑分段的地方，譬如不同方法的定义间、方法实现中的算法流程中等等。

public GameObject CreateText(string text, string style, Action clickHandler)
{
    var textGOPrefab = GetTextPrefab(style);
    if (textGOPrefab)
    {
        // create text game object
        var textPool = GetTextPool(style);
        var textGO = textPool.Spawn(textGOPrefab);
        var textComp = textGO.GetComponent<Text>();
        if (!textComp)
        {
            Debug.LogError("[UGUIGameObjectManager]Error to get Text component : " + style);
            textPool.Release(textGO);
            return null;
        }

        // set text game object
        textComp.text = text;

        // handler click handler
        var uguiClickHandler = RichTextUtil.GetOrAddComponent<UGUIClickHandler>(textGO);
        Debug.Assert(uguiClickHandler != null);
        uguiClickHandler.ClearHandlers();
        if (clickHandler != null)
        {
            uguiClickHandler.AddHandler(clickHandler);
        }

        return textGO;
    }

    return null;
}

(代码来自自己的一个开源项目)

代码注释

最好的注释就是没有注释，说白了就是代码的自注释，这就要求我们将代码书写的尽量清晰易懂，但是在实际的开发中，因为算法本身的复杂性或者代码优化等等原因，或多或少都会让代码变得越来越晦涩难懂，这时适当的注释便非常有必要性了，但是代码注释又很容易走向另一个极端：多余注释。
在不少项目里都看到这样类似的代码注释：

// increment i
++i;

这里的注释只说明了下代码的字面意义，没有什么实际用途，实际开发中我们应该尽量避免这种没有意义的多余注释，不过现实中还存在比多余注释更不好的情况，那就是错误的注释！
仍然考虑上面的代码，开发者因为某些原因做了代码改动，但是却没有修改注释：

// increment i
--i;

代码的阅读者将对此产生困惑：到底是注释不对还是代码有误呢？如果下次你在项目中遇到了这种情况，请马上修正他，哪怕直接删除注释也比错误的注释要好。

总结

以上便是一份简单的个人代码风格总结，总的原则其实还是保持简单(KISS)，虽然你的代码风格一定与我的不同，但是相信指导准则应该是一致的，最后还是要强调一句：统一的代码风格最重要，哪怕这种风格很糟糕！