Why can't variable names have spaces in them? [duplicate] - variables

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...

Related

Can kebab case have upper case letters as first letter?

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.

Naming conventions. Method or variable names containing numbers as a words

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

Which are the variable naming rules in Processing?

(Question by John Williams, from a Coursera forum, which I decided to share with the community, since I haven't been able to find this answered anywhere.)
The following code runs without error:
int _j = 1;
//int 2var = 2;
int var2 = 2;
int Kvar = 3; // first letter can be uppercase
int spec$var = 4;
int com_pound_var = 5; // compounding without camel case
int com$pound$two = 6;
int $var = 199;
println(_j);
println(var2);
println(Kvar);
println(spec$var);
println(com_pound_var);
println(com$pound$two);
println($var); //first character can be special
Since the compiler accepts _j, Kvar, and $var as valid variable names, it is clear that variable names do not need to start with a lowercase letter.
I was unable to locate the variable naming rules anywhere in the reference.
What are the variable naming rules for the Processing language?
Quick answer: can start with any letter, underscore and dollar signs, continue with letters, numbers, underscore and dollar signs. Details below.
I could also not find anything in the reference or the documentation at all. However, inspecting the source code, I found that Processing is not a language of its own, but rather a framework in which you run some commands. The difference is that you're actually writing a different language, and Processing just gives you some basic scaffolding where you build on top of.
For some technical details: Processing compiles a Java Build with some flags, spins up a virtual machine (Java VM, not same thing as a full fledged virtual machine) and connects to it to get input and output streams (this is why you can interact with the mouse or get the console output of your own program in a separate window). (Source.)
This language, which you may have guessed already, is Java.
With that said, the actual docs that answer this question is the Java Language Specification, which, to simplify things, is as close as you can get to an answer. (But if you really want to know, it's a mess.)
Specifically, the section on Identifiers, which I'll sum up below:
Can start with any letter (A-Z, a-z), underscore (_), dollar sign ($), or any unicode "letter" (accented, chinese, etc. Details.)
Can continue with any of the above, and can also continue with digits (0-9). Can also contain other unicode "letters" (Details.)
Can have unlimited length
Cannot be any Java keyword (list here)
Cannot be false, true, null
They can look the same and still be different if their codes are different (some Unicode letters look just like letters but are different ones)
I hope this helps! Investigating was fun.

RFC 6570 URL Templates : the role of / vs. other prefixes

I recently read some of : https://www.rfc-editor.org/rfc/rfc6570#section-1
And I found the following URL template examples :
GIVEN :
var="value";
x=1024;
path=/foo/bar;
{/var,x}/here /value/1024/here
{#path,x}/here #/foo/bar,1024/here
These seem contradictory.
In the first one, it appears that the / replaces ,
In the 2nd one, it appears that the , is kept .
Thus, I'm wondering wether there are inconsistencies in this particular RFC. I'm new to these RFC's so maybe I don't fully understand the culture behind how these develop.
There's no contradiction in those two examples. They illustrate the point that the rules for expanding an expression whose first character is / are different from the rules for expanding an expression whose first character is #. These alternative expansion rules are pretty much the entire point of having a variety of different magic leading characters -- which are called operators in the RFC.
The expression with the leading / is expanded according to a rule that says "each variable in the expression is replaced by its value, preceded by a / character". (I'm paraphrasing the real rule, which is described in section 3.2.6 of that RFC.) The expression with the leading # is expanded according to a rule that says "each variable in the expression is replaced by its value, with the first variable preceded by a # and subsequent variables preceded by a ,. (Again paraphrased, see section 3.2.4 for the real rule.)

What characters are allowed in Oracle bind param placeholders?

Could anyone please point me to where the characters allowed for a bind variable name are listed? I've spent several hours digging through Oracle SQL docs to no avail.
I mean ":id" in the following:
SELECT * FROM mytable WHERE id = :id
E.g. can a dot be used there like ":some.id"? Will it function exactly like the version without the dot?
These pages both state bind variables must be "legal Oracle identifiers"
The documentation I found doesn't specifically say that a dot can
be part of a legal identifer. I was able to use a dot in both
a table name and as a bind variable name, but it looks like it is
not recommended.
PAGES THAT HAVE BIND VARIABLE NAMING CONVENTIONS
(These pages state a bind variable must be a legal identifier):
http://www.utoug.org/i/doc/concept_bind_var.htm
http://docs.oracle.com/cd/E23903_01/doc.41/e21674/concept_ses_val.htm#BEIEGCCC
PAGE THAT DESCRIBES LEGAL IDENTIFIERS:
http://docs.oracle.com/cd/B19306_01/server.102/b14200/sql_elements008.htm
I could not find anything on this page that says that a dot is a legal
part of an identifier (E.G. table or bind variable name) except in a DB link.
Even though $ and # are legal, they are not even recommended, so "."
may work but is obviously not recommended (not even mentioned as legal on
this page)
Bind variable names must correspond to an item name.
Bind variable names are not case-sensitive.
Bind variable names cannot be longer than 30 characters (that is, they must be a valid Oracle identifier).
I know that a valid ORACLE identifer (based on ORACLE's definition
of a legal identifier) cannot start with a number,
and can have SOME special characters like $ and . but if there are
special characters the identifier MUST be in double quotes.
I was able to get an identifier with a dot to work in a bind
variable, but I had to put double quotes around the bind
variable when the bind variable had a dot in it.
create or replace function F0416B
RETURN VARCHAR2
is
V_STMT VARCHAR2(1999);
V_RESULT VARCHAR2(1999);
BEGIN
V_STMT := 'INSERT INTO TEST0411(FIELD1, FIELD2) VALUES ( :"A.1" , :"A.2")';
EXECUTE IMMEDIATE V_STMT USING 'AS201', 'AS202';
RETURN 'INSERT-OK';
COMMIT;
EXCEPTION
WHEN OTHERS THEN RETURN SQLERRM;
END;
#This may work but according to the above documentation a period/dot
in a bind variable or other object name is not legal/recommended...
#This is the sentence on the ORACLE schema object naming page that is
telling me this:
Nonquoted identifiers can contain only alphanumeric characters from your database character set and the underscore (_), dollar sign ($), and pound sign (#). Database links can also contain periods (.) and "at" signs (#). Oracle strongly discourages you from using $ and # in nonquoted identifiers.
I also had trouble finding the official Oracle doc for this: http://docs.oracle.com/cd/E14072_01/appdev.112/e10646/oci04sql.htm#i420655
On top of that, it turns out that you can quote placeholders (:"_normallyinvalid") and then most of the rules listed in the preceding link stop being relevant. I couldn't find any Oracle doc offering this suggestion; just hints around the internet.