Comment On Breaking Out of the Box

I've seen the first one heaps of times, it's not funny...

Is the comments system broken? Or am I the first to reply? :P

What is wrong with the StringToLong method?

The loop just remove all the zeros from the start of the string. (Yes it is a stupid way to do it, but is there something even worse that I am missing?)

I've seen the first one heaps of times, it's not funny...

Bah, that came out wrong, I was meant to say something like "I've seen the first one so many times that it's just not funny any more."

My mind has been boggled by these loops

Curious, what would be a better way to do it?

Bunny:

Curious, what would be a better way to do it?

Should be in reply to:

The loop just remove all the zeros from the start of the string. (Yes it is a stupid way to do it, but is there something even worse that I am missing?)


-Sorry

I might point out that the first function isn't really doing the same thing as a break statement would. When ( condition ) is true in the original WTF, /* something else important */ still happens, whereas with a break it wouldn't. Now I'm not saying that the snippet is the best way of writing it, but it's not as simple as just "use break, dammit"

if ( result == null ) return;
return result;

I don't think this will even compile, as a function either returns something (null OK if it is an object) or doesn't return anything (void return type)

And I'm not going to waste my time checking this.

As for the first one, back in the FORTRAN IV days, I had to use tricks like that; I was pleased with more modern languages and the break statement.

captcha: yummy well, breakfast (eating it while reading wtf) was OK.

long StringToLong( String s )
{
for ( int j = 0 ; (j < s.length()) && ( s.chatAt(0) == '0' ); j++ )
{
s = s.substring(1);

}
return Long.parseLong( s );
}

Dave:

I might point out that the first function isn't really doing the same thing as a break statement would. When ( condition ) is true in the original WTF, /* something else important */ still happens, whereas with a break it wouldn't. Now I'm not saying that the snippet is the best way of writing it, but it's not as simple as just "use break, dammit"

The break goes after the /* something else important */
And I wonder if that code actually uses the value of i, because it will get 11.

Curious, what would be a better way to do it?

How about:

while(s.length() && s.charAt(0) == '0') s = s.substring(1);

chatAt ?

Thats were you get to chat to a string?

Better way (for example):

s = s.replaceAll("^0+",""); // have not tested RegExp

That's why I prefer proper {}'s.. Properly {}'ed:

  foreach ( Term t in current ) 

  {

      if ( category == "" )

      {

          result = t;

          break;

      }

      else if ( t.category == category )

      {

         result = t;

      }

  }

  if ( result == null ) 

  {

    return;

  }

  return result;

It's not _that_ bad - without a break it returns the last item found instead of the first.. ;)

..And shouldn't that be 'charAt' and not 'chatAt'? ;)

nobody:

Dave:

I might point out that the first function isn't really doing the same thing as a break statement would. When ( condition ) is true in the original WTF, /* something else important */ still happens, whereas with a break it wouldn't. Now I'm not saying that the snippet is the best way of writing it, but it's not as simple as just "use break, dammit"

The break goes after the /* something else important */
And I wonder if that code actually uses the value of i, because it will get 11.

Why would it ever be 11?

GettinSadda:

Curious, what would be a better way to do it?

How about:

while(s.length() && s.charAt(0) == '0') s = s.substring(1);

What if s = "0"?

Besides, Long.parseLong is perfectly capable of handling leading 0's on its own.

StringToLong

1) I had no idea that Long.parseLong() couldn't handle leading zeros (I'm guessing that it can)

2) I'd feel really nervous about s.length() as a condition in the for loop since we're modifying the length of s inside the loop. This probably only works because there are more non-zero digits than leading zeros (and because the Long.parseLong() handles leading zeros). For instance, an input of '00001' would reduce to '01', not '1'.

3) What's wrong with a while loop?

while( s.length()> 0 && s.charAt(0) == '0')
s = s.substring(1);
return parse.parseLong(s);

The StringToLong is completely foobar..
Why are they even trying to remove the '0's? Im pretty certain that parseLong will succeed at parsing "0002" and give the same result as with "2".

