每个较大的开源项目都有自己的风格指南: 关于如何为该项目编写代码的一系列约定 (有时候会比较武断). 当所有代码均保持一致的风格, 在理解大型代码库时更为轻松.
“风格” 的含义涵盖范围广, 从 “变量使用驼峰格式 (camelCase)” 到 “决不使用全局变量” 再到 “决不使用异常”. 英文版项目维护的是在 Google 使用的编程风格指南. 如果你正在修改的项目源自 Google, 你可能会被引导至 英文版项目页面, 以了解项目所使用的风格.
我们已经发布了五份 中文版 的风格指南:
Google C++ 风格指南
Google Objective-C 风格指南
Google Python 风格指南
Google JSON 风格指南
Google Shell 风格指南
中文版项目采用 reStructuredText 纯文本标记语法, 并使用 Sphinx 生成 HTML / CHM / PDF 等文档格式.
英文版项目还包含 cpplint - 一个用来帮助适应风格准则的工具, 以及 google-c-style.el, Google 风格的 Emacs 配置文件.
另外, 招募志愿者翻译 JavaScript Style Guide 以及 XML Document Format Style Guide, 有意者请联系 Yang.Y.
Software Release Practice HOWTO
Eric Steven Raymond
This HOWTO describes good release practices for Linux and other open-source projects. By following these practices, you will make it as easy as possible for users to build your code and use it, and for other developers to understand your code and cooperate with you to improve it.
This document is a must-read for novice developers. Experienced developers should review it when they are about to release a new project. It will be revised periodically to reflect the evolution of good-practice standards.
Table of Contents
Introduction
1.1. Why this document?
1.2. New versions of this documentGood patching practice
2.1. Do send patches, don’t send whole archives or files
2.2. Send patches against the current version of the code.
2.3. Don’t include patches for generated files.
2.4. Don’t send patch bands that just tweak version-control $-symbols.
2.5. Do use -c or -u format, don’t use the default (-e) format
2.6. Do include documentation with your patch
2.7. Do include an explanation with your patch
2.8. Do include useful comments in your code
2.9. Just one bugfix or new feature per patch.Good project- and archive- naming practice
3.1. Use GNU-style names with a stem and major.minor.patch numbering.
3.2. But respect local conventions where appropriate
3.3. Try hard to choose a name prefix that is unique and easy to typeGood licensing and copyright practice: the theory
4.1. Open source and copyrights
4.2. What qualifies as open sourceGood licensing and copyright practice: the practice
5.1. Make yourself or the FSF the copyright holder
5.2. Use a license conformant to the Open Source Definition
5.3. Don’t write your own license if you can possibly avoid it.
5.4. Make your license visible in a standard place.Good development practice
6.1. Choose the most portable language you can
6.2. Don’t rely on proprietary code
6.3. Build systems
6.4. Test your code before release
6.5. Sanity-check your code before release
6.6. Sanity-check your documentation and READMEs before release
6.7. Recommended C/C++ portability practicesGood distribution-making practice
7.1. Make sure tarballs always unpack into a single new directory
7.2. Have a README
7.3. Respect and follow standard file naming practices
7.4. Design for Upgradability
7.5. Provide checksumsGood documentation practice
8.1. Documentation formats
8.2. Good practice recommendationsGood communication practice
9.1. Announce to Freecode
9.2. Have a website
9.3. Host project mailing lists
9.4. Release to major archivesGood project-management practice