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

関数が値のタプルを返すが、それらの値の1つだけが後で使用される状況を処理するための推奨/一般的に受け入れられているコーディングスタイルはありますか呼び出しはおそらく少しやり過ぎです...）？する代わりに a, b, c = foo() そして、andを使用bしないだけcで、次のバリアントのうちどれを優先する必要がありますか（または別のものがありますか？）： バリアント1（アンダースコア） a, _, _ = foo() （これは非常に明確でシンプル_ = gettext.gettextですが、翻訳を使用する多くのアプリケーションでの使用と衝突する可能性があります） バリアント2（ダミー名） a, unused, unused = foo() （あまり魅力的ではない、私は思う、同じような他の名前にも当てはまりますdummy） バリアント3（インデックス） a = foo()[0] （私にとっては、()[0]Pythonに見えない…）

30 python  coding-style 

スタイルが悪いコードを書く傾向がある人と仕事をしているとき、あなたは何をしますか？私が話しているコードは通常、技術的に正しく、合理的に構造化されており、アルゴリズム的にもエレガントかもしれませんが、見た目はいだけです。私たちは持っている： 異なる命名規則とタイトルの混合（underscore_styleおよびcamelCaseおよびUpperCamelおよびCAPSすべては、同じ関数内の異なる変数に多かれ少なかれランダムに適用されます） 奇妙で一貫性のない間隔、例えば Functioncall (arg1 ,arg2,arg3 ); コメントおよび変数名に多くのスペルミスのある単語 私が働いているコードレビューシステムは優れているので、最悪のものを調べて修正することができます。ただし、50行の「ここにスペースを追加します。「イタレーター」を正しく入力してください。この大文字化を変更します。」などの50行で構成されるコードレビューを送信するのは本当にささいなことです。 この種の詳細にもっと注意を払い、一貫性を保つよう、この人にどのように勧めますか？

30 coding-style  code-quality  teamwork  code-reviews 

このプログラミングスタイルのドキュメントには、次のような一般的なルールがあります。 強い個人的な異議がある場合、規則に違反する可能性があります。 これは私が考えている方法と衝突し、コーディングスタイルが実際に重要であると言っている多くの記事があります。たとえば、これは言う： コーディング標準ドキュメントは、開発者にコードの記述方法を伝えます。各開発者が独自のスタイルでコーディングする代わりに、ドキュメントで概説されている標準に従ってすべてのコードを記述します。これにより、大規模なプロジェクトが一貫したスタイルでコーディングされるようになります。パーツが異なるプログラマーによって異なって記述されることはありません。このソリューションはコードを理解しやすくするだけでなく、コードを見た開発者がアプリケーション全体で何を期待するかを確実に知ることができます。 だから、私はこの文書とこの質問の冒頭の引用から何かを誤解していますか？コーディングスタイルを本当に無視できるのでしょうか？ たぶん、私は十分に明確ではなかったので、この編集では、少し明確にするつもりです。 私はチーム用にコーディングスタイルドキュメントを作成していますが、いくつかの静的アナライザーを使用してスタイルを確認したいと思います。失敗すると、Jenkinsはメールを送信します。そして、スタイルが一致しない場合、コードレビューに失敗します。これは明らかに最初の引用と衝突します。 しかし、引用が正しい場合、誰かが望むことを何でもできるなら、コーディングスタイルドキュメントの使用は何ですか？

30 coding-style 

ポインターを宣言するお気に入りの方法は何ですか？ int* i; または int *i; または int * i; または int*i; 理由を説明してください。 参照：http : //www.stroustrup.com/bs_faq2.html#whitespace

30 c  coding-style  pointers 

私は、チームのためにJavaScriptスタイルガイドを作成しています。これにより、ドキュメントをより簡単に整理して投稿できます。しかし、私は私の質問が適用される場所である小さなバンプを打った... すぐに呼び出される匿名JavaScript関数を何と呼ぶべきでしょうか。単純に「匿名関数」と呼ぶことはできますが、すぐに呼び出されるという事実を強調したいと思います。 以下に例を示します。 var MyVariable = (function(data){ return "another value" })("some value"); console.log(MyVariable); // "another value"

29 javascript  coding-style  terminology 

現在、C ++コードでGoogle C ++スタイルガイドを使用していますが、非常に満足しています。 最近、このガイドは非常に悪いと言われました。Googleが内部で使用していることは知っていましたが、時代遅れであり、非常に悪い習慣を助長しています。そこで、別のコーディングスタイルを使用したいと思います。 どのような優れた、かなり使用されているC ++スタイルガイドがありますか？私はgccとVisual Studioの両方のコードを記述し、多くのC ++ 11機能を使用しています。 Google C ++ Style Guideで非常に気に入ったのは、インデント、空白、および命名規則（特に、すべてのクラス、タイプ-typedef、タイプエイリアス、テンプレートエイリアスを含む-最初の文字が大文字）です。 私は答えが主観的であることを知っており（このサイトでこれがOKであることを願っています）、どんな意見も感謝しますが、最近使用されているガイドは興味があります。

