Re: problem in creating Services

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



I do not consider most MSDN samples as examples of good coding. I more and more believe
that far too many of them were written by summer interns who were not very good
programmers. The presence of assignments embedded in if-statements is a strong indication
that the code was written by beginners. I found one article which "fixed" a problem by
solving one bug and introducing about six. Even when I fixed the five obvious bugs, it
still didn't work, and I found that the fundamental code was simply WRONG. I find that
every MSDN example, if it is to be reused, takes very careful reading, and usually some
rework (most are not as egregiously bad as kb192570, but some are not far behind it. It
took me five solid years of effort to kill off the FindWindow-solution for preventing
multiple instances, and it took sending a link to my essay to my MVP lead before we
actually got it removed from the MSDN.)

I consider the statement
if(++variable != whatever)
to be equally poor style. The fundamental rule is that side effects in if-statements are
a bad idea, and in whatever guise, they remain a bad idea. Instead of reading and
emulating bad C examples, you would be better served by reading books on good programming
style.

I would have written
++variable;
if(variable != whatever)

to get a side-effect-free if-statement. In an optimizing compiler, both forms will
generate the same code (debug compiler code efficiency is irrelevant).

The other example
array[++index]
is also incredibly bad, and should be used rarely, if at all. That is, consider ANY
statement which includes embedded ++ or - - operations as somewhere between exceptionally
poor style and marginal style, nearly all the time. In very, very rare cases you can
argue that the code makes more sense. But the usual arguments were not based on
readability or ease of programming, but on optimizing the code on the incredibly
brain-dead PDP-11 C compiler. (Most people don't remember that at one time only a++ and
--a were allowable forms, because they could be implemented by the autoincrement and
autodecrement addressing modes of the PDP-11.
mov r0, (r6)++ ; pop top of stack into r0
mov --(r6), r0 ; push r0 onto top of stack
By convention, r6 was used as the stack pointer. r7 was the program counter.

There were no push or pop instructions in the PDP-11 instruction set.

So this generalized to all registers. The idea was that you could declare the indices as
'register' data types and the compiler could then generate good code. Sadly, better
technology than this already existed in optimizing compilers, but the PDP-11 compiler did
NO optimizations, requiring the programmer to do them for it. This resulted in most of
the horrors of the C language, such as the embedded assignments,
autoincrement/autodecrement within indexing modes, the ghastly any-0-value-is-false style
of if-test, and so on. These were all compromises because the compiler was not just a bad
compiler, it was an EXCEPTIONALLY bad compiler, and without all these horrible shortcuts,
it couldn't generate decent code.

The Bliss-11 compiler practiced result register targeting and what we now call frame
pointer optimization and consistently produced far better code than the PDP-11 C compiler
or an assembler language programmer. The generated code was nearly unreadable. Consider
tst 2(r2),(r7)
which tested the 3rd bit of the second 16-bit field of the struct pointed to by r2.
Instead of putting the 16-bit constant 2 into the instruction stream, it reused the 2 used
to compute the offset, which was indirect-off-pc at the time of the operand fetch. The
first time I saw this I thought I'd found a compiler bug, but what I found was a
high-quality peephole optimization. Needless to say, the C compiler was incapable of
doing even an optimization this simple.

Sadly, although the compiler technology matured, the programmers didn't. Books teach bad
habits, code examples teach bad habits, and whenever anyone says "that is bad style" the
justification is "but I saw it in a [book, example, lecture]". So we perpetuate bad
style, and programmers believe that because they see bad style they must emulate it. Like
lemmings, authors follow each other, stealing bad style time after time, thinking it is
showing off something clever. It isn't. It merely demonstrates that no matter how hard
we try, bad program style continues to exist, and indeed is self-perpetuating.
joe

On Mon, 28 May 2007 14:23:54 -0700, "Ashot Geodakov" <a_geodakov@xxxxxxxxxxxxxxxxxx>
wrote:

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:7kql53di6jqe3m33hava0kri01i43vdc5n@xxxxxxxxxx
Putting an assignment inside an if-statement is incredibly poor style.
Write an assignment
statement, then write an if-test. This sort of coding is simply foolish.
It results in
unreadable and perhaps unmaintainable code.

MSDN samples are full of assignments inside if-statements. And I, for
instance, can read them easy. :)

What about
if( ++variable != whatever_constant ),
or
array[++index++] = ...;

Just C, imho. Nothing too hard to read.

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.



Relevant Pages

  • Re: Interesting article by Randall Hyde
    ... as you are the compiler optimization "expert". ... of the work that has gone into creating optimizing compilers. ... > Compilers generate better code than *most* programmers all of the ... learn without needing to know anything about assembly language. ...
    (comp.lang.asm.x86)
  • Re: Interesting article by Randall Hyde
    ... > restatement of a whileloop, ... then most optimizing C compilers are severely ... result that the compiler can determine at compile-time (assuming, ... I'm advocating that programmers take more ...
    (comp.lang.asm.x86)
  • Re: Optimal programming advice
    ... optimizing actual code is a black art. ... For expert programmers: don't do it now! ... Your own experience indicates that this is still very useful advice;) ... I can think of one thing that would help the compiler ...
    (comp.lang.fortran)
  • Re: Brian Kernighan, maybe Im not worthy, maybe Im scum
    ... what experienced programmers do, ... optimization, ... Thugs" ad nauseum fits that a lot more closely than discussing compiler ... be modified outside a loop, and guessing ...
    (comp.programming)
  • Re: "Sorting" assignment
    ... too slow, other times for optimizing too much, some times for being too ... That is a rather bizarre, not-quite-C compiler, but ok. ... The overlap issue is a different problem, but performing a "swap" on ... CPU hardware feature differences that can be incredibly important to ...
    (comp.programming)