スタイルの質問に

一万里の旅は、最初のステップから始まります。

前文

前の投稿の調査結果によると、私の記事を読んでいる人の大部分が組み込みシステムのプログラミングのコースを受講したいことが明らかになったので、次のテキストを入門講義と考えることを提案します。 別の、それほど大きくはないが、かなりの部分の読者が自分で同様のコースを読む機会を宣言したので、参加してください。Habréであなたの講義を見たことがありません。



MKのハードウェア初期化モジュールを構築する方法に関する最近の（私がそれを書き始めたとき、彼は本当に最近でした）投稿（ちなみに、このトピックに興味がある人は、コメントを必ず確認してください、残念ながら、完全に素晴らしい解決策はありません、この原稿の余白に収まる）私はSTMマイクロコントローラのUARTの機能に次の投稿を捧げることを約束しました。 それにもかかわらず、この約束を放棄することなく、特定の調整を行います-適切なソフトウェアパッケージ開発のトピックに関する一連の投稿が作成され（たとえば、MODBUSプロトコルの実装が採用されます）、そのフレームワーク内に上記のトピックに専念する部分があります。



私たちは正しい開発を研究するので、反例が必要になります。他の人の間違いを示すことほど簡単ではないため、前述のプロトコル、つまりFREEMODBUSのよく知られた実装が出発点として採用されます。 機能の問題を検討せずに、このソフトウェア製品のスタイルは私には理想的ではないようであり、どのように改善できるかを示してみます。



予定されている一連の投稿の目的は、組み込みデバイス用のソフトウェアシステムの設計方法、考慮すべき考慮事項、適用すべき基本的な手法、結果を示すことです。 プレゼンテーションでは、このテキストの読者が組み込みソフトウェア開発の分野で働くために必要な特定の知識を持っているという暗黙に暗示されている事実から進みます。私の仕事は、彼がこの知識を体系化して、可能な限り最高の品質の結果を得ることです。



したがって、プレゼンテーションは必ずしも十分に厳密であるとは限らず、多くの場合、問題を指定し、その重要性を証明せず、問題の可能な解決策を主張して表示するだけです。 それにもかかわらず、得られた結果は確かに真実であり、さらに、日常の実践で非常に適用可能です。 理論的な考察自体は、この理論の具体的な使用例ほど興味深いものではない（さらに、読み書きが難しい）ので、親愛なる読者は、前述のライブラリに基づいてライブラリを設計することに従事します。



ライブラリ、つまり私たちが今後使用することを意図していない製品を作成する場合、どの機能を考慮する必要がありますか。 まず、同僚の目を見るのが恥ずかしくないように、特別な注意を払って書かれるべきです。 「子供向けの本を書く方法は？ 大人だけでなく、それだけが優れています。」 もちろん、「フィガク、フィガク、プロダクション」スタイルは最近、特定のサークルで人気を博していますが、あなたと私は、一時的な利益のために信頼性のある船を離れるサイレンの呼び出しに屈することはありません。 さらに、コードの最も重要な読者（いいえ、これは社長ではありません）、つまり自分自身についても忘れてはなりません。 「なぜここで使用したのだろう...」のような表現は、私たちが望むよりもはるかに頻繁に発音されます。成功したライブラリ（および他の方法）を取得し、多くのユーザーから需要がある場合、それを修正する必要がある場合があるためです、そして私はロシア語の豊富な語彙、特に非規範的な部分を適用せずにこれをしたいと思います。 しかし、これらは一般的な考慮事項であり、すべての開発に当てはまる必要があります。これが常に行われるわけではないのは残念です。 したがって、実際のコードの記述を進める前に、それに伴う重要な状況を判断する必要があります。



変数（最悪の場合はモナド）を使用し、選択した言語で（一般的には、選択しなかったため、Pascalファミリーの言語ではなく、どこに行けばよいかわからない） Cは組み込みシステムのプログラミングにおける主要な言語であり、「敵を倒せない場合は、それらを導いてください」）変数は類型化されているので、まずは型について話しましょう。



