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

私は、会社や特定のプロジェクトの開発者向けにコーディングルールを設けるという考えを常にサポートしていました。特に、会社の規模が10を超える場合は、会社が大きくなるほどニーズも大きくなります。私は多くの人が意見を異にするだろうことを知っていますが、それらを持たないプロジェクトを見たことがあり、コードは完全な災害のように見えます。 これから来る本当の問題は、ifステートメントで角かっこを使用したくない、またはコード内のどこでも同じ接続文字列を使用したくない、またはそれらを反対にせずにコーディングルールを使用したくない頭のいいものを作成する方法ですアイデア？

10 coding  coding-standards  coding-style  company 

「ヘッダーコメント」の形式はプログラマーによって異なることに気づきましたが、「良い」ヘッダーコメントの例は何でしょうか？

10 c++  coding-style  comments  code-formatting  headers 

私と私の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 コード管理とスケーラビリティの点でより正しいものは何ですか？ 現在、両方のアプローチを組み合わせており、矛盾が生じ始めています

9 java  coding-style  coding-standards  naming  conventions 

データベースから2人に基づいて挨拶文を作成する方法を作成しています。 4つのパラメーターがあります。2つの名前（name1およびname2）および2つの性別（genderおよびgender2）です。 性別の組み合わせごとに、ある種の異なる出力があります。 たとえば、性別1がM（男性）で、性別2もであるM場合、出力は次のようになります。 Dear Sir name1 and Sir name2, 現時点では、私のスイッチは次のようになります。 switch(gender1){ case 'M': switch(gender2){ case 'M': printf("Dear Sir %s and Sir %s", name1, name2); break; case 'W': printf("Dear Sir %s and Madame %s", name1, name2); break; case 'R': ... } break; case 'W': switch(gender2){ case 'M': printf("Dear Madame %s …

9 design-patterns  coding-style  clean-code  switch-statement 

私が最近大企業で働いていたときに、プログラマーがこのコーディングスタイルに従っていることに気づきました。 入力がAの場合は12、入力がBの場合は21、入力がCの場合は45を返す関数があるとします。 だから私は関数のシグネチャを次のように書くことができます： int foo(String s){ if(s.equals("A")) return 12; else if(s.equals("B")) return 21; else if(s.equals("C")) return 45; else throw new RuntimeException("Invalid input to function foo"); } しかし、コードレビューで、関数を次のように変更するように求められました。 int foo(String s){ HashMap<String, Integer> map = new HashMap<String, Integer>(); map.put("A", 12); map.put("B", 21); map.put("C", 45); return map.get(s); } 2番目のコードが最初のコードよりも優れている理由を私は納得できません。2番目のコードの実行には、間違いなく時間がかかります。 2番目のコードを使用する唯一の理由は、コードが読みやすくなることです。しかし、関数が何度も呼び出される場合、2番目の関数はそれを呼び出すユーティリティの実行時間を遅くしませんか？ これについてどう思う？

9 coding-style  coding-standards 

私は、いくつかのCライブラリを含むいくつかのライブラリを使用するいくつかのC ++コードに取り組んでいますが、それらはすべて異なるコーディングスタイルを持っています。使用可能な段階に達すると、オープンソースになります。コードをチェックアウトして1つのバグを修正したり、1つの機能を追加したりする短期間の寄稿者の混乱を最小限に抑えるのはどれですか。 使用されるライブラリの一般的なコーディングスタイルと一致しない場合がある場合でも、アプリケーション全体で1つの一貫したコーディングスタイルを使用します。 ライブラリが特定のモジュールで頻繁に使用される場合、そのモジュールのそのライブラリの一般的なコーディングスタイル（ライブラリの独自のコードやドキュメントで使用されているコーディングスタイル）に準拠します。 私の考えでは、後者を使用すると、その特定のライブラリーの専門家が1回限りの貢献をしやすくなり、開発中にチュートリアル/サンプルコードを組み込むのが容易になります。ただし、アプリケーション全体でコーディングスタイルに一貫性がなくなります。各アプローチの長所と短所は何ですか？

9 coding-style 

私はnodeを使い始めたばかりですが、すぐに気付いたのは、コールバックが愚かなレベルのインデントまでどれだけ速く構築できるかです。 doStuff(arg1, arg2, function(err, result) { doMoreStuff(arg3, arg4, function(err, result) { doEvenMoreStuff(arg5, arg6, function(err, result) { omgHowDidIGetHere(); }); }); }); 公式のスタイルガイドは別の関数内の各コールバックを置くことを言いますが、それは、オブジェクトがすべてを通過する必要があるように、単一のオブジェクトは、利用可能ないくつかの層下にトップレベルで宣言されたクロージャの使用に過度に制限的と思われる、となってい中間コールバック。 ここで助けるために関数スコープを使用しても大丈夫ですか？グローバルっぽいオブジェクトへのアクセスを必要とするすべてのコールバック関数を、そのオブジェクトを宣言する関数の中に置いて、クロージャーに入りますか？ function topLevelFunction(globalishObject, callback) { function doMoreStuffImpl(err, result) { doMoreStuff(arg5, arg6, function(err, result) { callback(null, globalishObject); }); } doStuff(arg1, arg2, doMoreStuffImpl); } など、さらにいくつかのレイヤーについて... または、すべてのコールバックごとに名前付き関数を宣言せずにインデントのレベルを下げるのに役立つフレームワークなどはありますか？コールバックピラミッドをどのように扱いますか？

9 node.js  coding-style 

私が参加しているR＆Dチームは、コーディング標準を採用することを決定しました。私たちが最近結成したばかりであり、コードと共通のコーディング時間が少なすぎて、チームで有機的に開発されたもの、および独自のコードからの良い例などに基づいて標準/規約のドキュメントを作成できません。 今、私たち一人ひとりが過去の職場での経験を持っていますが、「ここで行うこの種の仕事にふさわしいことがわかった、この包括的なドキュメントをここで採用しましょう」と言っている人はいません（*）。さらに、一部の私（自分自身を含む）は、公式のコーディング標準がない場所、または別の設定で別の言語で作成した経験のみを持っています（より研究指向の開発作業ではなく、週ごとの高圧の本番環境）。 したがって、私が考えていたオプションの1つは、比較的よく知られていて評判の高いドキュメントを取り上げ、私たちが気にしていない/気にしていないものを切り取り、好みに基づいていくつかの変更を加えることです。 これは一般的な方法ですか？これは良いアイデアだと思いますか？もしそうなら、合理的な「ベースライン」コーディング標準とは何でしょうか（どちらが最善か教えてください、ここで宗教的対立を始めたくありません。包括的または「中立」に基づいて構築できるものを指摘してください） 。） ノート： C、C ++、OpenCL、CUDA、Pythonで動作することを期待しています。 私たちは4人のチームとマネージャーのチームで、1年程度で5〜6人に成長すると予想されています。 私たちの会社では、チームはほぼ完全に自律的であり、通常はまったく相互作用しません（お互いのコードを使用することによってさえも-作業は完全に異なるプロジェクトにあります）。そう-全社的な考慮事項はありません。 ツールに関しては、現時点ではEclipseを使用することがわかっているため、そのコードフォーマッターは少なくとも1つのツールになります。Ctrl + Shift + Fは長い間私の友人です 私がJavaを書くとき、私はBlochの効果的なJavaにできる限り厳密に従うことを採用しました。さて、それは完全なコーディング標準ではありませんが、コーディング標準のレンガ、セメント、モルタルを呼び出すことができます。そのようなものを「ミックス」の一部として含めることを考えていました（Javaは実行しないことに注意してください）。 より広い意味でのコーディング標準を意味します。たとえば、このP.SEの質問に対する回答で行われた提案を採用します。 C ++コーディング標準ドキュメントの大きなリストを見つけました。多分私は私たちのベースラインを採掘するべきです。 （*）それはまったく真実ではありませんが、私はこの質問をあまりにも多くの詳細で複雑にしたくありません。

9 c++  c  coding-style  coding-standards  team 

私はJavaからセミコロンでステートメントを区切るのに慣れているので、当然Scalaコードでもそれを行います。また、1つのステートメントが終了し、別のステートメントが開始する場所が明らかであるため、コードが読みやすいと感じています。しかし、SOにScalaコードを投稿すると、セミコロンを削除するためにコードが編集されることがよくあります。 セミコロンを使用する必要がありますか？「公式」のガイドラインやコーディングスタイルはありますか？ セミコロンが必要な場合はありますが、それ以外の場合はコードがあいまいですか？

9 coding-style  scala 

#includeHPPファイルを介して既に何がインクルードされているかに関係なく、CPPファイルで使用されるすべてのタイプのヘッダーには、一般的には良い習慣だと思います。#include <string>たとえば、CPPでスキップした場合でもコンパイルできたとしても、HPPとCPPの両方で使用する可能性があります。これにより、HPPがフォワード宣言を使用したかどうかを心配する必要がなくなります。 この#includeコーディングスタイルを適用できるツールはありますか？このコーディングスタイルを適用する必要がありますか？ プリプロセッサー/コンパイラーは#includeHPPからのものかCPPからのものかを気にしないので、このスタイルに従うのを忘れてもフィードバックは得られません。

9 c++  coding-style  include 

私はあなたが書くことができることを学びました '{}{}'.format(string_a, string_b) の代わりに '{0}{1}'.format(string_a, string_b) Pythonでは、順番に1つずつスロット化したい場合は、文字列フォーマットパラメータの数字を省略できます。 これはPythonicと見なされますか？ 注：「Pythonic」は慣用的なPythonコードを意味するPythonプログラマの間で一般的に使用される用語です。Pythonカルチャー内では、スタイルの質問について明確なコンセンサスが得られる傾向があります。特に、このような非常に具体的な質問の場合、「それを行うには1つ、できれば1つだけの明白な方法があるはずです」という言語の明確な設計哲学を考えると、これは、「Pythonの禅」から引用されています。これは、「Pythonic」とは何かを定義するのに大いに役立つ一連の格言であり、Pythonのすべてのディストリビューションに含まれています（Pythonインタープリターのコマンドラインで入力import thisして確認してください）。

9 coding-style  python 

次のコードを検討してください。 if (x == 1) { throw "no good; aborting" ; } [... more code ...] 今、このコードを考えてみましょう： if (x == 1) { throw "no good; aborting" ; } else { [... more code ...] } 2つのケースはまったく同じように機能します。最初のケースには、のコードの残りの部分を「囲む」必要がないという利点がありますelse。2番目の方法には、elsefor every を明示的に持つという慣例に従うという利点がありますif。 誰かが一方を他方に有利に支持するような確かな議論を提供できますか？

9 coding-style  exceptions 

数週間で私のプロジェクトは完成し、他の人が使用できるように私のコードを準備し始めたいと思います。 私はすべてをGitHubに投稿して、人々がそれを調整して、うまくいけばそれをより良くすることができるようにします。 私が求めているのは、他の人が使用できるように私のコードが十分に文書化され、正しく記述されていることを確認するための最良の方法は何でしょうか？ 私はあなたが常にすべてをコメントする必要があることを知っています、そして私はすべてのメソッドに対して@params機能を入れようとしていますが、一般的に他のヒントはありますか？

9 coding-style  coding-standards  github 

ページが読み込まれたときに物事を初期化するために使用されるいくつかのコードがあるとしましょう、それは次のようになります： function initStuff() { ...} ... $(document).ready(initStuff); initStuff関数は、スニペットの3行目からのみ呼び出されます。二度と。したがって、通常、これは次のような匿名のコールバックに入れられます。 $(document).ready(function() { //Body of initStuff }); 関数をコード内の専用の場所に置くことは、ready（）の呼び出しでこれが初期化コードであることを明確にするため、実際には読みやすさには役立ちません。 どちらか一方を優先する他の理由はありますか？

9 coding-style  jquery 

他のプログラマーのコードを読む際、彼は私が見たことのないフォーマットを使用しています。例えば namespace MyNs.HereWeAre {//tab here for some reason public class SomeClass {//here's another tab public string Method() {//yet another tab string _variable = "";//no tab implementation return _variable; } }//eof - class (Yes these eof comments are on every file) }//eof - namespace // eof - file 私は認めます...このコードは私を怒らせます。このスタイルを実現することは困難です。IDEのビジュアルスタジオが提供するデフォルトのフォーマットと戦う必要があります。 このスタイルには正当な理由があることを知っていれば、この錠剤をもう少し簡単に飲み込むことができます。このスタイルは他のプログラミング言語/ IDEに由来していますか？

9 c#  coding-style