1) I had no idea that Long.parseLong() couldn't handle leading zeros (I'm guessing that it can)

In Java, JavaScript and others, a leading zero signifies an octal number, just like the prefix "0x" signifies Hex..
Hint: Always specify 10 as the radix.. ;)

What is wrong with the StringToLong method?

The fact that Long.parseLong handles leading zeros:

public class PL {

    public static void main(String[] args) {

        String s = "00004567";

        System.out.println("String '" + s + "' as a long " + Long.parseLong(s));

    }

}

No loop necessary, despite the idiotic posts that use charAt and substring (they're WTF material themselves).

What if the spec was "if condition X occurs, set the value of i to 11, do something-else-important, and exit the loop"?

Another possibility is that the value of I has no bearing in the commented-out parts, but the condition else can only be tested at the point where the if test was inserted.

Without knowing what the removed parts parts do, there is no way of knowing if that is a WTF or not.

captcha:ninjas

long StringToLong (string s){
return Long.valueOf(s).longValue();
}

or

new Long(Long.parseLong(s)).longValue();

Which really shouldn't even be a method and just done inline (in Java 1.5 at least).

In some languages (e.g.: PHP) string-to-long parsing assumes a 'number' with a leading zero to be octal (base-8), in the same way that a 'number' with a leading "0x" is assumed to be hexadecimal (base-16).

So, "010" would return a decimal value of 8, whereas "10" would return a decimal value of (yes, you guessed it) 10.

This looks like Java though -- a quick 30 second look at the API shows that Long.parseLong(String s) ALWAYS assumes decimal. There is a separate Long.parseLong(String s, int radix) that lets you explicitly specify the radix if you need to.

I wonder how many WTFs could be avoided by a quick look at the API... =)

Iteration; see loop

Loop; see Iteration

Trondster:

In Java, JavaScript and others, a leading zero signifies an octal number, just like the prefix "0x" signifies Hex..
Hint: Always specify 10 as the radix.. ;)

Seems my Java is too rusty again.. When parsing, the radix is always 10 by default. However, when specifying literals, like "int foo=010;", you get octal numbers with leading zeros.

However, when parsing numbers in JavaScript, leading zeros indeed signify octal numbers. That's why many poorly written date selectors fail for august and september..

Bunny:

Curious, what would be a better way to do it?

"0001".TrimStart('0');

A regex should also do it, but it's extra effort.

binky:

long StringToLong (string s){
return Long.valueOf(s).longValue();
}

or

new Long(Long.parseLong(s)).longValue();

Which really shouldn't even be a method and just done inline (in Java 1.5 at least).

Oh yeah, forgot about Octal.

How about:

Long.parseLong(s, 10).longValue(); // base 10

I might point out that the first function isn't really doing the same thing as a break statement would. When ( condition ) is true in the original WTF, /* something else important */ still happens, whereas with a break it wouldn't. Now I'm not saying that the snippet is the best way of writing it, but it's not as simple as just "use break, dammit"

The statement

if ( condition ) i = 11;

terminates with a ';' so that /* do something else important */ always gets executed no matter what 'condition' is. Setting i to 11 if 'condition' is true just ensures the loop will terminate (eventually?).

The real WTF is that StringToLong doesn't look for a leading "-" even though it returns a signed value.

rmr:

Besides, Long.parseLong is perfectly capable of handling leading 0's on its own.

I don't know this for a fact or anything, but does Long.parseLong cause the function to interpret strings with leading zeroes as octal?

ParkinT:

Iteration; see loop

Loop; see Iteration

Recursion; see recursion

No, in Java it's always base-10.

Please iterate over the earlier posts once again... =)

Martin:

What is wrong with the StringToLong method?

The loop just remove all the zeros from the start of the string. (Yes it is a stupid way to do it, but is there something even worse that I am missing?)

Yes, the loop does not remove all '0' but instead does remove s.length()/2 rounded up leading zeros.

