Hacker News new | ask | show | jobs
by fat 4882 days ago
fwiw, we generally just try to do what the language does:

border-radius <- css dashes

document.createElement <- js camel (except constants, etc.)

etc…

4 comments

This is the correct rationale, and should be used to end every argument about naming conventions.
what about the programmers who made javascript and css? I'm sure they flame each other!
I personally prefer using the exact oposite to the language. That way my code or customizations are set apart visually:

   obj.getSomethingById()  <-- theirs

   obj.redraw_panel()   <-- mine
Non-native English speakers sometimes prefer to name variables in their native language for the same reason.
English is not my native language but I hate code with non-English variable names.
Why is it important that your code is visually set apart from the rest of the language?
When someone, particularly a beginner, is reading the code and come across, say, an unfamiliar function name, then they know straight away whether to look for it in the language docs or a definition somewhere else in the code. Not essential, but handy.
I guess that only works for really simple project. Once you bring in third party libraries, your own common library, your own multiple layers of abstraction, this naming convention means almost nothing. It pays the price of annoying programmers who are already familiar with the code for not-so useful short term benefit of the very early beginner.
Surely there are better ways to deal with this problem. Different languages have different solutions for this, but completely breaking the naming conventions doesn't seem like the way to go.
That's a really bad thing in my eyes. Why teach a beginner that consistency is something that does not exist?

Also, non-english variables are an abomination! I've worked with code with some finnish variables. Not only is it harder to grok, it's actively distracting.

this
AFAIK CSS uses camelCase for variables.[1]

1: http://css-tricks.com/currentcolor/