タグ付けされた質問 「coding-style」

私のCプログラムでは、ADTの文字列表現を作成する方法が必要になることがよくあります。文字列を画面に出力する必要がない場合でも、このようなデバッグ方法があると便利です。そのため、この種の機能がよく出てきます。 char * mytype_to_string( const mytype_t *t ); 文字列が返すメモリを処理するために、ここには（少なくとも）3つのオプションがあることを実感しています。 代替方法1：関数の静的文字配列に戻り文字列を格納します。文字列がすべての呼び出しで上書きされることを除いて、私はあまり考える必要はありません。これは、場合によっては問題になることがあります。 代替方法2：関数内のmallocを使用して、ヒープに文字列を割り当てます。バッファのサイズや上書きについて考える必要がないので、本当にすてきです。ただし、完了したら文字列をfree（）することを忘れないでください。また、解放できるように一時変数に割り当てる必要もあります。ヒープ割り当てはスタック割り当てよりもはるかに遅いため、これがループで繰り返されるとボトルネックになります。 代替方法3：ポインタをバッファに渡し、呼び出し側にそのバッファを割り当てさせます。お気に入り： char * mytype_to_string( const mytype_t *mt, char *buf, size_t buflen ); これにより、発信者により多くの労力がかかります。この代替案では、引数の順序に関する別のオプションが提供されることにも気づきました。最初と最後のどちらの引数が必要ですか？（実際には6つの可能性） それで、どちらを選ぶべきですか？なんで？Cの開発者の間には、ある種の未記述の標準がありますか？

11 c  coding-style  strings  malloc 

私は多くの操作を必要とする巨大な文字列を扱います。 たとえば、次のような文字列を生成します。 パート1 ボート セクションA プログラミング パート2 プログラミング用の分割ボート。 セクションAA セクションSQLエントリ。 文字列が大きすぎて手動ですべての部分をチェックすることはできません。今、私はする必要がありsplit、このstring中stringlistのセクションおよび部品によって。2つのオプションを考えることができます。 正規表現： QStringList sl = s.split(QRegularExpression("\n(?=Part [0-9]+|Section [A-Z]+)")); それはうまくいくように見えますが、時々例外が通り抜けます（IE：Section SQL Entries誤って分割されます） それ以外の場合は、最初の文字列を生成するときにマーカーを配置できます。 🚤💻パート1 ボート 🚤💻セクションA プログラミング 🚤💻パート2 プログラミング用のパーティショニングボート。 🚤💻 セクションAA セクションSQLエントリ。 つまり、文字列の分割が簡単になります。 QStringList sl = s.split("🚤💻")); これらのどちらも良いスタイルやプログラミングの実践ではないことはわかりますが、この時点まで、それについては議論しておらず、代替案も見つけていません。 あなたが私のプロジェクトマネージャーである場合、これらの方法のいずれかを受け入れますか？ そうでない場合、私がベストプラクティスとして何をすればよいと思いますか？

10 programming-practices  coding-style  coding-standards  strings  regular-expressions 

これは私が最近よくしていることです。 例： setCircle(circle, i, { current }) { if (i == current) { circle.src = 'images/25CE.svg' circle.alt = 'Now picking' } else if (i < current) { circle.src = 'images/25C9.svg' circle.alt = 'Pick failed' } else if (i > current) { circle.src = 'images/25CB.svg' circle.alt = 'Pick chance' } } …

10 coding-style  language-agnostic  conditions 

