Better way to do this?

[Barabajagal]

I suppose that'd work better, yes.

On a similar note, is it still correct to do it if it looks like this:

Code Select Expand


CheckIdleUser = CBool(ReadINI("Main", "UserIdleTime", "20", strConfig) > 0 And ReadINI("Main", "UserIdleGray", "Y", strConfig) = "Y" And GetTickCount \ 1000 - lvChannel.ListItems(UserIndex).SubItems(4) > ReadINI("Main", "UserIdleTime", "20", strConfig) * 60 And lvChannel.ListItems(UserIndex).ForeColor <> OtherApp.Error)

?

[Camel]

Congratulations, you totally missed the point.

Replace the code you just cited without the convention, and it's still atrocious. GG no re.

[Barabajagal]

Naw, I used variables for the ReadINI values before.

[brew]

I suppose. But I think it's easier to read, which is important in undocumented code

see: http://forum.valhallalegends.com/index.php?topic=16677.msg168793#msg168793
from that post on

[Barabajagal]

Brew... despite the minor topic relevance, wtf?

[Camel]

Naw, I used variables for the ReadINI values before.

And you should use variables in the contraction, as well. Your example is bad because of the lack of variables, not because of the contraction. Furthermore, no dimwit would be fooled by that logic trap. I'm not sure why you even post it.

[brew]

Brew... despite the minor topic relevance, wtf?

My point was that throughout that entire topic, you said how you had no need for code readability, comments, documentation and anything like that at all, yet in this topic you argue that your version of that code is superior because of readabilty? IIRC you're the code poet, you don't need any amount of readabilty. And compressing your code as camel suggested would not only help make your code much more efficient (the vb6 compiler would actually product very different results) but make it not look plain stupid. Thanks. To be completely honest, I used to make code blocks like that myself... when i just started vb6...

[Camel]

(the vb6 compiler would actually product very different results)

Can you support that statement? Not that I don't believe it, I just don't like to jump to conclusions.

[Barabajagal]

I don't need readability, other people might. And no, I've tried both ways, and the end compile result is the same.

[Banana fanna fo fanna]

Code Select Expand


CheckIdleUser = CBool(ReadINI("Main", "UserIdleTime", "20", strConfig) > 0
     And ReadINI("Main", "UserIdleGray", "Y", strConfig) = "Y"
     And GetTickCount \ 1000 - lvChannel.ListItems(UserIndex).SubItems(4) > ReadINI("Main", "UserIdleTime", "20", strConfig) * 60
     And lvChannel.ListItems(UserIndex).ForeColor <> OtherApp.Error)


Not too bad.

[Camel]

You could accomplish the identical result with:

Code Select Expand


CheckIdleUser = CBool(ReadINI("Main", "UserIdleTime", "20", strConfig) > 0
CheckIdleUser = CheckIdleUser And ReadINI("Main", "UserIdleGray", "Y", strConfig) = "Y"
CheckIdleUser = CheckIdleUser And GetTickCount \ 1000 - lvChannel.ListItems(UserIndex).SubItems(4) > ReadINI("Main", "UserIdleTime", "20", strConfig) * 60
CheckIdleUser = CheckIdleUser And lvChannel.ListItems(UserIndex).ForeColor <> OtherApp.Error)


Of course, in a language that short-circuits boolean operators, you'd want to put your safest/fastest operations first. Since VB doesn't, it doesn't matter unless the order of operations is relevant.

[brew]

That code wouldn't work. You're forgetting a ) on the first line. Not only that, but also why would you be CBool()ing a value that's already a boolean...? And I'm not even mentioning half the other bad coding habits in that sample. I sware to god. If there were no such things as code optimizers we would all be dead because of crappy code. Back in the 70-80s if you wrote it like that you would have been shot.

[Barabajagal]

brew. Stuff it.

"Antiquis temporibus, nati tibi similes in rupibus ventosissimis exponebantur ad necem"

[UserLoser]

use constants make code cleaner and easier to read.

[Barabajagal]

*sigh* none of this is the important part. Can we try getting back to the topic of this topic?