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.
Related
I am creating an ontology for urban systems. For instance if we have the variable that indicate the size of the population I would name it (using the so called camel notation) sizeOfPopulation. The length of the street as lengthOfStreet. Is there a specific or standardized way of doing it?
There is no correct answer to this question because it's extremely subjective.
Programming Style, Coding Conventions and Naming Conventions.
You are probably familiar with: Tabs versus Spaces?
TL;DR: Choose a style with your team or for youself, and be consistent. Look at strictly managed open source code for ideas, eg: Qt, ChibiOS, Linux.
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.)
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.
Feel free to point me to other answers if these have already been asked!
I'm just starting F# with the new release this month. I've got some background in both OO and functional languages (Haskell and Scheme, but not OCaml/ML). A couple of questions have arisen so far from reading through the little tutorial thing that comes with the F# CTP.
1) Are mutable variables preferred over monads? If so, are monads entirely shunned in F#?
2) I'm a tad confused by the capitalization being used. In this tutorial code file, sometimes functions start with a lowercase letter, and sometimes uppercase. I know MS tends to like initial caps with functions and methods, but here it seems like there are two ways of doing it. It's not a huge deal to me, as I'm just playing around on my own time, but I am curious what the standard is.
3) I'm pretty confused about this whole combination of OO and functional styles. print_string "string" makes sense, but then here is List.map fn list (unless List is just the namespace, forgive me if so). Then here is str.Length. Anyone care to elucidate when to use what, and which is preferred?
Thanks!
Regarding mutability: F# allows you to be pragmatic. I rarely prefer a state monad to a mutable/ref, but you can do whichever you like. Monads are not shunned, but I think people tend to only use them when they're a clear-cut win (e.g. async programming).
Regarding naming: there is a tension in the fact that 'functions are values' means you might choose to name a let-bound function with a capital letter (because it's a function, and functions begin with capitals) or with a lower-case letter (because it's a let-bound value (that just happens to have an '->' in its type name)). Personally I prefer to always use upper-case names for all functions, but you'll see both styles (especially since the style of the F# library itself has been slowly evolving/standardizing over the past year or two). Underscores seem to be shunned throughout .Net, and the F# library is no longer an exception (there are a few names left that use underscores, but they stand out now like a sore thumb and will probably be changed).
Regarding function style: I am unclear what you are asking. In the case of List.map, 'List' is the name of an F# module, and 'map' is a function in that module. Member functions (e.g. str.Length) have the advantage of being commonly used throughout .Net, and provide a nice intellisense experience in the editor.
1) I wouldn't go so far as to say monads are shunned... You mentioned you have some background with Haskell - so F# workflows are what you want to look into (the term workflow maybe confusing but these only have a tiny bit to do with business process stuff). In general, sequence expressions and more generally computational expressions (a.k.a workflows) are going to be close to monads. That said mutable is pretty common though I'm not sure 'preferred' would be the way to express it. They each have a place - Personally, I started with two books -- 'Foundation of F#' - but if you're looking to dive in - go 'Expert F#' -- both are good. Honestly, I needed Foundations to help me get started.
2) In the experience I've had, the confusion is that traditional functions in .NET have a convention that really doesn't lend itself to functional programming. As such, I feel that in F# you the confusion can sometimes be when you're looking at usage of 'traditional .NET' named functions vs. elements of F# that are clearly functional... For example, in the book I mention above 'Expert F#' - they mention that you'll see let values such as List.map and Dates.Today in both camelCase and PascalCase (Pascal case being a more traditional .NET). A good rule of thumb is that if you're staying in the functional world - use more traditional functional (camelCase) naming - however if what you're making is expected to be used by other .NET languages, go with the more .NET norm (Pascal). Also note in the functional world there is a much higher tolerance for abbreviation (itr, tbl, etc... ) where as .NET in general has went away from this... So again, you'll see a varying degree of this sort of thing based on if you're calling functional elements vs. elements exposed in F# that are shared across the whole of .NET.
3) I agree that the combination of OO and function styles can be confusing. Again, I'm not sure which is preferred, beyond saying that F# (being functional) clearly styles itself in terms of the functional paradigm. However, F# is a functional language in the .NET world (notice the relative confusion of naming I mention above)... So again, it's not totally clear cut.
Hope this helps... Believe it or not, as you use F# and think of other languages that have shared concepts C++ with C (for example) - it gets easier. Personally, the naming began to make sense and the concepts worked as I started to get that I was a F# is a functional language operating on a traditional platform - made to interoperate (though I'm not sure calling the interoperation seamless would be appropriate :D)
In general monads ("workflows" in F#) are much rarer than in Haskell, firstly because mutable variables are available so it's unlikely that people would choose to use a state monad instead. Secondly there are no higher-kinded type variables, which means that you can't write code that is overloaded to work on any monad, which makes using them much less attractive.
One place that they are commonly used is in sequence expressions (which are really like list comprehensions in Haskell, but those are closely related to the list monad).