软件项目规范(1):README文件的基本写作规范

看Github的开源项目,我们都能看到README.md文件的身影。

有不少同学都喜欢将自己的项目上传到Git托管起来,但是总能发现一个问题:明明自己这个项目挺有市场的啊,怎么这个代码放上去,就显得很“非官方”!

通常,笔者都会从文件结构,代码风格等来入手,解决这个项目形象问题。

一个有价值的项目,不仅要从功能上体现出这个价值,也要从文本的风格,字里行间体现这个价值。有一说一,几块钱买来的代码和几百块钱、几千块钱买来的代码风格差距确实大。看着文件的形象,就要让消费者觉得这钱花得值。


对于陌生人而已,README是项目程序的黑盒之窗。读者大概会花30秒左右的时间,捕捉项目内容的要点。因此,README应该是介绍项目整体的一个概览。其实这个静态文件是有约定成俗的规范,这个规范也就是众多开源开发者相互磨合所形成的。

  1. 项目介绍

  2. 代码实现了什么功能?

  3. 该如何使用? (系统环境参数,部署要素,操作说明等)

  4. 代码组织架构是什么样的?(目录结构说明等)

  5. 版本更新内容摘要(这个非常重要)


如果你的README包括上面的内容,那么当使用者拿到代码,打开README后,基本就知道该如何下手了。

通常大家采用markdown语法来书写README文件(即README.md),当然也有txt(即README.txt)。笔者呢更偏向markdown语法,主要是因为它能进行简单的排版。

这里摆上我自己项目的README.md作为示例吧:

# 项目介绍
    本项目是针对代码工具链生成的DDS服务文件所建立的。

    能够将多个DDS服务文件进行合并,构建DDS基本服务端以及客户端程序框架。包含生成server.cpp、client.cpp、CMakeLists.txt

# 环境依赖


# 目录结构描述
    ├── ReadMe.md           // 帮助文档
    
    ├── AutoCreateDDS.py    // 合成DDS的 python脚本文件
    
    ├── DDScore             // DDS核心文件库,包含各版本的include、src、lib文件夹,方便合并
    
    │   ├── include_src     // 包含各版本的include、src文件夹
    
    │       ├── V1.0
    
    │           ├── include
    
    │           └── src
    
    │       └── V......
    
    │   └── lib             // 包含各版本的lib文件夹
    
    │       ├── arm64       // 支持arm64系统版本的lib文件夹
    
    │           ├── V1.0
    
    │           └── V......
    
    │       └── x86         // 支持x86系统版本的lib文件夹
    
    │           ├── V1.0
    
    │           └── V......
    
    ├── target              // 合成结果存放的文件夹
    
    └── temp                // 存放待合并的服务的服务文件夹

# 使用说明



# 版本内容更新
###### v1.0.0: 
    1.实现gen文件的拷贝、合并
    
    2.实现common文件的合并
    
    3.实现指定版本的include、src、lib文件的拷贝


实现的效果如下:

软件项目规范(1):README文件的基本写作规范_第1张图片

 这种风格是一种比较简约的风格。当开发者熟练后,也会逐渐形成自己的代码风格。

文本规范,对于一个程序员来说非常重要,可以说是一个程序员的形象,说“字如其人”毫不过分。在团队中,大家如果彼此熟悉,基本上是能通过这些字里行间的蛛丝马迹,知道这些文本或者代码出自哪位成员之手。

你可能感兴趣的:(markdown,readme)