ノート:例外処理

本文中の注記(コメント)について

本文は注記も含めて合意形成の結果です。提案や主張はノートでお願いします。--Anonymouse jp（会話） 2017年5月9日 (火) 23:28 (UTC)

であれば、合意なしに一方的にコメントを削除するのも避けるべきです。すべての編集者がノートをじっくり読んだ後で本文を編集するとは限らないので、コメントで注意点や反例を本文近くに残しておくのは有用だと思われます。--sygh（会話） 2017年5月10日 (水) 18:10 (UTC)

返信 (Sygh宛) 皆さんが個人の主張を注記と書かれればどうなるでしょうか？syghさんに対立する意見を記述するかもしれません。そして全員がその意見を固持した場合、編集合戦あるいは対立する意見によるチャット状態になるでしょう。複数の対立した意見がならんだ状態が編集者のためになると思われますか?独断の注記を固持すべきではありません。合意を経た注記であれば、それを理由に固持することができ、合意なく変更しようとする人をブロックする事もできます。合意が無い以上固持するのは諦めてください。消された上で重要であるとの判断であればそれをノートに記載して合意を求めてください。コメント依頼からいらっしゃった方も私の主張にご意見があればどうぞ返信ねがいます。--Anonymouse jp（会話） 2017年5月11日 (木) 11:34 (UTC)

読む方を最優先に考えて編集してください

読者がWikipedia内で調べれば解かる表現をして下さい。記事中の「モノリシック仕様の関数」は脚注でいくらモノリシックがひと塊という意味と説明しても「モノリシック仕様の関数」の要件が解らないため何がひと塊なのか読者は理解できません。 読者が何の事を言っているのか混乱する内容で投稿しないで下さい。例外処理#戻り値と例外の箇条書きの下に「上記に関連および複合した派生の問題として、・・・」と説明が続いていますが箇条書きから上のどの部分の説明と繋がっているのか読者が考えこまなければわかりません。箇条書き全体でなく一部に対しての記載であれば項番を振ってどの箇所の説明か記述してください。また、必須ではありませんが箇条書き以下の項目は幾つか独立した段落を集めた文章になっています。小項目に分割できないでしょうか。--Anonymouse jp（会話） 2017年5月9日 (火) 23:36 (UTC)

であれば、なぜ精査・加筆せずにいきなりすべて差し戻しするという強硬手段に訴えたのでしょうか。単に殴られたから殴り返した、という報復行為にしか見えません。また、以前の版に書かれていた、十分な説明のない1ラインコードや、適切な読点や改行も入れずに書き散らした長文や、MSDNの内容を精査せずにうのみにした記述などのほうがよほど「読者」を混乱させ、考え込ませるものだと思います。熟練者、根気強い読者や原典を当たる読者であれば何が言いたいのか概ね理解できるでしょうが、初学者を含めた万人向けを謳うならば、少なくとも何の言語のコードなのかをあらかじめ明記し、可能な限りシンタックスハイライトを使用し、文章の構造に配慮し、また執筆者自身が可能な限り英語原文も参照するべきです。

箇条書きに続く内容をサブ項目に分割するという考えには賛同します。「エラーコードを利用した設計の問題例」などの項目名であればよいのではないでしょうか。ただ、箇条書きについてはむやみに増やすのではなく、シンプルかつ互いに合成不可能な原理および原則のみにとどめるべきだと思われます。本質的な問題点が別の原理・原則に帰結するのであれば、わざわざ箇条を作らず集約するべきです。--sygh（会話） 2017年5月10日 (水) 18:10 (UTC)

返信 (Sygh宛) 説明不足や読点等について。不備があるのであれば差し戻しせず不備の箇所だけを修正してください。ガイドラインにあるように荒らしでもないものを決して取り消してはいけません。--Anonymouse jp（会話） 2017年5月11日 (木) 11:56 (UTC)

返信 (Sygh宛) 一行のコードについて。箇条書きに書くため簡潔に記述する必要があり一行で書きました。処理内容が現実的でなかったのも簡潔に書く為です。箇条書きのガイドラインにもあるように箇条書きは長文を書くべきではありません。箇条書きを読む読者は一言程度を期待しています。箇条書きは簡潔であることが望まれることを留意ください。また言語が解らないなど説明不足があるのでしたら指摘いただければ脚注で補うことができます。指摘があればシンタックスハイライトをつけるこもできたでしょう。編集合戦を繰り返す前に問題の旨をノートに記載してください。--Anonymouse jp（会話） 2017年5月11日 (木) 12:10 (UTC)

