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

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

引子

对于稍有工作经验的程序员而言,或多或少都会关注到一个老生常谈的问题:代码风格(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),虽然你的代码风格一定与我的不同,但是相信指导准则应该是一致的,最后还是要强调一句:统一的代码风格最重要,哪怕这种风格很糟糕!

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏腾讯社交用户体验设计

ISUX Xcube智能一键生成H5

51220
来自专栏haifeiWu与他朋友们的专栏

复杂业务下向Mysql导入30万条数据代码优化的踩坑记录

从毕业到现在第一次接触到超过30万条数据导入MySQL的场景(有点low),就是在顺丰公司接入我司EMM产品时需要将AD中的员工数据导入MySQL中,因此楼主负...

29740
来自专栏怀英的自我修炼

考研英语-1-导学

英二图表作文要重视。总体而言,英语一会比英语二难点。不过就写作而言,英语二会比英语一有难度,毕竟图表作文并不好写。

11910
来自专栏前端桃园

知识体系解决迷茫的你

最近在星球里群里都有小伙伴说道自己对未来的路比较迷茫,一旦闲下来就不知道自己改干啥,今天我这篇文章就是让你觉得一天给你 25 个小时你都不够用,觉得睡觉都是浪费...

21740
来自专栏Ken的杂谈

【系统设置】CentOS 修改机器名

18130
来自专栏FSociety

SQL中GROUP BY用法示例

GROUP BY我们可以先从字面上来理解,GROUP表示分组,BY后面写字段名,就表示根据哪个字段进行分组,如果有用Excel比较多的话,GROUP BY比较类...

5.2K20
来自专栏钱塘大数据

理工男图解零维到十维空间,烧脑已过度,受不了啦!

让我们从一个点开始,和我们几何意义上的点一样,它没有大小、没有维度。它只是被想象出来的、作为标志一个位置的点。它什么也没有,空间、时间通通不存在,这就是零维度。

33730
来自专栏微信公众号:小白课代表

不只是软件,在线也可以免费下载百度文库了。

不管是学生,还是职场员工,下载各种文档几乎是不可避免的,各种XXX.docx,XXX.pptx更是家常便饭,人们最常用的就是百度文库,豆丁文库,道客巴巴这些下载...

44630
来自专栏腾讯大讲堂的专栏

白底黑字or黑底白字,眼睛更喜欢哪一个?

12310
来自专栏钱塘大数据

中国互联网协会发布:《2018中国互联网发展报告》

在2018中国互联网大会闭幕论坛上,中国互联网协会正式发布《中国互联网发展报告2018》(以下简称《报告》)。《中国互联网发展报告》是由中国互联网协会与中国互联...

13750

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励