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

今日のGUIツールキットの大部分は、Signals + Slotsモデルを使用しています。それを開拓したのは、QtとGTK +でした。 ご存知のように、ウィジェットまたはグラフィカルオブジェクト（場合によっては表示されないものも）がメインループハンドラーに信号を送信します。次に、メインループハンドラーは、そのウィジェット/グラフィカルオブジェクトに割り当てられたイベント、コールバック、またはスロットを呼び出します。通常、virtualすべての事前定義された信号を処理するために、ツールキットによってすでに提供されているデフォルト（およびほとんどの場合）のイベントハンドラーがあります。そのため、開発者がすべてのメッセージに対してメインループ全体とハンドラー全体を記述する必要がありました。 （WINAPIを考えてください）、開発者は新機能を実装するために必要な信号についてのみ心配する必要があります。 現在、私が知る限り、このデザインはほとんどの最新のツールキットで使用されています。Qt、GTK +、FLTKなどがあります。JavaSwingがあります。C＃には言語機能（イベントとデリゲート）さえあり、Windowsフォームはこの設計で開発されました。実際、過去10年間で、このGUIプログラミングの設計は、一種の未記述の標準になりました。それは生産性を高め、より優れた抽象化を提供するためです。 しかし、私の質問は： 現代のGUIプログラミングにとって並列または実用的な代替設計はありますか？ つまり、Signals + Slotsデザインは、町で唯一の実用的なデザインですか？他のデザインでGUIプログラミングを実行することは可能ですか？代替設計に基づいて構築された最新の（できれば成功し、人気のある）GUIツールキットはありますか？

9 design  coding-style  gui 