返信 (Sygh宛) 取消を取消した旨について。1度取消すにしてもなぜ私が体裁を修正した点を一切反映なさらなかったのでしょう。ガイドラインにあるように荒らしでも無いのに取消す行為は論外ではありますが、取消の件を差し置いても取り消し後の内容に本話題の冒頭に記述した問題があり、文章として読むに耐えられませんでした。同じ事の繰り返しになりますが「読者」のことを考え自分で書いた文章がよめるかどうか見直してください。箇条書きから長文を取り敢えず切り離すのではなく整合性がとれた状態にしてください。また、独自用語や略語は別ですが、追記されていた点については良いと思っています。体裁に改善の余地があるとは思いますが保護が解除されたら追記なさった内容を取り込みましょう。--Anonymouse jp（会話） 2017年5月11日 (木) 12:26 (UTC)

ソースコード改行統一について

中括弧の改行について議論になるため統一を提案致します。意見としてはC#, Javaのような製造元が決まっているものについては開発環境の製造元の記法。C++のように開発環境の製造元が決まっていないものBorland C++やVisual Studioなど複数の統合開発環境で既定となっている改行でよいかと考えています。この規則であれば読者にとって一番慣れ親しんだ表記であり読み易いかと思います。--Anonymouse jp（会話） 2017年5月10日 (水) 11:16 (UTC)

C#言語仕様を管理しているのはMS、Java言語仕様を管理しているのはOracleですが、「製造元」とはいいません。プログラミング言語や開発環境をひっくるめて、ソフトウェアは「製造」するものではなく、「設計」あるいは「開発」するものです。ソフトウェアとPL法との関係は非常に複雑なものとなっています。どうも初学者のように思われますが、「読者」のためにも、できるかぎり正確な用語を使用してください。

C#言語仕様にはコーディング標準は定義されていません。C# Language Specification 5.0に書かれているサンプルも、open braceの位置は型定義とメソッドとでは異なっています。仕様書をできるかぎりコンパクトにまとめる意図があるものと思われます。ただし、MS内部用のルールやNaming Guidelinesは存在します。Java言語にはSunの時代に作成されたJava Code Conventionsがあり、open braceの位置に関しても言及されています。これらの規約はもちろん絶対ではありません。また、Oracle自体はJavaのIDEとしてJDeveloperを手掛けていますが、Javaに対応するIDEにはもっと有名なEclipseなどがあり、事実上標準は1つではありません。C/C++に関しても、IDE云々以前に「プログラミング言語C」「C++の設計と進化」「Effective C++」といったバイブルがありますが、無理に統一する必要はないと思います。少なくともsource/syntaxhighlightタグの中で、もしくは言語ごとに統一されていれば十分ではないでしょうか。C系の言語はいずれもフリーフォーマットなので、あいまいさを排除したうえで、多様性は積極的に認めるべきだと思われます。一点のほころびも許さない、教義以外の価値観を認めない原理主義に陥ると、ものごとの本質が見えなくなります。なお、open braceのために1行費やすスタイルは縦に長くなってしまい、複数の例を比較しづらくなったり、コードとその後に続く解説を対比させづらくなったり、といったデメリットがあります。一方、字下げスタイルの記事に記載されているように、open braceに1行費やすスタイルには確かにメリットもあります。スタイルの統一は大切ですが、だからといって安易に事実上標準や慣例に乗っかるのではなく、そういったメリット・デメリットを考慮して天秤にかけ、臨機応変に対処することのほうが、「読者」のために最も重要となるのではないでしょうか。宗教と同じで、無理に教義を押し付けて統一しようとすると戦争が起こります。もちろん、会社のプロジェクトでコーディング規約が定められている場合は除きますが、そのコーディング規約も安易に標準や慣例に乗っかるべきではなく、きちんと理由や目的をもって定められるべきです。--sygh（会話） 2017年5月10日 (水) 18:10 (UTC)

返信 (Sygh宛) タグごとに書き方を変えるというご意見はわかりました。ただし、表記が統一できていないことを「読者」のためとは言わないでください。表記が統一できていないのは我々編集者の落ち度でしかなく「読者」にとって何の利点もありません。タグごとに書き方を変えるという事は編集者が合意形成を放棄した上で読者に負担をかけているということを忘れないでください。改行統一についてはコメント依頼を投げましたので他の方にご意見をいただくまで保留にしようと思います。それまでは、読者に負担をかけることになりますがタグごとで書き方をあわせることにします。また、タグごとに書き方があっていれば良いと主張されていますので、改行方法を主張する注記は今後やめてくださいますようお願いいたします。--Anonymouse jp（会話） 2017年5月11日 (木) 11:46 (UTC)