Would experienced programmers agree?

Question

I was looking at Javaranch, and found the following stated:
3.1 - Constructs to Avoid
Never use do..while. (examples and reasoning)
Never use return in the middle of a method. (reasoning)
Never use continue. (reasoning)
Never use break other than in a switch statement. (reasoning)
3.2 - Do Not Compound Increment Or Decrement Operators
Use a separate line for an increment or decrement. (examples and reasoning)
Never use pre-increment or pre-decrement (examples and reasoning)
3.3 - Initialization
Declare variables as close as possible to where they are used. (examples)
3.4 - Access
All fields must be private, except for some constants.
The reasonings are pretty good. But I have never come across any textbook that gives the same tips as that at Javaranch? Why is that? Does anyones company also follow the same principles as this Javaranch page?

Answer 1

I was looking at Javaranch, and found the following
stated:MIght help to post the link.
>
3.1 - Constructs to Avoid
Never use do..while. (examples and reasoning)
Never use return in the middle of a method.
(reasoning)
Never use continue. (reasoning)
Never use break other than in a switch statement.
(reasoning)
I disagree.
I do however seldom use any of those.
3.2 - Do Not Compound Increment Or Decrement
Operators
Use a separate line for an increment or decrement.
(examples and reasoning)
Presumably this means something like "doSomething(i++)"
I disagree.
I use syntax like the following (pseudo code) to extract stuff from result sets.
       int i=0;
       string customer = rs.getString(i++);
       string addr1 = rs.getString(i++);
       string addr2 = rs.getString(i++);
Breaking the above into seperate lines would not only make it harder to read it would make it more prone to mistakes when adding or removing a field.
Never use pre-increment or pre-decrement (examples
and reasoning)
3.3 - Initialization
Declare variables as close as possible to where they
are used. (examples)Yes.
3.4 - Access
All fields must be private, except for some
constants.
Nope.
See DTO in the java blueprints.
The reasonings are pretty good. But I have never come
across any textbook that gives the same tips as that
at Javaranch? Why is that? Does anyones company also
follow the same principles as this Javaranch page?Companies? Probably.
Of course there are many companies that think coding guidelines make the code "better" and yet completely ignore process control. Formal process control has been shown to improve in numerous studies to improve code quality while I have never seen a single study that demonstrated that coding guidelines do.