James Youngman wrote: > On Sun, Apr 11, 2010 at 1:08 PM, Bruno Haible <[email protected]> wrote: >> James Youngman wrote: >>> * lib/close-stream.c (close_stream): Make boolean variables const >>> to document the fact that we set but do not change them. >>> --- a/lib/close-stream.c >>> +++ b/lib/close-stream.c >>> @@ -55,9 +55,9 @@ >>> int >>> close_stream (FILE *stream) >>> { >>> - bool some_pending = (__fpending (stream) != 0); >>> - bool prev_fail = (ferror (stream) != 0); >>> - bool fclose_fail = (fclose (stream) != 0); >>> + const bool some_pending = (__fpending (stream) != 0); >>> + const bool prev_fail = (ferror (stream) != 0); >>> + const bool fclose_fail = (fclose (stream) != 0); >> >> There are programming languages where this style of using 'const' may >> be customary (like C++ or Java), but I don't think it helps in C code: >> 1) For the person reading the code, it draws the attention away from >> more importants parts of the code. > > On the contrary, it's a signal that there is no need to consider > changes to the values of those variables in the later code.
While "const" on a pointer is even more useful, I do find the "const" annotation to be useful also on scalars. When we declare a pointer to be const, it protects the careless maintainer from directly modifying anything through that pointer, as well as from using it as an argument to a function that expects a non-const parameter in that position. With a const scalar, we get only the first. The "const"-on-a-scalar also improves readability, by declaring the intent of the author. Even if you use an IDE with enough static analysis smarts to derive that a scalar is currently constant, that is not the same, and may not reflect #ifdef'd code that *does* modify it.
