If I come across a non-critical typo in code (say, an errant apostrophe in a print(error) statement), is it worth making a commit to resolve that error, or should it simply be left alone?
Specifically, I'm curious about weighing the gumming-up of the commit log against the value of resolving these non-critical typos. I'm leaning toward resolving them. Am I being pedantic?
My personal feeling is that improving quality is worth the minor inconvenience of an additional commit log entry, even for small improvements. After all, small improvements count a lot when you factor in the broken window effect.
You might want to prefix it with a TRIVIAL: tag, or mark it as trivial if your VCS supports it.
You aren't being pedantic, and it is better to resolve them individually. The more atomic a change is, the better -- you don't want a crashing bug fix to be mixed up with 500 comment/typo changes.
It's always worth it to increase the maintainability of your software.
Just go for it.
... and if you're not the team leader, then check with him/her.
I agree with others that you should at least write something make it distinct from "feature"-related commits, if it's only about fixing an isolated typo.
A common practice is to have some never-dying tasks in your issue tracker to track timeless and endless changes. For instance, it's not uncommon to have a task for:
Just be cautious that these do not get used as throw-away task IDs for just about anything when people get lazy about creating correctly documented tickets. Especially if you reject commits that are not linked to an ID (which is a good thing, but large tasks like these will be even more attractive for lazy developers).
Typos should be added as a commit. Fixing misspelled words or grammatical errors will increase the readability of your code.
Using a commit message such as "Fixed typo" or "Fixed typo in file.c" will help you distinguish these commits from other, major code commits.
Yes, you should absolutely do this, particularly early on in a project.
Why? Two points:
You likely won't know if a typo is "critical" or not until it is too late. Some fixes probably don't get fixed because everyone thinks it won't be a big deal. Until it is.
Fixing a typo early on and deliberately will be much easier than fixing it after several hundred lines of code/function calls have been made with it. Again, temporary hacks can become semi-permanent surprisingly quickly. This is why I have to deal with objects that have both "CollapseAll" AND "ColapseAll" methods.
For grammatical errors that may be seen by an end user, then yes, by all means it is worth making the commit as it is entirely possible that a user or QA may come along and report the error and it would need to be tracked. If it is already fixed then it could expedite the time it takes to resolve the issue.
If it is a grammatical error in comments around the code though, I wouldn't do anything about it unless it is part of changes to the actual code as well in which case you are updating the documentation of the code.
If you're worried about gumming up the commit log, then you're doing something else wrong. :-) Frequent commits are a good thing! I commit typo fixes all the time. Get 'em in the codebase ASAP and speed up the dev cycle!
I commit typo fixes all the time IMO that's worrisome, try to find programmers with better English?
I vote yes. Check them in. I've worked for a company that hated people checking stuff in. I mean almost anything.The code reviews were extensive and so if you checked in a change that just fixed a typo you got moaned at. You can imagine the state of the code. Actually the code wasn't dreadful, but it oozed like treacle rather than flowed like wine.
Does your change management process allow it?
In my environment, every commit I make must be tied back to a change request which has been requested either by the business users or a mandatory system-level change, complete with the corresponding end-user testing processes. A simple typo like you're describing probably wouldn't be logged as either of those (I've found typos & grammatical errors in one of my apps which existed for over 4 years without anyone noticing), so if/when the auditors came calling I'd have a very difficult time explaining myself.
I would save a change like you're describing (and actually have one, as a matter of fact - a method name is mis-spelled and I just discovered it) for a time when I have a "real" change that needs to be made as well and put "fixed various typos" in the log.
If you are concerned about a clean commit history, consider doing your main work in feature branches. If you happen to work with a distributed VCS, you can easily edit your commit history before pushing it to the main branch. If you are on SVN, try Git -- it can interact bidirectionally with Subversion, and you can also edit history before actually committing to Subversion.
If you don't want to or cannot edit commit history, there is no functional reason to do an early or an atomic commit for a minor typo that does not affect automatic tests or compilation. In this cases, in my opinion, keeping the commit history clean should be more important than doing really atomic commits. Mixing one or two typo corrections with a "regular" modification won't harm any potential review process. You might however want to group several trivial corrections into one commit, perhaps when "cleaning up" after a bigger coding session.
Note that functional bugs still should be committed ASAP in an atomic commit.
The general tone of the answers here seems to suggest a "commit everything fast" strategy even for minor typos. I tend to disagree and welcome discussion.
