Is there a strict definition for kabab case naming convention? Are uppercase letters allowed in kebab case? Does the following names follow kebab case?
Article
Article-Body
Yes, both of your examples adhere to the kebab case convention which only concerns how words in an identifier are separated. According to Wikipedia this naming convention is also called lisp-case, COBOL-CASE or brochette-case.
https://en.wikipedia.org/wiki/Naming_convention_(programming)#Delimiter-separated_words
It's worth noting that basically every programming language support PascalCase and camelCase, most support snake_case but only a few support kebab-case (since it clashes with the syntax for subtraction). Another interesting observation about snake case and kebab case is that they trade expression readability for identifier readability. Here are three examples:
myFirstVariable - mySecondVariable
my_first_variable - my_second_variable
(- my-first-variable my-second-variable)
In the first example the operator "-" stands out more so we see directly that this is a subtraction. In there last two lines there is more "noise" since the underscore character and the dash look somewhat like an operator. In this case the identifiers are easier to read but the expression is harder to read.
Related
I can't find even couple of words about containing numbers in names of variables or on methods. Does anyone have any authoritative information about such cases:
string2map
its4me
etc...
Exactly using number as a word but not number as a number.
Is it acceptable? Not acceptable, stupidly, professional or not. Please argue your opinion.
I haven't found any information either but below are my own thoughts.
Using a digit in an identifier which happens 2 be pronounced in the same way as a word is just silly word play. It also makes the meaning of the identifier ambiguous - does char2old mean that a character is too old, is it an old version of char2 or is it a conversion? It's fun however to come up with names like a10sorFlow, the2lbox, my4mula but they are best avoided.
When it comes to using numbers 1 to N at the end of equally named identifiers, it is probably better to use an array instead if N > 2. Also, when N = 2 there are often clearer names that can be used, like leftCircle and rightCircle instead of circle1 and circle2, or currentChar and nextChar instead of char1 and char2.
Here is a good general guide for naming variables:
Identifier kind
Word class
Example
Boolean variable or pure function
Last word is an adjective
doorClosed, TablePrepared
Non-boolean variable or pure function
Last word is a noun
closedDoor, PreparedTable
Non-pure function (has side-effects)
First word is a verb
CloseDoor, PrepareTable
Recently, i've wanted to use capitalize() function.
When I did so, a warning occured:
'capitalize(): String' is deprecated. Use replaceFirstChar instead.
The suggested replaceFirstChar feels quite long and complicated:
input.replaceFirstChar { if (it.isLowerCase()) it.titlecase(Locale.getDefault()) else it.toString() }
Although everything works fine with capitalize(), i've been just wondering what the reason for deprecated warning is, if there's any problem with it and how can i solve this.
There is no problem with the code per se. The "issue" is what capitalize means for all of the possible languages/characters/platforms/locales.
The doc even says why it is deprecated.
The title case of a character is USUALLY the same as its upper case
with several exceptions. The particular list of characters with the
special title case form depends on the underlying platform.
If you follow all of the reasoning why it is deprecated you reach isTitleCase where you will have an example of characters in languages where the character should not be "upper cased".
Capitalization is writing a word with its first letter as a capital letter (uppercase
letter) and the remaining letters in lower case, in writing systems
with a case distinction.
There are a few good examples and explanations for different languages on Letter case Wiki
e.g.
The German letter "ß" formerly existed only in lower case.
I have the following ABNF grammar:
zero = ["0"] "0"
I would expect this to match the strings 0 and 00, but it only seems to match 00? Why?
repl-it demo: https://repl.it/#DanStevens/abnf-rule-zero-0-0-matches-00-but-not-0
Good question.
ABNF ("Augmented Backus Naur Form"9 is defined by RFC 5234, which is the current version of a document intended to clarify a notation used (with variations) by many RFCs.
Unfortunately, while RFC 5234 exhaustively describes the syntax of ABNF, it does not provide much in the way of a clear statement of semantics. In particular, it does not specify whether ABNF alternation is unordered (as it is in the formal language definitions of BNF) or ordered (as it is in "PEG" -- Parsing Expression Grammar -- notation). Note that optionality/repetition are just types of alternation, so if you choose one convention for alternation, you'll most likely choose it for optionality and repetition as well.
The difference is important in cases like this. If alternation is ordered, then the parser will not backup to try a different alternative after some alternative succeeds. In terms of optionality, this means that if an optional element is present in the stream, the parser will never reconsider the decision to accept the optional element, even if some subsequent element cannot be matched. If you take that view, then alternation does not distribute over concatenation. ["0"]"0" is precisely ("0"/"")"0", which is different from "00"/"0". The latter expression would match a single 0 because the second alternative would be tried after the first one failed. The former expression, which you use, will not.
I do not believe that the authors of RFC 5234 took this view, although it would have been a lot more helpful had they made that decision explicit in the document. My only real evidence to support my belief is that the ABNF included in RFC 5234 to describe ABNF itself would fail if repetition was considered ordered. In particular, the rule for repetitions:
repetition = [repeat] element
repeat = 1*DIGIT / (*DIGIT "*" *DIGIT)
cannot match 7*"0", since the 7 will be matched by the first alternative of repeat, which will be accepted as satisfying the optional [repeat] in repetition, and element will subsequently fail.
In fact, this example (or one similar to it) was reported to the IETF as an erratum in RFC 5234, and the erratum was rejected as unnecessary, because the verifier believed that the correct parse should be produced, thus providing evidence that the official view is that ABNF is not a variant of PEG. Apparently, this view is not shared by the author of the APG parser generator (who also does not appear to document their interpretation.) The suggested erratum chose roughly the same solution as you came up with:
repeat = *DIGIT ["*" *DIGIT]
although that's not strictly speaking the same; the original repeat cannot match the empty string, but the replacement one can. (Since the only use of repeat in the grammar is optional, this doesn't make any practical difference.)
(Disclosure note: I am not a fan of PEG. So it's possible the above answer is not free of bias.)
As the title says how would camel case, which is: theQuickBrownFox, work when one of the words starts with a lower case letter followed by a capital such as is the case in iPhone.
getiPhoneNumber() for instance looks weird.
Would it be getIphoneNumber() or getIPhoneNumber() or what?
what if it was the first word? iPhoneNumber vs iphoneNumber? Since only each different word should be capitalized.
Any algorithm that separates a camel case identifier back into individual words would correctly produce: get IPhone number from getIPhoneNumber and would be fooled by getiPhoneNumber because it would separate this into geti phone number. Therefore, the correct naming is getIPhoneNumber.
Using the very same criterion I would use iphoneNumber rather than iPhoneNumber.
EDIT
Given that there is some consensus about this question being opinion-based I would like to say that any criterion on how to capitalize a sentence using the camel case convention shouldn't be opinion based but consistent with whatever separation algorithm one would happen to use.
This question already has answers here:
Is there any language that allows spaces in its variable names [closed]
(2 answers)
Closed 9 years ago.
Related: Why can't variable names start with numbers?
Is there a technical reason why spaces aren't allowed in variable names or is it down to convention?
For example, what's stopping us from doing something like this?:
average score = sum of scores / number of scores
The only issue that comes to mind is keywords, but one could simply restrict the use of them in a variable name, and the lexer would be able to distinguish between part of a variable and a keyword.
There’s no fundamental reason, apart from the decisions of language designers and a history of single-token identifiers. Some languages in fact do allow multi-token identifiers: MultiMedia Fusion’s expression language, some Mac spreadsheet/notebook software whose name escapes me, and I’m sure of others. There are several considerations that make the problem nontrivial, though.
Presuming the language is free-form, you need a canonical representation, so that an identifier like account name is treated the same regardless of whitespace. A compiler would probably need to use some mangling convention to please a linker. Then you have to consider the effect of that on foreign exports—why C++ has the extern "C" linkage specifier to disable mangling.
Keywords are an issue, as you have seen. Most C-family languages have a lexical class of keywords distinct from identifiers, which are not context-sensitive. You cannot name a variable class in C++. This can be solved by disallowing keywords in multi-token identifiers:
if account age < 13 then child account = true;
Here, if and then cannot be part of an identifier, so there is no ambiguity with account age and child account. Alternatively, you can require punctuation everywhere:
if (account age < 13) {
child account = true;
}
The last option is to make keywords pervasively context-sensitive, leading to such monstrosities as:
IF IF = THEN THEN ELSE = THEN ELSE THEN = ELSE
The biggest issue is that juxtaposition is an extremely powerful syntactic construct, and you don’t want to occupy it lightly. Allowing multi-token identifiers prevents using juxtaposition for another purpose, such as function application or composition. Far better, I think, just to allow most nonwhitespace characters and thereby permit such identifiers as canonical-venomous-frobnicator. Still plenty readable but with fewer opportunities for ambiguity.
I think it is bacause the designers of the language have followed this convention.
I have searched on Google and found that while naming a variable this is a rule which is followed while naming a variable.
Some links are given below:-
SPSS notes
The following rules apply to variable names:
Variable names cannot contain spaces.
C Programming/Variables
Variable names by IBM
Java Variable Naming convention
Variable names are case-sensitive. A variable's name can be any legal
identifier — an unlimited-length sequence of Unicode letters and
digits, beginning with a letter, the dollar sign "$", or the
underscore character "". The convention, however, is to always begin
your variable names with a letter, not "$" or "". Additionally, the
dollar sign character, by convention, is never used at all. You may
find some situations where auto-generated names will contain the
dollar sign, but your variable names should always avoid using it. A
similar convention exists for the underscore character; while it's
technically legal to begin your variable's name with "_", this
practice is discouraged. White space is not permitted.
Wiki for Naming Convention
In all of the above links you will find that the designers have followed this naming convention for naming the variable.
Also check Is there any language that allows spaces in its variable names
This is forced from language designing.
Compiler needs to find out the meaning of words.
Compiler works on a "State Machine" method, and it needs to distinguish key words.
Maybe placing variable names in "[" and "]" give us some solution(like SQL).
But it will be harder to use it in coding...