|
|
if you learn the rules of coercion you may love the language.
it's nothing ambiguous. you will become more expressive, but your expressions may look like gibberish to people coming from more strict languages.
on the other hand if you too are used to stricter language, didn't if bother you that you are assigning null to extra and then adding characters or integers to it?
don't you fell more natural to define extra as "" if you add strings to it or as 0 if you add integers to it?
|
|
|
|
|
sickfile wrote: didn't if bother you that you are assigning null to extra and then adding characters or integers to it?
That's actually a good point and good thinking.
I actually do like JavaScript, I just find that I get bit by these things and there are a lot of esoteric things to know about the language that cause my brain to burn more calories than I probably should have to. But that is the natural laziness that all we devs have I suppose.
The real thing that bothers me about JavaScript is the fact that there are two values which are so similar but are different:
undefined
null
I could just use one or the other really.
But then I become unusre at times and think, "hmm...is JS going to think this is undefined at this point? Is it going to think it is null?" then additionally in the case of a string I have to wonder if it is an empty string too (and there is no String.Empty to compare to so I have to use double-quotes "").
These are the things that are just bothersome. But they are bothersome because I cannot concentrate on JavaScript as much as I'd like too, since I'm an attempting to create solutions in software -- not just understand pedantic syntax.
I think that is why at times, I finally just have to rant about JS.
|
|
|
|
|
that's ok, we all rant here and there.
null is an object. it has it's purposes. it just takes time to make a significant difference between null and undefined .
not so long ago i have stumbled upon a situation at work where a coworker had decided to write the absence of an object in the database simply as 0 , instead of null .
all i can tell you is, and i remembered well, that the logic i had to use, because the field was either an object or 0 in it's absence, was like 3 boolean expressions concatenated with || or &&. if the absence of the object was marked with null i would have to use only one boolean expression. even tho if (0) and if (null) yield the same result.
there are many articles on the net that explain the differences between: 0, "", undefined, null, ... etc. and the subject can be sometimes so confusing that you would have to go through the comments of the article to figure it out and i'm talking about the best articles out there. no good text will only confuse a person.
|
|
|
|
|
raddevus wrote: there are two values which are so similar but are different:
undefined
null
or three. Don't forget
void 0
|
|
|
|
|
sickfile wrote: you will become more expressive, but your expressions may look like gibberish to people coming from more strict languages. Which makes stuff easy for maintenance, ofcourse.
sickfile wrote: on the other hand if you too are used to stricter language, didn't if bother you that you are assigning null to extra and then adding characters or integers to it? No, it would result in a compiler error.
sickfile wrote: don't you fell more natural to define extra as "" if you add strings to it or as 0 if you add integers to it? Yes, either and int or string, not a var. We don't DIM.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
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.
|
|
|
|