We are deciding if we should standardize on camelCase or PascalCase for XAML resource names.
Does anybody know if one style is usually favored over the other?
Does Microsoft have any convention for this?
For the record, we use camelCase for fields (that includes WPF controls, in the very few cases where they are named)
To avoid religious arguments: I'm not looking for "this approach is BETTER than the other because..." responses. A good answer would include links to reference material and/or statistics.
For the x:Name attribute, you should use camel casing, as this generally results in a field being created behind the scenes. Microsoft, doesn't really follow this though in their default Styles, as control templates are one exception where a backing field is not created.
For the x:Key attribute, I've only ever seen pascal casing used. This includes in Microsoft's default Styles.
Related
What would happen if I didn't use the camel case to name my Kotlin file? Would it cause performance issues or any other kind of technical issues?
e.g. SouthGeorgiaAndTheSouthSandwichIslands.kt instead of its country code SGS.kt
No technical issues, and no performance issues. The only drawback: it could be tricky to navigate and search classes. So, in general, it is better to stick to the Java convention, where a file name must be the same as a class name.
There are no technical or performance issues.
Names are written for developers and not for machines, so you choose a name you (and your team) understand and know what is meant by it. Also it is good practice stick to the convetions of CamelCase as all Java/Kotlin developers are used to it and tooling like auto-completion and search in IDEs are optimised to support the camel case schema.
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 am facing certain C/AL tasks those days and as I am used to code in c#, C/AL seems a bit "different" in several aspects.
In particular I am wondering, why it is recommed to use variable names starting with uppercase letters.
From my point of view it would be a benefit in terms of readability to use camelcase notation for variables.
Is there any reason, why it is recommed that way by Microsoft?
I do not think there is a specific reason why the Pascal Case (first letter always uppercase) is used. That being said it is more of a guideline for all developers so that the code is uniform across all products. The general idea is that if you merge code from two different sources (e.g. two different developers) the end result would appear as if the code was from a single source.
Some companies have their own internal rules how code should be formatted. I prefer the use of the naming conventions specified by Microsoft because:
it makes my code consistent with the Navision standard code (objects in the range 1..49999),
it makes my code consistent with my coworkers (our company policy is to use the Microsoft naming conventions).
The MSDN Naming Conventions page states:
"Precise and consistent terminology helps the end user work with the application. Rules for naming and abbreviating objects also help developers to understand the CRONUS International Ltd. demonstration database and develop new features faster."
Pascal Case should be used for general code consistency and overall uniformity but is not necessary or required. I would advise you to consult your company policy on Naming Conventions and follow those or if you are starting fresh to follow the Microsoft naming guidelines.
I'm pretty new to MvvmCross and understand that successful use of the framework relies on specific naming conventions in some areas. I have been looking around trying to find information on these naming conventions, but apart from figuring some of them out from watching various videos, I haven't been able to find anything that explains all the requirements in one place. Any suggestions?
The naming conventions used:
in bindings are in https://github.com/MvvmCross/MvvmCross/wiki/Customising-using-App-and-Setup#registering-custom-bindings
in View-ViewModel lookup are in https://github.com/MvvmCross/MvvmCross/wiki/Customising-using-App-and-Setup#overriding-view-viewmodel-associations
the default IoC setup - using the postfix "Service" is described in https://github.com/MvvmCross/MvvmCross/wiki/Service-Location-and-Inversion-of-Control#bulk-registration-by-convention
the registration of ValueConverters is described in https://github.com/MvvmCross/MvvmCross/wiki/Value-Converters#referencing-value-converters-in-touch-and-droid
The MvvmCross manifesto - https://github.com/MvvmCross/MvvmCross/wiki/The-MvvmCross-Manifesto - doesn't force any of these conventions on you - you can override this and use your own convention schemes or use your a different mechanism for anything you want to do.
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".