一連のソースコードのコード仕様とスタイルを分析し、最適化コードをどのように改善するかを議論します.

7270 ワード

エンジニアリング実践の選択問題と結びつけて、私が選んだのはオープンソースのC++軽量レベルのネットワークフレームワークであるZLToolKitです.以下、与えられた要求に従って順次展開する(以下、GoogleのC++符号化仕様を基準とする):
1.プログラミング言語またはプロジェクトの特徴に基づき、ソースコードディレクトリ構造、ファイル名/クラス名/関数名/変数名などの命名、インタフェース定義規範とユニットテスト組織形式などの面でのやり方と特徴を分析する.  src :
src
|
|-- NetWork				#     
|	|-- Socket.cpp			#        ,   TCP   /   ,UDP   
|	|-- Socket.h
|	|-- sockutil.cpp		#       API     
|	|-- sockutil.h
|	|-- TcpClient.cpp		# TCP     ,                
|	|-- TcpClient.h
|	|-- TcpLimitedSession.h 	#    TcpSession,              
|	|-- TcpServer.h			# TCP      ,                    
|	|-- TcpSession.h 		# TCP            ,    TCP        
|
|-- Poller				#          
|	|-- EventPoller.cpp		#    ,               
|	|-- EventPoller.h
|	|-- Pipe.cpp			#        
|	|-- Pipe.h
|	|-- PipeWrap.cpp		#      ,windows  socket  
|	|-- SelectWrap.cpp		# select         
|	|-- SelectWrap.h
|	|-- Timer.cpp			#           
|	|-- Timer.h
|
|-- Thread				#     
|	|-- AsyncTaskThread.cpp		#         ,                  
|	|-- AsyncTaskThread.h
|	|-- rwmutex.h			#    ,     
|	|-- semaphore.h			#    ,       
|	|-- spin_mutex.h		#    ,         ,  /       
|	|-- TaskQueue.h			# functional     
|	|-- threadgroup.h		#    ,   boost
|	|-- ThreadPool.h		#    ,    functional         
|	|-- WorkThreadPool.cpp		#           (              )
|	|-- WorkThreadPool.h
|
|-- Util				#     
	|-- File.cpp			#   /      
	|-- File.h
	|-- function_traits.h		#   、lambda functional
	|-- logger.h			#     
	|-- MD5.cpp			# md5    
	|-- MD5.h
	|-- mini.h			# ini        ,  unix/windows      
	|-- NoticeCenter.h		#      ,                
	|-- onceToken.h			#   RAII    ,                 
	|-- ResourcePool.h		#               ,         
	|-- RingBuffer.h		#     ,       ,   GOP   
	|-- SqlConnection.cpp		# mysql   
	|-- SqlConnection.h
	|-- SqlPool.h			# mysql   ,       sql      
	|-- SSLBox.cpp			# openssl     ,   ssl    ,     
	|-- SSLBox.h
	|-- TimeTicker.h		#    ,            
	|-- util.cpp			#         ,       
	|-- util.h
	|-- uv_errno.cpp		#    libuv       ,       windows
	|-- uv_errno.h

  , 。
  : Google C++ , 。 , , ,
  : Google C++ , , , , —— , , (typedef), 。
  , 。
  
class SocketFlags{
public:
    SocketFlags(int flags):_flags(flags){};
    ~SocketFlags(){}
    int _flags;
};

class MutexWrapper {
public:
    MutexWrapper(bool enable){
        _enable = enable;
    }
    ~MutexWrapper(){}

    inline void lock(){
        if(_enable){
            _mtx.lock();
        }
    }
    inline void unlock(){
        if(_enable){
            _mtx.unlock();
        }
    }
private:
    bool _enable;
    Mtx _mtx;
};

typedef enum {
	Err_success = 0, //  
	Err_eof, //eof
	Err_timeout, //  
	Err_refused,//     
	Err_dns,//dns    
	Err_shutdown,//    
	Err_other = 0xFF,//    
} ErrCode;

