We use cookies to ensure you have the best browsing experience on our website. Please read our cookie policy for more information about how we use cookies.
To create an array: stick with new Array(n). You want to spend time thinking about algorithms rather than implementation details, so stick with one way of doing things unless you see an obviously better way.
There is no algorithm style guide. Style guides try to tell you to do everything the same way as others do; that's good for software engineering, but not OJs. Style guides restrict you and distract you from problem-solving. In fact, many competitive programmers completelyignore style guides. (I'm not saying style guides are bad, what I'm saying is that they're irrelevant on OJs. Somecontestants do have pretty good styles, including a HackerRankuser.)
What you really need is: 1. a good grasp of your language's core, and 2. algorithms, which are hardly ever language-specific.
You don't have to know everything about js, just know vars, ints, strs, arrays, objs as dictionaries, conditionals, for-loops, while-loops, functions, I/O, and you are good to go. Very, very few problems require OOP/FP/callback/closure/weird stuffs.
As you can see, none of these requires a style guide or an “Algorithms in Javascript” tutorial. Any js tutorial + any algorithm book should do. If you don't want to buy a book, this repo seems to be a good resource.
Once you get to a certain level, you may start thinking about code templates and implementation details, all kinds of language-specific stuffs, but you will know what to do by then.
-------------------- All technical stuffs are above --------------------
-------------------- Everything below is higher level thoughts --------------------
While algorithmic awareness may help us optimize our js, we can't deny the fact that scripting languages are not designed for algorithms.
The general principle of scripting languages is: let the programmer do whatever he thinks is comfortable, and the compiler/interpreter shall try to figure out how to make things fast. In case there's nothing they can do about it, we call this a tradeoff: faster coding at the cost of slower execution. Hardwares are constantly improving, and programmers' time is always more valuable than CPU time, so why bother?
But algorithm is an exception. When we study algorithms, all we want is speed (ok, I lied, but let's say 90% of the time we only care about speed). In other words, our goal defeats the purpose of scripting languages.
That said, if you want to practice algorithms without having to learn C/C++/Java/stuffs, I totally understand. I often use Ruby to rush through problemsets, too. Here are some tips I find useful, and I believe they apply to most scripting languages:
Know how things work. Have an idea how GC, regex, etc work. Understand the magic of join, split, etc.
Be completely aware of when and where a new object is created. Know how to avoid memory allocation and copying by using in-place modification, pass by reference, etc.
Find the balance between convenience and performance. You may want to use an enumerator/generator to shorten your code, but the performance overhead could lead to a TLE.
Try to think in C. While scripting languages tend to have good abstractions, they come at a cost. Are we using a hash when we can use a plain old array? Is it really a good idea to build a suffix array using builtin sort function?
Try to be lazy. If your language gives you handy stuffs at relatively low overhead, go ahead and use it. E.g. if a C user tells you to use big integers, you might as well use py/rb's builtin bigint instead of hand-writing it.
Consider investing some time to take a “real” C/C++/Java algorithm course, online or offline.
Cookie support is required to access HackerRank
Seems like cookies are disabled on this browser, please enable them to open this website
Insertion Sort - Part 1
You are viewing a single comment's thread. Return to all comments →
(I apologize for making this post lengthy.)
To create an array: stick with
new Array(n)
. You want to spend time thinking about algorithms rather than implementation details, so stick with one way of doing things unless you see an obviously better way.There is no algorithm style guide. Style guides try to tell you to do everything the same way as others do; that's good for software engineering, but not OJs. Style guides restrict you and distract you from problem-solving. In fact, many competitive programmers completely ignore style guides. (I'm not saying style guides are bad, what I'm saying is that they're irrelevant on OJs. Some contestants do have pretty good styles, including a HackerRank user.)
What you really need is: 1. a good grasp of your language's core, and 2. algorithms, which are hardly ever language-specific.
You don't have to know everything about js, just know vars, ints, strs, arrays, objs as dictionaries, conditionals, for-loops, while-loops, functions, I/O, and you are good to go. Very, very few problems require OOP/FP/callback/closure/weird stuffs.
As you can see, none of these requires a style guide or an “Algorithms in Javascript” tutorial. Any js tutorial + any algorithm book should do. If you don't want to buy a book, this repo seems to be a good resource.
Once you get to a certain level, you may start thinking about code templates and implementation details, all kinds of language-specific stuffs, but you will know what to do by then.
-------------------- All technical stuffs are above --------------------
-------------------- Everything below is higher level thoughts --------------------
While algorithmic awareness may help us optimize our js, we can't deny the fact that scripting languages are not designed for algorithms.
The general principle of scripting languages is: let the programmer do whatever he thinks is comfortable, and the compiler/interpreter shall try to figure out how to make things fast. In case there's nothing they can do about it, we call this a tradeoff: faster coding at the cost of slower execution. Hardwares are constantly improving, and programmers' time is always more valuable than CPU time, so why bother?
But algorithm is an exception. When we study algorithms, all we want is speed (ok, I lied, but let's say 90% of the time we only care about speed). In other words, our goal defeats the purpose of scripting languages.
That said, if you want to practice algorithms without having to learn C/C++/Java/stuffs, I totally understand. I often use Ruby to rush through problemsets, too. Here are some tips I find useful, and I believe they apply to most scripting languages: