Replace convension words

welkineins · Jan 27, 2016 · b999977 · b999977
1 parent d5546a7
commit b999977
Show file tree

Hide file tree

Showing 12 changed files with 365 additions and 365 deletions.
diff --git a/conf.py b/conf.py
@@ -3,7 +3,7 @@
 
 
 import sys, os
-project = u'Google 開源項目風格指南'
+project = u'Google 開源專案風格指南'
 copyright = u''
 version = u''
 release = u''
@@ -26,13 +26,13 @@
 
 # otherwise, readthedocs.org uses their theme by default, so no need to specify it
 
-html_title = u'Google 開源項目風格指南'
+html_title = u'Google 開源專案風格指南'
 htmlhelp_basename = 'google-styleguide'
 html_add_permalinks = None
 
 file_insertion_enabled = False
 latex_documents = [
-  ('index', 'google-styleguide.tex', u'Google 開源項目風格指南',
+  ('index', 'google-styleguide.tex', u'Google 開源專案風格指南',
    u'', 'manual'),
 ]
 
@@ -41,7 +41,7 @@
 context = {
     'MEDIA_URL': "/media/",
     'slug': 'google-styleguide',
-    'name': u'Google 開源項目風格指南',
+    'name': u'Google 開源專案風格指南',
     'analytics_code': 'None',
 }
 

diff --git a/google-cpp-styleguide/classes.rst b/google-cpp-styleguide/classes.rst
diff --git a/google-cpp-styleguide/comments.rst b/google-cpp-styleguide/comments.rst
diff --git a/google-cpp-styleguide/end.rst b/google-cpp-styleguide/end.rst
@@ -1,12 +1,12 @@
-10. 結束語
+10. 結語
 ~~~~~~~~~~~~~~~~
 
 .. tip::
 
     運用常識和判斷力, 並 *保持一致*.
 
-編輯代碼時, 花點時間看看項目中的其它代碼, 並熟悉其風格. 如果其它代碼中 ``if`` 語句使用空格, 那麼你也要使用. 如果其中的註釋用星號 (*) 圍成一個盒子狀, 你同樣要這麼做.
+編輯程式碼時, 花點時間看看專案中的其它代碼, 並熟悉其風格. 如果其它代碼中 ``if`` 語句使用空格, 那麼你也要使用. 如果其中的註解用星號 (*) 圍成一個盒子狀, 你同樣要這麼做.
 
-風格指南的重點在於提供一個通用的編程規範, 這樣大家可以把精力集中在實現內容而不是表現形式上. 我們展示了全局的風格規範, 但局部風格也很重要, 如果你在一個文件中新加的代碼和原有代碼風格相去甚遠, 這就破壞了文件本身的整體美觀, 也影響閱讀, 所以要盡量避免.
+風格指南的重點在於提供一個通用的編程規範, 這樣大家可以把精力集中在實現內容而不是表現形式上. 我們展示了全局的風格規範, 但局部風格也很重要, 如果你在一個文件中新加的程式碼和原有代碼風格相去甚遠, 這就破壞了文件本身的整體美觀, 也影響閱讀, 所以要盡量避免.
 
-好了, 關於編碼風格寫的夠多了; 代碼本身才更有趣. 盡情享受吧!
+好了, 關於編碼風格寫的夠多了; 程式碼本身才更有趣. 盡情享受吧!
diff --git a/google-cpp-styleguide/exceptions.rst b/google-cpp-styleguide/exceptions.rst
@@ -3,43 +3,43 @@
 
 前面說明的編程習慣基本都是強制性的. 但所有優秀的規則都允許例外, 這裡就是探討這些特例.
 
-9.1. 現有不合規範的代碼
+9.1. 現有不合規範的程式碼
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. tip::
 
-    對於現有不符合既定編程風格的代碼可以網開一面.
+    對於現有不符合既定編程風格的程式碼可以網開一面.
 
-當你修改使用其他風格的代碼時, 為了與代碼原有風格保持一致可以不使用本指南約定. 如果不放心可以與代碼原作者或現在的負責人員商討, 記住, *一致性* 包括原有的一致性.
+當你修改使用其他風格的程式碼時, 為了與代碼原有風格保持一致可以不使用本指南約定. 如果不放心可以與代碼原作者或現在的負責人員商討, 記住, *一致性* 包括原有的一致性.
 
 .. _windows-code:
 
-9.2. Windows 代碼
+9.2. Windows 程式碼
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. tip::
 
-    Windows 程序員有自己的編程習慣, 主要源於 Windows 頭文件和其它 Microsoft 代碼. 我們希望任何人都可以順利讀懂你的代碼, 所以針對所有平台的 C++ 編程只給出一個單獨的指南.
+    Windows 開發者有自己的編程習慣, 主要源於 Windows 標頭檔和其它 Microsoft 程式碼. 我們希望任何人都可以順利讀懂你的代碼, 所以針對所有平台的 C++ 編程只給出一個單獨的指南.
 
 如果你習慣使用 Windows 編碼風格, 這兒有必要重申一下某些你可能會忘記的指南:
 
-    - 不要使用匈牙利命名法 (比如把整型變量命名成 ``iNum``). 使用 Google 命名約定, 包括對源文件使用 ``.cc`` 擴展名.
+    - 不要使用匈牙利命名法 (比如把整型變數命名成 ``iNum``). 使用 Google 命名約定, 包括對源文件使用 ``.cc`` 擴展名.
 
     - Windows 定義了很多原生類型的同義詞 (YuleFox 注: 這一點, 我也很反感), 如 ``DWORD``, ``HANDLE`` 等等. 在調用 Windows API 時這是完全可以接受甚至鼓勵的. 但還是盡量使用原有的 C++ 類型, 例如, 使用 ``const TCHAR *`` 而不是 ``LPCTSTR``.
 
     - 使用 Microsoft Visual C++ 進行編譯時, 將警告級別設置為 3 或更高, 並將所有 warnings 當作 errors 處理.
 
-    - 不要使用 ``#pragma once``; 而應該使用 Google 的頭文件保護規則. 頭文件保護的路徑應該相對於項目根目錄 (Yang.Y 注: 如 ``#ifndef SRC_DIR_BAR_H_``, 參考 :ref:`#define 保護 <define_guard>` 一節).
+    - 不要使用 ``#pragma once``; 而應該使用 Google 的標頭檔保護規則. 標頭檔保護的路徑應該相對於專案根目錄 (Yang.Y 注: 如 ``#ifndef SRC_DIR_BAR_H_``, 參考 :ref:`#define 保護 <define_guard>` 一節).
 
-    - 除非萬不得已, 不要使用任何非標準的擴展, 如 ``#pragma`` 和 ``__declspec``. 允許使用 ``__declspec(dllimport)`` 和 ``__declspec(dllexport)``; 但你必須通過宏來使用, 比如 ``DLLIMPORT`` 和 ``DLLEXPORT``, 這樣其他人在分享使用這些代碼時很容易就去掉這些擴展.
+    - 除非萬不得已, 不要使用任何非標準的擴展, 如 ``#pragma`` 和 ``__declspec``. 允許使用 ``__declspec(dllimport)`` 和 ``__declspec(dllexport)``; 但你必須通過宏來使用, 比如 ``DLLIMPORT`` 和 ``DLLEXPORT``, 這樣其他人在分享使用這些程式碼時很容易就去掉這些擴展.
 
 在 Windows 上, 只有很少的一些情況下, 我們可以偶爾違反規則:
 
     - 通常我們 :ref:`禁止使用多重繼承 <multiple-inheritance>`, 但在使用 COM 和 ATL/WTL 類時可以使用多重繼承. 為了實現 COM 或 ATL/WTL 類/接口, 你可能不得不使用多重實現繼承.
 
-    - 雖然代碼中不應該使用異常, 但是在 ATL 和部分 STL（包括 Visual C++ 的 STL) 中異常被廣泛使用. 使用 ATL 時, 應定義 ``_ATL_NO_EXCEPTIONS`` 以禁用異常. 你要研究一下是否能夠禁用 STL 的異常, 如果無法禁用, 啟用編譯器異常也可以. (注意這只是為了編譯 STL, 自己代碼裡仍然不要含異常處理.)
+    - 雖然程式碼中不應該使用異常, 但是在 ATL 和部分 STL（包括 Visual C++ 的 STL) 中異常被廣泛使用. 使用 ATL 時, 應定義 ``_ATL_NO_EXCEPTIONS`` 以禁用異常. 你要研究一下是否能夠禁用 STL 的異常, 如果無法禁用, 啟用編譯器異常也可以. (注意這只是為了編譯 STL, 自己代碼裡仍然不要含異常處理.)
 
-    - 通常為了利用頭文件預編譯, 每個每個源文件的開頭都會包含一個名為 ``StdAfx.h`` 或 ``precompile.h`` 的文件. 為了使代碼方便與其他項目共享, 避免顯式包含此文件 (``precompile.cc``), 使用 ``/FI`` 編譯器選項以自動包含.
+    - 通常為了利用標頭檔預編譯, 每個每個源文件的開頭都會包含一個名為 ``StdAfx.h`` 或 ``precompile.h`` 的文件. 為了使程式碼方便與其他專案共享, 避免顯式包含此文件 (``precompile.cc``), 使用 ``/FI`` 編譯器選項以自動包含.
 
-    - 資源頭文件通常命名為 ``resource.h``, 且只包含宏的, 不需要遵守本風格指南.
+    - 資源標頭檔通常命名為 ``resource.h``, 且只包含宏的, 不需要遵守本風格指南.