let it be s="00005"
j=0, s="00005", s.length()=5
j=1, s="0005", s.length()=4
j=2, s="005", s.length()=3
j=3, s="05", s.length()=2
3 > 2 , end of loop

call is then done to Long.parseLong("05");

:D

[quote]In Java, JavaScript and others, a leading zero signifies an octal number[quote]

long foo = 00020; // octal
long bar = Long.parse("00020"); // decimal

assert foo = 16;
assert bar = 20;


Long.parse() assumes a radix of 10 if you don't specify - see the Javadoc.

Perl always win.

#lame code ahead

@twosomething = (1..255);

foreach $ip (@twosomething) {
`pring 192.168.0.$ip`;
}

that way you can have a "named section"

@salesIps = (13..98);

foreach $ip (@salesIP) {
callShutdown($ip);
}

Thats much better than this one (c-ish):

for($t=$minimalSalesIp;$t<=$maxSalesIp;$t++){
callShutdown($t);
}

People whine that Perl is unreadable, but tome can be even more readable than everything else If you try to.

Of course, thinks like Ruby can add something to this...

#Fake Ruby code ahead

salesIp.each {|ip| callShutdown(ip) };

Still.. I think the Perl way is more readable for most people, acustomed to the C way object-less, or acustomed to the poor objectability of Java.

My last job forbade the use of breaks in anything but a switch/case statement.

ParkinT:

Iteration; see loop

Loop; see Iteration

Dammit, now I've got to wait for a stack overflow before I can read the rest of the posts.

captcha: digdug -- an inferior clone of Mr. Do!

Bunny:

Bunny:

Curious, what would be a better way to do it?

Should be in reply to:

The loop just remove all the zeros from the start of the string. (Yes it is a stupid way to do it, but is there something even worse that I am missing?)


-Sorry

Strings in Java are immutable, so every time s = s.substring(1) is called it is creating a brand new string and copying the substring into that new string. If this utility code is running on the server and it's in a high volume application that's a lot of extra load on the garbage collector.

IIRC, also Long.parseLong(s) strips leading zeros. Even if it doesn't, there are far more efficient ways of doing this like scanning through the string looking for the first non-zero character.

TheD:

Why would it ever be 11?

If you incremented "i" inside of the loop. I could see that in something like this:

for (int i = 0; i < myString.length-1; i++) {
if (myString.substring(i,i+1).equals("A")) {
i++;
continue;
}
// blah
}


Note: I didn't say it was a good practice

Dave:

I might point out that the first function isn't really doing the same thing as a break statement would. When ( condition ) is true in the original WTF, /* something else important */ still happens, whereas with a break it wouldn't. Now I'm not saying that the snippet is the best way of writing it, but it's not as simple as just "use break, dammit"

Uh yeah it is, it's just that the break goes after the other important thing...

Martin:

What is wrong with the StringToLong method?

The loop just remove all the zeros from the start of the string. (Yes it is a stupid way to do it, but is there something even worse that I am missing?)

Well the fact that parseLong works without having to strip the leading 0s sure makes me wonder why the hell you'd bother stripping them manually.

Richie:

long StringToLong( String s )
{
for ( int j = 0 ; (j < s.length()) && ( s.chatAt(0) == '0' ); j++ )
{
s = s.substring(1);

}
return Long.parseLong( s );
}

GettinSadda:

Curious, what would be a better way to do it?

How about:

while(s.length() && s.charAt(0) == '0') s = s.substring(1);

shoko:

Better way (for example):

s = s.replaceAll("^0+",""); // have not tested RegExp

Dudes, how about just using

long StringToLong(String s) {

    return Long.parseLong(s);

}

Cause it sure seems to work on my machine...

Trondster:

1) I had no idea that Long.parseLong() couldn't handle leading zeros (I'm guessing that it can)

In Java, JavaScript and others, a leading zero signifies an octal number, just like the prefix "0x" signifies Hex..
Hint: Always specify 10 as the radix.. ;)

Not in Java, or at least not for parseLong: if you don't give a radix, parseLong defauts to base 10, not to the language's parsing of literals, as mentioned in the Javadoc:

