For example: Meta-information
metaInfornation, metainformation or metainfo?
getMetainfo, getMetaInfo or getMetaInformation?
what about objective-c style?
I am personally a fan of camelCase and no abbreviations. So I would use metaInformation. metaInfo is also good because it's a very common abbreviation.
What I dislike is something like printAttr or similar.
Apple has docs on that topic describing the conventions.
Note that you should not use get in your getter!
When you apply these conventions you have many opportunities (e.g. Key-Value-Coding).
If it's a property, then you'd want to use metaInformation or metaInfo, and it will generate the getter as -metaInformation or -metaInfo. Never use get in a method name.
Related
If I have a view with two or more words, e.g.:
public function actionApprovalQueue()
what is the naming convention of the view file itself?
approval-queue.php
approvalQueue.php
approvalqueue.php
??
The documentation on Conventions only says:
View files should be named after the view name. For example, the index
view is in the index.php file.
which gives no clue about views with two or more words.
When it comes to naming conventions, it comes down to what suits your organisation, or what is followed in your organisation, or what the rest of your team decides. The key is consistency throughout your code base.
I would say go with the dash(hyphen), because variables are generally named $xyzAbc or $xyz_abc. So it would make sense to use approval-queue.php.
Definitely do not go for approvalqueue.php.
Edit: Read more about Yii's conventions here.
Yii recommends naming variables, functions and class types in camel case which capitalizes the first letter of each word in the name and joins them without spaces. Variable and function names should have their first word all in lower-case, in order to differentiate from class names (e.g. $basePath, runController(), LinkPager). For private class member variables, it is recommended to prefix their names with an underscore character (e.g. $_actionList).
Because namespace is not supported prior to PHP 5.3.0, it is recommended that classes be named in some unique way to avoid name conflict with third-party classes. For this reason, all Yii framework classes are prefixed with letter "C".
A special rule for controller class names is that they must be appended with the word Controller. The controller ID is then defined as the class name with first letter in lower case and the word Controller truncated. For example, the PageController class will have the ID page. This rule makes the application more secure. It also makes the URLs related with controllers a bit cleaner (e.g. /index.php?r=page/index instead of /index.php?r=PageController/index).
Is there a naming convention for a property/variable that has a dot/decimal in the name of the thing that the property/variable represents?
For example:
A class has a property that represents a 2.5 volt battery. Since we can't name the property/variable as "2.5VoltBattery" (the idea being that we can't have the decimal point in the name), I have always used the convention "2Point5VoltBattery" (replace the dot with the word Point).
I'm curious if there is a naming convention for this.
No; it is preferential and will vary by team preference more than anything.
You can use Battery_2_5_Volts. Not sure whether is exact naming convention. To me it feels as a relevant one.
What do you name your arrays when the name of the item is already plural?
array names makes sense.
array collisionDatas not so much.
I almost always name it as Item name + s. My goal when naming a variable is to make sure that I reduce the effort needed to read and understand source code.
So if I have an array of children for example I name it childrens. I don't care at all if the childrens is an english word or not, I'm not writing a book! So later when a see something like:
foreach (Object x in childrens) I know I'm iterating on an array of children and not on an array of child objects.
Your question heavily depends on the programming language. Objective-C has strong naming conventions that people adhere to.
Try collisionDataArray.
Personally, I'm used to Cocoa and Objective-C nowadays, and over here long variable and class names are not unusual. For me, autocomplete is good enough, and the code ends up being quite readable.
I sometimes add the type in front, like:
array arrNames
array arrColisionData
I prefer to add the "arr" in the beginning so when you get them in an ordered list, they stay together.
In this post Jon Skeet pointed out that the following code should be changed to conform with the .NET naming conventions. Doing that would also decrease the amount of noise in the code.
Enum enUtilityTypeDetailStudentEntryWorkflow As Integer
enUTDSEW_Default = 379
enUTDSEW_ApplicantRecordBook = 380
End Enum
I must admit, I was pretty much like a sheep and was following what others have done before me. I thought the prefix did not look right and then to have it twice did not make sense either.
After looking at a couple of .NET Framework examples, it looks like this would be closer to the standard.
Enum StudentEntryWorkflow As Integer
Default = 379
ApplicantRecordBook = 380
End Enum
Am I on the mark with using these names?
Any other suggestions or comments in general?
Where I work we also use a prefix for enums (E in our case), and I must say that I like it. It makes it very easy to spot an Enum and differentiate it from a class or variable. Here's an example from our codebase:
myJob.Status = EJobStatus.Completed
Here we can easily see that the status that's been assigned to the job is the value "Completed" from the enum "EJobStatus".
My personal preference aside, if you want to follow the .NET naming conventions, then there is no prefix to enums. But the most important of all is to always follow the same conventions in a given code base.
Edit: I just saw that you also prefix the actual enum values, we don't do that though. We always refer enums this way ESomeEnum.SomeValue. In that case it's not useful to prefix the actual enum value. Also, I don't think it's a good idea to use the same prefix for the enum name and the enum values, because they're not the same thing.
I don't know about standard, but using Hungarian notation on enums and enum values is not something I have seen before.
Your second example is closer to the kind of code I normally see, so in that respect, yes, it is more standard.
See section 8.2.3 on this guideline - pascal casing and no prefix/postfix.
Guideline 16 of Section 2.1 of Lance Hunt's C# coding standards also says to avoid prefixes and postfixes.
I would say this is pretty universal - the point of having enums it to aid readability. Using prefixes and postfixed reduces readability and thus is pretty universally discouraged.
In VB.net, I don't believe you can refer to an enum value without prefacing it with the name of the enum, so it's completely redundant to "prefix" the enum value name with anything.
ie, you couldn't use
dim x = enUTDSEW_Default
even if you wanted to, you'd have to use:
dim x = enUtilityTypeDetailStudentEntryWorkflow.enUTDSEW_Default
which is just silly.
The enum prefix probably came from a C++ programmer. In C++ the enum name isn't part of the value's fully qualified name:
class Class
{
public:
enum Enum
{
Value1,
Value2
};
};
// Yes
Class::Enum e = Class::Value1
// No
Class::Enum e = Class::Enum::Value1
but .NET syntax calls for the second version. So there's no benefit to a redundant value name.
I do it in C# to avoid the compiler issue of having the property name the same as its (enum) type, which I've found I'd liked to do in the past.
I have seen numerous developers postfixing variable names with a "List" when it's an array. What's the point of this and would you encourage this style? For example:
// Java
String[] fileList;
String file;
// PHP
$fileList = array();
$file = '';
The idea applies to any language with support for arrays.
The idea? Readability - you can tell the variable is a collection in one glance. This can be achieved with pluralizing the variable name (ie. files).
If the fact that the data type is a list is significant (assuming several different collection types), then using that postfix is the right thing to do (as opposed to simply being a collection).
I personally tend to pluralize variable names, using a list postfix only if it adds information or can't be inferred from the name otherwise (say a list of lists).
I think this is mostly a matter of taste. I tend to name things to reflect what they are or what they do. So if I have a collection or array of File instances, the variable would most probably named files, or have a more specific name if the context allows it. Naming an array of Files fileList is in my humble opinion plain wrong, because, at least in Java, an array is not a List. But then, the compiler won't complain...
More complex collections like a Map get names like keyToValue. So if I had a map which assigns teachers to classrooms this would be called teacherToRoom in my code. I hate grepping through the code to find out what the variables are meant to do, so I try to be as specific as needed with the names.
In conclusion it's all about correct code, and variable names can not influence this outcome from the compiler perspective. But they can very well affect the outcome when it comes to humans working with the code, so it's best to do whatever works for the majority of people working on a codebase.