29 c++  coding-style  c++11 

プログラマーとしての最初の本当の仕事はありますが、コーディングスタイルが使用されているため、問題を解決できません。ここのコード： コメントはありません 機能がない（50、100、200、300以上の行が順番に実行される） if多数のパスを持つ多数のステートメントを使用します 意味をなさないの変数を持っている（例えば：cf_cfop、CF_Natop、lnom、r_procod） 古い言語（2002年のVisual FoxPro 8）を使用しますが、2007年から新しいリリースがあります。 1970年に戻ったような気がします。OOP、クリーンコード、デザインパターンなどに精通したプログラマーが、この昔ながらの方法でコーディングに問題を抱えることは普通ですか？ 編集：すべての答えは非常に良いです。私の（未）希望として、この種のコードベースは世界中にたくさんあるように見えます。すべての答えに言及されているポイントは、コードのリファクタリングです。ええ、本当にやりたいです。私の個人的なプロジェクトでは、常にこれを行いますが、...コードをリファクタリングすることはできません。プログラマーは、設計されたタスク内のファイルのみを変更できます。 古いコードのすべての変更は、コードにコメントを付けておく必要があります（バージョン管理としてSubversionを使用する場合も含む）。さらに、その変更に関連するメタ情報（日付、プログラマー、タスク）古い行はコメントされました）。これはコードの問題だけでなく、ソフトウェア開発の管理の問題でもあると考えています。

29 coding-style 

SunのJavaコードの規則では、演算子の前に改行を配置することが提案されていますが、他の多くのガイドラインは改行に同意しません。明らかな長所と短所はないので、これらのスタイルの1つを別のスタイルよりも使用する利点はありますか？ String longVarName = a + b + c + d + e + f; 対 String longVarName = a + b + c + d + e + f;

29 java  coding-standards  coding-style 

HTML / CSS開発には多くの類似点があります。初心者にとっては少し混乱するかもしれません。 HTML =基礎/ハウス CSS = walls / blueprint / wallpaper ここにベストプラクティスはありますか？どちらを最初に書くべきですか？

28 coding-style  html  css 

私は数年前からプログラミングをしていて、ジレンマに陥っていることがよくあります。 2つの解決策があります- 一つはシンプルなもの、すなわちシンプルなアプローチであり、理解と保守が容易です。冗長性、余分な作業（余分なIO、余分な処理）が含まれるため、最適なソリューションではありません。 しかし、他は複雑なアプローチを使用し、実装が難しく、多くのモジュール間の相互作用を伴うことが多く、パフォーマンス効率の高いソリューションです。 達成するのに難しいパフォーマンスSLAがなく、シンプルなソリューションでさえパフォーマンスSLAを満たすことができる場合、どのソリューションに取り組むべきですか？簡単な解決策については、仲間の開発者の間で軽disを感じています。 シンプルなソリューションでパフォーマンスSLAを満たすことができる場合、最も最適な複雑なソリューションを考え出すのは良い習慣ですか？

28 design  programming-practices  coding-style  code-quality  performance 

質問： 構文classおよびid値の実用的な考慮事項は何ですか？ たとえば、このブログ投稿で説明されているように、セマンティクス、つまり使用されている実際の単語については聞いていないことに注意してください。命名規則のその側にはすでに多くのリソースがあり、実際には、さまざまな構文上のビットに関する実用的な情報の検索をあいまいにしています：大文字小文字の区別、インターパンクションの使用（特にダッシュ）、使用または回避する特定の文字など- 私がこの質問をしている理由を要約すると： 命名制限にIDとクラスが自然に任意の規則につながりません 命名規則のセマンティック側の豊富なリソースは、構文上の考慮事項の検索をあいまいにします これに関する信頼できる情報源が見つかりませんでした このトピックについては、SEプログラマーに関する質問はまだありませんでした:) 私が使用を検討した慣例のいくつか： UpperCamelCase、主にサーバー側のコーディングからのクロスオーバーの習慣として lowerCamelCase、JavaScript命名規則との一貫性のため css-style-classes、これはcssプロパティの命名と一致しています（ただし、Ctrl + Shift + ArrowKeyでテキストを選択すると迷惑になる場合があります） with_under_scores、私は個人的にあまり使用されていません alllowercase、覚えやすいが、長い名前では読みにくい UPPERCASEFTW、仲間のプログラマを困らせる素晴らしい方法として（おそらく読みやすさのためにオプション4と組み合わせる） そしておそらく、私はいくつかの重要なオプションや組み合わせも省略しました。命名規則にはどのような考慮事項があり、どの規則につながるのでしょうか？

