Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
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?
24th-Dragon231539dI prefer following the language preferred naming patterns, but as long as you have it consistent through out the project its ok i guess.
iiii306039dIt's okay. Consistency is good
eo287582838d@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'm being too picky I know 😆 but I dream of an infinitely consistent world...
junon278238dI have two minds about this.
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.
hjk101292738dIf 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?
pxeger46838dUhh "HTTP is strictly lower-case" you sure about that one? It's case sensitive for everything but the header names, and possibly the method.
pxeger46838dBut 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 😡)
> 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
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.
eo287582838dOh yeah my bad, URI's are case sensitive except for the scheme and domain.