カッコ内の発言に関する必要な説明は、私はまったくC言語の堅固な敵ではなく、敵ではないということですが、プログラマとしての私の開発はPascal言語（一般的に、正直に言うと、マシンのANPの言語「ナイリ」-ああ、これらの素晴らしい指令は「導入」と「終了」-それから、ロシア語の指令は以前のように良いアイデアではないことに気づきました、そしてFortranでは、これらの言語についてあまりにも多くの読者がしないことを恐れています彼らは知っているし、私は現時点ではそれらを推薦するつもりはないが、パスカルの 私はまったくそれを行うことはできません）、このシーリング現象が起こり、Cが提供するロープの長さを個人的に確信したとき、それは私にとって不快でした（そしてそれはパスカルがあなたを支えているサポートよりもはるかに長いですサポートなしで独立して移動します）。 しかし、それでも、Cを第一言語として、あなたはあなたの子供のためにそのような歩行指導をしたいと思いますか？

列挙と定義

それで、私たちの羊、つまりタイプに戻って、あなたは驚かれるかもしれませんが、本当に話すことがあります。 まず、ファイルを開きます...すぐに、著者がライブラリで積極的に使用することを計画しているユーザータイプのアナウンスに出会いますが、すぐに一部の執筆が気に入らなくなります。 この場合、ブール型の導入について説明しています。 これは、この言葉の受け入れられている意味の誤りではありませんが、私のプログラミングパラダイムのフレームワークの大きな誤りです。 バカな人はコンパイラを書くと思うので、言語を使用するという点で、自分よりもはるかに高度だと考えるべきではありません。 論理定数を定義する古典的な実装とchar型の使用がこのファイルに記載されています。列挙型による実装とは対照的です。

typedef enum {False=0,True=1} Boolean; Boolean IsOk=True; ...; if (IsOk==False) ...;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私たちは提案された実装をより詳細に検討して、それが提供するすべての利点を理解し、欠点がないことを確認します。その後、定義に基づいて最初の実装を一度忘れてしまい、その適用をまともな社会の許容できない現象に帰します。 「パーティーには不吉な静寂があり、誰もが振り向いてあなたを非難し、ホールの隅にいる誰かがカクテルを落とすことさえあります。」



そのため、まず、列挙型が作成された目的-割り当ての混在が許容されないため、これを実行しようとすると、コンパイラの警告が表示されます。 もちろん、変数全体を論理値に割り当てることには何の問題もないと誰かが言うでしょう。それらは同等であり、一般に警告はエラーとは異なります。それらを無視できます。私たちは人間ではありません-今日、彼は列挙型を混合し、明日ポインタを与え、明後日はポインタをローカル変数に戻すという警告を無視し、困惑してアイドルコードを見て、「昨日はすべてうまくいきました。おそらく Eコンパイラグリッチ「とINETAに行くにはneglyuchnyコンパイラを求め、そこには戻りませんが、細部にコードを無視する独特のスタイルでそれらを書かれて理解する必要があります。 怠inessと過失を除いて列挙型を混合する言い訳はないため、すべてがこの順序で発生し、リストされた最初のものにすべて敬意を払ってこれらの2つの性質を持っています（結局、彼女は前に生まれたので、一般的には進歩エンジンです）コードを同行させたいプログラマーの最高の特性に帰することができます。



ところで、私はコーダーに異常なほど熱くされたキャラクターがあることをすぐに警告したいと思いますが、私の投稿ではこの欠点をできるだけ隠していますが、血まみれのマニアと呼ぶことはかなり可能です、私はキャラクターより悪くない家にいくつかの大きな包丁を持っています有名な映画のスティーブン・セガールは、実際のIPアドレスを計算したり、コードからそれを抽出したりする技術において、私は同等ではありません。



次のプラスは、コンパイラが実装に必要なプリミティブ型を選択することです。値を格納するのに8ビットで十分な場合、列挙型は必ずしも整数として格納されません。 私にとって、IARは、論理型（列挙型）の変数を1バイトに配置することでそれを実現しました。 一般的に、論理型を直接決定する場合は、char型ではなくat_least8_tまたはfast8_tを使用する必要があります。最後の2つはバイトと一致する必要はありませんが、バイトと一致する必要はありません。 さらに、たとえば、メモリ内のアドレス指定可能なビットなど、論理変数をより適切な場所に配置できるコンパイラ実装を除外しません。これは、自作の定義よりもメモリと速度の両方で間違いなく効率的です。

明示的な比較

