5 ms·

I come from a Python background. However, thanks to work and school, I now program mostly in JavaScript, PHP, and Java (though I still use Python when I get a c

I come from a Python background. However, thanks to work and school, I now program mostly in JavaScript, PHP, and Java (though I still use Python when I get a chance). Now, I could use underscore_names in Java and JavaScript, but I don't. Even though I personally prefer underscore_names to camelCaseNames, I also realize that those languages are designed with camelCaseNames in mind, that the community conventions are for camelCaseNames, and that it is better to write code that looks nice and idiomatic in that language than it is to write code that looks nice and idiomatic in Python. Not to mention that there are some cases where camelCaseNames are required - for example, when overriding inherited methods in Java - and if I used camelCase where required and underscore_names everywhere else, my code would be inconsistent, which to me is worse than using a style I don't like. So just because I could use underscore_names when I wanted to, there are a lot of reasons that I shouldn't. A lot of those points also apply to JavaScript: * JavaScript was designed with the use of semicolons in mind. Brandon Eich himself has said that ASI was only intended as an extra check for sloppy programmers. * Outside the Ruby on Rails crowd, all the JavaScript I have ever seen uses semicolons. Even within the Rails crowd, this "no semicolons" thing is fairly recent. * Since the majority of JavaScript syntax is intended to mimic Java syntax, which does require semicolons to separate statements, semicolons blend well with the language, and are therefore nice and idiomatic. * There are situations where you have to use semicolons due to ambiguity to write straightforward code - there are workarounds, like tricks involving !, but they confuse the intent of the code. One thing that I noticed is that most of the notable semicolon-haters - fat, mislav, and the GitHub guys - come from Ruby on Rails. Conveniently enough, Ruby does not require semicolons at the end of statements. I suspect this anti-semicolon fervor may come from a desire to use Ruby's conventions with JavaScript.

jrockway 15y ago
Incidentally, we use CamelCaseMethodNames in Python at Google, presumably to be consistent between languages. If you're one company that uses multiple languages, it may be beneficial to use the same style in each, even if that style is non-idiomatic.
- frio 15y ago
  Doesn't that lead to inconsistencies in style when you use external libraries though?
  - jrockway 15y ago
    It's even inconsistent with the Python core. I'm not going to defend the practice, but it's ended up being a lot less terrible than I thought it was when I first started writing Python here. I've used Twisted before, with its own weird style, and the weird style doesn't really distract much from the rest of the program. It's bad when everyone uses their own style, but if you only have 1.5 styles, it's probably OK. (But again, I would never write a style guide that said methods in Python must start with a capital letter and contain no underscores. That convention is for classes.)
140dbs 15y ago
I think your camelCase example really nails it. Code should be written in a way that is both non-ambiguous and idiomatic to the existing codebase. If you're in a position where you can define that idiom, then by all means do so. But stay consistent so that when others join a project, or you leave a project, the intent of your codebase is well understood without needing to wade through pages of documentation. So, IMO, while semicolons are important, they're relatively trivial and an easy "bug" to fix. If I'm looking for an authority, I typically check out the Google Style Guides. A similar, though more pressing issue that I've faced recently is the proper parenthization of conditions for if. It's generally nice when you don't have to spend a minute or two remembering/looking up the nuances of C++ operator precedence. Know all of the intricacies and tricks for a language doesn't mean every member of your team knows them that well either.
sophacles 15y ago
Your comment makes me wonder if this is localized issue, or a more general anti-pattern in polyglot programming. The pattern being: "push my favorite language into the other ones I use". It may or may not be covered by "you can write FORTRAN in any language", or some sort of corollary to Greenspun's 10th law.
- web_chops 15y ago
  Actually, this is one of the reasons why some of the new languages pick a popular older language's syntax and coding style. Example, most static typed languages follow C syntax (C++,Java, C#) because most of them expect the programmers to migrate from the older language. This makes the migration much smoother. And when the syntax does differ, programmers tend to overestimate the complexity of the newer language (most C++ programmers complain a lot about Objective-C's syntax initially).
