views:

28

answers:

1

If I want to use the name baz defined in package foo|bar|quz, I've several choices:

  1. provide fbq as a short name for foo|bar|quz and use fbq|baz
    • use foo|bar|quz|baz
    • import baz from foo|bar|quz|baz and then use baz (or an alias given in the import process)
    • import all public symbols from foo|bar|quz|baz and then use baz

For the languages I know, my perception is that the best practice is to use the first two ways (I'll use one or the other depending on the specific package full name and the number of symbols I need from it). I'd use the third only in a language which doesn't provide the first and hunt for supporting tools to write the import statements. And in my opinion the fourth should be reserved to package designed with than import in mind, for instance if all exported symbols start with a prefix or contains the name of the package.

My questions:

  • what is in your opinion the best practice for your favorite languages?
  • what would you suggest in a new language?
  • what would you suggest in an old language adding such a feature?
A: 

In C# I use option 2, which makes sense because of the rich support of the development IDE. Since its common practice to declare the namespaces a the top of the code file (the imports you refer to in your bullet point) you can see at a glance what is being used by a given file.

I say the IDE support matters because it lets me see at a glance by tooltips where a given class being referenced in my code came from, and also lets me see which namespace declarations aren't actually being used and can be removed.

For an old language that did not have the IDE advantages described above, I'd probably lean towards number 3 so that you could still have terse code and avoid confusion as to where a given class comes from. I'd avoid option 1 personally because it seems like it would be too verbose.

Likewise for a new language, my decision would hinge on the IDE. If it has things available like what I described for C#, I'd go with option 2, otherwise option 3.

kekekela