Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@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... -
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. -
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? -
@pxeger
> 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.
We currently have multiple exercises for a lecture and they decided to use python this year instead of Matlab,...
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.
Opinions?
question
kebab-case
snake_case
camelcase