Do you use singular or plural in names of arrays, maps, sets, etc.? - variables

I have a quick question that is not particular technical, but I sometimes wonder what's better ...
Do you use singular or plural in names of arrays, maps, sets, etc.? Example:
Singular
1 std::map<string,double> age;
2 age["diego maradonna"] = 49;
Plural
1 std::map<string,double> ages;
2 ages["diego maradonna"] = 49;
In the plural version, the second line isn't nice (because you're looking up the age, not the ages of Maradonna). In the singular version, the first line sounds kind of wrong (because the map contains many ages).

Singular for instances, plural for collections.

For maps, I will typically even go a step further and name them in terms of both their keys and values (ex. agesByPersonNames). This is especially helpful if you have a map of maps.

Plurals. I use the same kind of names for SQL tables. The case of:
ages["diego maradonna"] = 49;
should be read as "in the collection of ages, find me the one that belongs to maradonna and change it to 49"

I would use nameToAgeMap["diego maradonna"], so it's obvious what you put in (a name) and get out (an age), it reads nicely in assignments: nameToAgeMap["diego maradonna"] = 49; which could be read as "put 49 into the name-to-age map for Diego Maradonna".

Related

Kotlin functional programming keep reference of previous object in List

I have a list of Person objects which are related to each other with spouse relation in the order of which they appear in the list.
enum class Gender {
MAN, WOMAN
}
data class Person(val name: String, val age: Int, val gender: Gender)
In the list, each Person with Gender MAN is the spouse of the following Person with WOMAN Gender (and vice versa) and each entry in the list is followed by alternating genders with MAN gender be the first.
The list should ideally be like [MAN, WOMAN, MAN, WOMAN, MAN, WOMAN] (obviously it will be a list of Person objects for simplicity I am putting a list of Gender here) but it could also be like [WOMAN, MAN, WOMAN, MAN, WOMAN, MAN]. In the latter case, the first appearing WOMAN is the spouse of the last appearing MAN.
How this second case could be handled in kotlin by using functional programming.
My current approach involves checking if the first Person has a gender women then i remove the first and last objects in the list and then add them in the end but this is not fully a functional programming solution.
Anyone can guide me about that?
Thanks
What do you mean by fully functional approach?
Similar to what you mentioned, you can fix the order by a simple statement like this:
val correctList = if(list.first().gender == MAN) list else list.drop(1) + list.first()
If you want a more general approach, you can do something like this:
// separate the people into a list of gender=MAN and a list of everyone else
// the result is a Pair, so I'm destructuring that into two variables
val (men, women) = people.partition { it.gender == MAN }
// use zip to take a person from each list and combine them into a list of pairs
men.zip(women)
// use flatMap to turn each pair into a list of two people
// just using map would create a list of lists, flatMap flattens that into
// a single list of people, alternating gender=MAN, gender=WOMAN
.flatMap { it.toList() }
This way it doesn't matter how your original list is ordered, it can start with any element and you can have the different types completely mixed up - BABBAABA will still come out as ABABABAB. So it's a general way to combine mixed data streams - partition separates them into groups, and zip lets you take an element from each group and do something with them.
Here I'm just letting zip create Pairs, and then flatMap turns those back into an ordered list (if that's what you want). You could also do a forEach on each pair instead (say if you wanted to set a value on each Person to link them to each other), or zip can take a transform function too.
Also zip terminates when one of the lists runs out (e.g for AAA and BB you'll get two pairs) so this works for generating complete pairs of elements - if you also needed to handle elements without a "partner" you'd need to do a bit more work

AreValid or IsValid? Naming bools that refer to multiple items

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.

Are mixed type indexes acceptable in Neo4j?

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.

How to name a variable: numItems or itemCount?

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.

Collection naming convention

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.