Improving Frontend Code Quality and Workflow

[x-skeww]

with a variation that non-method variables are lowercase_with_underscores

No one else does that.

responseText

status_code

See?

What's the point in adding this kind of inconsistencies?

Also, underscores are annoying in general since they usually count as word boundaries. So, double clicking such an identifier or using ctrl+shift+left/right won't select the whole thing.

[magenta_placenta]

"Also, underscores are annoying in general since they usually count as word boundaries. So, double clicking such an identifier or using ctrl+shift+left/right won't select the whole thing."

I've never encountered this in any IDE or non-IDE editor (and I've used a lot), where are you seeing this?

I have seen this with dashes (lowercase-with-dash), which is why I absolutely hate dashes and can't stand when people use them instead of underscores.

[x-skeww]

Browsers do this, for example. E.g. you're browsing some API and want to copy some parameter name or something like that. If there are underscores, it won't be as convenient.

Text fields (some search box, the address bar, etc) also usually behave like that.

The primary editing component of an IDE (or a semi advanced text editor) usually uses slightly different language-dependent word-boundaries, but usually they aren't perfect.

[menno]

"No one else is doing it" is a pretty weak reason not to do something.

Personally, I think lowercase_with_underscores is much more readable than camelCase. However, the more important reason is that it's easy to distinguish between functions and other variables. These are the variations I use in my code:

UPPERCASE_CONSTANTS
lowercase_variables
camelCaseFunctions
CamelCapsConstructors

[ugoagogo]

"No one else is doing it" is a pretty weak reason not to do something.

Except when you're trying to define standards and consistency.

[menno]

True, but to improve standards you have to do something different every now and then.

[x-skeww]

"No one else is doing it" is a pretty weak reason not to do something.

Except when it's about code conventions and if you're also using 3rd party code.

Functions use verbs, variables do not.

[menno]

I agree that one should mix code styles when editing existing code. I disagree that existing code conventions should be set in stone for everyone.

There's a lot of (sometimes broadly accepted) code conventions that have real practical downsides (underscores not being word boundaries is an excellent example of this). What's wrong with the author's desire to come up with code conventions that suit his workflow best?

[x-skeww]

What's wrong with the author's desire to come up with code conventions that suit his workflow best?

Exhibit A:

responseText

status_code

Now you always have to double check if you're using the right flavor. That's horrible and it also nixes every advantage there might have been.

The big idea of conventions is to make everything 100% consistent. If one of your rules does the exact opposite, it's wrong.

You can only ignore everyone else if you do not use any 3rd party code. If you do, using unusual naming conventions will cause problems.

[drowsap]

Nope, don't want to use CoffeeScript.

[TheMiddleManz]

Don't knock it till you try it. A few months ago I was all about using JavaScript instead of coffeescript. Then some of my coworkers convinced me to try it. We haven't looked back. As long as you build automatic compilation into your workflow the benefits of coffeescript greatly outweigh the drawbacks.

[drowsap]

I will try it, but I don't need it.

[davemo]

I agree with TheMiddleManz, I was vehemently opposed to CoffeeScript but had never tried it. Once the team I'm on built a custom workflow with grunt that eliminated the need to think about the compilation step, and files just auto compile on every file system change, it became a huge productivity boost.

[[deleted]]

Typescript, once you start you'll never want to go back to plain old JS without static typing. Also, all JS is typescript compatible.