There are:
camelCase
UpperCamelCase (aka PascalCase)
snake_case
kebab-case
but is there an official name for this case.with.dots?
Related
In the snake_case convention https://en.wikipedia.org/wiki/Snake_case, for example, snake_case, it seems snake is a specific type of case (there is CamelCase)
Is more common to put the specific thing first? E.g., list_fruit vs fruit_list in naming variables?
Yes, for non-boolean variables it's a good practice to let the last word in the identifier be a noun which describes the variable in a general sense. In your example it would be fruit_list or simply fruits. For boolean variables it's a good practice to let the last word be an adjective; compare for instance fruits_rotten with rotten_fruits. I would say the strategy of naming and the clarity of identifiers is independent of whether you use snake case or Pascal case, or any other convention.
Here is my general strategy for naming identifiers:
Variables or functions without side-effects
Truth value -> Adjective as the last word (e.g. fruits_rotten)
Non-truth value -> Noun as the last word (e.g. rotten_fruits)
Functions with side-effects (Procedures) -> Verb as the first word (e.g. discard_rotten_fruits)
What exactly does this mean? How to write package names.
"Package name 'OPERATORLER' part should not start with an uppercase letter"
Kotlin Documentation Says:
Names of packages are always lowercase and do not use underscores (org.example.project).
In programming languages, it is best practice to use lowercase letters or camel case notation for package names, variable and function names. Generally, you should avoid multiword names. But always remember, class names should always start with a capital letters. These rules are not necessary to follow but it is for your convenient thats why IDE recommend this.I should recommend to follow best practices for naming conventions and all other things.
I'm trying to call a child component's method from my parent component using $refs. It works if I do it the regular way: this.$refs.actualNameOfTheChildComponent.someMethod()
But for my app's needs I have to use a variable name instead of the child component's actual name:
const previousAction = `action${i-1}`
this.$refs.previousAction.showConflict()
In the second line, Vue doesn't understand that I'm not referring to a child component named previousAction, but I'm referring to a child component whose name is the value of the variable previousAction.
What's the right way to do it?
Writing .something is just syntactic sugar for ["something"]. Therefore you can use:
const previousAction = `action${i-1}`
this.$refs[previousAction].showConflict()
You can read more about the differences between dot notation and bracket notation here.
There are some important differences between dot and bracket
notation:
Dot notation:
Property identifies can only be alphanumeric
(and _ and $)
Property identifiers cannot start with a number.
Property identifiers cannot contain variables.
OK — obj.prop_1,
obj.prop$
Not OK — obj.1prop, obj.prop name
Bracket notation:
Property identifiers have to be a String or a variable that references a String.
It is okay to use variables, spaces, and Strings that start
with numbers
OK — obj["1prop"], obj["prop name"]
What are the backticks used for in the snippet below?
Why add them around the fun is(amount:Int ):Boolean { ... }?
verifier.`is`(amount)
It's because is is a reserved keyword in Kotlin. Since Kotlin is supposed to be interoperable with Java and is is a valid method (identifier) name in Java, the backticks are used to escape the method so that it can be used as a method without confusing it as a keyword. Without it it will not work because it would be invalid syntax.
This is highlighted in the Kotlin documentation:
Escaping for Java identifiers that are keywords in Kotlin
Some of the Kotlin keywords are valid identifiers in Java: in, object, is, etc. If a Java library uses a Kotlin keyword for a method, you can still call the method escaping it with the backtick (`) character
foo.`is`(bar)
Useful for tests
Backticks are very useful in tests for long function names:
#Test
fun `adding 3 and 4 should be equal to 7`() {
assertEquals(calculator.add(3, 4), 7)
}
This makes the function names more readable. We can add spaces and other special characters in the function names. However, remember to use it only in tests, it's against the Kotlin coding conventions of the regular code.
It allows you to call a Java method whose name is a Kotlin keyword. It won't work if you leave out the backticks.
The backtick are a "workaround" to allow you to call methods that have a name representing a Kotlin keyword.
See kotlinlang:
Some of the Kotlin keywords are valid identifiers in Java: in, object, is, etc. If a Java library uses a Kotlin keyword for a method, you can still call the method escaping it with the backtick (`) character
is in list of Kotlin reserved words
To use Kotlin reserved word (such as is or object) for function/class name you should wrap it to backticks
Some of the Kotlin keywords are valid identifiers in Java: in, object, is, etc. If a Java library uses a Kotlin keyword for a method, you can still call the method escaping it with the backtick (`) character
https://kotlinlang.org/docs/reference/java-interop.html
I've encountered a PC-Lint error message (e136) :
Illegal macro name -- The ANSI standard restricts the use of certain names as
macros. defined is on the restricted list.
I cannot find any reference to such a list in the ANSI C specifications. Is this list maintained by PC-Lint itself or is there an official list of Macro names forbidden in ANSI C?
The chances are that you're using a macro name such as _HEADER_FILE_H_ which is reserved to the implementation and PC Lint is telling you about this error.
After removing the horizontal scroll bar, it appears that the name you are misusing is defined. The C preprocessor uses the name defined for:
#if defined(SOME_MACRO)
You cannot, therefore, write:
#define defined(x) ((x) != 0)
or anything similar. You should treat defined as a keyword, at least in pre-processor directives (and you can't treat it as a macro outside of pre-processor directives). Although you could use it as a variable name (and you could use endif and define and elif as variable names too), you'd be best off not using it and treating them as reserved words.
The C11 standard (ISO/IEC 9899:2011) says:
7.1.3 Reserved identifiers
¶1 Each header declares or defines all identifiers listed in its associated subclause, and
optionally declares or defines identifiers listed in its associated future library directions
subclause and identifiers which are always reserved either for any use or for use as file
scope identifiers.
All identifiers that begin with an underscore and either an uppercase letter or another
underscore are always reserved for any use.
All identifiers that begin with an underscore are always reserved for use as identifiers
with file scope in both the ordinary and tag name spaces.
Each macro name in any of the following subclauses (including the future library
directions) is reserved for use as specified if any of its associated headers is included;
unless explicitly stated otherwise (see 7.1.4).
All identifiers with external linkage in any of the following subclauses (including the
future library directions) and errno are always reserved for use as identifiers with
external linkage.184)
Each identifier with file scope listed in any of the following subclauses (including the
future library directions) is reserved for use as a macro name and as an identifier with
file scope in the same name space if any of its associated headers is included.
¶2 No other identifiers are reserved. If the program declares or defines an identifier in a
context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved
identifier as a macro name, the behavior is undefined.
¶3 If the program removes (with #undef) any macro definition of an identifier in the first
group listed above, the behavior is undefined.
184) The list of reserved identifiers with external linkage includes math_errhandling, setjmp, va_copy, and va_end.
Previous editions of the standard used very similar wording for the equivalent set of restrictions.