It's another guideline I didn't previously mention.

In theory, it could be considered a corollary to the "assignment and assignment-like ops must be left most op" when you think of function call as a named op. However, I'm pretty sure the people who wrote the guidelines weren't thinking that way. They just were seeking ways to avoid non-obvious side effects.

Do you agree with these guidelines?

I won't argue with you about them. I once (long ago) was expected to work under a set of C programming guidelines that insisted that C header files should be named 'xxxx.C.Header.File'.

It turned out that the job of devising the company's (IBM UK) C programming guidelines had been handed -- by the manager designated to head-up the new project which was their first in C; and whom had never done any C -- to a summer intern (whom had also never done any C). They'd been handed a copy of the companies PL/1 programming guidelines and a copy of "The C programming language" and told to just do it.

It didn't take too long to get some of the more ridiculous ones -- like the file names which the compiler simply couldn't handle -- overturned. Some of the others were directly cribbed from the PL/1 programming standards were harder -- because they were used to them and (presumably) knew their value in that language. It was only when we pointed out that many of them simply had no meaning in the C language that they went out a bought a set of C guidelines from some university.

Not perfect as they were K&R style -- function args named in the parens, but typed between the parens and the opening brace. etc. -- but for the most part, at least familiar.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this

In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

Simple question, complex answer.

Summary: While they do highlight potential issues in code - like "hidden" side effects - some of the guidelines are just plain pedantic for the sake of being pedantic - like ++i vs i++. Some even force extra complexity, like not allowing break or continue (what Perl calls last and next) in loops. And some are just annoying.

While I agree the guidelines represent things we should be careful with, what really bugs me about the guidelines is not the guidelines themselves but that certain people take them as a license to assume we don't know what we are doing and so bludgeon us with the "rules". Yes, we are human and do make mistakes. But, as helpful as reasoned use of the guidelines can be, they don't prevent mistakes. Indeed, a program that is 100% compliant with the guidelines is almost always more complex, so is likely to "hide" more bugs then a reasonably written program where the programmer made no consideration of the guidelines.