|
Type coercion in JS has long been a known area of difficulty. However, if you learn it's peculiar rules, you may start to appreciate the method to the madness
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Good to know!
The good thing with JavaScript is that there is an endless stream of trick trivia question that can be made with it!
But it's better left to... others...
|
|
|
|
|
Super Lloyd wrote: there is an endless stream of trick trivia question that can be made with it!
Yeah, I often see those posted all over the place.
|
|
|
|
|
raddevus wrote: var extra = null;
Isn't this sort of thing why TypeScript was invented?
In TypeScript:
var extra:string;
|
|
|
|
|
markrlondon wrote: Isn't this sort of thing why TypeScript was invented?
Yes it is!
I will switch to TS one day too. I'm just so lazy I haven't gotten around to it.
|
|
|
|
|
Message Removed
modified 17-Sep-19 9:20am.
|
|
|
|
|
Message Removed
modified 17-Sep-19 9:20am.
|
|
|
|
|
TL:DR - C# + Visual Studio 2017 + careless developer = wasted time.
I decide to move image processing to its own DLL, so I create a new DLL and use the namespace ImageProcessing. All well and good, that compiles.
I then try to use it from my main application: Error - The type or namespace 'ImageProcessingBase' does not exist in Station.ImageProcessing.
Fool me, I did not read the Station portion of Station.ImageProcessing, so it took me far too long to figure out I needed to get rid of the Station.ImageProcessing namespace before I could access the new ImageProcessing namespace from the Station namespace, unless I want to add a lot of alias commands. Now Station.ImageProcessing is no more and everything compiles.
Why didn't Microsoft have a different convention for partial namespace definitions? Something like .ImageProcessing for accessing Station.ImageProcessing from the Station namespace would work.
|
|
|
|
|
Because that would be an ambiguity in one of the few places where ambiguity would break the system.
By and large, C# is really good about supporting abstractions. One of the main reasons for this is that the whole thing is underpinned with stringent structural rules in terms of where and how code is loaded. These rules, which include namespace definitions, make the entire idea of dynamic module loading work without a bunch of odd checks and locks.
An ambiguous namespace definition would break this system. Do I want System.Timers or System.Threading.Timers? The APIs are different, so if I load one ambiguously, I'd need to do some type checks before using anything from it an likely set aside some buffers and concurrency control while making the determination and loading the code.
Or I can just type: using System.Threading.Timers;
Side note: ReSharper automatically detects namespace issues and can automatically correct them for you.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
if (count == 1) {
var charge = list.FirstOrDefault();
netAmount = charge.NetAmount ?? 0;
isSingleCharge = true;
}
else if (count == 2)
{
var fcharge = list.FirstOrDefault();
var scharge = list.LastOrDefault();
var dt = Convert.ToDateTime("31 OCT 2015");
bool raisedon25th = (((DateTime)fcharge.DateRaised).Date.Equals(dt.Date)
|| ((DateTime)scharge.DateRaised).Date.Equals(dt.Date));
bool sameAgent = fcharge.Agent.Id == scharge.Agent.Id;
isSingleCharge = raisedon25th && sameAgent;
}
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Wow!
I honestly think that's as bad as anything I've ever seen in far more years than I'd care to mention.
Whenever you find yourself on the side of the majority, it is time to pause and reflect. - Mark Twain
|
|
|
|
|
Yes, I sat there dumbfounded for a good few minutes after encountering this gem. I still have no idea why it exists.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
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
|
|
|
|