プロジェクトのサイズが十分に大きいので、頭の中ですべての側面を維持することはできません。その中でいくつかのクラスと関数を扱っており、データを渡しています。 時間の経過とともにエラーが発生し続けることに気づきました。別の関数にデータを渡すときに、データの正確な形式を忘れてしまったためです（たとえば、ある関数が文字列の配列を受け入れて出力し、別の関数は後で記述します）。辞書などに保持されている文字列を受け入れるため、操作している文字列を配列に入れてから辞書に入れるように変換する必要があります）。 どこがどこでどこが壊れているのかを常に把握する必要がないように、私は各関数とクラスを「分離されたエンティティ」として扱うようになりました。場合によっては、データが間違った形式で指定されている場合は、データを再キャストします。 これにより、渡すデータがすべての関数に「適合」することを確認するために費やす時間が大幅に短縮されました。クラスと関数自体が、入力に問題がある場合に警告を発し（場合によってはそれを修正することもあり）、デバッガーを使用してコード全体を処理し、問題が発生した場所を特定する必要があります。 一方、これによりコード全体も増加しました。 私の質問は、このコードスタイルがこの問題の解決に適切かどうかです。 もちろん、最善の解決策は、プロジェクトを完全にリファクタリングし、データがすべての機能に対して均一な構造を持っていることを確認することです。 。 （参考：私はまだ初心者なので、この質問が素朴だった場合は失礼します。私のプロジェクトはPythonで行われています。）

10 python  coding-style  data-structures  refactoring  code-quality 

私は、以下の短いサンプルを含めたいくつかのひどいコードを継承しました。 この特定のアンチパターンに名前はありますか？ これをリファクタリングするための推奨事項は何ですか？ // 0=Need to log in / present username and password // 2=Already logged in // 3=Inactive User found // 4=Valid User found-establish their session // 5=Valid User found with password change needed-establish their session // 6=Invalid User based on app login // 7=Invalid User based on network …

10 coding-style  code-quality  coding-standards  code-reviews  code-smell 

ここで、メソッド/関数パラメーターとしてドメインオブジェクトまたは一意のIDを使用する必要があるかどうかに関するいくつかの有用な回答の後、IDとドメインオブジェクトをメソッドパラメーターとして使用します。これをカバーします）。一意のIDをメンバーとして使用するか、オブジェクトをメンバーとして使用することの長所と短所は何ですか。私はScala / C＃/ Javaのような強く型付けされた言語を参照して尋ねています。持っておくべき（1） User( id: Int, CurrentlyReadingBooksId: List[Int]) Book( id: Int, LoanedToId: Int ) または（2）、（1）より優先：通過後：すべてのタイプを定義する必要がありますか？ User( id: UserId, CurrentlyReadingBooksId: List[ BookId] ) Book( id: BookId, LoanedToId: UserId ) または（3） User( id: Int, CurrentlyReadingBooks: List[Book]) Book( id: Int, LoanedTo: User) オブジェクト（3）を持つメリットは考えられませんが、ID（2）および（1）を持つメリットの1つは、DBからUserオブジェクトを作成するときにBookオブジェクトを作成する必要がないことです。次に、Userオブジェクト自体に依存し、無限のチェーンを作成します。RDBMSとNo-SQLの両方でこの問題に対する一般的な解決策はありますか（それらが異なる場合）？ これまでのいくつかの回答に基づいて、私の質問を言い換えると：（ラップされたタイプであるはずのIDを使用して）1）常にIDを使用しますか？2）常にオブジェクトを使用しますか？3）シリアライズとデシリアライズで再帰のリスクがある場合はIDを使用しますが、それ以外の場合はオブジェクトを使用しますか？4）他に何かありますか？ 編集：オブジェクトを常にまたは一部のケースで使用する必要があると答える場合は、他の回答者が投稿した最大の懸念に必ず答えてください=> DBからデータを取得する方法

10 coding-style 

C ++には、引数の型が予期されたものでない場合に、パラメーターの型の一致するコンストラクターを自動的に呼び出す機能があります（適切な名前はわかりません）。 これの非常に基本的な例はstd::string、const char*引数付きのを期待する関数の呼び出しです。コンパイラーは、適切なstd::stringコンストラクターを呼び出すコードを自動的に生成します。 読みやすさに関しては、私が思うほど悪いのでしょうか。 次に例を示します。 class Texture { public: Texture(const std::string& imageFile); }; class Renderer { public: void Draw(const Texture& texture); }; Renderer renderer; std::string path = "foo.png"; renderer.Draw(path); いいですか？それとも行き過ぎですか？私がそれをするべきではない場合、どういうわけかClangまたはGCCにそれについて警告させることができますか？

