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.
Related
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.
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).
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 am generally not one to engage in subjective arguments over matters like variable naming, code formatting, etc. So I have no intention of starting an argument here.
I just came across this (old) blog post which recommends not prefixing member variable names:
Do not use a prefix for member
variables (_, m_, s_, etc.). If you
want to distinguish between local and
member variables you should use
"this." in C# and "Me." in VB.NET.
For C#, yeah, I get it: member variables can be lower camelCase, and public properties/methods can be PascalCase. But VB.NET is case-insensitive, so you can't really give a private member the same name as a public property except with a lower case first letter.
I've generally prefixed member variables with an underscore, but I've been told that's not idiomatic.
So really I'm just curious: how do you name your member variables in VB.NET? And is there a "standard" way?
I'm not asking because I believe there's a "right" way or because I particularly want to change my style, and certainly not because I have any desire to tell others they're "wrong." Like I said, I'm just curious.
It's personal preference, although there's widespread support for having some distinction. Even in C# I don't think there's one widely used convention.
Jeff Prosise says
As a matter of personal preference I typically prefix private fields with an underscore [in C#] ... This convention is used quite a lot in the .NET framework but it is not used throughout.
From the .NET Framework Design Guidelines 2nd Edition page 73.
Jeffrey Richter says
I make all my fields private and I prefix my instance fields with "m_" and my static fields with "s_" [in C#]
From the .NET Framework Design Guidelines 2nd Edition page 47. Anthony Moore (BCL team) also thinks using "m_" and "s_" is worth consideration, page 48.
I personally use m_ for member variables.
Although with automatic properties in VS 2010 I haven't needed to for any new code I've written recently.
I don’t like starting a line/name with an underscore since that always looks as if the line were indented by an additional space: it just makes the code unbalanced. Additionally, a lonely underscore is too inconspicuous for my taste: I prefer the identifiers to be clearly distinct.
Therefore, I periodically cycle between suffix underscore (e.g. example_) and prefix m_. I can’t decide which of those I prefer since I actually like neither. But the argument against prefix underscores partially also applies to suffix underscores.
But as you’ve remarked, some kind of distinction is necessary.
And as I’ve remarked elsewhere, I’ve had very bad experiences with case-only distinction in C# as well – it’s just too easy to confuse the names, and hence write into a private variable instead of the property. This matters if the property either checks or transforms the set value.
For that reason, I prefer to use some kind of prefix in C# as well.
I'm doing it like you.
Private _myVar as Object
Public Property MyVar() As Object
Get
Return Me._myVar
End Get
Set(ByVal value As Object)
Me._myVar = value
End Set
End Property
And in constructor
Public Sub New(myVar as object)
Me._myVar = myVar
End Sub
But I think that's a matter of taste.
The only time I use a prefix is with the private backing store for a public property. In these cases, the names are otherwise identical and most of the time the only place I'll ever reference the prefixed name is inside it's associated property. When I can finally use auto-implemented properties with VB.Net I won't even need to do that.
I do this in C# as well, on those instances when I can't just use an auto-implemented property. Better the _ prefix than varying the names only by case.
We use _ (underscore) to prefix our variables names. It's short and to the point...
Private _ID as integer
Public Property ID() As Integer
Get
Return _ID
End Get
Set(ByVal value As Integer)
_ID = value
End Set
End Property
Although a lot of the MS code seems to use m_* for private declarations, I save myself a character and just use _name for private members. My rules:
Private members are preceeded by an underscore
Public members (methods and properties) are PascalCase.
Parameters are camelCase.
Since I work in C#, having a parameter name with the same name as a property with different case is no problem. That won't work in VB, though.