To dot, or not to dot?

mvtab · 2025-12-14 13:08:27

I am in a very long "internal conflict" about a very simple question and I keep switching sides with no reason:
Should one end sentences/words in comments with dot or not? (in Bash)

My dilemma:

In long phases it makes perfect sense:
# Some very important detail about this line.
vs
# Some very important detail about this line

In very short ones not:
# Core.
vs
# Core

I am already mixing them a lot as I already mentioned, was just wondering if any of you actually came to a standard?

system72 · 2025-12-14 13:23:23

without the dot it looks better

mithrial · 2025-12-14 13:40:27

If the sentences are proper English sentences, the they should end with a full stop.

dimich · 2025-12-14 18:24:32

I have the same dilemma. Usually solve it like this: if it's a single sentence like a title or chapter name in a book, then no dot. If there are multiple sentences, then separate them with dots and dot in the end.

ReDress · 2025-12-15 17:48:52

Comments are passive statements.

I believe it doesn't matter how you make them

seth · 2025-12-15 18:09:13

I just learned not to care \o/

Usually I don't use sentence periods in one-liners
Only commas if necessary for clarity (and also probably wrongly) and exclamation points (in bulk) or question marks (dto)
And "fuck" and other curses. Also usually in bulk.

If you're writing a meaningful, lengthy comment that's supposed to be read by other developers you should care about proper English and punctuation.
If it's just an off-hand remark it's enough if everybody seeing it gets the message.

mvtab · 2025-12-20 16:19:53

Ok so my "internal conflict" is actually the standard, good to know Thanks for the inputs I'll keep free-styling it then!

mountaintrek · 2025-12-24 04:09:44

See comment section in Google Shell Style Guide.

Whatever you do, be consistent

Read lots of code, especially projects. Most have standards and guides, for example Linux kernel coding style.

mesaprotector · 2025-12-24 17:36:29

I normally do punctuate, influenced by my time reading config files... /etc/postfix/main.cf and the like tend to come with rather lengthy explanations that can stretch to multiple sentences. I'm the only one reading the vast majority of my code but it feels like good "discipline" to write code as if it'll be read by others.

At least compared to the disaster that is how I name files (why.txt, UGH, and ineedsleep are all in my personal documents archive).

Some people prefer to comment more tersely (a few words), and I've even seen the opinion that code shouldn't have comments at all—everything should be clear from variable names and the structure of the program. Though that feels unrealistic to me.

ReDress · 2025-12-24 17:52:44

mesaprotector wrote:

I'm the only one reading the vast majority of my code but it feels like good "discipline" to write code as if it'll be read by others.

I generally feel like quality code is very important, even if you're the only person who will be reading this code.

A vast majority of time, effort and other resources usually are spent maintaining the code than actually developing it.

If you do the math, then becomes quite clear that good coding habits are actually worth the time.

ewaller · 2025-12-24 18:05:22

ReDress wrote:

mesaprotector wrote:
I'm the only one reading the vast majority of my code but it feels like good "discipline" to write code as if it'll be read by others.
I generally feel like quality code is very important, even if you're the only person who will be reading this code.

I am always amused when I read my own code several years later and I find a comment written to my future self reminding me of why I did something a particular way.

Succulent of your garden · Yesterday 00:31:01

mesaprotector wrote:

At least compared to the disaster that is how I name files (why.txt, UGH, and ineedsleep are all in my personal documents archive)

I imagined a folder with a lot of UGH files on it, more like UGH1 UGH2 and so on and so on with a low voice pitch complaining sound and neuron synapse delay on it. Make me laugh a bit while imagine it while instantly reading your post

Nobody has been so annoying to put in the code format guidelines of a project that you should end your comments with a dot or without it ? I mean the Linux kernel have an standard and your PR can be the most beautiful PR ever made to the project but if it does lack the "standard in how the things are done in the Linux Kernel development" is gonna be rejected probably with someone telling to adjust to the code "standard". I never heard about anyone denying a PR because it lacks the dot at the end or no over here we don't make the comment ending with a dot

I guess is not important, and probably over commenting the code is far more worse. But I do tend to put the dot in long comments. I think is more like a signal to other like: Hey the reading about the comment has ended you are going to see again more code. But i think the most important thing is to find people who want to think with the code with you and questing you why are you doing the things that way if you can do it in another way, and add value to the project because of that. Instead of just: Here are the features, just do it i don't care how.

Last edited by Succulent of your garden (Yesterday 00:31:41)

Arch Linux

#1 2025-12-14 13:08:27

To dot, or not to dot?

#2 2025-12-14 13:23:23

Re: To dot, or not to dot?

#3 2025-12-14 13:40:27

Re: To dot, or not to dot?

#4 2025-12-14 18:24:32

Re: To dot, or not to dot?

#5 2025-12-15 17:48:52

Re: To dot, or not to dot?

#6 2025-12-15 18:09:13

Re: To dot, or not to dot?

#7 2025-12-20 16:19:53

Re: To dot, or not to dot?

#8 2025-12-24 04:09:44

Re: To dot, or not to dot?

#9 2025-12-24 17:36:29

Re: To dot, or not to dot?

#10 2025-12-24 17:52:44

Re: To dot, or not to dot?

#11 2025-12-24 18:05:22

Re: To dot, or not to dot?

#12 Yesterday 00:31:01

Re: To dot, or not to dot?

Board footer