関数名:標準に従って、通常の関数は単語の頭文字が大文字で、OpenFile()CheckFileName()などのコマンドニュアンスを使用します.アクセス関数や短いインライン関数は、set_などのアクセス変数と一致する小文字と下線を使用します.num_errors().このソースコードの一部の関数は、次のように宣言または呼び出されます.
  
void Socket::setOnErr(const onErrCB &cb);
void Socket::setOnAccept(const onAcceptCB &cb);

void Socket::setOnFlush(const onFlush &cb);

//  Socket     
void Socket::setOnBeforeAccept(const onBeforeAcceptCB &cb);

setsockopt(sockFd, IPPROTO_IP, IP_DROP_MEMBERSHIP,  (char*)&imr, sizeof (struct ip_mreq));

このソースコードにおける関数のネーミングの主な根拠となる時アルパカ式のネーミング法は,統一されていないが,時にはアルパカネーミング法に従い,時にはすべて小文字で,基準に合致しないことがわかる.
変数名:標準に従って、変数名はすべて小文字で、単語は下線で接続されています.例えば:int player_id; string table_name;特殊なのはクラスのメンバーの変数で、後に下線と普通の変数を区別して、player_よりname_   player_id_.このソースコードの変数の命名は基本的に小文字の要求に従っており、クラスの変数の命名も下線で普通の変数と区別されています.
  
class SockException: public std::exception {
public:
	SockException(ErrCode errCode = Err_success,
                   const string &errMsg = "",
                   int customCode = 0) {
        _errMsg = errMsg;
        _errCode = errCode;
        _customCode = customCode;

    }

    //    
	void reset(ErrCode errCode, const string &errMsg) {
		_errMsg = errMsg;
        _errCode = errCode;
	}
    //    
	virtual const char* what() const noexcept {
		return _errMsg.c_str();
	}
    //    
	ErrCode getErrCode() const {
		return _errCode;
	}
    //        
	operator bool() const{
		return _errCode != Err_success;
	}
    //         
    int getCustomCode () const{
        return _customCode;
    }
    //           
    void setCustomCode(int code) {
        _customCode = code;
    };
private:
	string _errMsg;
	ErrCode _errCode;
    int _customCode = 0;
};

 
2.コード仕様とスタイルの一般的な要件に合致する方法を列挙する
上記の分析によれば、
2.1このソースファイル名の命名規則はGoogleのC++規格に規定されていない——2.2このソースコードのタイプ名の命名規則は基本的にGoogleのC++規格に規定されている , , , —— , , (typedef)に し、 などは じ を する.
2.3このソース の は の に わない
2.4このソース は にGoogleのC++ に する
 
3.コードの さ、 さ、 さのない の に する と、 をさらに する を げる
 1.ソースコード の は なく、 がコードの20%を める をはるかに っており、 にマクロに する はほとんどありません. :コメントを します.マクロごとにコメントを します. の にコメントを して、その の を します.
 2.ソースコードの にはマクロ が いられているが,これはC++が しないやり である. :マクロ の わりにインライン を
 
4.コード とスタイルにおける のプログラミング またはプロジェクトの な をまとめる
コードスタイルは によって なり、 も なのは のコードスタイルの を することです.しかし、 くの の に っているため、 に するコード に づいてコードの な くことについて な をリストします.
 1. :
ファイル はすべて です. はすべて の で です. の はすべて です.メンバー を で_ をマークします.
 2.
を した 、 を します.
の が したら、 を します.
2つの に したブロック を にする
 3.スペース
の にスペースを さない(は ろに いています.),;の3つは に いている.すぐあとにスペースを さない
、 、 、 、ビット などの にスペースを ける
の にスペースを けない
 4.インデント
が しい は、インデントする はありません.コードの コードに する は、インデントする があります.
 5.コメント
の に して、 が すぎると まぐるしくなります
コードが い 、 に のネストがある は、 の わりにコメントを ける があります.
                ,