比較演算子が書かれている行に注意を払いましょう。「真実とは何か？」という確立された慣行とは対照的に、明確に書かれた比較でオプションを断固として主張します。 このオプションは必要な条件を明確に示しており、推測の余地がないため、「ゼロではありません」。 まあ、現代のコンパイラの99％を考慮すると（「すべて」を記述しますが、何が起こるかわかりません）、ゼロとの比較を見ると、その実装のコードは生成されません（または、まったく同じになります） if（！エラー）条件での比較の欠如については、効率が低下することはありません。結論として、NoErrのような名前の変数を避けることももう1つの考慮事項です（変数の名前は、格納されている値の意味と一致する必要がありますが、あなたは疑いを持っていない、そうでなければ私たちは大きな問題を抱えています） などの可能誤解と混乱式溶解if (NoErr==False)



、及び任意の手段によって回避されるべきであり、その意味でISOK変数が好ましいです。



ステートメント形式で条件を記述することも望ましいです。つまり、 (IsOk == False)



(IsOk |= True)



よりも望ましいのですが、 ~(IsOk == True)



オプションは思い浮かぶことすらありません。 （トローリングされていたかもしれませんが、私には微妙すぎますが、冗談を言うのは不適切です）バリアントState|= !!ErrNumber << 5



、通常の表現if (ErrNumber! = 0) State = State | (1 << StateErrorBitNumber)



if (ErrNumber! = 0) State = State | (1 << StateErrorBitNumber)



。 これが真実であり、私のコンパイラのコードが短くも速くも動作しなかったとしても、この効率は、同様の言語構造からの1分間の困惑の価値さえありませんでした。



おそらく、組み込みソフトウェアの分野で働いている人は、議論全体の二重反転の結果を理解する必要がありますが、それにもかかわらず、オリンピックやインタビューのためにそのような構造を保存しましょう。実際の作業ではそれらを回避します。 簡単な理由-読者が知的パズルを解く能力を評価するためのコードを書いているわけではありません（これは当業界にあります。まあ、私の反対意見を呼んでください。そして、プログラムコードでは、私は個人的にそのような行動を不適切であると考えています（誰かが私の行動に反して自分自身を持っているので、間違った意見がある場合は、コメントまたは応答で合理的に述べることができます それはそうですが、すなわち、I）は、間違っている可能性があります。



さて、もう1つ発言-C言語標準では、このフラグメントの（上記のコードの作成者の観点から）正しい動作の保証はないことをここで教えてくれます。 これが本当かどうかはわかりませんが、とにかく注意する方が良いです。

ビットフィールド

ところで、ビットフィールドに関して。 私の反対意見を読んだ人は知っています、そして残りのためにもう一度繰り返します-あなたがコンパイラで単語のバイト順序を制御できるなら、ビットフィールドはレジスタと通常の両方で個々のビットとビットフィールドを扱う本当に楽しい方法ですif (ErrNumber! = 0) State.ErrorBit = 1



前の段落で与えられたものよりもさらに明確なので、この機会を使用することを強くお勧めします。 子供の頃に宗教上の考慮事項や心理的トラウマを受け取った場合、両親が書いたファイルを予期せず開いて、そこにこの開かれたテクニックを見たとき、ビットフィールドを使用することを許可せず、ビットマスクを好む場合、私は強く推奨します-操作を隠すそれらはマクロの背後にあり、個別にではなく、従属定数を相互に定義します。



私の初期の投稿では、この問題を考慮しました。コメントには、 #define StateBitNumber (12)

#define StateBitMask (1 << StateBitNumber)



ような結合定数の従来の定義とともに許可するマクロさえあります。 #define StateBitNumber (12)

#define StateBitMask (1 << StateBitNumber)



#define StateBitNumber (12)

#define StateBitMask (1 << StateBitNumber)



は、 #define StateBitMask (0x00004000)

#define StateBitNumber (BITNUMBER(StateBitMask))



スタイルで反対を使用します #define StateBitMask (0x00004000)

#define StateBitNumber (BITNUMBER(StateBitMask))



#define StateBitMask (0x00004000)

#define StateBitNumber (BITNUMBER(StateBitMask))



。 最後のマクロの独自の実装を考え出すか、または見ることができます。 そして、神のために、これらの定数の導関数のみを使用してください。 *(uint *) 0x20008000 = *(uint*) 0x20008000 & 0xffff0fff | 0x00004000



