I'm teaching myself Objective-C and I noticed in a lot of books and examples the use of 'k' and camel-casing in constant definition, e.g.
#define kMyConstant 0
What is the significance of the 'k'?
Is this unique to Objective-C style, or common to C in general?
Why the deviation from (what I've always thought as a best practice) K_MY_CONSTANT style?
Thanks.
It was mentioned once before in the SO question, Lower case "k" in Cocoa.
It is a general programming notation
not specific to Objective-C (i.e.
Hungarian Notation) and the "k" stands for "constant".
If you look at the Google cache of Google's guidelines for Objective-C you can see that they used to include it in their styleguide:
Constant names (#defines, enums, const local variables, etc.) should start with a lowercase k and then use mixed case to delimit words, i.e. kInvalidHandle, kWritePerm.
Though a pain to write, they are absolutely vital to keeping our code readable. The following rules describe what you should comment and where. But remember: while comments are very important, the best code is self-documenting. Giving sensible names to types and variables is much better than using obscure names and then trying to explain them through comments.
But it has since been removed in the live version of the document. It should be noted that it goes against the the Official Coding Guidlines for Cocoa from Apple.
All caps (as in K_MY_CONSTANT) normally denotes a macro - not necessarily a constant. It's generally important for macros to stand out because they clobber all namespaces.
The 'k' convention is used (but not universally) for non-macro constants in C/C++ and probably other languages. I suspect 'k' is used because 'c' is already often used - either to denote a class name (as in CString) or that a variable is a counter.
The kMyConstant thing goes back to the very old Mac programming days (80s/90s being "very old"). This was a standard Apple used and many Mac programmers also used; this took the place of MY_CONSTANT-type definitions.
I would imagine the authors you are reading were Mac Pascal/C programmers for the old Mac Toolbox prior to being NeXT/Cocoa programmers. The Mac libraries used to be called the "Toolbox"--this was the set of APIs and libraries that turned into Carbon over time.
I still use kMyConstant sometimes; drives my old school Unix programmer colleagues nuts. :-)
I think use of a leading "k" is because all languages pronounce it as a hard consonant and thus it reminds people of the english pronunciation of "constant" :-)
No reserved words start with k so it is easier as a search target.
Alternatively, from a graphical aspect, as a leading character it provides a very clear flag in front of the rest of the name. Leading "c" is less obvious and might be used to indicate roles (such as in Hungarian notation) or classes (if in a case-insensitive language).
MY_CONSTANT is pretty well agreed as being for macro-based constants. It is sometimes important to know that a constant is defined by a macro, for example that implies it is based on literals and thus from a limited range of data types, as well as being defined at a global scope and thus (as Michael Burr pointed out) overrides any local namespaced constants.
Related
I hope this doesn't get closed due to being too broad. I know it comes down to personal preference, but there is an origin to all casing conventions and I would like to know where this one came from and a logical explanation as to why people use it.
It's where you go all like var empName;. I call that lower camel, although it's probably technically called something else. Personally, I go like var EmpName. I call that proper camel and I like it.
When I first started programming, I began with the lower camel convention. I didn't know why. I just followed the examples set by all the old guys. Variables and functions (VB) got lower camel while subs and properties got proper camel. Then, after I finally acquired a firm grasp on programming itself, I became comfortable enough to question the tactics of my mentors. It didn't make logical sense to me to use lower camel because it wasn't consistent, especially if you have a variable that consists of one word which ends up being in all lowercase. There is also no validation mechanism in place to make sure you are appropriately using lower vs. upper camel, so I asked why not just use proper camel for everything. It's consistent since all variable names are subject to proper camelization.
Having dug deeper into it, it turns out that this is a very sensitive issue to many programmers when it is brought to question. They usually answer with, "Well, it's just personal preference" or "That's just how I learned it". Upon prodding further, it usually invokes a sort of dogmatic reaction with the person as I attempt to find a logical reason behind their use of lower camel.
So anyone want to shed a little history and logic behind casing of the proper camelatory variety?
It's a combination of two things:
The convention of variables starting with lower case, to differentiate from classes or other entities which use a capital. This is also sometimes used to differentiate based on access level (private/public)
CamelCasing as a way to make multi-word names more readable without spaces (of course this is a preference over underscore, which some people use). I would guess the logic is that CamelCasing is easier/faster for some to type than word_underscores.
Whether or not it gets used is of course up to whomever is setting the coding standards that govern the code being written. Underscores vs CamelCase, lowercasevariables vs Uppercasevariables. CamelCase + lowercasevariable = camelCase
In languages like C# or VB, the standard is to start private things with lowercase and start public/protected things with uppercase. This way, just by looking at the first letter you can tell whether the thing you are messing could be used by other classes and thus any changes need more scrutiny. Also, there are tools to enforce naming conventions like this. The one created/used internally at Microsoft is called StyleCop and is available as a free download.
Historically, well named variables in C (a case-sensitive language) consisted of a single word in lower case. UPPERCASE was reserved for macros.
Then came along C++, where classes are usually CapitalizedAndCamelCased, and variables/functions consisting of several words are camelCased. (Note that C people tend to dislike camelCase, and instead write identifiers_this_way.
From there, it spread.
And, yes, probably other case-sensitive languages have had some influence.
lowerCamelCase I think has become popular because of java and javascript.
In java, it is specifically defined why, that the first word should be a verb with small letters where the remaining words start with a capital letter.
The reason why java chose lowerCamelCase I think depends on what they wanted to solve. Java was launched in 1995 as a language that would make programming easy. C/C++ that was often used was often considered difficult and too technical.
This was something java claimed to solve, more people would be able to program and the same code would work on different hardware. The code was the documentation, you didn't need to comment code, just read and everything would be great.
lowerCamelCase makes it harder to write "technical" code because it removes options to use uppercase and lowercase letters to better describe the code from a technical perspective. Java didn't want to be hard, java was the language to use where everyone could learn to program.
javascript in browsers was created in 10 days by Brendan Eich in 1995. Why javascript selected lowerCamelCase I think is because of java. It has nothing to do with java but it has "java" in its name "javascript".
I see a lot of different styles of variable names used in different kind of languages. Sometimes these names are lowercase and using underscores (i.e. test_var) and other times I see variables like testVar.
Is there a specific reason why programmers use different variable name styles in different languages?
It's really just the convention for that programming language.
For example, most Java programs use camel-casing (testVar) while a lot of C programs use _ to seperate words (test_var).
It's completely the choice of the programmer, but most languages have "standard" naming conventions.
As Wiki says :
Reasons for using a naming convention (as opposed to allowing programmers to choose any character sequence) include the following:
to reduce the effort needed to read and understand source code;1
to enhance source code appearance (for example, by disallowing overly long names or abbreviations).
Also there are code conventions in companies that care about readability of their code.
This simplify the code sharing between programmers and they don't spend time to understand what means variables name "aaa" and "bbb".
There is no real reason. Each language and sometimes even platform can have varying naming conventions.
For instance, in .Net TestVar would be seen if it was a public class variable. In C++, testVar would probably be opted for. In Ruby, test_var, etc. It's just a matter of preference by the community and/or creators.
I urge you to follow language standards. I work on a team that has had many developers working on the code over the years, and very few standards have been followed. The majority of our code is nearly unreadable. I have been working on a standardization project for the last several months. It has been very difficult to enforce and get buy-in. I'm hopeful that people will come around as they start seeing the benefits of easy to read code.
For naming conventions/standards keep this in mind:
Follow team/company standards
Follow language standards
Follow the style that the program is already using
Do whatever you want (Not really - if you don't have standards follow
your language standards/conventions.)
One thing I like very much is reading about different programming languages. Currently, I'm learning Scala but that doesn't mean I'm not interested in Groovy, Clojure, Python, and many others. All these languages have a unique look and feel and some characteristic features. In the case of Clojure I don't understand one of these design decisions. As far as I know, Clojure puts great emphasis on its functional paradigm and pretty much forces you to use immutable "variables" wherever possible. So if half of your values are immutable, why is the language dynamically typed?
The Clojure website says:
First and foremost, Clojure is dynamic. That means that a Clojure program is not just something you compile and run, but something with which you can interact.
Well, that sounds completely strange. If a program is compiled you can't change it anymore. Sure you can "interact" with it, that's what UIs are used for but the website certainly doesn't mean a neat "dynamic" GUI.
How does Clojure benefit from dynamical typing
I mean the special case of Clojure and not general advantages of dynamic typing.
How does the dynamic type system help improve functional programming
Again, I know the pleasure of not spilling "int a;" all over the source code but type inference can ease a lot of the pain. Therefore I would just like to know how dynamic typing supports the concepts of a functional language.
If a program is compiled you can't change it anymore.
This is wrong. In image-based systems, like Lisp (Clojure can be seen as a Lisp dialect) and Smalltalk, you can change the compiled environment. Development in such a language typically means working on a running system, adding and changing function definitions, macro definitions, parameters etc. (adding means compiling and loading into the image).
This has a lot of benefits. For one, all the tools can interact directly with the program and do not need to guess at the system's behaviour. You also do not have any long compilation pauses, because each compiled unit is very small (it is very rare to recompile everything). The NASA JPL once corrected a running Lisp system on a probe hundreds of thousands of kilometres away in space.
For such a system, it is very natural to have type information available at runtime (that is what dynamic typing means). Of course, nothing hinders you from also doing type inference and type checks at compilation time. These concepts are orthogonal. Modern Lisp implementations typically can do both.
Well first of all Clojure is a Lisp and Lisps traditionally have always been dynamically typed.
Second as the excerpt you quoted said Clojure is a dynamic language. This means, among other things, that you can define new functions at runtime, evaluate arbitrary code at runtime and so on. All of these things are hard or impossible to do in statically typed languages (without plastering casts all over the place).
Another reason is that macros might complicate debugging type errors immensely. I imagine that generating meaningful error messages for type errors produced by macro-generated code would be quite a task for the compiler.
I agree, a purely functional language can still have an interactive read-eval-print-loop, and would have an easier time with type inference. I assume Clojure wanted to attract lisp programmers by being "lisp for the jvm", and chose to be dynamic like other lisps. Another factor is that type systems need to be designed as the very first step of the language, and it's faster for language implementors to just skip that step.
(I'm rephrasing the original answer since it generated too much misunderstanding)
One of the reasons to keep Clojure (and any Lisp) dynamically typed is to simplify creation of macros. In short, macros deal with abstract syntax trees (ASTs) which can contain nodes of many, many different types (usually, any objects at all). In theory, it's possible to make full statically typed macro system, but in practice such systems are usually limited and sparsely spread. Please, see examples below and extended discussion in the thread.
EDIT 2020: Wow, 9 years passed from the time I posted this answer, and people still add comments. What a legacy we all have left!
Some people noted in comments that having a statically typed language doesn't prevent you from expressing code as data structure. And, strictly speaking, it's true - union types allow to express data structures of any complexity, including syntax of a language. However I claim that to express the syntax, you must either reduce expressiveness, or use such wide unions that you lose all advantages of static typing. To prove this claim I will use another language - Julia.
Julia is optionally typed - you can constrain any function or struct field to have a particular type, and Julia will check it. The language supports AST as a first class citizen using Expr and Symbol types. Expression definition looks something like this:
struct Expr
head::Symbol
args::Vector{Any}
end
Expression consists of a head which is always a symbol and list of arguments which may have any types. Julia also supports special Union which can constrain argument to specific types, e.g. Symbols and other Exprs:
struct Expr
head::Symbol
args::Vector{Union{Symbol, Expr}}
end
Which is sufficient to express e.g. :(x + y):
dump(:(x + y))
Expr
head: Symbol call
args: Array{Any}((3,))
1: Symbol +
2: Symbol x
3: Symbol y
But Julia also supports a number of other types in expressions. One obvious and helpful example is literals:
:(x + 1)
Moreover, you can use interpolation or construct expressions manually to put any object to AST:
obj = create_some_object()
ex1 = :(x + $objs)
ex2 = Expr(:+, :x, obj)
These examples are not just a funny experiments, they are actively used in real code, especially in macros. So you cannot constrain expression arguments to a specific union of types - expressions may contain any values.
Of course, when designing a new language you can put any restrictions on it. Perhaps, restricting Expr to contain only Symbol, Expr and some Literals would be useful in some contexts. But it goes against principles of simplicity and flexibility in both - Julia and Clojure, and would significantly reduce usefulness of macros.
Because that's what the world/market needed. No sense in building what's already built.
I hear the JVM already has a statically typed language ;)
Objective-C doesn't have namespaces, and many (such as CocoaDevCentral's Cocoa Style Guide) recommend prefixing your class names with initials to avoid namespace collision.
Quoting from the above link:
Objective-C doesn't have namespaces,
so prefix your class names with
initials. This avoids "namespace
collision," which is a situation where
two pieces of code have the same name
but do different things.
That makes sense, I suppose. But honestly, in the context of a relatively small app (say, an iPhone game), is this really an issue? Should I really rename MyViewController to ZPViewController? If not, at what point do namespace collisions really become a concern?
If you're writing an application that uses some set of libraries, then you already know what your namespace looks like and you just need to select names that do not conflict with existing available functions.
However, if you are writing a library for use by others, then you should pick a reasonably unique prefix to try to avoid name collisions with other libraries. With only two characters there may still be name collisions, but the frequency will be reduced.
Small apps shouldn't use up all the good names, so won't have a problem with namespaces.
But it is a good idea to get used to the style that languages are generally written in. It makes it easier to read other people's code, and for others to read yours.
E. g., use camelCase variables in Java, but CamelCase vars in C#, hyphen_separated_names in C, etc.
It will make it easier for you to learn in the long run.
I have read (but haven't verified) that Apple has private classes in their frameworks that don't include any prefixes on the names. So if your application classes' names have no prefixes, you risk colliding with those.
I've worked with repositories where classes were not prefixed. (Or only some of the classes were prefixed.)
One thing that I found painful is it's sometimes hard to tell if code was written by someone inside or outside the company. Using a consistent prefix makes it immediately obvious for someone reading the code for the first time.
Keep in mind that code will be read many more times than written.
Also, it can definitely come in handy when using tools like grep and sed.
what is the best way to declare variable names.... in uppercase ...? .. lowercase? in which area must be declared in any case ... and what name is appropriate depending on the roll of the standard variable ... there are some variables to declare?...sorry for the question..I'm new to the world of programming ... I hope not bother .... =)
Well here are some links for the coding standards for various languages..
This has standards for variable naming and a lot more.
C# coding standards
C++ coding standards
Java coding standards
And here is generic coding standards article that explains the reasoning behind the coding standards.
Atleast for C and C++ we can use Hungarian notation
If:
the language doesn't dictate it; and
your coding standards don't dictate it,
then just make it as readable as possible. Hordes of developers in the future will sing praises to your name for not inflicting horrible code on them.
My personal favorite is all uppercase and underscores for constants (IQ_LIMIT) and camel case for everything else (getItembyId(), itemCount). But that's personal preference, not something written on stone tablets.
It really depends on the programming language you use, and any coding conventions that are followed by a group.
For example, there is the GNU coding standards for writing C code which covers variable names down to the indentation of lines.
For languages, the Code Conventions for the Java Programming Language lays out some coding conventions for capitalization and naming of variables, packages, classes, methods, etc in the Java programming language.
When in Rome, do as the Romans. Each language usually has its own idioms with respect to these sorts of things.
IMO, knowing the scope of a variable is the most important thing. You should know at a glance how much code can effect a variable and how much code will be effected by your changing it. In this way encapsulation (and your sanity) can be maintained. You won't accidentally change a global variable and mysteriously hose the whole program. Also they should stand out like a sore thumb just begging to be refactored away.
Therefore upper-case the first letter for globals (where "global" is any variable that can be seen by more than one function) and lower-case the first letter for every else. Constants traditionally get all caps.
So in studlyCaps style it would be:
GlobalVariable
localVariable
CONSTANTVARIABLE
And using under scores:
Global_Variable
local_variable
CONSTANT_VARIABLE
Whether you use studlyCaps or under scores depends on your programming language and local style (I prefer under scores for their readability and no confusion about capitalization).
In C#, we use PascalCase for properties and methodnames and camelCase for other members. For constants we use CAPS_WITH_UNDERSCORE. For the html elements hungarian notation is used. (I think these are Microsoft standards.)
A corollary to "When in Rome..." is to do as the previous coder has done. When you are working on another developers code or project, you should match your style to the existing style. While seeing a weird convention is puzzling and hard to deal with at first, it is nothing compared to sorting out a file that switches notation and style every couple of functions.
When working on your own project, or as a single developer you can do what is most comfortable within reason.