看Github的开源项目，我们都能看到README.md文件的身影。
有不少同学都喜欢将自己的项目上传到Git托管起来，但是总能发现一个问题：明明自己这个项目挺有市场的啊，怎么这个代码放上去，就显得很“非官方”！
通常，笔者都会从文件结构，代码风格等来入手，解决这个项目形象问题。
一个有价值的项目，不仅要从功能上体现出这个价值，也要从文本的风格，字里行间体现这个价值。有一说一，几块钱买来的代码和几百块钱、几千块钱买来的代码风格差距确实大。看着文件的形象，就要让消费者觉得这钱花得值。
对于陌生人而已，README是项目程序的黑盒之窗。读者大概会花30秒左右的时间，捕捉项目内容的要点。因此，README应该是介绍项目整体的一个概览。其实这个静态文件是有约定成俗的规范，这个规范也就是众多开源开发者相互磨合所形成的。
-
项目介绍
-
代码实现了什么功能?
-
该如何使用? (系统环境参数，部署要素，操作说明等)
-
代码组织架构是什么样的?（目录结构说明等）
-
版本更新内容摘要（这个非常重要）
如果你的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文件的拷贝
实现的效果如下：
?这种风格是一种比较简约的风格。当开发者熟练后，也会逐渐形成自己的代码风格。
文本规范，对于一个程序员来说非常重要，可以说是一个程序员的形象，说“字如其人”毫不过分。在团队中，大家如果彼此熟悉，基本上是能通过这些字里行间的蛛丝马迹，知道这些文本或者代码出自哪位成员之手。