*(uint *) 0x20008000 = *(uint*) 0x20008000 & 0xffff0fff | 0x00004000



、さらに、同じ定数を持つ類似の表現がテキストに何度もありますが、大きな包丁についてはすでに覚えています。



レジスタ内のビットフィールドは決して論理型ではありませんが、1ビットの長さではあるが整数はその型を整数と決して異にしませんが、プロセス状態ワード（変数内）ではまた、このような構造-ビット長1の論理タイプを許可します。また、elseブランチについても忘れないでください。これは、この例ではかなり意識的に見逃しました。そのため、批判される演算子に完全に対応し、対応するコンテキストで正しい場合があります。 同時に、 ProcessOK = (Boolean) (((ReadOk==True) || (WriteOK==True)) && (ErrNum ==0))



ようなものを書く権利を制限しません。オペレーターは、何が起こっているのかを明確に理解し、起こりうる結果に対して責任を負う決意を表明しました。

変数名

別の重要ではないが、特定のサークルでは、物議を醸す状況、すなわち変数の名前は、存在する限り影響を受けます。 私の例からわかるように、私はこの点に関して特定の好みを持っていますが、私はそれらを決して強要しません、下線付きのスタイルは悪くありません（おそらく、私はそれを使用しないため、とにかくそれはおそらく悪いです）、ハンガリーの表記は非常に一般的です広く、その利点があるため、オブジェクトと属性の順序はどのような方法でも可能です。そのため、唯一の推奨事項は、同じ命名スタイルを厳守し、IsOK6のような名前を避けることです。



個人的または組織内で、変数のコーディングおよび命名の形式が非公式または正式に確立されている場合は、標準ではなくても標準よりも優れているため、優れています。 ho声やパーソナライズに至るまで、変数の真に正しい命名のトピックについて無限に議論することができますので、私はあなたがやりたいこと（特定のルールに従います）をもう一度言います、そして私は「はい、すべての本当の信じる卵割」の支持者ですEMUがより便利な最後から」という有名な引用の私の改訂が強調されていますが、そのような修正がリリプートを内戦から救うかどうかは完全にはわかりません。



実際、列挙型の長所と短所は、私の奇妙な想像力の逃避に続いて誰かが忘れていない場合、考慮したので、この問題に戻りましょう。 提案された実装の利点を調べ、目に見えるマイナスがないことを確信しましたが、それは起こらず、何かが悪化するはずでした。 「読者はすでにバラの韻を待っています-まあ、すぐにそれをキャッチします。」 列挙型を論理式として解釈する機能を失いました。これは、デフォルトでは組み込み整数型のCで表されますが、完全に失われることはありませんでしたが、そのような試みにはコンパイラーの警告が伴うため、無視しないことに同意しました。



はい、私たちはif (~NoErr || !NoSuccess && NoRetry) ...



ような魅力的な表現を書くことができませんif (~NoErr || !NoSuccess && NoRetry) ...



これは、半年の休憩の後に著者に間違いなく数分の不快な時間を提供し、残りについて話すことは何もありませんが、私を信じて、損失は​​それほど大きくありません。 そして、誰もが理解できる形式で論理条件を表現するには、たとえばif (IsOk==True) || ((Success==True) && (Rerty==False))) ...



if (IsOk==True) || ((Success==True) && (Rerty==False))) ...



ここでは、すべてがシンプルで明確であり、この構造に2マイクロ秒かかる場合でも、個人的にはわからないので、それだけの価値があります。 賢い人の一人が言ったように、私たちはコンパイラのためではなく、他の人のためにプログラムを書いています。



さて、先ほど述べたように、誰も型キャストをキャンセルしていません。私はそれを普遍的な悪とは考えていません。また、暗黙のキャストを避け、健康のためにそれを使用します。これは本当に悪です。 結局、キャスト演算子を書いた場合、結果として得られるものを理解し、整数バイトを割り当てると上位ビットが破棄され、関数にアクセスするときに定数変数へのポインターを使用することを理解していることをコンパイラに示したことが理解されます、仮パラメーターが変数へのポインターである場合、一部のランタイム環境で例外が発生する可能性がありますか？ あなたはこれを理解していなかったので、（迷惑な）警告を取り除くために型キャストを設定しました-これらはあなたの問題です、コンパイラはあなたが十分に責任あるプログラマであり、彼を失望させないようにあなたの動機を掘り下げません。かなり。

