タグ付けされた質問 「conventions」

10
職場で確立された慣習に従うためだけに、悪いコーディングスタイルに従うべきですか?
私は約1年間仕事で働いています。私は主にCバックエンドのメソッドを使用するGUIインターフェースで作業しますが、通常は戻り値を除いてそれらを処理する必要はありません。私たちのGUIは、制限があるため、かなり合理的に構成されています。 私は、プログラムのコマンドライン部分に関数を追加する仕事をしました。これらの関数のほとんどは、長さが300行で使いにくいものです。特定のアラーム情報を取得するためにそれらの断片を収集しようとしていますが、整理するのに苦労しています。単一の長い関数でテストを行うことで、テストをより複雑にしていることを知っています。 既存の機能のスタイルに従って、すべてを巨大な機能に保持する必要がありますか、それともアラームを独自の機能にカプセル化する必要がありますか? 現在のコーディング規約に反するのが適切かどうか、または単に弾丸を噛んでコードを少し混乱させて書くべきかどうかはわかりません。 要約すると、私は比較しています showAlarms(){ // tons of code } に対して showAlarms(){ alarm1(); alarm2(); return; } alarm1(){ ... printf(...); return; } 編集:みんなのアドバイスのおかげで、ファクタリングされたコードを設計し、彼らが何をしたいのかを尋ねることに決めました、そして彼らがそれをすべて1つにしたいなら、ファクタリングされたコードから切り取って1に戻すことができます大きな機能。これにより、すべてのコードを単一の定義で必要とする場合でも、簡単に記述してテストできるようになります。 更新:彼らはファクタリングされたコードに満足しており、複数の人がこの前例を設定してくれたことに感謝しています。

6
必要なメソッドパラメータにassertまたはIllegalArgumentExceptionを使用する方が良いですか?
Javaでは、どちらがより強く推奨されますか?その理由は?どちらのタイプも例外をスローするため、それらの処理に関しては同じです。assert少し短くなりますが、それがどれほど重要かはわかりません。 public void doStuff(Object obj) { assert obj != null; ... } 対 public void doStuff(Object obj) { if (obj == null) { throw new IllegalArgumentException("object was null"); } ... }

5
メソッドを引数名(型ではなく)で区別するだけで十分ですか?
メソッドを引数名(型ではなく)で区別するだけで十分ですか、それとも明示的に名前を付ける方がよいでしょうか? たとえば、T Find<T>(int id)VS T FindById<T>(int id)。 ById引数名だけを保持するのではなく、より明示的に名前を付ける(つまり、追加する)正当な理由はありますか? 私が考えることができる理由の1つは、メソッドのシグネチャが同じであるが、意味が異なる場合です。 FindByFirstName(string name) そして FindByLastName(string name)

4
本当に定数にすべて大文字を使用する必要がありますか?
私は主にパイリントを使用してソースコードをリントするPythonプログラマです。1つを除くすべての警告を削除できます:定数の名前が無効です。名前をすべて大文字に変更すると修正されますが、本当にそうすることになっていますか?私がそれを行うと、ほとんどの変数が定数であるため、コードがいように見えます(pylintによると)。


2
DBテーブル名は単数形であるがRESTfulリソースは複数形である必要があると慣習で規定されているのはなぜですか?
少なくともSQLでは、データベーステーブル名は単数形である必要があるという、かなり確立された規則です。この質問と議論をSELECT * FROM user;参照してください。 また、RESTful APIリソース名は複数にする必要があるという確立された規則です。GET /users/123そして、これをPOST /users見てください。 最も単純なデータベースベースのAPIでは、URLのリソースの名前はテーブルになり、URLのデータ要素と要求/応答本文はDBの列に直接マップされます。概念的には、この理論的なAPIを介してデータを操作することと、SQLを介して直接操作することとの間に違いはありません。そして、そのため、間の命名規則の違いuserとはusers私には意味がありません。 概念的に、REST APIとSQLが同じことをしているときに、複数形の違いをどのように正当化できますか?

3
「状態」または「ステータス」?変数名に「状態」という単語を含めるべき場合と、変数名に「状態」という単語を含める必要がある場合 [閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 コードとコードに関連する議論を読んで、「状態」と「状態」という言葉が同じ意味で使われているのをよく目にしますが、次の傾向があるようです。 変数が何かが特定の状態にあることを示す値を保持している場合、その変数の名前には「状態」という単語またはその省略形が含まれていることがよくあります。 ただし、関数の戻り値がそのような状態を示すのに役立つ場合、その値を「ステータスコード」と呼ぶ傾向があります。そして、その値が変数に格納されると、この変数は一般に「ステータス」または類似の名前が付けられます。 単独では大丈夫だと思いますが、前述の変数が実際にはまったく同じである場合、英語(または人間の言語全般)の複雑な複雑さを含む選択を行う必要があります。 2つのあいまいさを解消する際の一般的なコーディング標準または慣習は何ですか?それとも、この2つのうちの1つを常に避けるべきですか? このenglish.stackexchangeの質問も関連があると思います。

3
なぜ木は下に成長するのですか?
なぜコンピューターサイエンスで木が下向きに成長するのですか? 私はそれがプリンタに戻って、木を横断するプログラムが最初にルートを印刷し、遭遇するかもしれない再帰の無限のレベルを表現するために底なしの紙の束の概念を使用していると感じています。 参照: 木は下に向かって成長し、根はページの上部にあり、葉は下にあります 聖なる戦いと平和のための場所から。 慣例により、木は下向きに成長して描かれます ツリーデータ構造に関するWikipediaの記事から。 本物の木は根から空に向かって成長しますが、コンピューターサイエンスの木は根から下に向かって成長します David Schmidtの講義ノートより。

5
enumの文字列表現をより単純にするために、すべて大文字のネーミングに反対してもかまいませんか?
たとえば、列挙型定数にタイトルケースまたはすべて小文字のネーミングを使用する人を見たことがあります。次に例を示します。 enum Color { red, yellow, green; } これによりthrow new IllegalStateException("Light should not be " + color + ".")、たとえば、必要に応じて、文字列形式での作業が簡単になります。 列挙型がの場合、これはより受け入れられるようですがprivate、それでも私はそれが好きではありません。次のように、Stringフィールドを使用してenumコンストラクタを作成し、toStringをオーバーライドしてその名前を返すことができることを知っています。 enum Color { RED("red"), YELLOW("yellow"), GREEN("green"); private final String name; private Color(String name) { this.name = name } @Override public String toString() { return name; } } しかし、それがどれほど長いか見てください。シンプルにしたい小さな列挙型がたくさんある場合、これを続けるのは面倒です。ここでは、型破りなケースフォーマットを使用しても大丈夫ですか?
14 java  conventions  enum 

1
iOS / OSXオープンソースプロジェクトの命名規則
常にではありませんが、ほとんどの場合、作成者の姓と名の頭文字で始まる名前のiOSまたはMac OS Xオープンソースプロジェクトがあります。プロジェクトがNick Leblancによって作成される場合、プロジェクトはとして読み取られNLMyProjectます。 例: Rune MadsenによるRMSwipeTableViewCell、 Ezequiel BecerraによるEBCardCollectionViewLayout、 SDiPhoneVersionセバスチャンDobrincuすることにより、 Leo NatanによるLNNotificationsUI。 それはどこから来たのですか?ある人が最初にこのように書いて、それから他のみんながそれに続きましたか? Appleガイドラインでさえ、それについて何も見つけることができませんでした。そのイディオムはどこにでも書かれていますか?

6
Javascriptの命名規則
私はJavaのバックグラウンドで、JavaScriptを初めて使用しています。次の例のように、単一文字のパラメーター名を使用する多くのJavaScriptメソッドに気付きました。 doSomething(a,b,c) 好きではありませんが、仲間のJavaScript開発者が、これはファイルサイズを小さくするために行われ、JavaScriptファイルをブラウザーに転送する必要があることに気付きました。 それから私は別の開発者と話をしていることに気づきました。Firefoxがページをより速くロードするために変数名を切り捨てる方法を教えてくれました。これはWebブラウザーの標準的なプラクティスですか? JavaScriptでプログラミングする際に従うべきベストプラクティスの命名変換は何ですか?識別子の長さは重要ですか?その場合、どの程度ですか?

4
メソッド名での接続詞の使用が悪い命名規則なのはなぜですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 私のチームでは、数人のソフトウェアアーキテクトと緊密に連携しています。彼らは私たちのプロジェクトのすべての設計決定を承認し、コードレビューなどを行います。 私たちのプロジェクトは、主にSymfony 2フレームワークを使用してPHPで実装されたバックエンド機能で構成されています。そのため、構文的には、コード、命名規則、およびプロジェクト構造は、Javaがどのように見えるかとほぼ同じに見えます(Symfony 2はそのような構造を推奨しています)。Java固有の規則もこのケースに適用されるため(可能であれば)、これについて言及しています。 最近、彼らは私が非常に奇妙だと思うことを提案しました:すべてのメソッドはgetEntityOrNull、例えば、setValueOrExceptionなどの名前に接続詞を持つべきです このような命名規則は私にとって非常に間違っているように感じますが、具体的な議論や、これに特に挑戦するオンラインの記事/ページを思い付くことができません。 私が思いついた唯一のものは: そのような情報は次のように、メソッドの注釈中に存在すべきです@returnか@throws メソッド名に接続詞(「and」、「or」など)を使用すると、通常、単一責任原則が適切に尊重されないことが示唆されます。 この命名規則に対する他の具体的な議論は何ですか?

2
C#プログラミング言語での変数の命名規則[終了]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 変数に関するC#のビデオを見ています。著者はメソッド内で変数を宣言し、次のように名前を付けました。string MyName = "James"; 私の質問は、.Net Frameworkが推奨する規則です。上記の例のようなパスカルケースですか、それともキャメルケースですか?

1
コメントの「TILT」とはどういう意味ですか?
私はRobert C. MartinのClean Codeを読んTILTでいますが、このフレーズは一部のコードサンプルに不可解に表示されています。例(ちなみにJavaです): ... public String errorMessage() { switch (status) { case ErrorCode.OK: // TILT - Should not get here. return ""; case ErrorCode.UNEXPECTED_ARGUMENT: return "Unexpected argument"; case ErrorCode.MISSING_ARGUMENT: return "Missing argument"; ... } ... コンテキストから、TILT到達できない状態であり、コンパイラを満たすためにのみ含まれている状態を指定していると思います(たとえば、上記のコードでは、状態がの場合はエラーメッセージが表示されないためTILT、ErrorCode.OKケースに表示されますOK)が、よく分かりません。 誰かがTILT/の意味が何であるか知っていますか?

3
同じ名前のクラスを処理する方法(異なるパッケージ)
私と私のR&Dチームは、大規模なコードベースを維持しています。ビジネスロジックを複数のパッケージに分割しました。そのうちのいくつかは持っている同じ名前のクラスを。 ご想像のとおり、両方のクラスが同じJavaファイルで参照されている場合、名前は競合します。 例えば: com.myapp.model (package) - Device (class) - ... com.myapp.data (package) - Device (class) - ... これらのケースを処理するためのベストプラクティスは何かについて議論があり、次のオプションが考えられました。 最初のオプション クラスの名前を変更し、接頭辞を追加する ModelDevice DataDevice 2番目のオプション 両方が参照されている場合の完全なパッケージ+クラス名の使用 com.myapp.model.Device com.myapp.data.Device コード管理とスケーラビリティの点でより正しいものは何ですか? 現在、両方のアプローチを組み合わせており、矛盾が生じ始めています

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.