[訳]Google C++プログラミングスタイルガイド(八)[完]
3008 ワード
原文アドレス:Google C++Style Guideルールの例外 前述した符号化習慣は基本的に強制的であるが,すべての優れた規則は例外を許容する.
1.既存の不統一コード(Existing Non-conformant Code)
既定のプログラミングスタイルに合わない既存のコードについては、ネットワークを開くことができます.
他のスタイルを使用するコードを変更する場合は、コードの元のスタイルと一致するように、このガイドの規則を使用しないことができます.コードの原作者や現在の担当者と相談して、一貫性には既存の一貫性が含まれていることを覚えておいてください.
1.Windowsコード(Windowsコード)
Windowsプログラマーは、主にWindowsのヘッダファイルやその他のMicrosoftコードに由来する独自の符号化習慣を持っています.私たちは誰もがあなたのコードをスムーズに読むことができることを望んでいるので、すべてのプラットフォームのC++符号化に対して個別の指導案を提供します.
Windowsのエンコードスタイルをずっと使っている場合は、忘れてしまうかもしれないガイドラインを再確認する必要があります(注、私はどのように洗脳されているように感じますか:D):
1)ハンガリーの命名法(Hungarian notation、例えば整数変数を
2)Windowsは、
3)Microsoft Visual C++を使用してコンパイルする場合、警告レベルを3以上に設定し、すべてのwarningsをerrorsとして処理する.
4)
5)やむを得ない限り、
Windowsでは、たまに守らないルールはごくわずかです.
1)通常、多重継承の使用は禁止されていますが、COMクラスとATL/WTLクラスを使用する場合は多重継承を使用できます.COMクラスまたはATL/WTLクラスおよびそのインタフェースを実行する場合は多重継承を使用できます.
2)コードに異常を使用すべきではないが、ATLと部分STL(Visual C++を含むSTL)で異常が広く使用されている.ATLを使用する場合は、
3)通常、各プロジェクトの各ソースファイルには、
4)通常、チームワーク 常識を参考にして、一致を保つ.
コードを編集するときは、プロジェクトの他のコードを見てスタイルを決定します.他のコード
プログラミングスタイルガイドの使用のポイントは、表現形式ではなくコンテンツの実現に集中できる共通の符号化規範を提供することです.私たちはグローバルなスタイル規範を提供しましたが、局所的なスタイルも重要です.もしあなたが1つのファイルに追加したコードが元のコードスタイルとはかけ離れていると、ファイル自体の全体的な美観を破壊し、読書にも影響を与えるので、できるだけ避けなければなりません.
よし、符号化スタイルについて書く差は多くないし、コード自体がもっと面白いから、楽しんでください.
Benjy WeinbergerCraig SilversteinGregory EitzmannMark MentovaiTashana Landray
______________________________________
最终的には、2周间にわたって、仕事の関系で怠っていたが、やっと虎头蛇尾ではなく(少なくとも私の态度は非常にまじめです:D)、あなたに役立つかどうかにかかわらず、私にとって、少なくとも前に知っていた知识を温习して、前に知らなかった知识を学んだ.
ちょうどこの2,3日はまだ緊張していないので、急いでひっくり返して、仕事を始めます......
1.既存の不統一コード(Existing Non-conformant Code)
既定のプログラミングスタイルに合わない既存のコードについては、ネットワークを開くことができます.
他のスタイルを使用するコードを変更する場合は、コードの元のスタイルと一致するように、このガイドの規則を使用しないことができます.コードの原作者や現在の担当者と相談して、一貫性には既存の一貫性が含まれていることを覚えておいてください.
1.Windowsコード(Windowsコード)
Windowsプログラマーは、主にWindowsのヘッダファイルやその他のMicrosoftコードに由来する独自の符号化習慣を持っています.私たちは誰もがあなたのコードをスムーズに読むことができることを望んでいるので、すべてのプラットフォームのC++符号化に対して個別の指導案を提供します.
Windowsのエンコードスタイルをずっと使っている場合は、忘れてしまうかもしれないガイドラインを再確認する必要があります(注、私はどのように洗脳されているように感じますか:D):
1)ハンガリーの命名法(Hungarian notation、例えば整数変数を
iNum
と定義する)を使用しないで、ソースファイルに対して.cc
拡張子を使用することを含むGoogleの命名規則を使用しないでください.2)Windowsは、
DWORD
、HANDLE
など、既存の組み込みタイプの同義語を多く定義しており、Windows APIを呼び出す際には完全に受け入れられ、励ましられるが、const TCHAR *
ではなくLPCTSTR
を使用するなど、できるだけ元のC++タイプを使用する.3)Microsoft Visual C++を使用してコンパイルする場合、警告レベルを3以上に設定し、すべてのwarningsをerrorsとして処理する.
4)
#pragma once
を使用しない.包含保護として、C++標準を使用して保護を含み、保護を含むファイルパスはプロジェクトツリーの最上位層に含まれる(#include<prj_name/public/tools.h>
).5)やむを得ない限り、
#pragma
および__declspec
のような非標準的な拡張子は使用されず、__declspec(dllimport)
および__declspec(dllexport)
を使用することができるが、DLLIMPORT
およびDLLEXPORT
などのマクロを使用して、他の人がこれらのコードを共有する際にこれらの拡張子を放棄しやすいようにしなければならない.Windowsでは、たまに守らないルールはごくわずかです.
1)通常、多重継承の使用は禁止されていますが、COMクラスとATL/WTLクラスを使用する場合は多重継承を使用できます.COMクラスまたはATL/WTLクラスおよびそのインタフェースを実行する場合は多重継承を使用できます.
2)コードに異常を使用すべきではないが、ATLと部分STL(Visual C++を含むSTL)で異常が広く使用されている.ATLを使用する場合は、
_ATL_NO_EXCEPTIONS
を定義して異常を遮断すべきである.STLの異常も遮断するかどうかを検討し、遮断しない場合はコンパイラをオンにしてもよい.これはSTLをコンパイルするためだけであることに注意してください.異常処理を含むコードを自分で書かないでください.3)通常、各プロジェクトの各ソースファイルには、
StdAfx.h
またはprecompile.h
というヘッダファイルが含まれており、ヘッダファイルのプリコンパイルを容易にするために、コードが他のプロジェクトと共有されやすいように、このファイル(precompile.cc
を除く)が明示的に含まれないように、コンパイラオプション/FI
を使用して自動的に含まれる.4)通常、
resource.h、
という名前のリソースヘッダファイルは、このスタイルガイドにこだわる必要はありません.コードを編集するときは、プロジェクトの他のコードを見てスタイルを決定します.他のコード
if
文でスペースが使用されている場合は、あなたも使用します.注釈がアスタリスク(*
)で箱状に囲まれている場合、あなたもそうします./**********************************
* Some comments are here.
* There may be many lines.
**********************************/
プログラミングスタイルガイドの使用のポイントは、表現形式ではなくコンテンツの実現に集中できる共通の符号化規範を提供することです.私たちはグローバルなスタイル規範を提供しましたが、局所的なスタイルも重要です.もしあなたが1つのファイルに追加したコードが元のコードスタイルとはかけ離れていると、ファイル自体の全体的な美観を破壊し、読書にも影響を与えるので、できるだけ避けなければなりません.
よし、符号化スタイルについて書く差は多くないし、コード自体がもっと面白いから、楽しんでください.
Benjy WeinbergerCraig SilversteinGregory EitzmannMark MentovaiTashana Landray
______________________________________
最终的には、2周间にわたって、仕事の関系で怠っていたが、やっと虎头蛇尾ではなく(少なくとも私の态度は非常にまじめです:D)、あなたに役立つかどうかにかかわらず、私にとって、少なくとも前に知っていた知识を温习して、前に知らなかった知识を学んだ.
ちょうどこの2,3日はまだ緊張していないので、急いでひっくり返して、仕事を始めます......