自分を明確に表現する

したがって、可能な限り単純なコード（よく知られているKISSルール）を書くことをお勧めします。これは、常にプロのプライドの誤った理解から違反します（ブラックボックスの最後のレコードは「どうすればいいか」と思われる意見があります）多くの場合、習慣から外れています。 前の投稿へのコメントで私に勧められた「21世紀から」という良い本を読みましたが、非常に馴染みのある場所であるstatic int Data=0; if (!Data) ...



static int Data=0; if (!Data) ...



; 単純で理解しやすい条件（データ== 0）がこの形式で書かれている目的について質問があります。もし私たちが変質することに決めたら、（〜Data＆1）と書くこともできます（この表現はもっとクールで、タイプ全体の振る舞いを深く理解しますが、これはプログラムを書く主な目標です-あなたの知識を誇示するために）、しかし、あなたは何か他のものを思いつくことができます。 テキストを入力するときに2文字を保存し、ファイルを保存するときにディスク容量を節約するためですか？ もちろん、3つのオプションはすべて同じように機能し、Cでは型全体を条件として解釈できますが、それでも、なぜですか？ 読者（ユーザー）がC構文規則の知識を確認する必要はありません。繰り返しますが、インタビューはしていません。



パフォーマンスについて私に話を始めないでください。事前に、より理解しやすいバージョンのコードは、両方の異常な（この定義を主張する）メソッドのコードに過ぎないと言うことができます。 ちなみに、最初の2つのオプションではコードはまったく同じであることが判明しましたが、3番目のオプションはコードの作成者の深い知識を示すように設計されており、当然長くなりました。

マシンに依存しないタイプ

プログラムのテキストをさらに調べて、別の神秘的な場所、つまり、UCHAR型とUINT型の定義に出会います。 なぜ神秘的な場所ですか？ 第一に、これらのタイプがまったく導入されない理由が明確ではなく、名前から何も続きません（意味のある識別子に同意しましたか？）、第二に、テキストはこれらが標準タイプの単なるエイリアスであることを示し、第三に、標準タイプが採用された理由、およびサイズが明示的に示されている組み込みプログラミングでの使用が明示的に推奨されていないタイプ。 入力する文字数を少なくしようとするだけですか？



もしそうなら、この決定はまだ存在する権利を持っていますが、もしそれがマシン独立型を定義する試みであったなら（そして、これは「私の手紙の最初の行で」行われるべきですので、私は心からそう望みます）、それは明らかに失敗しました。 マシンに依存しない型の正しい名前の問題は別のholivarのトピックです。TIがその例で使用するミニマリストの定義、つまりu8、s16などは個人的には好きですが、別のオプションを好むかもしれません。



ところで、好奇心reader盛な読者にとって興味深い質問は、これらの型が言語実装のサイズの明示的な指示でどのくらい正確に定義されているかということです。 しばらく考えてからオプションを提案し、コンパイラのstdint.hファイルコードを確認することをお勧めします。 個人的には、__ INT8_T__のような式のIARエイリアスを見つけました。これはさらに分析することはできず、明らかにコンパイラー自体に実装する必要があります。 C言語標準を読んでいる人（私が自分の無知を誇示する方法を参照してください、これは初めてではありません）はコメントで私を修正できますが、これらのマクロはsizeof演算子の場合のように、内部実装であるようです私がかつて探したが、見つけられなかった人は、同様の表現に反して休んだ。 しかし、Keilでは、これらの型は標準型を介して直接実装されているため、どのように実際にあるべきか、または実装は完全にコンパイラメーカーに委ねられているのではないでしょうか？



好奇心reader盛な読者に対する別の質問は、サイズを明示的に指定する必要がある場合、どのタイプを使用でき、どのタイプを使用する必要があるかということです。 一方では、ケース（u）int8_tを使用することをお勧めします。その実装はオプションですが、fastint8_tは、長さが下から制限されており、タイプatleast8_tのように厳密に設定されていません。 もちろん、経験上、明示的にサイズを示すすべてのタイプのタイプが、実際にアクセス可能なすべてのコンパイラーに実装されていることが示されています（反対のケースはわかりませんが、読者は個人的な経験を一般化するという私の欲求にすでに気付いているようですが）、墓の2メートルよりも溝のメートル。 一方、最後の2つのタイプは正確な長さを保証するものではありませんが、短い整数とみなされ、バイトと一致しません。



