This is PascalCase: SomeSymbol
This is camelCase: someSymbol
This is snake_case: some_symbol
So my questions is whether there is a widely accepted name for this: some-symbol? It's commonly used in url's.
There isn't really a standard name for this case convention, and there is disagreement over what it should be called.
That said, as of 2019, there is a strong case to be made that kebab-case is winning:
https://trends.google.com/trends/explore?date=all&q=kebab-case,spinal-case,lisp-case,dash-case,caterpillar-case
spinal-case is a distant second, and no other terms have any traction at all.
Additionally, kebab-case has entered the lexicon of several javascript code libraries, e.g.:
https://lodash.com/docs/#kebabCase
https://www.npmjs.com/package/kebab-case
https://v2.vuejs.org/v2/guide/components-props.html#Prop-Casing-camelCase-vs-kebab-case
However, there are still other terms that people use. Lisp has used this convention for decades as described in this Wikipedia entry, so some people have described it as lisp-case. Some other forms I've seen include caterpillar-case, dash-case, and hyphen-case, but none of these is standard.
So the answer to your question is: No, there isn't a single widely-accepted name for this case convention analogous to snake_case or camelCase, which are widely-accepted.
It's referred to as kebab-case. See lodash docs.
It's also sometimes known as caterpillar-case
This is the most famous case and It has many names
kebab-case: It's the name most adopted by official software
caterpillar-case
dash-case
hyphen-case or hyphenated-case
lisp-case
spinal-case
css-case
slug-case
friendly-url-case
As the character (-) is referred to as "hyphen" or "dash", it seems more natural to name this "dash-case", or "hyphen-case" (less frequently used).
As mentioned in Wikipedia, "kebab-case" is also used. Apparently (see answer) this is because the character would look like a skewer... It needs some imagination though.
Used in lodash lib for example.
Recently, "dash-case" was used by
Angular (https://angular.io/guide/glossary#case-types)
NPM modules
https://www.npmjs.com/package/case-dash (removed ?)
https://www.npmjs.com/package/dasherize
Adding the correct link here Kebab Case
which is All lowercase with - separating words.
I've always called it, and heard it be called, 'dashcase.'
There is no standardized name.
Libraries like jquery and lodash refer it as kebab-case. So does Vuejs javascript framework. However, I am not sure whether it's safe to declare that it's referred as kebab-case in javascript world.
I've always known it as kebab-case.
On a funny note, I've heard people call it a SCREAM-KEBAB when all the letters are capitalized.
Kebab Case Warning
I've always liked kebab-case as it seems the most readable when you need whitespace. However, some programs interpret the dash as a minus sign, and it can cause problems as what you think is a name turns into a subtraction operation.
first-second // first minus second?
ten-2 // ten minus two?
Also, some frameworks parse dashes in kebab cased property. For example, GitHub Pages uses Jekyll, and Jekyll parses any dashes it finds in an md file. For example, a file named 2020-1-2-homepage.md on GitHub Pages gets put into a folder structured as \2020\1\2\homepage.html when the site is compiled.
Snake_case vs kebab-case
A safer alternative to kebab-case is snake_case, or SCREAMING_SNAKE_CASE, as underscores cause less confusion when compared to a minus sign.
I'd simply say that it was hyphenated.
Worth to mention from abolish:
https://github.com/tpope/vim-abolish/blob/master/doc/abolish.txt#L152
dash-case or kebab-case
In Salesforce, It is referred as kebab-case. See below
https://developer.salesforce.com/docs/component-library/documentation/lwc/lwc.js_props_names
Here is a more recent discombobulation. Documentation everywhere in angular JS and Pluralsight courses and books on angular, all refer to kebab-case as snake-case, not differentiating between the two.
Its too bad caterpillar-case did not stick because snake_case and caterpillar-case are easily remembered and actually look like what they represent (if you have a good imagination).
My ECMAScript proposal for String.prototype.toKebabCase.
String.prototype.toKebabCase = function () {
return this.valueOf().replace(/-/g, ' ').split('')
.reduce((str, char) => char.toUpperCase() === char ?
`${str} ${char}` :
`${str}${char}`, ''
).replace(/ * /g, ' ').trim().replace(/ /g, '-').toLowerCase();
}
This casing can also be called a "slug", and the process of turning a phrase into it "slugify".
https://hexdocs.pm/slugify/Slug.html
Related
Why are these libraries named after _ ?
Is there some significance behind it or the reason is "Just because we can"?
As far as i know, underscore and lodash do a lot of similar stuff. Also, both the names point to _
Even their variable names are _
So is there some relation of _ with the working of these libraries? Or its just a name?
Lodash
From my understanding of the history of the two, lodash was meant as a lightweight replacement for underscore. So lodash is effectively a play on words on underscore - "low dash", what does a dash - look like when its a bit lower to the ground? _ Why, an underscore of course
So that covers lodash in as much detail as it warrants.
Underscore
Underscore's origin would only be a guess - but a guess I shall make.
"Back in the golden days" of Javascript, when the mighty JQuery reigned supreme, small (at the time) utility libraries started emerging - but one thing we didn't have at the time (or wasn't well known) was simple constructs for import and requiring external libraries.
Very much like JQuery grouping all of its functionality under one giant $ object - underscore (I am guessing) wanted the same. Why? Probably for brevity and that l33t factor. Especially in the days where most people were just including a bunch of script tags in the footer. If you were looking at utility library home page, what appeals to you more:
// totes l33t
_.map(a, function(e) { ... }
// pfft, no thanks grandpa
underscore.map(a, function(e) { ... }
But why _. Well after $ its one of few cool short names left:
An identifier must start with $, _, or any character in the Unicode
categories “Uppercase letter (Lu)”, “Lowercase letter (Ll)”,
“Titlecase letter (Lt)”, “Modifier letter (Lm)”, “Other letter (Lo)”,
or “Letter number (Nl)”.
https://mathiasbynens.be/notes/javascript-identifiers
JSON is not a subset of JavaScript. I need my output to be 100% valid JavaScript; it will be evaluated as such -- i.e., JSON.stringify will not (always) work for my needs.
Is there a JavaScript stringifier for Node?
As a bonus, it would be nice if it could stringify objects.
You can use JSON.stringify and afterwards replace the remaining U+2028 and U+2029 characters. As the article linked states, the characters can only occur in the strings, so we can safely replace them by their escaped versions without worrying about replacing characters where we should not be replacing them:
JSON.stringify('ro\u2028cks').replace(/\u2028/g,'\\u2028').replace(/\u2029/g,'\\u2029')
From the last paragraph in the article you linked:
The solution
Luckily, the solution is simple: If we look at the JSON specification we see that the only place where a U+2028 or U+2029 can occur is in a string. Therefore we can simply replace every U+2028 with \u2028 (the escape sequence) and U+2029 with \u2029 whenever we need to send out some JSONP.
It’s already been fixed in Rack::JSONP and I encourage all frameworks or libraries that send out JSONP to do the same. It’s a one-line patch in most languages and the result is still 100% valid JSON.
Consider the following sample codes:
1.Sample
var IsAdminUser = (User.Privileges == AdminPrivileges)
? 'yes'
: 'no';
console.log(IsAdminUser);
2.Sample
var IsAdminUser = (User.Privileges == AdminPrivileges)?'yes': 'no';
console.log(IsAdminUser);
The 2nd sample I am very comfortable with & I code in that style, but it was told that its wrong way of doing without any supportive reasons.
Why is it recommended not to use a single line ternary operator in Node.js?
Can anyone put some light on the reason why it is so?
Advance Thanks for great help.
With all coding standards, they are generally for readability and maintainability. My guess is the author finds it more readable on separate lines. The compiler / interpreter for your language will handle it all the same. As long as you / your project have a set standard and stick to it, you'll be fine. I recommend that the standards be worked on or at least reviewed by everyone on the project before casting them in stone. I think that if you're breaking it up on separate lines like that, you may as well define an if/else conditional block and use that.
Be wary of coding standards rules that do not have a justification.
Personally, I do not like the ternary operator as it feels unnatural to me and I always have to read the line a few times to understand what it's doing. I find separate if/else blocks easier for me to read. Personal preference of course.
It is in fact wrong to put the ? on a new line; even though it doesn’t hurt in practice.
The reason is a JS feature called “Automatic Semicolon Insertion”. When a var statement ends with a newline (without a trailing comma, which would indicate that more declarations are to follow), your JS interpreter should automatically insert a semicolon.
This semicolon would have the effect that IsAdminUser is assigned a boolean value (namely the result of User.Privileges == AdminPrivileges). After that, a new (invalid) expression would start with the question mark of what you think is a ternary operator.
As mentioned, most JS interpreters are smart enough to recognize that you have a newline where you shouldn’t have one, and implicitely fix your ternary operator. And, when minifying your script, the newline is removed anyway.
So, no problem in practice, but you’re relying on an implicit fix of common JS engines. It’s better to write the ternary operator like this:
var foo = bar ? "yes" : "no";
Or, for larger expressions:
var foo = bar ?
"The operation was successful" : "The operation has failed.";
Or even:
var foo = bar ?
"Congratulations, the operation was a total success!" :
"Oh, no! The operation has horribly failed!";
I completely disagree with the person who made this recommendation. The ternary operator is a standard feature of all 'C' style languages (C,C++,Java,C#,Javascript etc.), and most developers who code in these languages are completely comfortable with the single line version.
The first version just looks weird to me. If I was maintaining code and saw this, I would correct it back to a single line.
If you want verbose, use if-else. If you want neat and compact use a ternary.
My guess is the person who made this recommendation simply wasn't very familiar with the operator, so found it confusing.
Because it's easier on the eye and easier to read. It's much easier to see what your first snippet is doing at a glance - I don't even have to read to the end of a line. I can simply look at one spot and immediately know what values IsAdminUser will have for what conditions. Much the same reason as why you wouldn't write an entire if/else block on one line.
Remember that these are style conventions and are not necessarily backed up by objective (or technical) reasoning.
The reason for having ? and : on separate lines is so that it's easier to figure out what changed if your source control has a line-by-line comparison.
If you've just changed the stuff between the ? and : and everything is on a single line, the entire line can be marked as changed (based on your comparison tool).
Within Node.js, I am using querystring.stringify() to encode an object into a query string for usage in a URL. Values that have spaces are encoded as %20.
I'm working with a particularly finicky web service that will only accept spaces encoded as +, as used to be commonly done prior to RFC3986.
Is there a way to set an option for querystring so that it encodes spaces as +?
Currently I am simply doing a .replace() to replace all instances of %20 with +, but this is a bit tedious if there is an option I can set ahead of time.
If anyone still facing this issue, "qs" npm package has feature to encode spaces as +
qs.stringify({ a: 'b c' }, { format : 'RFC1738' })
I can't think of any library doing that by default, and unfortunately, I'd say your implementation may be the more efficient way to do this, since any other option would probably either do what you're already doing, or will use slower non-compiled pure JavaScript code.
What about asking the web service provider to follow the RFC?
https://github.com/kvz/phpjs is a node.js package that provides all the php functions. The http_build_query implementation at the time of writing this only supports urlencode (the query string includes + instead of spaces), but hopefully soon will include the enc_type parameter / rawurlencode (%20's for spaces).
See http://php.net/http_build_query.
RFC1738 (+'s) will be the default enc_type either way, so you can use it immediately for your purposes.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I've just had a discussion with a developer about naming classes in C#. My final throw away line was, "Let's not put any emoticons in our class names."
I can't think of a way you could put emoticons in C# class names, but I haven't thought too hard about it. Is this possible?
Does any programming language allow it? What would be the best/worst language to be able to perform this in?
Update: The Scheme answer bests answers my question. It was a quick idea after a quick discussion so I'm going to accept after a short amount of time and then move on with my life. Thanks for the responses.
Many Japanese-style emoticons - O_o, v_v and the like - are perfectly legal substrings of identifier names in most languages.
For example in Scheme you have the flexibility to include symbols like :, -, / ... in the names,
(define (:-D x)
(+ x 1))
...
(:-D 9)
output: 10
C# supports any Unicode letter for identifiers, so if you find some suitable for emoticons in the Unicode tables, you can use them. The CLR itself allows far more characters in identifier names, like the typical backtick used in compiler-generated names, so you could get really crazy by defining really strange names in MSIL, and then loading the classes with reflection in C# because it does not support those characters...
The method name oO comes to mind. It's an emoticon in itself (small and large eye), but when called on a reference, it expands to a thought bubble: .oO(Hello).
Slightly off-topic: I was processing filenames the other day and realised that all sorts of faces had appeared in my code:
string number(fn.begin()+fn.rfind('_')+1,fn.begin()+fn.rfind('.'));
And of course there are the right-to-left emoticons you almost always get at the end of lines of C++ code:
mesh->Delete();
Why does C++ look so sad?
In C++, if you name a class/struct _ (a poor decision, but here we go), you can derive from it like this:
struct emoticon_to_the_right_of_this :_{
};
Thinking about this, a class o might be just as good:
struct another_emoticon_to_the_right_of_this :o{
};
Hm. I seem to only come up with sad ones. Is that Freud guy around here today? I do have a question to ask him...
Perl uses :: as a package name separator, which means that an IM client might decide to insert a smiley when I talk about XML::Parser (contains ":P") or Data::Dumper (contains ":D"). Punctuation other than :: isn't recommended in package names, so most "extended" smileys are out of the picture, but if I wanted to be very silly I could reference a variable named ${ ':-)' } -- but it would always have to be referenced using the ${'...'} syntax since it's not a recognizable identifier name :)
At this moment in 2014, Apple have just released Swift yesterday. And I made a short example for this. It compiles and runs perfectly fine. :D
I believe I've seen languages that use => to access object attributes (something like person=>father)
It's not actually part of the name, but it could be an emoticon.
Not strictly class names, but there are a few that pop up in PHP from time to time, like an underscore in single quote when concatenating:
$foo = $bar.'_'.$baz;
And as someone else pointed out, you don't even really need special symbols for some of them:
class o_0 {}
class v_v {}
class T_T {}
Something more convoluted:
function d() { echo 'Thumbs up!!'; }
d('_');