問題タブ [code-readability]

私は最近、当社に一連のコーディング ガイドラインがあることを発見しました (ドキュメント管理システムに隠されているため、誰も見つけることができません)。それは一般的にかなり賢明に見え、「{」をどこに置くか、ハードタブを使用するかどうかについての通常の宗教戦争から遠ざけます. ただし、「行に複数のスペースを埋め込んではならない」ことを示唆しています。つまり、このようなことをしないでください。

またはこれ：

またはこれ：

これは、1 つの行を変更すると、多くの場合、すべての行を編集する必要があるためです。これにより、変更がより困難になり、差分を理解するのが難しくなります。

私は引き裂かれています。一方では、このように並べると、繰り返しコードが読みやすくなります。一方で、差分が読みにくくなります。

これについてどう思いますか。

System.Data.Odbc や System.Data.OracleClient などの名前空間を使用する場合、通常、さまざまなデータ リーダー メソッドでは、列に対応する整数を関数に提供する必要があります (例: OracleDataReader.GetInt32 )。

私の質問はこれです。コードがかなり自己文書化されるように、これらの関数を操作する最良の方法は何ですか。現時点では、次の 3 つのオプションがあるように思われます。

これらの手法にはそれぞれ長所と短所があるようで、他の人がどう思うか、またはそれを行うより良い方法があるかどうかに興味があります.

最終的に、コードは (最終的に) CPU の命令にコンパイルされます。ただし、コードは (私の謙虚な意見では) 人間が読み取り、更新し、対話するためのものです。これは、次の観察につながります。

たとえ機能していたとしても、他のエンジニアが読めないコードは悪いコードです。

このことを念頭に置いて、コードを人間が読みやすくするために、このプログラマーは何ができるでしょうか?

• 命名規則？（ジョエルはそれについてかなりのことを言っています）

• コード構造/レイアウト? {(神様の愛のために、配置の議論に参加しないでください)

• 言い回し？(より英語に近いコードを書くことは可能ですか)

Joel以外にも優れた記事はありますか。

選択した IDE で「View Right Margin」を有効にすると、デフォルトで 80 文字になる可能性があります。私は、数年前にいた会社の標準であり、他の会社から別の方法に変更するように言われたという理由以外に、120 に変更する傾向があります。

私の質問は、実際に 80 文字がコードの読みやすさの最適な最大幅であることを示す研究はありますか、それともこの値は単に「これまでどおり」であり、その理由を誰も本当に知らないのでしょうか? また、コード行の幅をコーディング標準の一部にする必要がありますか?

次の行を検討してください。

明らかに、この行は潜在的なバグであり、属性がバグである可能性がnullあり、NullPointerException. したがって、次の 2 つの選択肢のいずれかにリファクタリングする必要があります。

最初のオプション:

2 番目のオプション:

最初のオプションは読みにくいですが、より簡潔です。2 番目のオプションは意図は明確ですが、冗長です。

読みやすさの観点から、どのオプションを好みますか?

たとえば、ブログ ソフトウェアを作成していて、エントリに付けられたコメントの数を表示したいとします。あなたはこのようにするかもしれません：

次のような結果になる可能性があります。

しかし、エントリにコメントが 1 つしかない場合は、その行に「コメント」ではなく「コメント」と表示する必要があります。そして in-lineif/elseは醜くて反復的です。

これに対処する最善の方法は何ですか？

変数が2つの異なる値を持つ可能性があり、一方が何かを実行し、もう一方が異なる場合は、次のようにします。

またはあなたはしますか：

明確にするために、読者が必ずしも同じことをしているとは言えない状況では（ただし、「不要な」表現をしている場合はそうではありません）？それで、あなたは何をしますか？ありがとう！

編集：実際には、このようなものにはもっと多くの異なるオプションがあります：三項演算子、if-else、if-elseif、if-elseif-else、-if-else（assert付き）、スイッチ。それぞれに場所がありますが、決めるのは難しいです。

「コードの賞賛」の問題を論じている記事を見つけました。基本的に、著者は、開発者が自分が作成するコードについてより懐疑的になる方法について語っています。コードを「賞賛」しすぎて、コードに自分自身を結びつけ、目の前にある可能性のあるバグやその他の事故に対して脆弱になる方法。

この問題についてどう思いますか。また、この問題を回避する/意識する方法について、さらにヒントはありますか?

私は Lucene 2.9 とやり直し tokenstream API の違いを調べてきましたが、古いものと比べて特に醜いのは、トークンを再利用する場合に新しいものを返すか、指定された値を再入力するだけだと思います。

私はプロファイリングを行っていませんが、MAP を使用して属性を格納することは効率的ではないようで、値などを保持する新しい値の型を作成する方が簡単です。TokenStream と属性のものは、ほとんど必要のないオブジェクト プールのように見えます最近では、テキストのトークンのような単純な値の型が対象です。

Option[T]for some 型Tを使用していて、オプションの値を特定の値に対してテストしたいと思うことがよくあります。例えば：

次のコードは同等で、オプションの値の存在をテストする要件を削除します。

しかし、これは私には読みにくいようです。その他の可能性は次のとおりです。

しかし、これらが意図を明確に表現しているとは思いません。

誰かがこのテストを行うためのより良い方法を持っていますか?