私の解決策は、sizeof（char）== 1が標準で厳密に固定されているため、本当にバイトが必要な場合、char型は正しいですが、16ビットの整数にはfast16_tを使用する必要がありますが、これも何も保証しません。 したがって、正しいソリューションは、バイトのセットの形式で情報パケットを記述し、バイトの配列を使用して明示的に規定された操作によって、さまざまなタイプの内部変数への変換およびその逆の変換です。

符号なしの型

すぐに符号なし数字のトピックに触れてください。 何らかの理由で、外部デバイスのレジスタを決定するために（およびデータ転送パケットの構造を記述するときに）符号なしの型が使用されるという慣行が開発されました。符号付きと符号なしの型の違いは>と<operationsの実装のみであるため、先頭のビットは符号付きの型、符号なしの型のキャリービットは分析されますが、これらの演算は実行しません。また、型変換にもわずかな違いがあり、これによりパフォーマンスがわずかに変化します（少なくともARMストーンの場合）。また、方向が異なります。



同時に、符号なしの型の使用は、余分なu文字を記述する必要があることを除いて、マイナスの結果につながりません。これは、ディスクスペースを節約するという現代のプログラミングの主なパラダイムに準拠していません。たとえば、パケット内のデータの長さなど、符号なしの値として解釈される情報を実際に含むフィールドの場合、定義によって負になることはありません。符号なしの型を使用すると、式（Len> 0）と（Len！= 0）を同等にすることができます。より便利なものを使用しますが、そのような情報を含まないフィールドの場合、符号なしの型はオプションです。



さて、最後の発言-これらのタイプが大文字で書かれている理由は明らかではありません。そのような命名が推奨されているマクロがないため、おそらくおそらく、過去の遺産、実際に定義があり、カスタムタイプに置き換えられたマクロがありません。誰にもわからないが、私にとっては大文字だけで構成される名前が目を引き、このスタイルはサポートしていないが、ご存知のように「色はすべて味が違う」。繰り返しますが、正当な反対意見を持っていることをコメントしてください。

ファイル構造

ファイルについて少し説明します。私はあなたのことを知りませんが、これまで（十数年以上ありましたが）モジュールの構造とそれらを実装するファイルが置かれている場所の説明が記載されたテキストファイルをプロジェクトのルートディレクトリで見つけられないのは珍しいことです。おそらく、ヘッダーファイルはINCで始まる名前のディレクトリとSRCディレクトリのソースにあることを理解していますが、ここには既にSOURCEなどのオプションがありますが、若い頃はそのようなファイルの存在が必須と考えられていたので、この理由はわかりません私は練習を拒否し、このソフトウェアパッケージの作成者とそれが開発されたライセンスの種類を通知するテキストファイルを、私はそれが完全に不適切であると考えます。



Jack Gansleyがブログで書いたように、「プログラムテキストの冒頭に、ライセンスの要件に関する2ページの説明があり、コメントがほぼ終了しているので、著者の資格について疑問があります。」この表現は、問題の製品を完全に少しだけ言及しています。そして、Doxygenを促進するサイレンがあなたにコメントを書くことを信じないでください。彼はファイルの構造と構成の説明を本当に準備できます。特にあなたが彼を助ければ、コメントはあなただけの仕事です。



そして、コメントについて話し始めたので、私のアドバイスは、コメントを次のスタイルで書くべきではないということです。Counter ++; //



。これは冗談ではありません。そのようなコメントは、多くの場合、著者がそれらを公開することを恥ずかしがらないプログラムで見られます。最近、「コメントは読者を怒らせてはならない」という良い表現を読みました。確かに、この現象はArduino環境の特徴ですが、それでも、そのようなコメントは存在しないというよりも悪いのです。しかし実際には、コメントはなく、まったく同じ操作がわずかに異なるプログラミング言語で書かれており、この種のコメントがプログラムのロジックを理解するのに役立つコードの読者と予想される人がいる場合（そしてこれがコメントの主な目的です）私が彼らにアドバイスできるのは、活動の種類を変更し、精神的能力を非常に明確に超える要件のある領域に関与しないことです。