10 c++  coding-style  readability  type-conversion  construction 

Martin Fowlerのリファクタリングを読んでいます。それは一般的に優れていますが、ファウラーの推奨の1つが少し問題を引き起こしているようです。 Fowlerは、一時変数をクエリに置き換えることを推奨しているため、これの代わりに： double getPrice() { final int basePrice = _quantity * _itemPrice; final double discountFactor; if (basePrice > 1000) discountFactor = 0.95; else discountFactor = 0.98; return basePrice * discountFactor; } あなたはヘルパーメソッドに引き出します： double basePrice() { return _quantity * _itemPrice; } double getPrice() { final double discountFactor; if (basePrice() > …

10 coding-style  refactoring  variables 

概要：非同期コードとコールバックを使用しているにもかかわらず、コードを読みやすくするために使用できる、確立されたベストプラクティスのパターンはありますか？ 非同期に多くのことを行い、コールバックに大きく依存するJavaScriptライブラリを使用しています。単純な "load A、load B、..."メソッドを書くのはかなり複雑になり、このパターンを使用するのは難しいようです。 （不自然な）例を挙げましょう。リモートWebサーバーから一連の画像を（非同期で）ロードしたいとします。C＃/ asyncでは、次のように記述します。 disableStartButton(); foreach (myData in myRepository) { var result = await LoadImageAsync("http://my/server/GetImage?" + myData.Id); if (result.Success) { myData.Image = result.Data; } else { write("error loading Image " + myData.Id); return; } } write("success"); enableStartButton(); コードレイアウトは「イベントのフロー」に従います。最初に、開始ボタンが無効になり、次に画像が読み込まれ（awaitUIの応答性が維持されます）、その後、開始ボタンが再び有効になります。 JavaScriptでは、コールバックを使用して、これを思いつきました： disableStartButton(); var count = myRepository.length; function loadImage(i) { …

10 javascript  coding-style  async  continuation 

最近、いくつかのプロジェクトと開発環境を切り替えています。それぞれのコーディングスタイルに対する期待は異なります。 さて、私の質問は3つの部分で、最初は好奇心の問題です。 コーディングスタイルをどのように定義して見つけましたか？ どのようにしてそれを増強し、改善し続けますか？ どのように維持しますか？（メンタルノートから、ドキュメントの保持、StyleCopなどのツールの使用）

10 coding-style  maintenance 

通常、C ++クラスを宣言する場合は、宣言のみをヘッダーファイルに配置し、実装をソースファイルに配置することをお勧めします。ただし、このデザインモデルはテンプレートクラスでは機能しないようです。 オンラインで見ると、テンプレートクラスを管理する最良の方法について2つの意見があるようです。 1.宣言とヘッダーの実装全体。 これはかなり簡単ですが、私の意見では、テンプレートが大きくなるとコードファイルを保守および編集することが困難になります。 2.最後にインクルードするテンプレートインクルードファイル（.tpp）に実装を記述します。 これは私にはより良い解決策のようですが、広く適用されているようには見えません。このアプローチが劣っている理由はありますか？ 多くの場合、コードのスタイルは個人の好みやレガシースタイルによって決定されます。私は新しいプロジェクト（古いCプロジェクトをC ++に移植）を開始しており、OO設計は比較的初心者なので、最初からベストプラクティスに従いたいと考えています。

10 object-oriented  c++  coding-style  templates 

メソッドと関数のパラメーターとしてのオブジェクトと一意のIDの使用について賛成または反対の客観的な引数はありますか？（および他のオブジェクトのメンバー？）。特に静的型付け言語のコンテキスト（C＃/ Java / Scala） オブジェクト自体の長所： よりタイプセーフな呼び出し。IDを使用すると、引数の順序が誤ってしまうリスクがあります。これは、そのクラスのIDのみを格納するクラスごとに「ミニ」クラスを保持することで軽減できます。 永続化から一度取得し、再度取得する必要はありません （：courtsey - IDと、IDタイプが変更された場合、INTを言う>長い、そして...ミスの可能性が軒並み変更を必要とするhttps://softwareengineering.stackexchange.com/a/284734/145808） IDを使用するメリット： ほとんどの場合、実際のオブジェクトは必要ありません。uniqueidで十分です。そのため、IDがあれば、永続化から取得する時間を節約できます。 これらのテクニックの混合は、私が見る限り、両方の長所と短所の両方を持っています。 これが具体的に定義された問題であることを考えると、「私は思う」または「好き」タイプではなく、客観的な答えがあることを願っています... :-)。 編集：コメンターの提案に関するコンテキスト-唯一の制限は静的に型付けされた言語です。このアプリケーションは汎用アプリケーションですが、特定の使用シナリオに基づいて回答を得ることもできます。 編集：もう少しコンテキスト。書籍管理システムがあるとします。私のモデルは： Book: { id: Int, isbn: String, donatedBy: Member, borrowedBy: Member } Member: {id: Int, name: String} Table- wishlist: { isbn: String, memberId: Int} Table- borrows: { id: Int, memberId: Int} Method: isInWishList( book: …

10 coding-style  methods  parameters 

以下のリスクがあるいくつかの（かなりまれな）ケースがあります。 再利用を目的としていない変数の再利用（例1を参照）、 または、別の変数の代わりに変数を使用して、意味的に近い（例2を参照）。 例1： var data = this.InitializeData(); if (this.IsConsistent(data, this.state)) { this.ETL.Process(data); // Alters original data in a way it couldn't be used any longer. } // ... foreach (var flow in data.Flows) { // This shouldn't happen: given that ETL possibly altered the contents of `data`, it is …

10 c#  coding-style  language-features  scope 

コードの中で、特定の条件を何度もチェックしていることがよくあります。 簡単な例を挙げましょう。「a」で始まる行、「b」で始まる行、およびその他の行を含むテキストファイルがあり、実際には最初の2種類の行のみを処理したいとします。私のコードは次のようになります（Pythonを使用しますが、擬似コードとして読み取ります）。 # ... clear_lines() # removes every other line than those starting with "a" or "b" for line in lines: if (line.startsWith("a")): # do stuff elif (line.startsWith("b")): # magic else: # this else is redundant, I already made sure there is no else-case # by using clear_lines() # ... …

10 coding-style  clean-code 

一般に、ファイルハンドルやUNIXプロセスなどを扱っていない限り、ルーチン名やクラス名の一部として「ハンドル」や「プロセス」などの単語を使用しないことをお勧めします。しかし、抽象クラスは、処理などの他に何かをどうしようとしているのか、実際には分からないことがよくあります。私の現在の状況では、ユーザーの受信ボックスにログインして、そこからのメッセージを処理する「EmailProcessor」があります。次のスタイルの問題が発生することに気づきましたが、これをより正確な名前にする方法は本当にわかりません。 派生クラスをクライアントとして扱い、実装する機能の一部によって基本クラスに名前を付けた方が良いですか？より意味を与えますが、is-aに違反します。たとえば、EmailAcquirerは、派生クラスのために取得しているため、適切な名前になりますが、派生クラスは誰のためにも取得しません。 あるいは、派生クラスが何をするのか誰が知っているので、本当にあいまいな名前です。ただし、「Processor」は、ログインやIMAPの使用など、関連する多くの操作を実行しているため、まだ一般的すぎます。 このジレンマから抜け出す方法はありますか？ 問題は、「これは何をするのか」という質問に実際に答えることができない抽象メソッドの場合により明白になります。答えは単に「クライアントが望むものは何でも」だからです。

10 object-oriented  coding-style  naming