so some controversial opinions

Our company is moving most of our code style to snake_case, even the JavaScript. Here's our resoning:

Take the CustomerAccountMembership model. In our Python server, we would access it as obj.customer_account_membership, in JavaScript as obj.customerAccountMembership and our API endpoint as api/path/customer-account-membership. Thus we had several String utility functions such as `camelize`, `kebabChop` (which is ironically camelCased) and `snakeify`, and we would use them in translating from URL path to JS to Python, which was troublesome.

Now HTTP allows _underscores_ unescaped and do not pose any significant meaning. JavaScript also accepts it as a valid character in variable names. On the other hand, HTTP is strictly lower-cased, and all computer languages use the -dash- to signify subtraction. Sooo the _underscore_ is the only style that is compliant everywhere.

Unless, of course, we go with customeraccountmembership, which I refuse to do.

I'm not that deep into code character rules.

  • 8

    I think I put too much rum in my coffee.

    You're using coding style to circumvent proper encoding and translation to w protocol like HTTP?
  • 4
    I prefer following the language preferred naming patterns, but as long as you have it consistent through out the project its ok i guess.
  • 1
    It's okay. Consistency is good
  • 2
    @24th-Dragon the problem is that following language's preferred naming patterns and being consistent are mutually exclusive if you're using many languages.

    The thing was like this: everyone was fine using camelCase until Python tried to show off how unique it was by "being out of the box" and preferring snake_case. However... snake_case might be the ONLY way to be consistent.

    I'll put Vue as an example: "Prop names should always use camelCase during declaration, but kebab-case in templates". That's just plain inconsistency. Again, HTML ignores case, but JavaScript uses dashes as subtraction. BUT HTML accepts snake_cased attributes.

    I'm being too picky I know 😆 but I dream of an infinitely consistent world...
  • 1
    I have two minds about this.

    For one, I prefer consistency. I also prefer snake_case. However, using it in Javascript feels like blasphemy.

    There are exceptions whre it's used in JS, though - namely, when using it in APIs or databases (in databases, it's common to use snake_case over camelCase).

    So when you receive an object from a document DB, the keys are usually in snake_case anyway. Linters have always barked about this even though it's a legitimate situation.

    To be quite honest, as long as you're still sanitizing user input, I don't really see an issue with this. The only IMPERATIVE thing is that you have automated enforcement (linters + CI) that can automatically classify what is stylistically correct and what is not. Otherwise, you're going to cause headaches with it.

    There are worse things I've seen done. At least logic went into the decision, it doesn't (appear) to be a "workaround" for security issues and the like, and it only strengthens consistency across a large base.
  • 0
    If the JS is an API lib for customers I would definitely not do that.
    Use a router/muxer for setting up a decent API. If it looks like data in an URL beyond path beyond an ID you are probably doing it wrong.
    When doing RPC the first argument should be the sting of the method/function you want to call in that case it's perfectly fine too use the convention of the stuff you are calling (it's just saying data like a db/table name).
    If it is an API lib than your functions are the explicit mapping. Where is the problem?
  • 0
    Uhh "HTTP is strictly lower-case" you sure about that one? It's case sensitive for everything but the header names, and possibly the method.
  • 1
    But personally snake case is so much easier to read than camel case. Also it works even in uncased languages like Chinese, and like you said works everywhere (except domain names in URLs 😡)
  • 0

    > This specification defines a number of standardized methods that are
    commonly used in HTTP, as outlined by the following table. By
    convention, standardized methods are defined in all-uppercase
    US-ASCII letters.

    As per RFC 7231, it is convention that the standard headers are uppercase but it doesn't appear mandator. The BNF snippet for method is just a token, which does not enforce casing.

    Therefore, method names (at least in HTTP 1.1) can be whatever case you prefer; it is just convention to use uppercase.
  • 0
    Oh yeah my bad, URI's are case sensitive except for the scheme and domain.
Add Comment