すぐに必要な説明をしたいと思います-私はこの方向のフォロワーを決して無視しません、Arduinoには本当に良いプロジェクトがあり、これはそれ自体の素晴らしいシステムです、それはかなり歴史的に起こったので、あまり経験のある人たちは、指定された例に似たプログラムを書くスタイルを自分自身に許可する初心者プログラマと慣習的に呼んでいます。あなたの痛みを伴う困惑とそれらに対する唯一の可能な答えは、プログラミング全般、特にC言語に関する本を読むという提案でしょう。

ヘッダーファイル

ヘッダーファイルについてもう1つ、または2つです。

まず、ファイルに保存するのではなく、番号を保存しないでください。モジュールが内部定数またはユーザーが必要としない他のエンティティを必要とするが、それらの単純で便利な変更の可能性を保持したい場合（ただし、そのようなオブジェクトの説明はプログラムテキストの先頭にあり、別のファイルにないため、変更は複雑になりますが、一致するものは保存しません）、モジュールインターフェイスの説明がある共通のヘッダーファイルにドラッグしないでください。あらゆる場合にモジュールごとにヘッダーファイルを1つだけ持つというルールはありません。また、誰もがこれを行うという事実は、あなたにとって正当な理由にはなりません。



ユーザーは必要なものを知るだけで多くの理由がありますが、重要な情報を含む小さなファイルは5ページのシートよりも読みやすく、最初の2ページでライセンスの詳細がわかります製品、次の3つは、使用しない内部定数とオブジェクトを定義し、最後のページの終わりに、ユーザーが必要とする3つの関数のプロトタイプが孤独に潜んでいます。



他の場合には、複数のヘッダーファイルが役立つ場合があります。いくつかのアクティブに使用される変数を含むパッケージがある場合の例を見てみましょう。たとえば、多くのモジュールが読み取ることができるが、変更できるのはごく少数のエラーコードです。もちろん、ユーザーの慎重さを期待してそれにアクセスすることはやや無謀であるため、ゲッターは自然な解決策のように見えるので、2つのヘッダーファイルを作成します。1つは内部使用を目的とし、2つ目は読み取り関数のシグネチャとユーザーのみが、たとえその変数の存在を知っているだけなので、本当に望んでも変数を台無しにすることはできません。



第二に、添付されたヘッダーファイル。聖戦を開始するリスクがあると、私は次のことを宣言します-それらの解決は、モジュールを接続するための真に効果的なメカニズムを作成することをためらうことによって引き起こされた言語開発者の間違い、またはむしろ松葉杖でした。はい、現時点では、C言語はネストされたヘッダーを使用していますが、必須ではありませんが、これはugい解決策です。ただし、あまり美しくはありませんが、このソリューションでは、ライブラリ内の各モジュールがパッケージ全体にのみ含まれるすべてのヘッダーファイルを含むグローバルヘッダーを含むことで始まる場合、モンスターを生成する必要はありません。 STMのライブラリもこのアプローチの例として機能し、このソリューションはすべてのリリースで保持されているという事実に基づいて、これが会社の主要な位置です。もちろん同時に、各ヘッダーには繰り返しインクルードに対する保護が装備されており、コンパイラーはそのようなビネグレットを冷静に消化しますが、そのような解決策は、パッケージ内のモジュールの相互接続が開発者によって考慮されておらず、パッケージ自体の機能部分を実装するのに十分な資格があるかどうか疑問です。



彼らはここで教えてくれます（もちろん、この人はプログラマーとして非常に資格があり、彼の意見は価値がありますが、彼は私の末っ子であり、彼が最初の声明を書いた瞬間から私と議論してきたので、これはある程度長引く独立のデモだと思います-悪気そのような解決策を行うことはできませんせずに、我々は、我々は彼の単位で仕事に行くされているオブジェクトのすべてのヘッダを含まないことを、最大）が、私は、言っていない「と理由を、実際には、ないでしょうか？」



一部で明示的にリストする必要がある言語特定のモジュールからインポートされたすべてのエンティティを解決するために、私は（私だけでなく、自分の経験のみに依存しています）これらの言語で作業しましたが、「生きて、健康で、陽気です」、つまり、そのような要件は死刑宣告に相当しません。



