関数式プログラミングの重要性を深く理解します.

最近は『コード大全2』を読み始めましたが、「多くの良いプログラミング方法は脳の灰質の負担を軽減できます」という一節を紹介しました.そこで、『＊会社C言語プログラミング規範』を探して読んでみました.昼には多くの収穫があります.その中でいくつかの点に言及して、この記録を書いてください.
本文では関数に対して以下の部分の要求があります.

再入力可能関数は、共有変数の使用を避けるべきであり、使用が必要であれば、相互反発手段(オフ、信号量)によって保護されるべきである.

関数は、グローバル変数、静的局所変数、およびIO動作の使用を避けるべきであり、避けられないところで集中的に使用すべきである.

関数のパラメータの個数は5つを超えません.

ソースファイルの範囲内で宣言および定義されたすべての関数は、外部から見られない限り、staticキーを追加すべきである.

本文のヘッダファイルの部分に対する要求:

ヘッダファイルにインターフェースを配置するのに適した声明は、不適切な配置で実現される.

ヘッダファイルの循環依存を禁止します.

ヘッダのファイルは自分で含めるべきです.

以上のような点を出して、これから書く時は注意してください.

グローバル変数を関数にカプセル化しました.

プロジェクトではしばしば構造タイプ(構造体)を使用して、大域変数を異なる関数で使用するために定義します.頭ファイルで自分の構造タイプを定義し、ファイルの先頭に大域変数を定義します.

多くの関数がこのグローバル変数のメンバーコンテンツを読み出したり変更したりする必要があると、ヘッダファイルに追加されます.

//protocol_data.h      
typedef struct my_protocol
{
	uint8_t frame_len;
	uint8_t frame_data[20];
} MY_Protocol_t;
//protocol_data.c     
MY_Protocol_Typedef Pro_Info;

は、したがって、他の.cファイル関数では、&Pro_Info、またはPro_Info.frame_lenをあちこち呼び出して、内容を修正する.これはプログラム設計上非常に良くない行為です.プロトコールにあります.data.csのほとんどは関連コンテンツのデータ処理関数であり、Pro_Infoはプライベートメンバ変数が情報を交換し続けていると考えられ、このとき、外部のtest.cの関数が呼び出されて修正されたと考えられています.data.cの他の関数の影響は、特にマルチスレッドシーンで大きな可能性がある.

採用できる仕様は

extern MY_Protocol_Typedef Pro_Info;

です.

このとき、test.c関数の各場所で、Pro_info_f()の返却結果を受け取りに局所ポインタ変数を使用して、次のステップに進みます.

は、一般的に、様々な構造型の変数が各関数間で使用されることがあります.これらの変数に対する関数パッケージを使用すると、これらの変数へのアクセスが明確になり、安全になります.

私たちのファイルは第三者に提供するかもしれませんので、必ずcファイルを倉庫に入れて、ユーザーにヘッダファイルを残します.この時、グローバル変数がたくさんあると、ユーザーがアクセスしやすくなります.

モジュール間関数デカップリング:

以前に書かれたコードは、モジュール間で相互に多くの大域変数に使用されるため、知らず知らずのうちに結合性が大幅に増加し、常に1つの変数のポインタが最外層関数から4、5層の内部に入って使用される.実は多くの設計方式に問題があります.このように処理する必要はありません.サンプルコードを見れば分かります.

// protocol_data.c     
static MY_Protocol_Typedef Pro_Info;

MY_Protocol_Typedef *Pro_info_f(void)
{
	return &Pro_Info;
}
// protocol_data.h      
MY_Protocol_Typedef *Pro_info_f(void);

は、形参としてp_deviceによって最外層関数Mate_Respond_processによってもたらされ、PICK_Switchに時又に一度入ったことが明らかになっている.

実はPICK_Switchは1つのメンバの値だけを読み取っていますが、Device_TypDefのタイプ全体のポインタp_deviceに完全に入ってきました.この構造タイプは他のモジュールヘッダファイルで定義され、PICK_Switchも外部関数として宣言されている.したがって、Aモジュールのヘッダファイルに他のBモジュールのヘッダファイルを導入して、Device_TypDefタイプによって定義された位置を識別する必要がある.Bモジュールが変更されるとAモジュールも再コンパイルされます.このような操作は大工事の中で多くなります.コンパイル時間の増加は非常に大きいです.

は、正確な値でPICK_Switchにパラメータとして伝えられ、規格タイプのuint8_t which_node_valをさわやかに定義することができ、Bモジュールのヘッダファイルを導入する必要がなくなりました.

Mate_Respond_processは、p_deviceの後の2回の使用も、簡単にメンバーの値を読み取っています.上記のような方法で処理すれば、1つのパスが少なくなり、関数の使用の複雑さが減ります.多くの類似の関数はこのように結合を簡単にすることができ、いくつかの大規模なプロジェクトの維持には非常に友好的で必要である.

まずここに記録して、食事に行きます.