ifステートメントでtrueまたはfalseの値を返すメソッドを呼び出すのは良い習慣ですか？ このようなもの： private void VerifyAccount() { if (!ValidateCredentials(txtUser.Text, txtPassword.Text)) { MessageBox.Show("Invalid user name or password"); } } private bool ValidateCredentials(string userName, string password) { string existingPassword = GetUserPassword(userName); if (existingPassword == null) return false; var hasher = new Hasher { SaltSize = 16 }; bool passwordsMatch = hasher.CompareStringToHash(password, existingPassword); return …

9 object-oriented  programming-practices  clean-code  coding-style 

私が働いている場所には、変数の宣言の配置に関する明確なガイドラインがあります。それによると、内部ブロック（forループなど）ではなく、グローバルレベルまたは関数の最初にそれらを配置する必要があります。それらは私よりも経験豊富な人たちによって指定されているので、それには正当な理由があるに違いないと私は確信しているが、それが何であるかを理解することはできない。それらをより大きなスコープで宣言させることでコンパイル時/実行時の利点があるかどうかを知るのは良いことです。

9 c  coding-style  declarations 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 特定のファイルのコードの最大行数について、評判の良いソースからの推奨事項を誰かが知っているかどうか知りたいと思いました。たとえば、GoogleのClosure Linterは、各行が80文字を超えないようにすることを推奨しています。

9 coding-style 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 6年前休業。 私はStackoverflowでこの質問をしましたが、それがブーイングする前に、PéterTörökから投稿するのにこれがより良い場所であるかもしれないという有益な提案を受けました。 数年前からJavaでプログラミングしています。私は、「良いスタイル」を構成する要素に基づいて、同僚と設計上の決定についてよく話し合いました。実際、何かが「良いスタイル」であるかどうかに基づいてデザインを検討するStackOverflowの質問/回答がいくつかあります。 しかし、「良いスタイル」を作るものは何ですか？多くのことと同様に、私はそれを見るとそれを知っています...しかし、このデザインは正しくないと感じているという私の良心よりも良い考えを知りたかったのです。 適切に設計された優れたコードを作成するために、あなたは何を考えていますか？ （これはやや主観的なものであることを認めます。「良いスタイル」とは、目前のタスクに依存するためです）。（また、「4ではなく2スペースのインデントを使用する」など、チームスタイルには興味がないことも付け加えておきます。Javaコードの規則には興味がありません。） 編集：これまでのすべての良い答え/コメントをありがとう。私は特に、プログラマーの良心（そして場合によってはお腹も）のレンチを成し遂げることを成文化するのに役立つ答えを求めていますか？

9 java  coding-style 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 私の会社（小規模、3つのオフィスで約40人）は、開発者の1人が技術的なトピックについてのプレゼンテーションを主催する「開発者ワークショップ」をオンラインで行う場合があります。それは必ずしも私たちの仕事に関するものではなく、単に皆が彼らのスキルと理解を向上させるのを助けるためです。 私は次のものをホストするように頼まれました、そしてトピック（私が提供したリストから選ばれました）はコードスタイルとデザインパターンです。私はそれらがそれほど密接に関連していないことを知っていますが、私に耐えます。私のコードベースには改善の余地のある場所がたくさんあります。その一部はDailyWTFに適格な場合さえあるので、このプレゼンテーションをできるだけ効果的にしたいと思っています。問題は、1時間で何をカバーするかが正確にわからないことです。 私の最初のアイデアは、例として独自のコードを使用して、「これを実際に作業に適用してください」という要点を理解することです。しかし、トピックはとても広いです。 私たちのコード（PHP）のいくつかの問題は次のとおりです。 最小限のオブジェクト指向。最近は改善していますが、グローバルな機能はまだたくさんあります。物を見つけるのにしばらく時間がかかります。 グローバル構成（私が推測する意見）。$ GLOBALS ['blah']は、ほぼすべてのファイルに散在しています。 一貫性のないブレーススタイル。最小限に聞こえますが、これにより実際には5日前に構文エラーが発生し、昨日現在でも修正されていません。 非効率な構成。一部の地域での実行時間を70％削減するいくつかの基本的な改善を行うことができました。 私はこのことを、同僚に無礼に聞こえることなく、できる限り役立つものにしたいと考えています。では、「スタイル」のどの側面に焦点を当てるべきか、そしてどのデザインパターンが説明に最も役立つかもしれませんか？

9 education  design-patterns  coding-style  presentation 

これはばかげた質問かもしれませんが、しばらく頭の後ろにいて、他のどこにもまともな答えを見つけることができません。 私には、説明が1つしかない場合でも、各パラメーターと説明を明示的にリストする必要があると言う先生がいます。これは多くの繰り返しにつながります： double MyFunction(const int MyParam); // Function: MyFunction // Summary: Does stuff with MyParam. // Input: int MyParam - The number to do stuff with. // Output: MyParam with stuff done to it. コード内のドキュメントを書くとき、あなたはどのくらい詳細ですか？

9 documentation  comments  coding-style 

私のプログラムは、最初から最後まで一連のステップを実行する必要があります。ただし、異なる入力に基づいて開始点は異なります。たとえば、最初のステップから最後まで実行されるもの、2番目のステップから最後まで実行されるもの、3番目から最後まで実行されるものなどがあります。 シンプルなデザインが必要ですが、現在は次のようなフォールスルースイッチを使用しています。 switch (step) { case 1: //do the 1st step //fall through, so no break here case 2: //do the 2nd step //fall through case 3: //do the 3rd step //fall through ... } それは機能しますが、フォールスルーコードは常に私を不快にします。それを行うためのより良い簡単な方法はありますか？

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

ある日、未使用の変数の警告を消去していましたが、熟考し始めました。それらの問題は何ですか？ 実際、それらの一部はデバッグにも役立ちます（例：例外の詳細を調べる、または返される前に戻り値を確認する）。 私はそれらを持っていることで本当の実際のリスクを見つけることができませんでした。 例 次のような他のプログラマーの注意を引く時間がかかる行を意味するのではありません。 int abc = 7; それは明らかな冗長性と注意散漫です。私は次のようなものを意味します： try { SomeMethod(); } catch (SomeException e) { // here e is unused, but during debug we can inspect exception details DoSomethingAboutIt(); }

9 programming-practices  coding-style  patterns-and-practices  warnings 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 3年前休業。 彼らの言語には、状態を変化させる関数の名前が感嘆符で終わらなければならない慣習があると誰かが言うのを聞いた 私はもっ​​と機能的なコードを書こうとしているのですが、副作用ステータスに従って関数を何とかマークするアイデアが好きです。つまり、なし、内向きの副作用、外向きの副作用（私は正しいfp用語を知らないですが、望む）。 自分の命名スキームを思いつくのは簡単ですが、そのようなスキームや慣習がホームベイクする前にすでに存在しているかどうか疑問に思っていました。 編集：すべての回答に感謝します。それはまさに私が求めていたものであり、それらはすべて本当に有用であることがわかりました。おそらく、古いJavaScriptをリファクタリングしているので、静的に型付けされた言語では、副作用のあるコードとないコードの違いを強制できるかもしれないが、自分で付けた命名規則に頼らなければならないでしょう。 edit2：これを主にオピニオンベースとして閉じるmodについては、私は同意しなければなりません。私は、もしあれば、どのような慣習が一般的に使用されているのかを尋ねていました-これは誰かの定義によると、意見ではなく事実の問題です！

9 coding-style  functional-programming  coding-standards  naming  conventions 

最近の宿題でuglyReceipt(cashParser(cashInput()))は、プログラム自体が完璧に機能する醜い方法で関数を呼び出すことになりましたが、それでも何か間違ったことをしているように感じました。 関数の呼び出しはこのような悪い習慣であり、そうであれば、代わりに何をすべきですか？

9 python  coding-style  code-quality  python-3.x 

注：この質問は、JavaまたはC＃で記述されたコードに関するものです。 私はいくつかの大規模なプロジェクトを管理しており、サードパーティ/ SDKのメソッドで問題（必ずしもバグではない）を発見し、代わりに使用する必要がある独自の拡張機能を作成しました。これらの方法を使用することは、このプロジェクトでは推奨されないことを開発者に覚えておいてください。 独自のライブラリを使用していた場合は、そのメソッドを簡単に削除したり、廃止/非推奨にしたりできますが、自分で作成していないライブラリに対してはそうすることはできません。 例として、2つのオーバーロードを提供するライブラリを使用します。 acme.calculate(int quantity_, double priceInUsDollars_); acme.calculate(int quantity_, string currencyCode_, double priceInCurrency_); 私たちは開発者が常に最初のものを使用して、私たち自身の標準的な為替レートシステムから米ドルで価格を得ることを望んでいます。そして、IDE（Eclipse / Visual Studio）が最初の開発者を使用するときに開発者に警告するのは良いことです。コンパイラの警告でも十分です。 今のところ、現状では、コードレビュー担当者にそのようなエラーを発見してもらう必要があります。ご覧のとおり、これは信頼できるアプローチではありません。 準備ができている1つの方法は、独自のチェックスタイルチェック（http://checkstyle.sourceforge.net/writingchecks.html）を記述することです。でも、何か使えるシンプルなものはないのかと思っていました。私が説明したようなIDE /コンパイラの警告を達成する方法を知っている人はいますか？ IDE /コンパイラ以外のソリューションは大歓迎です。

9 java  c#  coding-style  ide 

次の2種類の実装を検討してください。 public int add(int x, int y) { return mysteriousAdd(x, y); } public int add(int x, int y) { int output = mysteriousAdd(x, y); return output; } 私の同僚は、デバッグ中にmysteriousAdd返される変数を見ることができ、スタックに追加の変数を作成するのはそれほどオーバーヘッドがないため、2番目の実装の方が優れていると述べています。今日のほとんどのコンパイラーは、追加の変数なしでデバッグ中に関数の応答を示すことができ、スタックでの追加の変数の作成も回避しているため、最初の実装の方が適切であり、彼のポイントはそれほど有効ではないと思います。 スタックでの参照変数の作成は安価な操作ですか？上記の2つの方法のうち、コーディングに適しているのはどれですか。その理由は何ですか。

8 java  coding-style  coding-standards 

よると、機能が受け入れるべきか、多くのパラメータにそこガイドラインはありますか？、メソッドにパラメータが多すぎてはいけません。ただし、いくつかの回答は、この問題はビルダーパターンによって解決できることを示唆しています。 Builder b=new Builder(); b.setParm1("a"); b.setParm2("b"); . . . Obj obj=b.createObj(); または、単一のオブジェクトにパラメーターをカプセル化します。 ObjectParam op=new ObjectParam(); op.param1="a"; op.param2="b"; . . . obj.f(op); しかし、それが問題を解決するかどうかは疑わしいです。なぜなら、パラメーターをより適切な方法で（つまり：水平から垂直に）配置する方法だと思いますが、タスクがあまりにも多くのパラメーターに依存するという性質は変わりません。そして、パラメーターのチェーンをより見やすくしたい場合は、各パラメーターに次のような新しい行を使用できます。 https://softwareengineering.stackexchange.com/a/331680/248528 だから私の質問は、「パラメータが多すぎる」は視覚的な問題（コードの長い1行を読み取るのは難しい）ですか、それとも論理的な問題（タスクの性質はパラメータが多すぎるかによって異なり、分解する必要があります）ですか。それが視覚的な問題の詳細である場合、各パラメーターの新しい行で問題が解決されますか？

8 coding-style  parameters 

たまにはこういうコメントをします # We only need to use the following for V4 of the computation. # See APIPROJ-14 for details. または # We only need to use the following for V4 of the computation. # See https://theboringcompany.atlassian.net/browse/DIGIT-827 for details. そうすることに関する私の主な懸念は、JIRAへの依存度が高まることです。そのため、別のプロジェクト管理システムに移行する場合、これらのコメントはまったく意味がありません。近い将来に発生することは予測できませんが、組織コンポーネント（この場合は、コード、コードリポジトリ、プロジェクト管理システム）の結合の増加に引き続き注意します。 ただし、コードベース全体で、文書化された設計の決定と機能のインスピレーションへの参照があることの利点はわかります。私の知る限り、メリットは 設計の決定への明確な道筋。これは、見慣れないコードの特定のセグメントのデバッグと強化に役立ちます。 複数行のコメントが少ないため、コードがよりクリーンになり、新しい貢献者を脅かすことが少なくなります。 （潜在的に）現在の技術的および非技術的利害関係者への明確な道筋 前述の理由により、「なぜここにあるのか」という質問の数は減少しています。

8 project-management  coding-style  communication  comments  jira