Align v/vids argument name?

[maelle]

It was vids for the estimate_ function, it's vids for closeness(), but it's v for betweenness() and edge_betweenness().

[szhorvat]

This should be cleaned up. I often complain about this, e.g. #692

[maelle]

What's the final state, what should the argument names be?

[maelle]

related #691

[szhorvat]

I don't have a strong feeling about v vs vids, but currently more functions seem to use vids. We should definitely not use nodes. One argument against vids is that it seems to suggest that the input should be numerical vertex IDs, while they can be names as well.

I collected some functions on #691, noting what parameter name they use.

Let's keep in mind that we also have e in edge_betweenness(). If we go with vids, this should be changed to eids. If we go with v this should be e.

[szhorvat]

We need to make a decision here and then stick with it.

As I said above, I do not have a strong opinion on what the name should be, only on that it should be consistent.

To push things forward, I propose using v with the reasoning that it's generic (does not imply integers) and simple. Please comment on whether you agree / disagree, or make counterproposals we can vote on.

Currently some functions use v (e.g. degree), some use vids (e.g. closeness), some use index (e.g. vertex_attr), some use nodes (e.g. alpha_centrality).

Some use context-specific names such as from and to. E.g. distances uses v and to while shortest_paths uses from and to. I suggest always using context-specific names when it makes sense, i.e. eventually transitioning distances to from/to as well.

Why is this decision urgent? While refactoring function for consistency is not urgent, we need a decision now so we can use consistent naming in newly added functions.

[maelle]

if we didn't have any renaming to do, I'd actually be in favor of something more explicit like vertices. 😅

[krlmlr]

vertices and from_vertices + to_vertices ?

[szhorvat]

As I said, I'll accept anything. Just pointing out some disadvantages:

• No current function uses vertices. Going with it will cause more inconvenience than any other choice.
• Our primary users are not developers but researchers. Spelling out everything is not the most productive approach in this context. If we are consistent, it will be clear to everyone with minimal experience that v means vertices. Learning this is a one-time cost. Having to type out vertices every time is a major inconvenience that continually affects people who use igraph—it's an ongoing cost. We need to support people who use igraph interactively at least as much as other packages depending on igraph.

[krlmlr]

We could switch to something like v and e if this consistently means the same for all functions. Can we do a survey across all functions before committing to such a change?

[maelle]

@szhorvat that's an interesting point. I'd assume many people use some sort of code editor with autocompletion (like RStudio IDE) but maybe not.