wahnfrieden 15y ago
As a counterpoint, we decided to with underscored_names for our JS since we work with a lot of serialized Python data structures via JSON and using the same naming convention on server as client means our JS doesn't have a mix of camelCase and under_scores for things received via JSON and things defined in the JS. We're not writing reusable libraries for other projects to use, and we don't use a heavy amount of 3rd party code, so it's no big deal.
- LeafStorm 15y ago
  You bring up a good point. There may be times when technical constraints mean you have to go against the prevailing style -- in your case, interoperability with existing code. (I know that a lot of this works in the other direction when dealing with "foreign" API's in Python.) However, fat and co. aren't avoiding semicolons because there are technical constraints that require them to avoid them. They just seem to not like semicolons.
- quanticle 15y ago
  "using the same naming convention on server as client means our JS doesn't have a mix of camelCase and under_scores for things received via JSON" Couldn't that almost be viewed as a feature, rather than a bug? I mean, this way you can instantly tell if a particular variable was received from the server via JSON or was defined in the client code itself. I would consider a naming distinction like to be a benefit, rather than a harm.
  - wahnfrieden 15y ago
    Hm, how is that generally valuable to know? Maybe in certain use cases but for us that would just be noise.

jrockway 15y ago

Incidentally, we use CamelCaseMethodNames in Python at Google, presumably to be consistent between languages. If you're one company that uses multiple languages, it may be beneficial to use the same style in each, even if that style is non-idiomatic.

frio 15y ago
Doesn't that lead to inconsistencies in style when you use external libraries though?
- jrockway 15y ago
  It's even inconsistent with the Python core. I'm not going to defend the practice, but it's ended up being a lot less terrible than I thought it was when I first started writing Python here. I've used Twisted before, with its own weird style, and the weird style doesn't really distract much from the rest of the program. It's bad when everyone uses their own style, but if you only have 1.5 styles, it's probably OK. (But again, I would never write a style guide that said methods in Python must start with a capital letter and contain no underscores. That convention is for classes.)

140dbs 15y ago

I think your camelCase example really nails it. Code should be written in a way that is both non-ambiguous and idiomatic to the existing codebase. If you're in a position where you can define that idiom, then by all means do so. But stay consistent so that when others join a project, or you leave a project, the intent of your codebase is well understood without needing to wade through pages of documentation. So, IMO, while semicolons are important, they're relatively trivial and an easy "bug" to fix. If I'm looking for an authority, I typically check out the Google Style Guides. A similar, though more pressing issue that I've faced recently is the proper parenthization of conditions for if. It's generally nice when you don't have to spend a minute or two remembering/looking up the nuances of C++ operator precedence. Know all of the intricacies and tricks for a language doesn't mean every member of your team knows them that well either.

sophacles 15y ago

Your comment makes me wonder if this is localized issue, or a more general anti-pattern in polyglot programming. The pattern being: "push my favorite language into the other ones I use". It may or may not be covered by "you can write FORTRAN in any language", or some sort of corollary to Greenspun's 10th law.

web_chops 15y ago
Actually, this is one of the reasons why some of the new languages pick a popular older language's syntax and coding style. Example, most static typed languages follow C syntax (C++,Java, C#) because most of them expect the programmers to migrate from the older language. This makes the migration much smoother. And when the syntax does differ, programmers tend to overestimate the complexity of the newer language (most C++ programmers complain a lot about Objective-C's syntax initially).

wahnfrieden 15y ago

As a counterpoint, we decided to with underscored_names for our JS since we work with a lot of serialized Python data structures via JSON and using the same naming convention on server as client means our JS doesn't have a mix of camelCase and under_scores for things received via JSON and things defined in the JS. We're not writing reusable libraries for other projects to use, and we don't use a heavy amount of 3rd party code, so it's no big deal.

LeafStorm 15y ago
You bring up a good point. There may be times when technical constraints mean you have to go against the prevailing style -- in your case, interoperability with existing code. (I know that a lot of this works in the other direction when dealing with "foreign" API's in Python.) However, fat and co. aren't avoiding semicolons because there are technical constraints that require them to avoid them. They just seem to not like semicolons.
quanticle 15y ago
"using the same naming convention on server as client means our JS doesn't have a mix of camelCase and under_scores for things received via JSON" Couldn't that almost be viewed as a feature, rather than a bug? I mean, this way you can instantly tell if a particular variable was received from the server via JSON or was defined in the client code itself. I would consider a naming distinction like to be a benefit, rather than a harm.
- wahnfrieden 15y ago
  Hm, how is that generally valuable to know? Maybe in certain use cases but for us that would just be noise.