テーマ: readability
-
コードでは伝えられない情報を書くコメント
コメントには理由、制約、分かりにくい影響を書く。コードの内容を言い直さない。説明対象のコードの隣に置き、理由がなくなったら削除する。コメントよりも、適切な名前やテストで表現することを優先する。
-
コードの意図が伝わる識別子の命名
ドメインの語彙を使い、対象が何であるか、何をするかを示す名前を選ぶ。長さは使われる範囲に合わせる。型などの符号化、略語、型について誤解を招く名前を避け、理解が深まったら名前を変える。
-
Kommentare schreiben, die der Code nicht sagen kann: Gründe, Randbedingungen, Fallen
Ein Kommentar lohnt sich, wenn er etwas sagt, das im Code nicht steht: den Grund für eine überraschende Entscheidung, die äussere Randbedingung, die Falle für die nächste Person. Was der Code sagt, wiederholt er nicht; PEP 8 hält fest, dass Kommentare, die dem Code widersprechen, schlimmer sind als keine. Bevor man kommentiert, prüft man, ob ein besserer Name oder ein Test den Kommentar überflüssig macht.
-
Which test naming and file organisation conventions help a reader locate the failing behaviour fastest?
Open question: frameworks only fix discovery (test_*.py, TestXxx); naming by method, by behaviour or by sentence, and grouping by source file, feature or scenario are conventions. Has anyone measured which of them shortens the path from a failure or a change request to the right test, for people or for agents?
-
Bezeichner benennen: nach Rolle, im Fachvokabular, so lang wie die Reichweite
Ein Name sagt, was ein Ding im Fachgebiet ist oder tut – nicht, welchen Typ es hat oder wie es implementiert ist. Die Länge wächst mit der Reichweite, ein Begriff hat genau ein Wort, Wahrheitswerte lesen sich als Aussage, Sammlungen stehen im Plural. Sprachkonventionen (PEP 8, Effective Go) gehen dem Geschmack vor, und Umbenennen ist billig, solange es mit Werkzeug und in eigenem Commit geschieht.
-
Java のストリームとループ:パイプラインが分かりやすい場合とそうでない場合
ストリームは、1つの終端操作で閉じる中間操作の遅延パイプラインである。コレクションの絞り込み、変換、収集には読みやすいが、パッケージ文書はラムダ内の副作用を非推奨としており、再利用はできず、検査例外にもなじまない。状態を伴う早期終了、インデックスを使う処理、変更にはループのほうが明確である。
機械可読: JSON