Why would you use the keyword const if you already know variable should be constant?

Apart from specifying to readers of the code that you may cause errors if you modify this variable(you can use comments to do this)

Not "may"; will cause errors in your program.

• A C++ compiler will enforce it with compilation failures and diagnostic messages ("compiler errors"), with no need for comments;
• A C compiler will enforce it for the most part, though its standard library has holes thanks to legacy, such as strchr, and it has some rather lenient implicit conversion rules that can allow you to drop constness without realising it quite easily. However, just because you got a successful compilation doesn't mean that you don't have errors; unfortunately, it does mean that the errors can be subtle bugs in your program, as well as big, spectacular crashes.

Either way, your program is guaranteed to contain an error inside it.

It seems to me that if you don't want a variable modified, simply don't.

Well that's all well and good, but nobody's perfect. Programmers make mistakes. This allows the compiler — which never makes mistakes (at least, not usually) — to point them out to you.

It's of particular use when you're using some data variable many, many lines of code away from where it was created. The further away it is, the easier it is to modify it without realising that you were not supposed to. For large, complex code bases it is simply a must.

You get a new measure of provability, correctness and stability in your code base, as well as a huge chunk off possible causes of really subtle and nasty bugs. There are also vast optimisation opportunities for your compiler (in some cases) when it knows that some value won't change after compilation.

We could list the advantages all day but, really, you won't fully grok it until you've worked on such a codebase.

In fact, in a perfect world, all variables would be const by default, and you would need to declare them with the keyword mutable to be able to change them. C++ is backwards.

At least in C++, const has some uses beyond just documenting your intent to other programmers.

const can also tell the compiler some things. For example, a function that takes a reference, like: void f(T &t); can't accept a temporary object as its parameter. To get it to do so, you need to const qualify the reference, like: void f(T const &t).

Likewise, to invoke a member function on a const object, the member function must be const qualified like: void T::foo() const {}.

In an embedded system, const can mean more still, possibly telling the compiler about where to locate the object in question (putting it in ROM vs. RAM). const by itself isn't necessarily enough tell it "put this object in ROM", but it's still often a prerequisite.

Likewise (under C++11) const tells the compiler about thread safety.

Now, it's undoubtedly true that you could define some other language that (in other ways) bore some resemblance to C or C++ that didn't use const in these ways. The result would be a rather different language from either one though. Without knowing your intent, it's impossible to say how it would turn out, but it might end up closer to Java or C# (for a couple of examples) both of which are somewhat similar to C and C++ in some ways, but not this particular one (i.e., don't use const like C and C++ do).

Besides the usual programming considerations already discussed in other answers, one thing that concerns me is the attitude:

It seems to me that if you don't want a variable modified, simply don't.

A general rule of thumb is that 20% of the cost of writing code is spent in the development phase. The other 80% is spent over the lifetime of the code upgrading it, maintaining it, etc. This means that many other people will work on your code other than yourself.

Time spent during development that avoids problems years later is a good investment. This effort includes: writing comments; defining constants that are constants; and writing explicit code that does not rely on obscure language constructs.

Also, @worlboss, I hear a fair amount of intolerance. As some others have commented, carbon units make mistakes and anything a silicon unit can do to help avoid mistakes is appreciated.