28 coding-style  naming  html  coding-standards  css 

私はかなり若いプログラマーであり、中規模の会社のIT部門で働いています。同僚がいますが、彼は本当に優れたVisual Basic 6プログラマです。そして、私は本当に良いことを意味します。正直に。彼は、最初のコーヒーを手に入れてマシンを起動する必要があるときに、バグをほとんど含まない実用的なアプリケーションを提供できます。彼はちょうどいいです。 事は、私達はチームと協力しており、彼の働き方は完全に時代遅れです。彼はソフトウェアのバージョン管理を信じていません（コードが正しいことを確認するだけであれば、そのナンセンスは必要ありません）。展開を信じていません（実行可能な実行可能ファイルを配信できます。展開方法は、システム管理者が判断するためです）。抽象化を信じていません。（「サブルーチンを作成したい場合は、先に進みますが、そのサブルーチンからサブルーチンを呼び出さないでください。そのように面倒になり、コードを追跡するのが難しくなります。 'または'はい、そのライブラリを使用してそれを行うことができますが、その方法では何が起こっているのか本当に理解していません）」と確かにOOPを信じていません。（VB.netで作業しています） 彼は自分の仕事がとても上手で、私よりも早くアプリケーションを配信できます。しかし、チームでは機能しません。私たちの他のチームメンバーは静かで、発言するのは好きではありませんが、彼は同意する傾向があります。私たちのマネージャーは、私が正当な点を挙げていると思いますが、プログラマーではありません。 私は彼が書いたプログラムを維持するのに本当に苦労しており、それは良いチームの雰囲気にはなりません。私にとって何が一番いいと思いますか？

28 coding-style  teamwork 

Fortifyのような静的コードアナライザーは、finallyブロック内で例外がスローされる可能性があるときに「文句を言う」と言いUsing a throw statement inside a finally block breaks the logical progression through the try-catch-finallyます。通常、私はこれに同意します。しかし最近、私はこのコードに出くわしました： SomeFileWriter writer = null; try { //init the writer //write into the file } catch (...) { //exception handling } finally { if (writer!= null) writer.close(); } をwriter適切に閉じることができない場合、writer.close()メソッドは例外をスローします。（ほとんどの場合）ファイルは書き込み後に保存されなかったため、例外をスローする必要があります。 追加の変数を宣言し、閉じるときにエラーが発生した場合に設定しwriter、finallyブロックの後に例外をスローできます。しかし、このコードは正常に機能し、変更するかどうかはわかりません。 finallyブロック内で例外をスローすることの欠点は何ですか？

27 coding-style  exceptions  exception-handling 

私はこのようなコードをたくさん書いていることに気づきました。 int myFunction(Person* person) { int personIsValid = !(person==NULL); if (personIsValid) { // do some stuff; might be lengthy int myresult = whatever; return myResult; } else { return -1; } } 特に複数のチェックが関係する場合は、かなり面倒になります。そのような場合、次のような代替スタイルを試しました。 int netWorth(Person* person) { if (Person==NULL) { return -1; } if (!(person->isAlive)) { return -1; } int …

27 coding-style  language-agnostic 

メソッドを短くすることについて多くのことを聞き、多くのプログラマーが、メソッド内で#regionタグを使用することは、それが長すぎて複数のメソッドにリファクタリングする必要があることの確かな兆候だと言うことを聞きました。ただし、メソッド内で#regionタグでコードを分離することが、複数のメソッドにリファクタリングするための優れたソリューションである多くの場合があるように思えます。 計算を3つの異なるフェーズに分割できるメソッドがあるとします。さらに、これらの各段階はこのメソッドの計算にのみ関係するため、新しいメソッドに抽出してもコードの再利用はできません。それでは、各フェーズを独自のメソッドに抽出することの利点は何ですか？私が知る限り、私たちが得るのは、読みやすさと、各フェーズの個別の変数スコープです（これにより、特定のフェーズの変更が誤って別のフェーズを壊さないようにすることができます）。 ただし、これらの両方は、各フェーズを独自のメソッドに抽出することなく実現できます。リージョンタグを使用すると、コードを同じように読みやすい形式に折りたたむことができ（コードを展開して調査することにした場合に、このファイルに場所を残す必要がなくなるという追加の利点があります）、単純に各フェーズをラップします{}動作する独自のスコープを作成します。 この方法で行う利点は、実際には4番目のメソッドの内部動作にのみ関連する3つのメソッドでクラスレベルのスコープを汚染しないことです。長いメソッドをすぐに一連の短いメソッドにリファクタリングすることは、時期尚早な最適化と同等のコード再利用のように思えます。多くの場合決して発生しない問題に対処するために、余分な複雑さを導入しています。コードの再利用の機会が生じた場合、後からいつでも独自のメソッドにフェーズの1つを抽出できます。 考え？

27 c#  coding-style