how should I name array that holds widths of columns? I would use:
int[] columnsWidths;
but I saw in many places names like:
columnWidths
or
colWidths
Of course "widths of columns" is only an example.
Moreover, I think there is also another case, when 2 words are not 2 separate words, but create some kind of name, e.g.
class TableView
How in this case variable's name should look like?
TableView[] tableViews;
or
TableView[] tablesViews;
Read Code Complete. But there is no right or wrong answer -- choose what suits you and your colleagues and be consistent.
Related
I apologize if this has been asked before (I couldn't find anything).
I'm an extreme noob in Livecode, and I want to know if there is a way of programming a button to create many new, unique variables and assign a value to them. I apologize if this is a dumb question.
Usually you use an array for that. An array is basically a list of things, where each thing is associated with an "index". An index can be any word, so you can use an array like a dictionary, where you'd e.g. have French words as the index, and English words as the value, like:
put "cow" into myDictionary["vache"]
But you can also just use numbers as the keys and make them a numbered list:
put "cow" into allMyAnimals[1]
put "duck" into allMyAnimals[2]
In end effect, you create one variable and put several things in it. For example if you had a loop that calculated something (in this example a number +100) and you wanted to have variables containing all those numbers, but named with 100 less, you'd do something like:
repeat with x = 1 to 250
put x +100 into twoHundredFiftyNumbersFrom101[x]
end repeat
And to read the first one:
answer "the first number is" && twoHundredFiftyNumbersFrom101[1]
Or all of them:
repeat with x = 1 to 250
answer twoHundredFiftyNumbersFrom101[x]
end repeat
Or whatever. You could also use 'do' to build the lines of code as a string, but then you have to make sure your variable names are generated in a fashion that makes them valid identifiers (e.g. have no spaces in them, no special characters). An array key can be any valid string, and the compiler can optimize them, and you can treat them as a whole and pass them between handlers.
Or you can do this "in the clear" with a "do" construction:
on mouseUp
repeat with y = 1 to 10
get random(100)
do "put it into onTheFlyVariable" & y
end repeat
end mouseUp
Step through this handler and watch the variables assemble themselves.
This probably sounds like an obvious one for experienced coders but for me who codes only occasionally AreValid seems to get lost in the code. So I am tempted to use IsValid, as long as the name is in plural form e.g. AreUserInputsValid but what do the naming conventions say?
I think in the most languages it is preferred to use the non-plural notation. So you can define it like IsUserInputValid (Notice Input instead of Inputs).
Input can be considered as a 'group' and therefore can be named as with Is. This goes the same for array/List implementation IsArrayValid, still it can has more than 1 entries, yet you will 'group' it by the name of array.
I have a data set which includes a number of nodes, all of which labeled claim, which can have various properties (names P1, P2, etc., through P2000). Currently, each of the claim nodes can have only one of these properties, and each property has value, which can be of different types (i.e. P1 may be string, P2 may be float, P3 integer, etc.). I also need to be able to look up the nodes by any property (i.e. "find all nodes with P3 which equals to 42").
I have modeled it as nodes having property value and label according to the P property. Then I define schema index on label claim and property value. The lookup then would look something like:
MATCH (n:P569:claim) WHERE n.value = 42 RETURN n
My first question is - is this OK to have such index? Are mixed type indexes allowed?
The second question is that the lookup above works (though I'm not sure whether it uses index or not), but this doesn't - note the label order is switched:
neo4j-sh (?)$ MATCH (n:claim:P569) WHERE n.value>0 RETURN n;
IncomparableValuesException: Don't know how to compare that. Left: "113" (String); Right: 0 (Long)
P569 properties are all numeric, but there are string properties from other P-values one of which is "113". Somehow, even though I said the label should be both claim and P569, the "113" value is still included in the comparison, even though it has no P569 label:
neo4j-sh (?)$ MATCH (n:claim) WHERE n.value ="113" RETURN LABELS(n);
+-------------------+
| LABELS(n) |
+-------------------+
| ["claim","P1036"] |
| ["claim","P902"] |
+-------------------+
What is wrong here - why it works with one label order but not another? Can this data model be improved?
Let me at least try to side-step your question, there's another way you could model this that would resolve at least some of your problems.
You're encoding the property name as a label. Perhaps you want to do that to speed up looking up a subset of nodes where that property applies; still it seems like you're causing a lot of difficulty by shoe-horning incomparable data values all into the same property named "value".
What if, in addition to using these labels, each property was named the same as the value? I.e.:
CREATE (n:P569:claim { P569: 42});
You still get your label lookups, but by segregating the property names, you can guarantee that the query planner will never accidentally compare incomparable values in the way it builds an execution plan. Your query for this node would then be:
MATCH (n:P569:claim) WHERE n.P569 > 5 AND n.P569 < 40 RETURN n;
Note that if you know the right label to use, then you're guaranteed to know the right property name to use. By using properties of different names, if you're logging your data in such a way that P569's are always integers, you can't end up with that incomparable situation you have. (I think that's happening because of the particular way cypher is executing that query)
A possible downside here is that if you have to index all of those properties, it could be a lot of indexes, but still might be something to consider.
I think it makes sense to take a step back and think what you actually want to achieve, and why you have those 2000 properties in the first place and how you could model them differently in a graph?
Also make sure to just leave off properties you don't need and use coalesce() to provide the default.
I want to make a variable that is condiments that the customer wants.
I thought 'condimentCustomerWants' is okay
But I would never see variable name that contains relative pronouns in other's codes.
So I asked to my friends, and he recommended 'customerWantsCondiment', which is sentence.
Hmm.. which name is proper, good, and readable?
I'll throw desiredCondiments into the mix.
Depends on everyone's coding style really. i would do
requestedCondiment
desiredCondiment
preferredCondiment
condimentForCustomer
preferredCondimentForCustomer
wantedCondiment
and so on...
HOW you name your variables is entirely up to you, however they should always reflect what the variable is actually supposed to do.
If it is: 'Does the customer want a condiment', you'd want:
CustomerWantsCondiment (true/false value, probably a boolean)
If it is: 'Which condiment does the customer want?', you'd want:
CondimentCustomerWants (for example an int value)
They sound similar, but both have different meanings.
Whatever works best for you, really.
You may also want to adhere to a variable name convention, starting your variable name with a letter, that indicates the type of the variable. That way, you will know the type of a variable at a glance, without having to look for the actual definition.
Please note, that the introducing letter(s) are always lower case.
For example:
bool bCustomerWantsCondiment;
int iCustomerWantsCondiment;
char *sCustomerWantsCondiment;
etc.
For more information regarding the hungarian notation, please look here for example:
http://en.wikipedia.org/wiki/Hungarian_notation
Also, for readability, you should use the 'CamelCase' convention. That means, each time you begin a new word in the variable name, start it with a capital letter.
What is the right way to name a variable
int numItems;
vs.
int itemCount;
or constant:
public static final int MAX_NUM_ITEMS = 64;
vs.
public static final int MAX_ITEM_COUNT = 64;
In "Code Complete," Steve McConnell notes that "Number" is ambiguous. It could be a count, or an index, or some other number.
"But, because using Number so often
creates confusion, it's probably best
to sidestep the whole issue by using
Count to refer to a total number of sales and Index to refer to a
specific sale."
item_count or itemCount (there's a religious war brewing there, though)
For Java I would use itemCount and MAX_ITEM_COUNT. For Ruby, item_count and MAX_ITEM_COUNT. I tend not to use names that can be interpreted wrongly (numItems may be a shortcut for numerate_items or number_of_items), hence my choice. Whatever you decide, use it constantly.
It's a matter of personal preference, just make sure you are consistent throughout your code. If you're working with others check what's been done in existing code.
For the constant I would find MAX_ITEMS more logical than MAX_NUM_ITEMS or similar, it just sounds better to me.
It actually depends on you. The two types of naming conventions are
camelCase and snake_case
As you can identify from the naming, camel case has one small letter in the initial part of the variable followed by the Capital words
Eg itemCount.
snake case is a continuous word with an underscore ' _ ' in between the words
Eg item_count
As far as the naming is concerned, numItems is quite confusing for others to read. But itemCount is a good name for a counter variable
I've been wondering about this question too, and thought it interesting in all these answers that no one said just items, but I can see that would be a bad name perhaps if it's in a codebase that has objects or arrays, but maybe okay as like a field name in SQL.
But one downside I just realized to going with something like numItems is that if you have multiple similar fields and use anything with intellisense or autocomplete, there's a risk of accidentally using the wrong field, whereas item_count begins with the thing you're counting.