ファイルの先頭にインクルードヘッダーファイルの名前を含むページ（または2つ）を本当に配置する必要がある場合、おそらくモジュールが大きすぎるため、voutを分解する必要がありますか？この場合、無理をせずに、2行の実行でコードを含む100500の小さなファイルを作成しないのがいいでしょう。真実は、いつものように、両極端の間に位置し、非常に素晴らしい特性を持っています-常に真ん中に横たわる（あなたがそれに書かれていることを超えてこのフレーズから何かを読んでいるなら、あなたは恥ずべきです）はい、前述のスピーカーに同意する準備ができています。多くの場所で、添付されたヘッダーファイルは非常に明白ですが、それでも、それらは便利であり、必要ではありません。「デリゲーター」パターンを実装した組み込みプログラミング（およびソフトウェア開発のこのセクションについてのみ書いている）が最後だったのはいつですか？

キーワード

同様に重要なトピックであるキーワードについて説明しましょう。エントロピー、エルゴード的情報源、多次元メッセージ空間、ビット、多義性、マルコフ過程など、非常に魅力的なストーリーからの長い引用を許可します。これらの言葉はすべて、並べられた順序に関係なく非常に印象的です。それらを正しい順序に並べると、特定の理論的内容が得られます。そして、本当の専門家は、彼らの助けを借りて、日常の実際的な問題の解決策を見つけることができます。」したがって、キーワードを有意義に使用します。つまり、

volatile — , ,

static — , ,

const — , ,

auto register — , , , .

他のキーワードはそれほど重要ではありませんが、コンパイラーの機能を忘れていない場合、インラインディレクティブを適切に使用することで実際にパフォーマンスを向上させることができますが、その動作のメカニズム、したがってその使用の意味を実際に理解していないため、組み込みディレクティブを強くお勧めしません。他のすべてのディレクティブは、通常コンパイラに依存し、他の実装（GNUコンパイラで気に入っているwarm__unused_resultプラグマなど）に存在せず、機能が多少異なるため、非常に注意して使用する必要があります。取り上げたトピックにより、次の段落、つまりランタイムへのチューニングにスムーズに進むことができます。

コンパイラーのセットアップ

プログラマからの疎外を暗示するソフトウェアパッケージに固有の別のセクションは、ターゲットコンパイラへのチューニングです。ここで現在コンパイルされている通常のプログラムとは異なり、開発中の汎用ソフトウェアパッケージは、異なるプログラミング言語（少なくともCおよびC ++）、異なるアーキテクチャ、同じ言語内の異なるコンパイラーで動作する必要がありますさまざまな違いがあります）、さまざまなプログラミング環境（およびそれらにはさらに違いがあります）およびさまざまなターゲットMC（まあ、後者はコードに弱い影響を直接与えますが、モジュールの構造を設計するときはこの要件を考慮するとよいでしょう）。



まず、言語の設定が必要です。この特定の場所で、extern Cディレクティブとして表され、C ++プログラムがC言語の規則に従ってオブジェクトファイルで設計された関数を使用できるようにします。パッケージを渡す場合、このディレクティブの使用は絶対に必要ですオブジェクトファイルまたはライブラリの形式ですが、完全なアセンブリのソースコードを使用する場合は除外できます。完全に組み立てられたら、このディレクティブをオフにすることをお勧めしますが、ここで決めることができます。しかし、スタイルに関する単なる発言-元の例では、このディレクティブは条件付きの用語で直接記述されており、個人的にはあまり好きではありません。このようなディレクティブを個別のインクルードファイルとして設計することを好みます。また、ディレクティブの実装を制御し、このアプローチを推奨します。

まとめ

要約すると、どこでも同じスタイルで話す名前を使用し、可能であれば列挙型を作成し、必要に応じてデータのサイズを明示的に示し、マシンに依存しない型を使用し、パッケージ構造とモジュールの関係を熟考し、ヘッダーファイルを慎重に管理し、コードにコメントを付け、複雑なものを避けます理解および/またはあいまいな表現と何が起こるかを参照してください。

PS

上記の推奨事項に基づいて構築されたコードの最初の部分は、Githが最終的に対処するときに、Githab / tGarryC / Modbus /に配置されます。