|
|
|
You know you've posted this too many times when Chrome auto-completes the subject line for you!
Anyways, I have this function:
function initializePage(raceList, hlsList) ...
(for demographics, race and Hispanic/Latino/Spanish, of course, a "I don't want to answer" is accepted) but anyways,
Randomly, the list would not load. Really hard to reproduce locally, would happen once every 10 or 15 pages loads on the real site.
Those lists, and others, are acquired from an Ajax call that only calls this function after all the lists have been loaded from the server. Of course it's a stupid way of doing it, but at the time... Plus this particular page used to only have those two lists, but then it grew to more things...you know how that story goes.. and of course what's worse is that this is the only page where I seem to have forgotten to refactor the code and do it "the right way."
Anyways, in one place, I accidentally forgot to pass in the lists:
initializePage()
which resulted in the random "why isn't the list showing up" error.
I blamed my SPA code, I blamed jqWidgets, I blamed my mother.
And after staring at the code for hours over several weeks, I finally actually saw the offending line.
God, I want parameter type checking. I know, use TypeScript or something.
Marc
|
|
|
|
|
Marc Clifton wrote: Anyways, in one place, I accidentally forgot to pass in the lists:
Rule #1 for every JS function I write: Check for undefined, null, and empty values if I don't want them.
I do null param checks as the first line of code in every .NET method, why would I do any different in another language? is my thinking.
|
|
|
|
|
Vark111 wrote: Rule #1 for every JS function I write: Check for undefined, null, and empty values if I don't want them.
Good point.
Vark111 wrote: I do null param checks as the first line of code in every .NET method, why would I do any different in another language? is my thinking.
I agree, but in this case, I know the data was there, it was an error in the parameter list. And yes, Rule #1 would have caught it.
Marc
|
|
|
|
|
I use javaScript for what it does, expect from it no more than what it is. None the less, I feel sympathy for your never-ending distress on this topic. Perhaps?[^] will make all of the pain finally go away?
<script type='text/javascript'>
return;
</script>
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Jeremy Falcon
|
|
|
|
|
You're looking at JavaScript the wrong way man. Really, this stuff is a result of not being used to JS. Welcome to the fun. You have to look at it like this, JS is a language that's finally growing up. But, it's powerful in its own right. You can do some pretty amazing stuff with it, provided you learn its quirks. One of which you obviously know about now. 
It's a flexible language. That's the idea. That's the idea of the web even, and so JS is no exception. However, you must also deal with this as a result. ES6 provides some new stuff, but you can achieve what you're after regardless...
Handling required parameters in ECMAScript 6[^]
Is it totally different than C#? Yes. But once you get used to the flexibility, it does more good than harm.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: You're looking at JavaScript the wrong way man.
You're absolutely right.[^] I'll endeavor to break the pattern and write an "I love Javascript" post.
Someday. 
Marc
|
|
|
|
|
Marc Clifton wrote: Someday.
Jeremy Falcon
|
|
|
|
|
And I know it's been said before, but you really want to look at TypeScript or at least ES6/2015 transpilers. It will make your life easier and save some hair in the process.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: but you really want to look at TypeScript or at least ES6/2015 transpilers.
Will do. I'm at a good juncture of being able to do that, starting a new side project.
Marc
|
|
|
|
|
Yes, it's finally growing up. despite the parents being siblings.
And it can do pretty amazing stuff, on the banjo.
|
|
|
|
|
A true loving and caring lanaguage keeps it in the family. 
Jeremy Falcon
|
|
|
|
|
Who told you to love it  It's just like a wild pet. Measure your distance on it.
|
|
|
|
|
Earlier iterations of C were so type-ignoring, you could pass 3.14 to a function expecting an int parameter. It compiled nontheless and produced horrible stack garbage.
|
|
|
|
|
Don't confuse "optional" type checking with "impossible" type checking. You were never been on the other side, where in some random language (I don't want to mention names) you are enforced to write a specific type, where the parameter must be one type if the first parameter has a specific value and another one if it has another value.
|
|
|
|
|
As a general rule, I hate interpreted languages, in the sense: Languages where the syntax the basic semantics are not checked for all the code before execution starts. Some languags would be suitable for such checks even though they are (semi)interpreted languages, but leave the checking to independent lint-like tools (which reminds me: By my definition, good old K&R C comes very close to the 'interpreted' class!) - use them if you care to, but you may ignore them if you want.
There is one readon why some interpreted langages (barely) tolerable to me: I was responsible for maintaining a program system of roughly 100K lines of Tcl - a language having a syntax which is roughly
<token>*
The permitted sequence of tokens, and the semantics of them, are totally context dependent. You don't know if a line is a string constant or an active statement until you encounter it during execution. Or rather, any time you encounter it. In one context the line may be an active statement, a moment later it may be a string literal.
Coming from Tcl to a language where an 'if (<expr>) {...}' really is a conditional statement, always and every time, is a great relief. I sure wish that <expr> was verified to be a boolean expression before we start, but even without that, we are way better off than with Tcl.
But if at all possible, I try to avoid interpreted languages. And dynamic binding. And plugins (well, they are a special case of dynamic binding). Whatever can be checked statically, should be checked statically. And that should be as much of your code as possible, preferably 100%.
|
|
|
|
|
I only use it once in a blue moon so maybe I am missing something but so much of it seems like guesswork - tools such as intellisense don't work with it because objects could be anything. I spend at least 80% of my time in javascript trying to work out what I have and what I can do with it.
|
|
|
|
|
JavaScript is an aberration. Any efforts to make it more manageable (i.e. TypeScript) is just putting lipstick on a pig.
|
|
|
|
|
Agreed, and to really understand the future of JS:
once upon a time people said BASIC would go away, it really needed to happen
well years, no decades later, not just still here, but the super tankers of lipstick applied to it over the years has resulted in such a huge steaming mountainous POS it would choke the black hole in the center of the Milky Way.
and yes, that's where java script is headed.
|
|
|
|
|
I have written quite a bit of complex JavaScript in my time as a corporate developer.
And I am still amazed at why anyone would use such an awful language as their primary language for web development when there are other more mature options available such as not using it altogether and make the bloody server call...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
JavaScript is a terrible language and you have plenty of justification to hate it. It is only used because it is the only option on browsers. If another existing language was suddenly supported by all browsers today, it would probably take over JavaScript quickly.
JavaScript is so terrible, many developers prefer not to code in it. Many are creating new languages such as CoffeeScript, TypeScript, etc., that compile to JavaScript. Many are writing compilers for known languages (python, C#, etc.) that compile to JavaScript.
Even the most popular JavaScript libraries (Angular) are written in TypeScript, not JavaScript, and those libraries recommend that we do the same.
|
|
|
|
|
Although it won't make you hate JavaScript any less, you could use a countify factory function to make your existing functions pedantic about the number of arguments they receive:
function argsLength(func) {
return (func + '')
.replace(/[/][/].*$/mg,'')
.replace(/\s+/g, '')
.replace(/[/][*][^/(*)]*[*][/]/g, '')
.split('){', 1)[0].replace(/^[^(]*[(]/, '')
.replace(/=[^,]+/g, '')
.replace(/[\(\)]/g, '')
.split(',').filter(Boolean)
.length;
}
function countify(fn) {
var expectedArgsCount = argsLength(fn);
return function() {
var receivedArgsCount = arguments.length;
var expectedDescription = expectedArgsCount === 1 ? "argument" : "arguments";
var receivedDescription = receivedArgsCount === 1 ? "argument" : "arguments";
if(arguments.length !== expectedArgsCount) {
var errorMessage = ["Expected",
expectedArgsCount.toString(),
expectedDescription + ",",
"received",
receivedArgsCount.toString(),
receivedDescription + "."];
throw new Error(errorMessage.join(" "));
} else {
fn.apply(this, arguments);
}
}
}
Then, with initializePage, you could change its definition to
var initializePage = countify(function(raceList, hlsList) {
});
but, since changing the function definitions of functions you want to countify is a pain, you could just do
initializePage = countify(initializePage)
anywhere after initializePage is defined. As a bonus, you can use this approach to countify library code as well, as long as you don't countify a function that does different things depending on the number of arguments it receives.
Heck, with a few small modifications, you could make countify check argument types as well, by making it take two arguments: an array containing the types of the function arguments, and then the function itself. Adding the checks will of course add a small amount of overhead at run time, but it won't be noticeable at all unless your function is being called tens of thousands of times in a tight loop...and maybe not even then, aside from the tens of thousands of error messages you'd see if you have the browser dev tools open.
As you mentioned, a lot of people will say "just use TypeScript!" which isn't a bad suggestion, but it's not always an option when you've got an existing code base and limited time.
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
