71–80 of 170 posts
>Let's give em names! The key piece of advice. It helps tremendously with backtraces if your program crashes.
Excel has one of the worst cultures when it comes to naming things. Easy to blame the users, but tools end up being used the way their design encourages. Excel gives you meaningless names. So most things have meaningless names.
I don't consider myself a huge code style pusher but when I see two space indentation I have to really ask... seriously... why???!!! Its funny to me because the languages where you get massive nesting you almost want greater indentation as it gets extremely confusing as to what scope you are in. While I prefer either 4 spaces or tabs (obviously not mixed) I'm not completely revolted with 2 spaces in Algo languages li…
It's because when you use 4 spaces, the lines just become too long. I use 4 spaces in C and 2 in javascript and that makes sense visually for me.
I don't consider myself a huge code style pusher but when I see two space indentation I have to really ask... seriously... why???!!! Its funny to me because the languages where you get massive nesting you almost want greater indentation as it gets extremely confusing as to what scope you are in. While I prefer either 4 spaces or tabs (obviously not mixed) I'm not completely revolted with 2 spaces in Algo languages li…
It's because when you use 4 spaces, the lines just become too long. I use 4 spaces in C and 2 in javascript and that makes sense visually for me.
I don't consider myself a huge code style pusher but when I see two space indentation I have to really ask... seriously... why???!!! Its funny to me because the languages where you get massive nesting you almost want greater indentation as it gets extremely confusing as to what scope you are in. While I prefer either 4 spaces or tabs (obviously not mixed) I'm not completely revolted with 2 spaces in Algo languages li…
I used to feel the same way. Any confusion goes away after you get used to it. Used 4 spaces for ~14 years, used 2 spaces now for 3 years. Now feel the same way about 4 as I once felt about 2 spaces.
As a curious and perhaps naive aside, I've been wondering why the programmer should need to care about asynchronous execution of code at all. Can't it all be abstracted under a procedural layer and let the OS worry about not blocking anything? The advent of promises, async.js, and other paradigms tell me that people still kind of want to write code that does one thing after another, then another, then another.
No. There's no way around understanding that some of your code will run now, and some will run later. It's imperative to understand this in places where you mix sync and async code. It's not possible to avoid mixing them, after all, the async functions have to be called by something.
You could hide all async in a procedural layer if you accepted the constraint that once an async call starts, none of your own code will run until it returns. It wouldn't block the browser or OS, but it would block you. That's the only way to abstract async away, but that's a constraint I think most people would not be willing to accept.
> ...people still kind of want to write code that does one thing after another
I have no choice in the matter. I can't make use of the result of a REST call until I actually have the result.
But, you're right at a fundamental level as well; people do want strict ordering and simple to understand execution with predictable results. The ideal is being able to read a piece of code and see & understand everything about it based on the function you're looking at, and not a bunch of context outside that function. It's the reason functional programming paradigms are favored by so many.
From the site, I get that add(1+1) doesn't require a callback, whereas downloadFile(url) does.
What about somethingHarderThanAddition(noExternalDependency)?
My question is, what is the threshold that I can assume that my code will run sync, and when it cant?
Earlier quoted context omitted.
It's because when you use 4 spaces, the lines just become too long. I use 4 spaces in C and 2 in javascript and that makes sense visually for me.
Let me guess... It is hard for you to read long lines or your monitor isn't big enough? You might call that an accessibility thing right? You get what I'm getting at. You traded one accessibility that is fairly easy to fix (at worse case you have line wrapping) for one that is almost impossible to fix (zooming and large font don't really help).
To me some parts of FE development kind of require deep nesting, e.g. css, but in javascript if you are 4/5 levels deep in the nest (with the "long lines symptom"), then you should do as proposed in the article: split into modules and functions.
And sometimes (often?) long lines comes from the bad habit to do 3/4 things in one statement. To me good code does exactly one thing per statement, and except for config or urls, is should not be long.
Are we back to "semi-colons are uncool"? It's so much eaier for me to glean the intent when browsing JS written with semi-colons.
Modern JavaScript has gotten very complicated lately because it's so flexible. Many people are developing interesting frameworks to solve niche problems; however, it feels like many of these solutions are overly complicated outside the niche. Yet, developers are adopting these frameworks due to it being trendy instead of choosing the correct tool for the job.
Many times, the correct "tool" for the job can be a mixture of an effective standard library, small specific libraries, and good conventions like the author describes.
I've been a programmer for 18 years now, and I am convinced that simple proven solutions are the way to go.
Earlier quoted context omitted.
Let me guess... It is hard for you to read long lines or your monitor isn't big enough? You might call that an accessibility thing right? You get what I'm getting at. You traded one accessibility that is fairly easy to fix (at worse case you have line wrapping) for one that is almost impossible to fix (zooming and large font don't really help).
Reading long lines is also difficult. To me some parts of FE development kind of require deep nesting, e.g. css, but in javascript if you are 4/5 levels deep in the nest (with the "long lines symptom"), then you should do as proposed in the article: split into modules and functions. And sometimes (often?) long lines comes from the bad habit to do 3/4 things in one statement. To me good code does exactly one thing per…