Please keep code descriptions simple

Lobsters Hottest News

Summary

A developer argues that code descriptions, commit messages, and merge request descriptions should be kept simple and focus on explaining why changes were made, not what, to improve accessibility for reviewers with attention difficulties.

<p><a href="https://lobste.rs/s/y4hgjd/please_keep_code_descriptions_simple">Comments</a></p>
Original Article
View Cached Full Text

Cached at: 06/23/26, 11:45 AM

# Please keep code descriptions simple | AksDev Source: [https://akselmo.dev/posts/please-keep-code-descriptions-simple/](https://akselmo.dev/posts/please-keep-code-descriptions-simple/) Just something I experience more and more these days\. When it comes to reviewing code, the descriptions, commits and such can be massive blast of information: Full of extraneous details depicting what was changed\. The main point is why was something changed\. And often in only one huge commit with massive diffs\. I'm sorry but my poor ADHD brain can't take this very well\. I don't want to read a novel\. Usually blurbs of text are fine: Extraneous detail I can ask about if I need to know\. So this is my plea, from pure accessibility standpoint, to keep commit messages, merge request descriptions and code comments clear, to the point, need\-to\-know basis\. Do not explain what, but why\. Usually the code itself is enough to tell rest of the story\. If not, I will ask questions\. That's why it's a review\. It's easy to think that having huge description with all and everything is the way to go, but it will just make it slower for people like me to review it\. I can barely concentrate already\.\. Then commits should always be atomic, especially during merge review\. Use git amend to make small changes\. Before merging, rebase and clean up, or squash\. But try your best keep commits atomic: changes that can stand alone\. \(Note that this is not aimed at any specific individual, I just finally had brains to write this post since I was reminded of the topic\.\) If you use LLM tools, please still write comments, descriptions, commit messages etc\. yourself\. It helps you to understand whats going on, and it's more accessible for me to review\.*\(Or better yet, try to avoid these tools if you can\. I don't think anyone actually needs them\. You're good enough without, I promise\!\)*

Similar Articles

Stop advertising in your commits

Lobsters Hottest

A discussion on why commit messages should not be used for self-promotion or advertising, focusing on maintaining clear and useful commit history.

Reviewing code requires reading

Lobsters Hottest

A developer blog post argues against the idea of shipping AI-generated code to production without reading it, emphasizing that code review serves critical purposes: diffusing responsibility, reducing bus factor, and maintaining team knowledge of the codebase.

The User Doesn't Care - But you should

Lobsters Hottest

A blog post arguing that while users don't directly care about code internals, good code quality is essential for performance, bug fixes, and feature delivery, contrary to the common cliché that only user-facing results matter.

Always Be Blaming

matklad

The article discusses strategies for reading and understanding code by tracing its evolution through version control, emphasizing the use of `git blame` and the importance of understanding the author's perspective.