|
If I understand the code fragment correctly, this sort of thing always rankled me too. Instead of finding and fixing the root cause of something, sometimes you'd see this:
if(the conditions under which bug report #n occur are true)
{
fix things up and carry on;
}
|
|
|
|
|
Is it humanly possible to truly understand code like this? Believe me, it makes no more sense given the context.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
And they completely forget about the netAmount in the second case.
|
|
|
|
|
The worst thing is that it is probably a global variable (disguised as a non-static "field" shared by public methods) which is just set somewhere else and possibly at some different point of time.
|
|
|
|
|
That must have been a trick instead of a treat! at least it's documented as a special case.
"Go forth into the source" - Neal Morse
|
|
|
|
|
I see...
They tried to make the thing future proof, and provide a possibility to seamlessly add more special cases (count == 3 etc). But then they forgot to safeguard this code block from currently invalid values...
The great handling of Dates looks like that of a special colleague of mine: Convert.ToDateTime("31 OCT 2015") and ((DateTime)fcharge.DateRaised).Date . At least, they did not invent their own Date.Equals function (or did they?).
And then followed by the very clear naming of a variable raisedon25th - yeah, what's special about the 25th? Oh, nothing, that's just part of the variable name...
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
It is in the number base.
OCT 31 = DEC 25
That is why programmers never know whether it is Christmas or Halloween.
|
|
|
|
|
How about this gem then, hot from some inherited code:
CREATE VIEW [dbo].[vwSomething]
AS
SELECT dbo.AA_SomeTable.some_table_id AS parent_id,
...
CASE WHEN SUBSTRING(CONVERT(nvarchar(30), dbo.AA_SomeTable.date_created, 126), 9, 2)
+ '/' + SUBSTRING(CONVERT(nvarchar(30), dbo.AA_SomeTable.date_created, 126), 6, 2) + '/'
+ SUBSTRING(CONVERT(nvarchar(30), dbo.AA_SomeTable.date_created, 126), 0, 5)
+ ' ' + SUBSTRING(CONVERT(nvarchar(30), dbo.AA_SomeTable.date_created, 126), 12, 2) + ':'
+ SUBSTRING(CONVERT(nvarchar(30), dbo.AA_SomeTable.date_created, 126), 15, 2) IS NULL
THEN 'None'
ELSE SUBSTRING(CONVERT(nvarchar(30), dbo.AA_SomeTable.date_created, 126), 9, 2) + '/'
+ SUBSTRING(CONVERT(nvarchar(30), dbo.AA_SomeTable.date_created, 126), 6, 2)
+ '/' + SUBSTRING(CONVERT(nvarchar(30), dbo.AA_SomeTable.date_created, 126), 0, 5) + ' '
+ SUBSTRING(CONVERT(nvarchar(30), dbo.AA_SomeTable.date_created, 126), 12, 2)
+ ':' + SUBSTRING(CONVERT(nvarchar(30), dbo.AA_SomeTable.date_created, 126), 15, 2) END AS
date_details
FROM dbo.AA_SomeTable INNER JOIN
dbo.AA_Other ON dbo.AA_SomeTable.SomeTable_user_id_FK = dbo.AA_Other.user_id
Ummmmmmm?
(Table & Column names changed to protect the guilty)
|
|
|
|
|
Wow. Since most of our business logic is in the database, we hope to fix problems there, because that means we can slip a db correction into production without having to do an app deployment. 99.99% of the time, it works out that way.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I've been using JS for the last 2-3 years. This is par for the course
|
|
|
|
|
This code is like a surgery made by Frank Barnes in Mash 4077
|
|
|
|
|
In Kotlin you can do this:
var items = (1..300)
Additionally you can call the shuffle() method on the range to randomly shuffle the ints.
Then you can call last() on the returned shuffled ints to get the random last item.
So if you want a list of 10 random values in the range of 1 - 1000, you can do it with just a couple of lines of Kotlin. Each time through the loop the range is shuffled and a new last() is chosen.
for (i in 1..10) {
print((1..1000).shuffled().last())
print (" | ")
}
Output looks like the following:
795 | 948 | 719 | 304 | 733 | 849 | 723 | 66 | 316 | 619 |
Try it out in your browser at : Try Kotlin[^]
These new types of syntax are ugly to me, but I can see that they could grow on a dev.
*Note:By emerges, I just mean that newer languages have syntax which looks similar to this. Kotlin has had the Range type for a long time.
Basically a fluent interface[^] but just interesting that it becomes more of a core part of syntax in newish languages.
modified 15-Aug-19 16:49pm.
|
|
|
|
|
It's very Python or Ruby or whatever-esque. Personally, I really like that syntax, as it's so much easier to read. In fact, in C# I wrote an extension method so I can do:
5.ForEach(n=>DoSomethingWithN());
So technically, in C# with extension methods, I should be able to write:
10.ForEach(n=>1000.Shuffle().Last().ConsoleOut());
I like that syntax because it reads left-to-right and would be very much like the pipe operator in F#.
Marc
|
|
|
|
|
Good point about Left to Right reading. I mostly like it too and I’m sure it will grow on me.
I think the declaration/instantiation of the Range is a bit odd (1..10). No new operator or anything. but, it is quite streamlined.
|
|
|
|
|
Hmm, neat. I like it. Looks pretty similar to how I'd use ranges in Ruby:
(1..10).each do
print (1..1000).to_a.shuffle.last
print " | "
end
The only real difference is that I had to convert the range to an array, since arrays have a shuffle method and ranges don't.
Of course, being Ruby, I could just patch a shuffle method onto the Range class.
|
|
|
|
|
Oh, wow, that’s very interesting that it is that close to the Ruby version.
That’s one language I’ve stayed away from.
|
|
|
|
|
The subrange notation is about 50 years old, isn't it? In Pascal (1970), the parentheses are not needed, though.
Subranges are, of course, allowed on any discrete type. So if you have a TYPE month: (jan, feb, mar, apr, may, june, july, aug, sept, oct, nov, dec); - note that these are NOT integers, but a distinct value domain - you can declare a VAR SummerMonth: may..aug; and assigning a value to SummerMonth outside that range causes an exception. Maybe Kotlin provides a similar full-blown enum concept, including subranges.
(In Pascal, arrays can have any subrange index, e.g. Members: ARRAY [1970..2025] OF MemberList; - maybe that is possible in Kotlin as well, but it usually is not in C-derived languages.)
|
|
|
|
|
Member 7989122 wrote: Subranges are, of course, allowed on any discrete type.
That's something I got used to with Ada that I wish I had in C++ (or any of the other static typed languages I use) - even in languages like Kotlin or Rust, which have first class support for ranges, they're still a run-time entity, not a compile-time thing, so you can't constrain how a function works by a range in the same way... And you can't take sub-ranges of enums either
Oh, for a dependently typed language?
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Member 7989122 wrote: The subrange notation is about 50 years old, isn't it?
Yeah, it probably is quite old.
Member 7989122 wrote: but it usually is not in C-derived languages.
And almost every language I use is C-derived (C++, C#, Java, JavaScript) so that's why it just looks odd to me.
|
|
|
|
|
Reminds of Turbo Pascal, so not that new.
|
|
|
|
|
Yeah, I probably have forgotten about Pascal. Last time I actually used it was probably 1996 or so.
|
|
|
|
|
raddevus wrote: Each time through the loop the range is shuffled and a new last() is chosen.
Isn't that code going to be horribly inefficient? Surely the language must provide a better way to get a random number in a particular range?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: Isn't that code going to be horribly inefficient? Surely the language must provide a better way to get a random number in a particular range?
Oh yes, just laziness on my part for a quick example.
There may be other ways to accomplish the same thing that are more efficient.
|
|
|
|
|
This approach would not scale well if you want a random number between 1 and 2^31-1.
|
|
|
|
|
That was my immediate thought too. Glad to see someone else cares about wasting cycles.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|