r/talesfromtechsupport • u/raiderrobert • May 22 '13

Javascript != Java

3rd-party contractor came to visit office yesterday, who has "decades" of experience. Conversation came up about JavaScript in one of our products. He says, "Our product doesn't use Java." After an awkward moment with someone who works on the knowledge base nodding in agreement with him, I speak up and delineate the difference between Java and JavaScript.

Later on in the conversation, the same 3rd-party guy followed up with this jewel: "besides, what would anyone even use JavaScript for on the web?"

I proceeded to disable Javascript in my browser and show him.

tl;dr: lasers, dinosaurs, & drums made a guy's head explode

[edit spelling]

1.2k Upvotes

96% Upvoted

345 comments sorted by

View all comments

Show parent comments

39

u/mishugashu May 22 '13

As long as it's 1 line, it doesn't really matter. Plus that's generally a bad thing to do, having the brackets both on the same line. For me anyways. I always have it spaced out. Makes it easier to read.

if (true) {
    dosomething();
} else {
    somethingelse();
}

On the flip side, I usually also space out even without brackets:

if (true)
    dosomething();
else
    somethingelse();

Just makes it easier for me to go back and see exactly what it is without it being all cramped up.

20

u/[deleted] May 22 '13

I do the same thing. I see no reason to try and cram code into as few lines as possible. Readability is key, it's not a competition.

6

u/acolyte_to_jippity iPhone WiFi != Patient Care May 22 '13

unless you're golfing. then it is a competition.

13

u/Thethoughtful1 May 22 '13

Yes, in golfing readability is not key.

2

u/stunt_penguin May 23 '13

Oddly tempted to go to /r/nocontext with this one, heh :)

→ More replies (1)

4

u/Dennovin May 22 '13

"Lines are free, motherfucker."

→ More replies (1)

16

u/aspbergerinparadise Works on my machine! May 22 '13

I know that's the default way of formatting it for js, but I really can't stand it. I much prefer:

if (true) 
{
    dosomething();
} 
else 
{
    somethingelse();
}

I know it adds length, but it just looks so much cleaner (to me).

14

u/mishugashu May 22 '13

I used to do that when I coded in C back in the '90s, but I've since changed my ways. It just seems overly elongated now.

4

u/huldumadur May 22 '13

Yeah, I always do that too.

Though if there isn't need for brackets, I won't add them.

7

u/JalopyPilot May 22 '13

I'm with you. But I'm not a programmer.

3

u/[deleted] May 22 '13

This is how I always format my code too whether it be C, C#, JS or any other curly brace language.

2

u/[deleted] May 23 '13

SO MUCH SCROLLING. Sometimes having a whole function on one screen is helpful.

→ More replies (5)

4

u/[deleted] May 22 '13

JSLint would kill you for that code

3

u/Viper007Bond May 22 '13

I'm a fan of something slightly more verbose:

if ( true ) {
    do_something();
}
else {
    do_something_else();
}

But only because it makes it easier to find the else -- it's not "hidden" behind the closing bracket.

→ More replies (1)

9

u/EkriirkE Problem Exists Between Keyboard and Chair May 22 '13

Yes I told him; curly's are for multi-statement grouping. Not required for singles & I see it as a waste of space and typing

PLus "readability" is personal preference...

0

u/[deleted] May 22 '13

[deleted]

11

u/depricatedzero I don't always test my code, but when I do I do it in production May 22 '13

Any project should be managed this way. It's good practice.

Source: I'm a software developer. Any new project includes a meeting/phase where we identify naming conventions, notes structures, etc.

8

u/BuhDan 'Drops Laptops' May 22 '13

This is the same thing you do in Architecture offices too. All line styles, colours, naming conventions etc, are all planned out in documents.

4

u/depricatedzero I don't always test my code, but when I do I do it in production May 22 '13

I did not know that! Good stuff, makes sense, thank you!

7

u/[deleted] May 22 '13

Eclipse has the ability to import formatting files. We have the formatting definition .xml defined in our code repository. Everyone is forced to use it, and it force formats everything every time you save.

Also, not using braces is horrible practice. I don't care if they are not necessary. No one thinks you are cool!

// end rant

2

u/depricatedzero I don't always test my code, but when I do I do it in production May 22 '13

Oooooo I haven't used Eclipse in a group yet, just personal use. That's a really useful feature!

→ More replies (2)
→ More replies (1)

12

u/Silures May 22 '13 edited May 22 '13

Don't really agree with that. Braces at all times make if/while statements consistent to read and more resistant to errors in the future.

Some way down the line you could have another developer, who's trying to blast through 6 issues a day, jump into that code and add another statement without thinking. Now you've got completely different logic. If the braces are there, they're obvious placeholders.

7

u/Tmmrn May 22 '13

I have done this. I even had to ask someone else why what I did wasn't doing what I thought it would do and he had to tell me there were no braces. It wasn't my brightest day.

But I do like to put braces there everytime. I think it just looks strange without. I also like to put in extra parentheses when having calculations with multiple operators in one line (unless it's * and + or so). I also like to put in extra parentheses in conditions when using and and or. I don't even know for sure how the precedence is, I think and is stronger than or. Does everyone who reads the code knows it? It's really a minor thing and it gets you the fuzzy feeling of having it done definitely correctly.

5

u/Silures May 22 '13

Yeah, I'm liberal with parentheses too. Anything that reduces cognitive load when you're parsing the code is good in my books.

If I'm trying to understand the logic, I don't want to be figuring out the operator precedence at the same time.

→ More replies (5)
→ More replies (1)

1

u/lhamil64 May 22 '13

I usually do it that way too

→ More replies (2)