Comments: Difference between revisions

From YM2149.org
Jump to navigationJump to search
No edit summary
No edit summary
Line 7: Line 7:
* when working on legacy code, assume it's all there for a reason even if it's bad code
* when working on legacy code, assume it's all there for a reason even if it's bad code
** effectively this is [https://en.wiktionary.org/wiki/Chesterton%27s_fence Chesterton's fence] when the original motivation has been lost
** effectively this is [https://en.wiktionary.org/wiki/Chesterton%27s_fence Chesterton's fence] when the original motivation has been lost
== Although ==
* certain individuals need to be spoon-fed, and will raise a huge damaging stink when they jump to the wrong conclusion, so it's regrettably worth humouring them even though it may patronise others


[[Category:Programming]]
[[Category:Programming]]

Revision as of 18:19, 12 November 2024

  • comments distract from the code and are too easily lost in conflict resolution, or moved in reformatting
    • the initiated do not need to re-read the comments
  • use self-documenting names in preference to comments, add a new function if necessary
    • this is of more use to the uninitiated
  • when working on a ticket, that can be the decision record and commit messages should already refer to it
  • the readme doesn't have to be behind a pull request wall, it can simply contain a link to the wiki to make documentation more inclusive
  • when working on legacy code, assume it's all there for a reason even if it's bad code

Although

  • certain individuals need to be spoon-fed, and will raise a huge damaging stink when they jump to the wrong conclusion, so it's regrettably worth humouring them even though it may patronise others