Just a simple question, there aren't a lot of people I know that use Expression Trees so I don't see a lot of resources on how to name them. How would you name an expression variable? Pref. no Hungarian Notations.
For now I just go with:
var newItem = Expression.New(typeof(T));
var itemProperty = Expression.Property(newItem,propertyInfo);
I would call it newExpression and memberExpression perhaps.
To be honest though, I try to limit the number of expression variables I have (i'm content with really long expression declarations that span many lines), obviously parameterexpressions for parameters/variables i declare seperately and I name them as such (ie itemParameter, listVariable)
Related
Not really related to programming in general.
I don't know if this is a struggle for anybody, and there's probably an easy solution to this problem, but I couldn't find any elegant solutions.
Everyone knows that if you're a programmer, you should write readable code to save time and help yourself in the future, like giving variables better names instead of s or n.
For Example:
public void doSomething(Function<> functionToDo, int numberOfTimes)
instead of:
public void doIt(Function<> f, int n)
But sometimes, if I have a long variable name and I have to type it in an equation that makes me have to scroll right to see the whole thing, that can get frustrating.
So, my question is: Is there any way I can define a shortcut variable that doesn't affect runtime or memory?
like c++'s pre-proccesor statement #define: #define n numberOfTimes
Or, if there isn't solution to this at all, should I keep long variable names for the readability, or keep things short instead?
Any ideas are appreciated.
It's all about the context where an identifier is declared. For instance, if your function doIt was named doNTimes it would be perfectly fine to name the parameters f and n. Also, they are local to the function so you don't need to search for their documentation (which should be just before or after the function header). As you mention, in choosing a name there is also a tradeoff between identifier comprehensibility and expression comprehensibility; whereas a more descriptive name increases the former and decreases the latter the opposite holds true for a short name.
If you know that your identifier is going to be used in complex expressions it's a good idea to use a shorter name. A function call with side-effects on the other hand will (should) only be a single statement so then the name can be longer.
To summarize, I would say that it's a good idea to keep formal parameters and local variables short as that make expressions easy to comprehend; the documentation is right there in the function anyway, e.g.
public void doNTimes(Function<> f, int n); /** apply f n times */
Note: In a real scenario you would also need to provide the actual parameters of f.
I have seen an incredibly large number of variables in our codebase at work that are along the lines of myCounter or myClassVariable. Why?
I don't just see this at work, either. I see this in tutorials online, github, blogs, etc. I would understand if it's just a placeholder for an example, but otherwise I can't imagine it being a standard of any kind.
Is this a holdover from some old standard or is it just a bad practice that snuck in before code reviews were common place? Was it an ancestor to people's usage of the underscore to indicate a _ClassName?
Starting a variable name with my indicates that it is defined by the programmer rather than a predefined variable. In a statically typed language (with explicit types) it also prevents a name clash with the type name, for instance
Collection myCollection;
A my variable name should only be used in generic examples where the variable has no other interpretation.
It may also be worth mentioning that in the programming language Perl (since version 5 from 1994) the keyword my is used to declare a local variable, for instance
my $message = "hello there";
https://perldoc.perl.org/functions/my
I am wondering if there exists already some naming conventions for Ocaml, especially for names of constructors, names of variables, names of functions, and names for labels of record.
For instance, if I want to define a type condition, do you suggest to annote its constructors explicitly (for example Condition_None) so as to know directly it is a constructor of condition?
Also how would you name a variable of this type? c or a_condition? I always hesitate to use a, an or the.
To declare a function, is it necessary to give it a name which allows to infer the types of arguments from its name, for example remove_condition_from_list: condition -> condition list -> condition list?
In addition, I use record a lot in my programs. How do you name a record so that it looks different from a normal variable?
There are really thousands of ways to name something, I would like to find a conventional one with a good taste, stick to it, so that I do not need to think before naming. This is an open discussion, any suggestion will be welcome. Thank you!
You may be interested in the Caml programming guidelines. They cover variable naming, but do not answer your precise questions.
Regarding constructor namespacing : in theory, you should be able to use modules as namespaces rather than adding prefixes to your constructor names. You could have, say, a Constructor module and use Constructor.None to avoid confusion with the standard None constructor of the option type. You could then use open or the local open syntax of ocaml 3.12, or use module aliasing module C = Constructor then C.None when useful, to avoid long names.
In practice, people still tend to use a short prefix, such as the first letter of the type name capitalized, CNone, to avoid any confusion when you manipulate two modules with the same constructor names; this often happen, for example, when you are writing a compiler and have several passes manipulating different AST types with similar types: after-parsing Let form, after-typing Let form, etc.
Regarding your second question, I would favor concision. Inference mean the type information can most of the time stay implicit, you don't need to enforce explicit annotation in your naming conventions. It will often be obvious from the context -- or unimportant -- what types are manipulated, eg. remove cond (l1 # l2). It's even less useful if your remove value is defined inside a Condition submodule.
Edit: record labels have the same scoping behavior than sum type constructors. If you have defined a {x: int; y : int} record in a Coord submodule, you access fields with foo.Coord.x outside the module, or with an alias foo.C.x, or Coord.(foo.x) using the "local open" feature of 3.12. That's basically the same thing as sum constructors.
Before 3.12, you had to write that module on each field of a record, eg. {Coord.x = 2; Coord.y = 3}. Since 3.12 you can just qualify the first field: {Coord.x = 2; y = 3}. This also works in pattern position.
If you want naming convention suggestions, look at the standard library. Beyond that you'll find many people with their own naming conventions, and it's up to you to decide who to trust (just be consistent, i.e. pick one, not many). The standard library is the only thing that's shared by all Ocaml programmers.
Often you would define a single type, or a single bunch of closely related types, in a module. So rather than having a type called condition, you'd have a module called Condition with a type t. (You should give your module some other name though, because there is already a module called Condition in the standard library!). A function to remove a condition from a list would be Condition.remove_from_list or ConditionList.remove. See for example the modules List, Array, Hashtbl,Map.Make`, etc. in the standard library.
For an example of a module that defines many types, look at Unix. This is a bit of a special case because the names are mostly taken from the preexisting C API. Many constructors have a short prefix, e.g. O_ for open_flag, SEEK_ for seek_command, etc.; this is a reasonable convention.
There's no reason to encode the type of a variable in its name. The compiler won't use the name to deduce the type. If the type of a variable isn't clear to a casual reader from the context, put a type annotation when you define it; that way the information provided to the reader is validated by the compiler.
In the example below, what would you name the parameter given that it is used to initialize the property FromDate?
For class constructor methods, I like to have the name of the constructor parameter variable match the name of the property which is being initialized. For example, the parameter "fromDate" is used to initialize the module level variable "_FromDate" with the statement _FromDate = fromDate. Likewise, I could have alternatively written Me.FromDate = fromDate.
Proponents of C#'s case sensitivity would probably say that using a leading lower cased letter for the param variable name, which I believe is MS convention, is an acceptable approach to distinguish it from the Property of the same name but different casing.
However, VB is not case sensitive, which I generally appreciate. In the following example, I am using a param name that matches the property name, 'fromDate," and VB refers to the local instance when there is ambiguity. However, many would probably argue that this "ambiguity" introduces the opportunity for the developer to get confused and not realize which variable is being used. For example, my intent below was to have TWO params passed in, "fromDate" and "toDate" but I accidentily ommited one and as a result, the VB.NET did not warn me of the mistake because it assumed that the statement _ToDate = ToDate was equivalent to _ToDate = Me.ToDate instead of informing me that the variable on the right side of the assignment statement was undeclared.
Public Class Period
Property FromDate As Date
Property ToDate As Date
Public Sub New(ByVal fromDate As Date)
If fromDate > ToDate Then
Throw New ArgumentException("fromDate must be less than or equal to toDate")
End If
_FromDate = fromDate
_ToDate = ToDate
End Sub
End Class
So what is the best solution for VB.NET?
In my judgement, we should have a convention for prefixing all parameter variable with a prefix, but hasn't the use of prefixes been discouraged by Microsoft? For example:
Public Sub New(ByVal paramFromDate As Date, paramToDate As Date)
..or maybe it could be shortened to pFromDate, pToDate...
Whatever approach is taken, I feel that it should be a consistant approach that is used throughout the application.
What do you do?
Use the clearest code possible, which I would suggest is not a prefix. I think using the same name (first letter lowercased) is the clearest code. To avoid the problem encountered I'd rely on a tool, like compiler warnings, FxCop, or ReSharper to alert me that I'm assigning something to itself, since that is almost certainly a mistake in all scenarios.
I know this is against all Microsoft convention, but we use v_ for ByVal parameters, r_ for ByRef parameters and m_ for Module level variables. This allows you to have
m_FromDate = v_FromDate
And you can see straight away what is going on without needing to check the definitions of the variables. I think the biggest argument for non-Hungarian was that modern IDE's allow you to see type on hover over, and changing the type will leave incorrect variables. This scope prefix doesn't clash with that theory and also with CodeRush and ReSharper you can update every instance of a variable if it is required.
Personally, I prefer the _ prefix convention, but there are others I like too. In PL/SQL, my parameters are prefixed with in_, out_, or io_ for in, out, or in/out parameters.
I dislike using only upper and lower cases to distinguish in any language.
I get obsessed with the best names for arrays and variables that I use, I'll look up words in the thesaurus, dictionary, etc..
So I'm trying to name this array / structure:
$nameMe = array(
'392' => TRUE,
'234' => TRUE,
'754' => TRUE,
'464' => TRUE,
);
and it's used to check if that id has a certain property, like so
if(isset($name[$id])) {
doSomething();
}
Problem being I'm getting really long variable names like
$propertyNameArrayIdIndexed
Any ideas for how I can better name this particular function of array? or better names in general
$hasProperty[$id]
or
$isSomething[$id]
What is the property exactly?
$isOdd[$id]
$isWriteable[$id]
$hasAssociatedFile[$id]
Nothing wrong with long variable names, as long as they describe what the variable is doing, rather than how it's declared or defined.
I would drop "Array" from variable names.
A function that used the array may be named something like:
IsPropertyAvailable?($id)
or just
IsAvailable?($id)
when properly encapsulated.
So the associated data structure for querying could be named
$availableIds
Name variables by their "role" (in the UML sense) not their type. So, the proper name for the variable should depend very much on where and how its used. Simply knowing the type of data structure is not enough to give it an apt name. So, say that you have an enumeration of properties, each of which might be renderable as an icon. I'd leave out any indication of type, and declare it something like Set<Property> displayableIcons.
Even if you are using Hungarian notation, the actual type shouldn't be part of the name, but some type-qualifier or indication of an informal sub-type would be alright, like String b64JpgMugshot.
You want your code to read as much like plain English as possible. In plain English you'd end up with something like;
If the car is red
Do the red car stuff
So my recommendation is to avoid introducing unnecessary computerese ('array', 'property', 'index' etc.) into the naming of the variable. Your programming language is imposing "isset" on you. That's fine, that makes it clear that you have an array of booleans and means you can simply say;
if( isset(red[car_idx]) )
dosomething();
Summary: I think the array should be named simply as the property you are trying to test for. If the name of the property is a nice English language adjective that either applies to a noun or not, the boolean nature of the array is apparent even without isset(). So simply;
Red[], Oblong[], Large[]
Not IsRed[], IsOblong[], IsLarge[] because the extra "Is" in addition to the one in isset() is redundant.
propertyNameable, IspropertyNameable.
is your array only going to contain true? If so, I'd say change your data structure to something like this:
$availableIds = array(392, 234, 754, 464);
and then your if statements are much more meaningful:
if (in_array($myId, $availableIds)) { ... }
I just use dah[].
I would agree with other commenters that the question seems to lack proper context for proper concise naming, but something generic like able['foo'], enabled['bar'] or ready['ack'] may work.