I use javascript:void(0)
.
Three reasons. Encouraging the use of #
amongst a team of developers inevitably leads to some using the return value of the function called like this:
function doSomething() {
//Some code
return false;
}
But then they forget to use return doSomething()
in the onclick and just use doSomething()
.
A second reason for avoiding #
is that the final return false;
will not execute if the called function throws an error. Hence the developers have to also remember to handle any error appropriately in the called function.
A third reason is that there are cases where the onclick
event property is assigned dynamically. I prefer to be able to call a function or assign it dynamically without having to code the function specifically for one method of attachment or another. Hence my onclick
(or on anything) in HTML markup look like this:
onclick="someFunc.call(this)"
OR
onclick="someFunc.apply(this, arguments)"
Using javascript:void(0)
avoids all of the above headaches, and I haven't found any examples of a downside.
So if you're a lone developer then you can clearly make your own choice, but if you work as a team you have to either state:
Use href="#"
, make sure onclick
always contains return false;
at the end, that any called function does not throw an error and if you attach a function dynamically to the onclick
property make sure that as well as not throwing an error it returns false
.
OR
Use href="javascript:void(0)"
The second is clearly much easier to communicate.
I am not sure what you are trying to do. You can implement a do-while loop like this:
while True:
stuff()
if fail_condition:
break
Or:
stuff()
while not fail_condition:
stuff()
What are you doing trying to use a do while loop to print the stuff in the list? Why not just use:
for i in l:
print i
print "done"
Update:
So do you have a list of lines? And you want to keep iterating through it? How about:
for s in l:
while True:
stuff()
# use a "break" instead of s = i.next()
Does that seem like something close to what you would want? With your code example, it would be:
for s in some_list:
while True:
if state is STATE_CODE:
if "//" in s:
tokens.add( TOKEN_COMMENT, s.split( "//" )[1] )
state = STATE_COMMENT
else :
tokens.add( TOKEN_CODE, s )
if state is STATE_COMMENT:
if "//" in s:
tokens.append( TOKEN_COMMENT, s.split( "//" )[1] )
break # get next s
else:
state = STATE_CODE
# re-evaluate same line
# continues automatically
Best Answer
Both loops are infinite, but we can see which one takes more instructions/resources per iteration.
Using gcc, I compiled the two following programs to assembly at varying levels of optimization:
Even with no optimizations (
-O0
), the generated assembly was identical for both programs. Therefore, there is no speed difference between the two loops.For reference, here is the generated assembly (using
gcc main.c -S -masm=intel
with an optimization flag):With
-O0
:With
-O1
:With
-O2
and-O3
(same output):In fact, the assembly generated for the loop is identical for every level of optimization:
The important bits being:
I can't read assembly very well, but this is obviously an unconditional loop. The
jmp
instruction unconditionally resets the program back to the.L2
label without even comparing a value against true, and of course immediately does so again until the program is somehow ended. This directly corresponds to the C/C++ code:Edit:
Interestingly enough, even with no optimizations, the following loops all produced the exact same output (unconditional
jmp
) in assembly:And even to my amazement:
Things get a little more interesting with user-defined functions:
At
-O0
, these two examples actually callx
and perform a comparison for each iteration.First example (returning 1):
Second example (returning
sqrt(7)
):However, at
-O1
and above, they both produce the same assembly as the previous examples (an unconditionaljmp
back to the preceding label).TL;DR
Under GCC, the different loops are compiled to identical assembly. The compiler evaluates the constant values and doesn't bother performing any actual comparison.
The moral of the story is: