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. -
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?