Parses the string argument as a signed decimal long. The characters in the string must all be decimal digits, except that the first character may be an ASCII minus sign '-' (\u002D') to indicate a negative value. The resulting long value is returned, exactly as if the argument and the radix 10 were given as arguments to the parseLong(java.lang.String, int) method.

binky:

binky:

long StringToLong (string s){
return Long.valueOf(s).longValue();
}

or

new Long(Long.parseLong(s)).longValue();

Which really shouldn't even be a method and just done inline (in Java 1.5 at least).

Oh yeah, forgot about Octal.

How about:

Long.parseLong(s, 10).longValue(); // base 10

Dude, your code's a trainwreck, Long.parseLong returns a long not a Long, and it defaults to base 10 when no radix is given...

Hux:

rmr:

Besides, Long.parseLong is perfectly capable of handling leading 0's on its own.

I don't know this for a fact or anything, but does Long.parseLong cause the function to interpret strings with leading zeroes as octal?

No it doesn't, go read the damn javadoc already, please.

Kiss the snake

[call_shutdown(ip) for ip in sales_ips]

endless...

I think everyone's forgeting that the best way to solve any problem is a case statement.

int j = 0;

while(s.CharAt(j) == '0')
j++;

switch(j)
{
case 1: s=s.substring(1);break;
case 2: s=s.substring(2);break;
case 3: s=s.substring(3);break;
case 4: s=s.substring(4);braek;
etc...
}

return Long.parseLong(s);

Foo:

Strings in Java are immutable, so every time s = s.substring(1) is called it is creating a brand new string and copying the substring into that new string. If this utility code is running on the server and it's in a high volume application that's a lot of extra load on the garbage collector.

Not exactly. String.substring() uses a package level constructor on the String class that allows a substring to share the data of its parent string. It does not need to copy the data each time because it knows that the object it is passing the data array to is another immutable string. Anyway, that doesn't make the code any less of a wtf since Long.parseLong() could have been used on the string with leading zeroes.

The StringToLong is completely foobar..

'foobar' as in F*cked Object-Oriented Beyond All Reason/Recognition ?

And why does everyone keeps posting the CAPTCHA's? Aren't you guys affraid the Evil Spammers (tm) will make a list and start spamming this forum :)

-Edoode

Shareware:

Perl always win.

#lame code ahead

@twosomething = (1..255);

foreach $ip (@twosomething) {
`pring 192.168.0.$ip`;
}

that way you can have a "named section"

@salesIps = (13..98);

foreach $ip (@salesIP) {
callShutdown($ip);
}

Thats much better than this one (c-ish):

for($t=$minimalSalesIp;$t<=$maxSalesIp;$t++){
callShutdown($t);
}

People whine that Perl is unreadable, but tome can be even more readable than everything else If you try to.

Of course, thinks like Ruby can add something to this...

#Fake Ruby code ahead

salesIp.each {|ip| callShutdown(ip) };

Still.. I think the Perl way is more readable for most people, acustomed to the C way object-less, or acustomed to the poor objectability of Java.

I think I might be part of the problem then. If these loops weren't likely to be expanded on, I'd write them as:

my @twosomething = (1.255);
my @salesIps = (13..98);

`ping 129.168.0.$_` for @twosomething;
callShutdown($_) for @salesIps;


Perl most certainly, doesn't always win though, lets return a reference to a array of upper cased entries in the name column of a database table passed as the only argument.

sub returnUpperCaseNames {

 return [map {uc($_->[0])} @{DB->exec('SELECT name FROM $_[0]')}];

}

Snakelin, I am with ya all the way. Half the comments were a WTF in and of themselves.

Manager: Why set it to 11?
Coder: Well, it would be one better then, wouldn't it?

Bad programmers makes baby Jesus cry.

This topic reminded me a bit of code my co-worked showed me last week. It looked like:

my @list = ();

for my $elem (@list) {

    # nearly a page of code here

    ...

    ...

}