Object naming convention
-
Hi guys, The question is of pure interest: how do you prefer naming a variable/parameter of type
Object? Most of the time it depends upon the logic of its usage, but not always. Sometimes you just want to express a generic entity:public byte[] Encrypt(Object x)
public byte[] Serialize(Object o)Its tempting to name
xasobjorobjToEncrypt, but it sounds more like a Hungarian notation. So how would you consider naming it? -
Hi guys, The question is of pure interest: how do you prefer naming a variable/parameter of type
Object? Most of the time it depends upon the logic of its usage, but not always. Sometimes you just want to express a generic entity:public byte[] Encrypt(Object x)
public byte[] Serialize(Object o)Its tempting to name
xasobjorobjToEncrypt, but it sounds more like a Hungarian notation. So how would you consider naming it?I try not to append the type to the object as it seems redundent. However, I append it when it makes it simpler as there may be multiple of the concept (different types, e.g. ValueInt and ValueString). As an example I may have an ICommand that will fire the "DoSomething" sequence. The ICommand will be named, "CommandDoSomething", which then calls the "DoSomething" private method. Keeps my XAML standardized as I know my commands will be Command[ACTION] then. Otherwise what you have is what I have done.
public byte[] Encrypt(Object encrypt)
public byte[] Serialize(Object serialize)in this particular case I might append a 'me' or a 'this', although I am not keen on using them ('me' and 'this'). In some cases it makes it more understandable though. As in this case because you are running the encryption on it.
public byte[] Encrypt(Object encryptMe)
public byte[] Serialize(Object serializeMe)Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
I try not to append the type to the object as it seems redundent. However, I append it when it makes it simpler as there may be multiple of the concept (different types, e.g. ValueInt and ValueString). As an example I may have an ICommand that will fire the "DoSomething" sequence. The ICommand will be named, "CommandDoSomething", which then calls the "DoSomething" private method. Keeps my XAML standardized as I know my commands will be Command[ACTION] then. Otherwise what you have is what I have done.
public byte[] Encrypt(Object encrypt)
public byte[] Serialize(Object serialize)in this particular case I might append a 'me' or a 'this', although I am not keen on using them ('me' and 'this'). In some cases it makes it more understandable though. As in this case because you are running the encryption on it.
public byte[] Encrypt(Object encryptMe)
public byte[] Serialize(Object serializeMe)Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
Thanks for suggestion, I was always tempted to append "to". In that case it would be
toEncrypt. But it scratches my ear badly. I really likeencryptbut its a verb, and it breaks the convention a little. As for yourCommandDoSomething.DoSomethingexample. I might have misunderstood you, but I prefer not appending action name to class name or viceversa://prefer
User client = User.Create();
//instead of
User client = User.CreateUser();Anyway, I believe its a matter of preference :) Regards
-
Hi guys, The question is of pure interest: how do you prefer naming a variable/parameter of type
Object? Most of the time it depends upon the logic of its usage, but not always. Sometimes you just want to express a generic entity:public byte[] Encrypt(Object x)
public byte[] Serialize(Object o)Its tempting to name
xasobjorobjToEncrypt, but it sounds more like a Hungarian notation. So how would you consider naming it?The only time I even append a type to an object name is when I'm naming controls. For example, Building_TextBox or Building_ComboBox. It comes in handy if you have a couple of controls related to the same thing.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
Hi guys, The question is of pure interest: how do you prefer naming a variable/parameter of type
Object? Most of the time it depends upon the logic of its usage, but not always. Sometimes you just want to express a generic entity:public byte[] Encrypt(Object x)
public byte[] Serialize(Object o)Its tempting to name
xasobjorobjToEncrypt, but it sounds more like a Hungarian notation. So how would you consider naming it?public byte[] Encrypt(Object sourceObject)
public byte[] Serialize(Object sourceOject)..although that would make 'em hard to distinguish from local variables.
public byte[] Encrypt(Object AsourceObject)
public byte[] Serialize(Object AsourceOject)The prefix stands for "Argument", but "Parameter" would be just as effective :) This gives you an assigment statement like
byte[] b = Encrypt(AsourceObject := ObjectThatWouldbeSerialized);
Bastard Programmer from Hell :suss:
-
Thanks for suggestion, I was always tempted to append "to". In that case it would be
toEncrypt. But it scratches my ear badly. I really likeencryptbut its a verb, and it breaks the convention a little. As for yourCommandDoSomething.DoSomethingexample. I might have misunderstood you, but I prefer not appending action name to class name or viceversa://prefer
User client = User.Create();
//instead of
User client = User.CreateUser();Anyway, I believe its a matter of preference :) Regards
Maybe your not a XAML programmer. The Public property would be
CommandDoSomethingand in the data context I would haveCommandDoSomething = new RelayCommand(() => DoSomething());
...
private void DoSomething()
{
}It is deffinately user preference. Unfortunately we all end up on teams and one persons preference is different from another. My rule there is code as they did (unless it is like sticking needles in your eyes). With that, I usually pick up on what ever the last naming convention of the system I was in. Then I am in a new system and use it. If I have the pleasure to start from scratch and make my own, I will likely use the naming convention of the last system I was in. Just because it is fresh.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
public byte[] Encrypt(Object sourceObject)
public byte[] Serialize(Object sourceOject)..although that would make 'em hard to distinguish from local variables.
public byte[] Encrypt(Object AsourceObject)
public byte[] Serialize(Object AsourceOject)The prefix stands for "Argument", but "Parameter" would be just as effective :) This gives you an assigment statement like
byte[] b = Encrypt(AsourceObject := ObjectThatWouldbeSerialized);
Bastard Programmer from Hell :suss:
Source. I like that. I have used that as well (I dropt the Object though). I then often use result for my local return.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
public byte[] Encrypt(Object sourceObject)
public byte[] Serialize(Object sourceOject)..although that would make 'em hard to distinguish from local variables.
public byte[] Encrypt(Object AsourceObject)
public byte[] Serialize(Object AsourceOject)The prefix stands for "Argument", but "Parameter" would be just as effective :) This gives you an assigment statement like
byte[] b = Encrypt(AsourceObject := ObjectThatWouldbeSerialized);
Bastard Programmer from Hell :suss:
Cool stuff, like the
sourceObjectsolution. Though, justsourcesounds even better. -
Hi guys, The question is of pure interest: how do you prefer naming a variable/parameter of type
Object? Most of the time it depends upon the logic of its usage, but not always. Sometimes you just want to express a generic entity:public byte[] Encrypt(Object x)
public byte[] Serialize(Object o)Its tempting to name
xasobjorobjToEncrypt, but it sounds more like a Hungarian notation. So how would you consider naming it? -
Hi guys, The question is of pure interest: how do you prefer naming a variable/parameter of type
Object? Most of the time it depends upon the logic of its usage, but not always. Sometimes you just want to express a generic entity:public byte[] Encrypt(Object x)
public byte[] Serialize(Object o)Its tempting to name
xasobjorobjToEncrypt, but it sounds more like a Hungarian notation. So how would you consider naming it?Source, Subject, Value, Victim, etc. ::shrug::
-
Hi guys, The question is of pure interest: how do you prefer naming a variable/parameter of type
Object? Most of the time it depends upon the logic of its usage, but not always. Sometimes you just want to express a generic entity:public byte[] Encrypt(Object x)
public byte[] Serialize(Object o)Its tempting to name
xasobjorobjToEncrypt, but it sounds more like a Hungarian notation. So how would you consider naming it?There's been excellent suggestions from the other folks around, like: source, data, item, target. One could argue that these are too vague, but the
objecttype is kind of vague in itself, so this time this issue is unescapable. I think that, as long as a noun or noun phrase is used, and the argument is named according to its role in the process carried out by the method, everything should be fine (granted that casing and other details of the chosen naming convention are complied with). -
There's been excellent suggestions from the other folks around, like: source, data, item, target. One could argue that these are too vague, but the
objecttype is kind of vague in itself, so this time this issue is unescapable. I think that, as long as a noun or noun phrase is used, and the argument is named according to its role in the process carried out by the method, everything should be fine (granted that casing and other details of the chosen naming convention are complied with).Good point.
-
Hi guys, The question is of pure interest: how do you prefer naming a variable/parameter of type
Object? Most of the time it depends upon the logic of its usage, but not always. Sometimes you just want to express a generic entity:public byte[] Encrypt(Object x)
public byte[] Serialize(Object o)Its tempting to name
xasobjorobjToEncrypt, but it sounds more like a Hungarian notation. So how would you consider naming it?You should name the parameter in such a way that the user of the method can see what it is (i.e. what's going to be done with it and what limitations there are on what they can pass). So if it really is a totally generic object, I see nothing wrong with calling the parameter 'object' (or 'obj' or 'o' depending on how professional you're being at the time). A more common situation is probably
public byte[] Encrypt(IDataSource dataSource)
... or similar interface-parameter declarations where the name can match the type because you really can pass any instance of that type. I also like the word 'source' for parameters that are going to be transformed into a new format. My code is full of this type of declaration because I like to make methods as generic as reasonably possible.
-
I try not to append the type to the object as it seems redundent. However, I append it when it makes it simpler as there may be multiple of the concept (different types, e.g. ValueInt and ValueString). As an example I may have an ICommand that will fire the "DoSomething" sequence. The ICommand will be named, "CommandDoSomething", which then calls the "DoSomething" private method. Keeps my XAML standardized as I know my commands will be Command[ACTION] then. Otherwise what you have is what I have done.
public byte[] Encrypt(Object encrypt)
public byte[] Serialize(Object serialize)in this particular case I might append a 'me' or a 'this', although I am not keen on using them ('me' and 'this'). In some cases it makes it more understandable though. As in this case because you are running the encryption on it.
public byte[] Encrypt(Object encryptMe)
public byte[] Serialize(Object serializeMe)Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
I like to
pub byte[] Encrypt(object aValue)
where a is for argument I usually do this for class members
int iVariableName
string sVariableName
byte [] byData
sometimes ill append an 's' to arrays
string [] sNames
Common .net objects I like to turn to an acronym FolderBrowserDialog - fbd SaveFileDialog - sfd StringBuilder - sb Socket - soc or cli The result of a method is usually called result no matter what type.