Some things just shouldn't be allowed to compile...
-
I fully agree with you. In fact, I usually write code like this myself. But then how to explain those snippets which begin with
c = False? We need more context here. Also,cis a lousy variable name, unless the surrounding code makes its meaning clear.Nonsense.bas(1) : error E3401: 'c' : can't guess the meaning
-
c = True If \_start > \_end Then c = False End If c = True If \_end < \_start Then c = False End If c = True If Not \_start < \_end Then c = False End If c = True If Not \_end > \_start Then c = False End If c = False If \_start < \_end Then c = True End If c = False If \_end > \_start Then c = True End If c = False If Not \_start > \_end Then c = True End If c = False If Not \_end < \_start Then c = True End If.
It's so tempting to start a language flame war.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
I am sorry I will contradict you. With a pinch of sadism/bad faith. I find these statements more readable thant would the terse
c= _start < _end. They tell you a story: by default all is fine; but if you observe an inversion of the bounds, flag this as wrong. The third variant withNot _start < _endcan be seen as the best choice as it makes explicit the desired condition as opposed to the "buggy" one. But that's not all. These forms are not only more informative for humans, but also for compilers. A single assignment would be perfectly neutral and give no hint for branch prediction. On the opposite, anIfstatement is an opportunity for compiler designers to enforce branch prediction rules such as "thethenbranch is more likely to be taken than not, unless it starts with a negation". :)YvesDaoust wrote:
But that's not all. These forms are not only more informative for humans, but also for compilers. A single assignment would be perfectly neutral and give no hint for branch prediction
But.. there is no branch that needs predicting.. except the gratitous one the programmer added.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
c = True If \_start > \_end Then c = False End If c = True If \_end < \_start Then c = False End If c = True If Not \_start < \_end Then c = False End If c = True If Not \_end > \_start Then c = False End If c = False If \_start < \_end Then c = True End If c = False If \_end > \_start Then c = True End If c = False If Not \_start > \_end Then c = True End If c = False If Not \_end < \_start Then c = True End If.
I guess there’s no way to teach a complier to look for stupid?
-
YvesDaoust wrote:
But that's not all. These forms are not only more informative for humans, but also for compilers. A single assignment would be perfectly neutral and give no hint for branch prediction
But.. there is no branch that needs predicting.. except the gratitous one the programmer added.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
As far as I know there is always one when using an Intel processor. A comparison needs to be followed by a conditional branch. The Intel has only conditional branch instructions, no conditional moves or conditional arithmetic. Nor have I ever seen the value of a condition flag being transferred to a register. Branchless expressions can be used, such as
(_end - _start) >> 31, giving-1or0, which are even less readable. -
As far as I know there is always one when using an Intel processor. A comparison needs to be followed by a conditional branch. The Intel has only conditional branch instructions, no conditional moves or conditional arithmetic. Nor have I ever seen the value of a condition flag being transferred to a register. Branchless expressions can be used, such as
(_end - _start) >> 31, giving-1or0, which are even less readable.YvesDaoust wrote:
As far as I know there is always one when using an Intel processor A comparison needs to be followed by a conditional branch
You are incorrect. There's a compare, which sets flags, followed by a jump, which is the actual branch instruction and needs prediction. Here's some C# disassembly, Intel native will be similar:
bool b = i1 < i2;00000071 mov eax,dword ptr [ebp-40h]
00000074 cmp eax,dword ptr [ebp-44h]
00000077 setl al
0000007a movzx eax,al
0000007d mov dword ptr [ebp-48h],eaxbool c = true;00000080 mov eax,1
00000085 and eax,0FFh
0000008a mov dword ptr [ebp-4Ch],eax
if (i1 > i2)
0000008d mov eax,dword ptr [ebp-40h]
00000090 cmp eax,dword ptr [ebp-44h]
00000093 setle al
00000096 movzx eax,al
00000099 mov dword ptr [ebp-50h],eax
0000009c cmp dword ptr [ebp-50h],0
000000a0 jne 000000A9
{
000000a2 nop
c = false;
000000a3 xor edx,edx
000000a5 mov dword ptr [ebp-4Ch],edx
}
000000a8 nopYvesDaoust wrote:
The Intel has only conditional branch instructions, no conditional moves or conditional arithmetic. Nor have I ever seen the value of a condition flag being transferred to a register
You need to go read the Intel assembly guide. Compares (and many other instructions) set flags bits in the flags register. The jump instructions base their decision on how those flags are set. Intel instruction set has been this way since the 8008, and probably the 4004 before that.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
YvesDaoust wrote:
As far as I know there is always one when using an Intel processor A comparison needs to be followed by a conditional branch
You are incorrect. There's a compare, which sets flags, followed by a jump, which is the actual branch instruction and needs prediction. Here's some C# disassembly, Intel native will be similar:
bool b = i1 < i2;00000071 mov eax,dword ptr [ebp-40h]
00000074 cmp eax,dword ptr [ebp-44h]
00000077 setl al
0000007a movzx eax,al
0000007d mov dword ptr [ebp-48h],eaxbool c = true;00000080 mov eax,1
00000085 and eax,0FFh
0000008a mov dword ptr [ebp-4Ch],eax
if (i1 > i2)
0000008d mov eax,dword ptr [ebp-40h]
00000090 cmp eax,dword ptr [ebp-44h]
00000093 setle al
00000096 movzx eax,al
00000099 mov dword ptr [ebp-50h],eax
0000009c cmp dword ptr [ebp-50h],0
000000a0 jne 000000A9
{
000000a2 nop
c = false;
000000a3 xor edx,edx
000000a5 mov dword ptr [ebp-4Ch],edx
}
000000a8 nopYvesDaoust wrote:
The Intel has only conditional branch instructions, no conditional moves or conditional arithmetic. Nor have I ever seen the value of a condition flag being transferred to a register
You need to go read the Intel assembly guide. Compares (and many other instructions) set flags bits in the flags register. The jump instructions base their decision on how those flags are set. Intel instruction set has been this way since the 8008, and probably the 4004 before that.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
Glad to know about the
setlinstruction which indeed has the effect of transferring a flag to a register. Regarding the conditions flags, thank you, I am not a complete dummy. -
I guess there’s no way to teach a complier to look for stupid?
Obviously not - stupidity is highly creative in how it manifests itself ;)
-
YvesDaoust wrote:
As far as I know there is always one when using an Intel processor A comparison needs to be followed by a conditional branch
You are incorrect. There's a compare, which sets flags, followed by a jump, which is the actual branch instruction and needs prediction. Here's some C# disassembly, Intel native will be similar:
bool b = i1 < i2;00000071 mov eax,dword ptr [ebp-40h]
00000074 cmp eax,dword ptr [ebp-44h]
00000077 setl al
0000007a movzx eax,al
0000007d mov dword ptr [ebp-48h],eaxbool c = true;00000080 mov eax,1
00000085 and eax,0FFh
0000008a mov dword ptr [ebp-4Ch],eax
if (i1 > i2)
0000008d mov eax,dword ptr [ebp-40h]
00000090 cmp eax,dword ptr [ebp-44h]
00000093 setle al
00000096 movzx eax,al
00000099 mov dword ptr [ebp-50h],eax
0000009c cmp dword ptr [ebp-50h],0
000000a0 jne 000000A9
{
000000a2 nop
c = false;
000000a3 xor edx,edx
000000a5 mov dword ptr [ebp-4Ch],edx
}
000000a8 nopYvesDaoust wrote:
The Intel has only conditional branch instructions, no conditional moves or conditional arithmetic. Nor have I ever seen the value of a condition flag being transferred to a register
You need to go read the Intel assembly guide. Compares (and many other instructions) set flags bits in the flags register. The jump instructions base their decision on how those flags are set. Intel instruction set has been this way since the 8008, and probably the 4004 before that.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
patbob wrote:
followed by a jump
Ooooh, the Jump instruction. Otherwise known in the somewhat higher level languages as "Goto" which of course "real" programmers are not allowed to use but for some unknown reason a compiler is. :)
If your neighbours don't listen to The Ramones, turn it up real loud so they can.
-
c = True If \_start > \_end Then c = False End If c = True If \_end < \_start Then c = False End If c = True If Not \_start < \_end Then c = False End If c = True If Not \_end > \_start Then c = False End If c = False If \_start < \_end Then c = True End If c = False If \_end > \_start Then c = True End If c = False If Not \_start > \_end Then c = True End If c = False If Not \_end < \_start Then c = True End If.
I have a guy three doors away (thank god) that likes to put in his monthly reports to the big cheese how many lines of code this or that module/programme has, as though that actually means something. I wonder how many of those lines consist of this kind of thing? No, I'm not going to look.
If your neighbours don't listen to The Ramones, turn it up real loud so they can.
-
I fully agree with you. In fact, I usually write code like this myself. But then how to explain those snippets which begin with
c = False? We need more context here. Also,cis a lousy variable name, unless the surrounding code makes its meaning clear. -
c = True If \_start > \_end Then c = False End If c = True If \_end < \_start Then c = False End If c = True If Not \_start < \_end Then c = False End If c = True If Not \_end > \_start Then c = False End If c = False If \_start < \_end Then c = True End If c = False If \_end > \_start Then c = True End If c = False If Not \_start > \_end Then c = True End If c = False If Not \_end < \_start Then c = True End If.
If you have code that has the full series of statement snippets compiled together, I fully agree with you. If you are complaining about having so many ways to check for the same thing, I disagree with you. On a personal basis, some of those series of "saying almost the same thing" (When you start off as false and don't use Not logic = is false, all other cases, = is true.) aren't as readable as others, but also on a personal basis, I can choose the format that makes the most sense to me. Did you intend to say the same thing consistently and made a mistake?:
0bx didn't write:
c = False If _start <= _end Then c = True End If
Or are you making the point that it is difficult to always say the same thing by intentionally including a mistake in your logic? What makes it even more fun is if you make the object nullable. I don't know the VB.NET format, but C# would be:
?int c;
(Making coding more complex reduces the pool of people who can write code well. That improves your chances to shine or show you are a dunderhead. :laugh: )
-
c = True If \_start > \_end Then c = False End If c = True If \_end < \_start Then c = False End If c = True If Not \_start < \_end Then c = False End If c = True If Not \_end > \_start Then c = False End If c = False If \_start < \_end Then c = True End If c = False If \_end > \_start Then c = True End If c = False If Not \_start > \_end Then c = True End If c = False If Not \_end < \_start Then c = True End If.
-
If you have code that has the full series of statement snippets compiled together, I fully agree with you. If you are complaining about having so many ways to check for the same thing, I disagree with you. On a personal basis, some of those series of "saying almost the same thing" (When you start off as false and don't use Not logic = is false, all other cases, = is true.) aren't as readable as others, but also on a personal basis, I can choose the format that makes the most sense to me. Did you intend to say the same thing consistently and made a mistake?:
0bx didn't write:
c = False If _start <= _end Then c = True End If
Or are you making the point that it is difficult to always say the same thing by intentionally including a mistake in your logic? What makes it even more fun is if you make the object nullable. I don't know the VB.NET format, but C# would be:
?int c;
(Making coding more complex reduces the pool of people who can write code well. That improves your chances to shine or show you are a dunderhead. :laugh: )
I'm not the kind of person who likes to complain about things, it was a digital poem; or perhaps an act of "trolling". As you so generously pointed out: "a < b" and "b >= a" are the same thing. Why would we use "<" at all? At least ">=" reminds you to think about limits like when "a == b", imo it's preferable to use "<=" instead of ">". Because "<" doesn't make that possibility go away, it just makes it more confusing.
And Jesus said:
'As The Lord tried to cast _start and _end as DateTime and saw that they aren't null
Dim isValid As Boolean = false
'Check if _end doesn't occur before _start
If _start <= _end Then
isValid = True
else
'TODO: dear collegues, please make the errormessages dynamic for different languages while I go on vacation
lblError.txt = "Warning, your event may cause temporal paradoxes."
EndIfReturn isValid
And say in this case the time also isn't allowed to be equal. Then this:
Dim isValid As Boolean = false
'Check if _end doesn't occur before _start
If _start < _end Then
isValid = True
elselblError.txt = "There can be no energy transfer at an infantessimally small amount of time, this violates the laws of physics rendering this appointment highly dangerous; then again it could be that the event is so short that it's beyond the discreet boundaries of SQL server; but this possibility will be neglected because it makes the animation of the dancing animals on the agenda look weird."
EndIfWould be preferable to this
'Writing comments really helps to think about what you're doing
If _end >= _start ThenBut in that case why not do this.
'It's also nice for future you
If Not _start >= _end Then.
-
I have a guy three doors away (thank god) that likes to put in his monthly reports to the big cheese how many lines of code this or that module/programme has, as though that actually means something. I wonder how many of those lines consist of this kind of thing? No, I'm not going to look.
If your neighbours don't listen to The Ramones, turn it up real loud so they can.
-
c = True If \_start > \_end Then c = False End If c = True If \_end < \_start Then c = False End If c = True If Not \_start < \_end Then c = False End If c = True If Not \_end > \_start Then c = False End If c = False If \_start < \_end Then c = True End If c = False If \_end > \_start Then c = True End If c = False If Not \_start > \_end Then c = True End If c = False If Not \_end < \_start Then c = True End If.
Not a professional programmer, just an amateur, so correct me if I'm out of line. I guess I'd have less problems understanding this if the following were done: 1) Add comments to the code. Would clear up a world of problems. 2) Why do you need to do all of these?
If _start > _end Then
If _end < _start Then
If Not _start < _end Then
If Not _end > _start ThenAren't they all the exact same statement? 3) Assuming that being equal has the same meaning as one of the less than statments (there is no third option for the value of c) there should only be the need to write less than statements. 4) Wouldn't a Select Case (or Switch) block work based on the result of _start < _end (slightly more verbose than c = _start < _end, so maybe a little clearer)
Select Case _start < _end 'check that start is less than end
Case True
c = True 'OK to continue
Case False
c = False 'Not OK to continue
End Select -
Not a professional programmer, just an amateur, so correct me if I'm out of line. I guess I'd have less problems understanding this if the following were done: 1) Add comments to the code. Would clear up a world of problems. 2) Why do you need to do all of these?
If _start > _end Then
If _end < _start Then
If Not _start < _end Then
If Not _end > _start ThenAren't they all the exact same statement? 3) Assuming that being equal has the same meaning as one of the less than statments (there is no third option for the value of c) there should only be the need to write less than statements. 4) Wouldn't a Select Case (or Switch) block work based on the result of _start < _end (slightly more verbose than c = _start < _end, so maybe a little clearer)
Select Case _start < _end 'check that start is less than end
Case True
c = True 'OK to continue
Case False
c = False 'Not OK to continue
End Select- Fully agree 2-3) "a < b" is the same as "b >= a" and "not a >=b "; I personally don't like the "<" or ">", because it leads to oversights imo. Other people seem to disagree; but well. I find inequalities mighty confusing; it's like by brain isn't made to handle them, especially when the complexity ramps up, you start to get lost pretty easily. 4) Selects are used when there value you are evaluating isn't a Boolean. So using a Select to evaluate a bool is a bit weird imo...
if (a == "yellow") {do this;}
else // a is green
{ do that;}This is the typical example of when you actually should use a select block (combined with an enum instead of a string); because there's always the possibility that there are more options, even if they aren't implemented right now.
.
-
- Fully agree 2-3) "a < b" is the same as "b >= a" and "not a >=b "; I personally don't like the "<" or ">", because it leads to oversights imo. Other people seem to disagree; but well. I find inequalities mighty confusing; it's like by brain isn't made to handle them, especially when the complexity ramps up, you start to get lost pretty easily. 4) Selects are used when there value you are evaluating isn't a Boolean. So using a Select to evaluate a bool is a bit weird imo...
if (a == "yellow") {do this;}
else // a is green
{ do that;}This is the typical example of when you actually should use a select block (combined with an enum instead of a string); because there's always the possibility that there are more options, even if they aren't implemented right now.
.
0bx wrote:
"a < b" is the same as "b >= a" and "not a >=b ";
I personally don't like the "<" or ">", because it leads to oversights imo.
Other people seem to disagree; but well.
I find inequalities mighty confusing; it's like by brain isn't made to handle them, especially when the complexity ramps up, you start to get lost pretty easily.I disagree that a < b gives the same result as b >= a. Here is a truth table:
a b a < b b > a b>=a not(a>=b)
10 20 T T T T
20 10 F F F F
10 10 F F T FBased on the results of the truth table, in my interpretation, a < b is the same as b > a so testing them both is pointless. Also, since b >= a is not the same as a < b the risk (as others have pointed out) is that you may not have assumed the correct resutl for a = b. Am I missing something?
-
Nonsense.bas(1) : error E3401: 'c' : can't guess the meaning
-
0bx wrote:
"a < b" is the same as "b >= a" and "not a >=b ";
I personally don't like the "<" or ">", because it leads to oversights imo.
Other people seem to disagree; but well.
I find inequalities mighty confusing; it's like by brain isn't made to handle them, especially when the complexity ramps up, you start to get lost pretty easily.I disagree that a < b gives the same result as b >= a. Here is a truth table:
a b a < b b > a b>=a not(a>=b)
10 20 T T T T
20 10 F F F F
10 10 F F T FBased on the results of the truth table, in my interpretation, a < b is the same as b > a so testing them both is pointless. Also, since b >= a is not the same as a < b the risk (as others have pointed out) is that you may not have assumed the correct resutl for a = b. Am I missing something?