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

コーディングスタイルは、ソースコードの読みやすさと理解に役立つ一連のガイドラインです。

1
コメント置換として追加のローカル変数を導入
技術的に不要な追加のローカル変数を使用して、何が起こっているのかを説明するのは良いスタイルですか？ 例えば： bool easyUnderstandableIsTrue = (/* rather cryptic boolean expessions */); if(easyUnderstandableIsTrue) { // ... } 技術的なオーバーヘッドに関しては、コンパイラがこの追加の行を最適化することを期待しています。しかし、それは不必要なコードの肥大化と見なされますか？私の目には、古いコメントのリスクを減らします。
3
C ++での非オプションポインターと非const参照
では他のC ++の機能、リファレンス引数のGoogleのC ++スタイルガイドでは、私は非const参照は使用してはならないことをお読みください。 参照によって渡されるすべてのパラメーターには、constというラベルを付ける必要があります。 引数として参照を使用する関数呼び出しを見ることは、Cプログラマーにとって完全に混乱することは明らかですが、CとC ++は今では異なる言語です。出力パラメーターが必要な場合、必要な出力パラメーターへのポインターを使用すると、関数本体全体がスキップされる可能性があり、関数の実装がより複雑になります（関数の循環的な複雑さと深さが正式に増加します）。 C ++コードをできるだけ簡単に理解/保守できるようにしたいので、コーディングスタイルガイドを読むことに興味があります。しかし、チームのベストプラクティスを適応させるには、スタイルガイド要素の背後にある理論的根拠を理解することが重要な要素だと思います。 非const参照は本当に悪いですか？それらを禁止するのはGoogle固有のものだけですか、それとも一般に受け入れられているルールですか？出力パラメーターをポインターとして実装するための余分な労力を正当化するものは何ですか？
7
パラメータリスト内のロガーの位置はどうあるべきか[閉じた]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 私のコードでは、コンストラクターのパラメーターリストを介して、多くのクラスにロガーを挿入しています ランダムに配置していることに気付きました。リストの最初に表示される場合もあれば、最後に表示される場合もあります。 好みはありますか？私の直感では、一貫性はこの場合に役立ち、私の個人的な好みはそれを最初に置くことです。
4
新しいオブジェクトに割り当てるときのスイッチまたは辞書
最近、ステートメントのDictionaries代わりに1-1の関係をマッピングすることを好むようになりましたSwitch。書くのが少し速く、精神的に処理するのが簡単だと思います。残念ながら、オブジェクトの新しいインスタンスにマッピングするとき、次のように定義したくありません。 var fooDict = new Dictionary<int, IBigObject>() { { 0, new Foo() }, // Creates an instance of Foo { 1, new Bar() }, // Creates an instance of Bar { 2, new Baz() } // Creates an instance of Baz } var quux = fooDict[0]; // quux references Foo …
12 c#  coding-style 
2
エンジニアのプロセスを分析するエレガントな方法はありますか？
コミットを測定することは不適切であるという感情がたくさんあります。 次のような、コミットよりも多くのソースを引き込もうとする研究が行われましたか？ ブラウジングパターン IDEの作業（事前コミット） アイドルタイム マルチタスク これらの対策を行う簡単な方法は考えられませんが、何らかの研究が行われたかどうかは疑問です。 個人的な注意として、パフォーマンス評価にこれらを使用するかどうかに関係なく（または使用しない場合）、自分の「メトリック」を反映することは価値があると考えています。IEあなたの習慣を反映する偏りのない方法。しかし、これはQ＆Aを超えた議論の問題です。
5
コーディング標準の進化、それらにどのように対処しますか？
既存のコードベースのプロジェクトのコーディング標準/スタイルガイドの進化にどのように対処しますか？あなたのチームの誰かがプログラミング言語でオブジェクトのインスタンス化のより良い方法を発見したとしましょう。古い方法が悪いことやバグがあるということではなく、新しい方法のほうが冗長でなく、はるかにエレガントだと感じるだけです。そして、すべてのチームメンバーが本当に気に入っています。既存のコードをすべて変更しますか？ コードベースが約500.000行以上のコードであるとします。それでも既存のコードをすべて変更しますか？それとも、新しいコードのみを新しい標準に準拠させますか？基本的に一貫性を失いますか？ プロジェクトのコーディング標準の進化にどのように対処しますか？
5
参照によって渡されたオブジェクトの変更は悪い習慣ですか？
過去には、通常、作成/更新されるプライマリメソッド内でオブジェクトのほとんどの操作を行ってきましたが、最近は別のアプローチを取っていることがわかりました。 以下に例を示します。Userエンティティを受け入れるリポジトリがあるとしますが、エンティティを挿入する前に、いくつかのメソッドを呼び出して、すべてのフィールドが必要なものに設定されていることを確認します。ここで、メソッドを呼び出してInsertメソッド内からフィールド値を設定するのではなく、挿入前にオブジェクトを整形する一連の準備メソッドを呼び出します。 古い方法： public void InsertUser(User user) { user.Username = GenerateUsername(user); user.Password = GeneratePassword(user); context.Users.Add(user); } 新しいメソッド： public void InsertUser(User user) { SetUsername(user); SetPassword(user); context.Users.Add(user); } private void SetUsername(User user) { var username = "random business logic"; user.Username = username; } private void SetPassword(User user) { var password = "more …
3
Golangでの「this」の使用
Golangがここにあるスタイルガイドに最も近いのは、Receiver Namesの下です。 メソッドのレシーバーの名前は、そのアイデンティティを反映したものでなければなりません。多くの場合、そのタイプの1文字または2文字の略語で十分です（「クライアント」の「c」または「cl」など）。「me」、「this」、「self」などの汎用名は使用しないでください。これらは、関数ではなくメソッドに重点を置くオブジェクト指向言語の典型的な識別子です。名前はメソッドの引数のように説明的なものである必要はありません。その役割は明白であり、文書の目的には役立たないからです。 個人的には、「this」が関数の記述および編集時に取り組んでいるものの焦点であるため、常に「this」を識別子として使用しています。それは正しいように聞こえ、（少なくとも私には）理にかなっています。 名前が記述的である必要がない場合、その役割は明白であり、ドキュメンタリーの目的を果たしません。なぜ「これ」の使用が眉をひそめるのでしょうか？
3
それを可能にする言語で関数をネストする必要がありますか、それを避けるべきですか？
JavaScript、PL / SQL、および他のいくつかの言語では、関数をネストできます。つまり、別の関数内で宣言できます。これは、大きな機能を小さな部分に分割するために使用できますが、それらの部分を大きな機能のコンテキスト内に保持します。 function doTooMuch() { function doSomething () { ... } function doSomethingElse() { ... } function doYetAnotherThing() { ... } // doTooMuch body doSomething(); doSomethingElse(); doYetAnotherThing(); } 場合によっては、これらの小さい関数が大きい関数のローカル変数を使用しない場合、これはすべての関数がネストされていないバージョンに簡単に変更できます。 function doSomething () { ... } function doSomethingElse() { ... } function doYetAnotherThing() { ... } function doTooMuch() { doSomething(); …
5
bool / intを返し、実際のオブジェクトを出力パラメーターとして持つメソッドがあるのはなぜですか？
私の会社のコードベース（.NET 3.5アプリケーション）のいたるところに次のコードパターンがあります。 bool Foo(int barID, out Baz bazObject) { try { // do stuff bazObject = someResponseObject; return true; } catch (Exception ex) { // log error return false; } } // calling code BazObject baz = new BazObject(); fooObject.Foo(barID, out baz); if (baz != null) { // do stuff …
4
インターフェイスを実装し、他のクラスを実装しないクラスでのみ使用可能なメソッドを呼び出すより良い方法はどれですか？
基本的に、特定の条件が与えられたときにさまざまなアクションを実行する必要があります。既存のコードはこのように書かれています 基本インターフェース // DoSomething.java interface DoSomething { void letDoIt(String info); } 最初のワーカークラスの実装 class DoItThisWay implements DoSomething { ... } 2番目のワーカークラスの実装 class DoItThatWay implements DoSomething { ... } メインクラス class Main { public doingIt(String info) { DoSomething worker; if (info == 'this') { worker = new DoItThisWay(); } else { worker …
6
命名：明快さのために簡潔さを犠牲にするべきですか？
たとえば、次の関数は、入力フィールドの名前とエラーを含む配列をループします。これは、検証フィールドの名前を確認し、エラー情報を無効なフィールド配列にプッシュすることにより行います。 簡潔にこれを書く方が良いですか？ addInvalidField (field, message) { const foundField = this.invalidFields.find(value => { return value.name === field.name }) const errors = foundField.errors if (!errors.some(error => error.name === message)) { errors.push({ name: message, message }) } }, または、このように具体的にしますか？ addInvalidField (validatingField, message) { const foundField = this.invalidFields.find(invalidField => { return validatingField.name === invalidField.name …
4
Ruby：if variable vs if variable.nil？
私はRubyを初めて使い、nilとfalseを除いてすべてのオブジェクトがtrueであることを知って驚いた。0でも真です。 言語のその特性についての良いところは、あなたが書くことができるということです： if !variable # do stuff when variable is nil end 経験豊富なRuby開発者である同僚は、.nilを使用する代わりにそれを選択すべきだと主張しています。そのようです： if variable.nil? # do stuff when variable is nil end ただし、後者は次の2つの理由により優れたオプションであると考えています。2.私の主題の意見では、たとえそれがよりコンパクトでなくても、より読みやすいです。 ここで「初心者」の間違いを犯していますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.